cptbstd 0 Posted February 9, 2017 Share Posted February 9, 2017 (edited) Using arr 3 on iis 8 rewrite reverse proxy.was working a few revisions ago.now when trying to stream a video via the reverse proxy the url is =https://emby.mydomain.co.uk/web/tv.html?topParentId=7c6b1294b30d4c722993e4036d0425ac just hangs with the art in the background. when not using reverse proxy the url ishttps://mydomain.co.uk:8920/web/videoosd.html Apple TV4 and IOS work fine. ffmpeg-transcode-ea7e8710-67c6-45b5-87d7-d855fd7f5e49.txt ffmpeg-transcode-615d6d08-bcec-433f-807b-fce519b886a6.txt web.config.txt server-63622195200.txt Edited February 10, 2017 by cptbstd Link to comment Share on other sites More sharing options...
Luke 36879 Posted February 9, 2017 Share Posted February 9, 2017 hi @cpybstd, the best thing to do is provide the information requested in how to report a problem. thanks ! Link to comment Share on other sites More sharing options...
mobamoba 12 Posted March 3, 2018 Share Posted March 3, 2018 I know this is an older thread, but I have the exact same issue behind an IIS reverse proxy - nothing plays. The file plays fine everywhere else using Emby. Here are the relevant part of my logs which will hopefully point to a solution: 2018-03-03 06:48:31.750 Info HttpResultFactory: Transmit file R:\Recorded TV\Sorted\REAL Sports with Bryant Gumbel\Season 24\Real Sports with Bryant Gumbel Ep 251 (February 2018)-thumb.jpg 2018-03-03 06:48:31.750 Info HttpResultFactory: Transmit file R:\Recorded TV\Sorted\REAL Sports with Bryant Gumbel\Season 24\Real Sports with Bryant Gumbel Ep 251 (February 2018)-thumb.jpg 2018-03-03 06:48:31.751 Info HttpServer: HTTP Response 200 to MYDOMAINIP:57390. Time: 6ms. http://192.168.1.164:8096/Items/d70ff83a5a2b545176b42f6607acec18/Images/Primary?maxHeight=450&tag=6f686abcb319af2f670ba30aa19f76cc&quality=90 2018-03-03 06:48:31.751 Info HttpServer: HTTP Response 200 to MYDOMAINIP:57391. Time: 6ms. http://192.168.1.164:8096/Items/d70ff83a5a2b545176b42f6607acec18/Images/Primary/0?maxWidth=1920&tag=6f686abcb319af2f670ba30aa19f76cc&quality=90 2018-03-03 06:48:31.751 Info HttpServer: HTTP Response 200 to MYDOMAINIP:57392. Time: 15ms. http://192.168.1.164:8096/Shows/0f35783931ad3c4b011551635df92b3c/Episodes?SeasonId=9f8e0f216e179f22d6dcc7d364ed56ee&UserId=cafaf763b2c64b7fa7bfc3ab46797135&Fields=ItemCounts%2CPrimaryImageAspectRatio%2CBasicSyncInfo%2CCanDelete 2018-03-03 06:48:34.822 Info HttpServer: HTTP POST http://192.168.1.164:8096/Items/d70ff83a5a2b545176b42f6607acec18/PlaybackInfo?UserId=cafaf763b2c64b7fa7bfc3ab46797135&StartTimeTicks=11873461020&AutoOpenLiveStream=true&AudioStreamIndex=1&MediaSourceId=d70ff83a5a2b545176b42f6607acec18&MaxStreamingBitrate=646153846. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 2018-03-03 06:48:34.942 Info App: User policy for Matt. EnablePlaybackRemuxing: True EnableVideoPlaybackTranscoding: True EnableAudioPlaybackTranscoding: True 2018-03-03 06:48:34.963 Info App: Profile: Unknown Profile, Path: R:\Recorded TV\Sorted\REAL Sports with Bryant Gumbel\Season 24\Real Sports with Bryant Gumbel Ep 251 (February 2018).mp4, isEligibleForDirectPlay: True, isEligibleForDirectStream: True 2018-03-03 06:48:34.994 Info App: Profile: Unknown Profile, Path: R:\Recorded TV\Sorted\REAL Sports with Bryant Gumbel\Season 24\Real Sports with Bryant Gumbel Ep 251 (February 2018).mp4, isEligibleForDirectPlay: True, isEligibleForDirectStream: True 2018-03-03 06:48:34.994 Info App: Profile: Unknown Profile, Path: R:\Recorded TV\Sorted\REAL Sports with Bryant Gumbel\Season 24\Real Sports with Bryant Gumbel Ep 251 (February 2018).mp4, isEligibleForDirectPlay: True, isEligibleForDirectStream: True 2018-03-03 06:48:35.005 Info HttpServer: HTTP Response 200 to MYDOMAINIP:57391. Time: 183ms. http://192.168.1.164:8096/Items/d70ff83a5a2b545176b42f6607acec18/PlaybackInfo?UserId=cafaf763b2c64b7fa7bfc3ab46797135&StartTimeTicks=11873461020&AutoOpenLiveStream=true&AudioStreamIndex=1&MediaSourceId=d70ff83a5a2b545176b42f6607acec18&MaxStreamingBitrate=646153846 2018-03-03 06:48:35.058 Info HttpServer: HTTP GET http://192.168.1.164:8096/Items/0f35783931ad3c4b011551635df92b3c/Images/Backdrop?quality=100&tag=e929a994e8587b62fd277db73c64674f. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 2018-03-03 06:48:35.058 Info HttpResultFactory: Transmit file R:\Recorded TV\Sorted\REAL Sports with Bryant Gumbel\fanart.jpg 2018-03-03 06:48:35.059 Info HttpServer: HTTP Response 200 to MYDOMAINIP:57391. Time: 1ms. http://192.168.1.164:8096/Items/0f35783931ad3c4b011551635df92b3c/Images/Backdrop?quality=100&tag=e929a994e8587b62fd277db73c64674f 2018-03-03 06:48:35.334 Info HttpServer: HTTP GET http://192.168.1.164:8096/Videos/d70ff83a5a2b545176b42f6607acec18/stream.mov?Static=true&mediaSourceId=d70ff83a5a2b545176b42f6607acec18&deviceId=764292a9cdc57021e0b90ff20882b6b5b22aa035&Tag=38295a92f6cdebd42ec85584bfb08dff. Connection=Keep-Alive, Accept=*/*, Accept-Language=en-US,en;q=0.9, Host=192.168.1.164:8096, Max-Forwards=10, Referer=https://emby.MYDOMAIN.com/web/itemdetails.html?id=d70ff83a5a2b545176b42f6607acec18&context=home&serverId=8b3456aed8154e4a896526b3b91ea4b9, Range=bytes=0-, User-Agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36, X-Original-URL=/Videos/d70ff83a5a2b545176b42f6607acec18/stream.mov?Static=true&mediaSourceId=d70ff83a5a2b545176b42f6607acec18&deviceId=764292a9cdc57021e0b90ff20882b6b5b22aa035&api_key=5abab39256514736a400f8e0ac215393&Tag=38295a92f6cdebd42ec85584bfb08dff, X-Forwarded-For=MYDOMAINIP:57391, X-ARR-SSL=4096|256|C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3|CN=MYDOMAIN.com, X-ARR-LOG-ID=e40d4dda-baa7-4f96-9144-c118eb03c07e 2018-03-03 06:48:35.422 Info HttpResultFactory: Setting range response values for R:\Recorded TV\Sorted\REAL Sports with Bryant Gumbel\Season 24\Real Sports with Bryant Gumbel Ep 251 (February 2018).mp4. RangeRequest: bytes=0- Content-Length: 1562637078, Content-Range: bytes 0-1562637077/1562637078 2018-03-03 06:48:35.425 Info HttpResultFactory: Transmit file R:\Recorded TV\Sorted\REAL Sports with Bryant Gumbel\Season 24\Real Sports with Bryant Gumbel Ep 251 (February 2018).mp4 2018-03-03 06:48:35.545 Info HttpServer: HTTP GET http://192.168.1.164:8096/Videos/d70ff83a5a2b545176b42f6607acec18/stream.mov?Static=true&mediaSourceId=d70ff83a5a2b545176b42f6607acec18&deviceId=764292a9cdc57021e0b90ff20882b6b5b22aa035&Tag=38295a92f6cdebd42ec85584bfb08dff. Connection=Keep-Alive, Accept=*/*, Accept-Language=en-US,en;q=0.9, Host=192.168.1.164:8096, If-Range="42a19affff4d98c5be7b3396c0b346e0", Max-Forwards=10, Referer=https://emby.MYDOMAIN.com/web/itemdetails.html?id=d70ff83a5a2b545176b42f6607acec18&context=home&serverId=8b3456aed8154e4a896526b3b91ea4b9, Range=bytes=1558708224-1562640383, User-Agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36, X-Original-URL=/Videos/d70ff83a5a2b545176b42f6607acec18/stream.mov?Static=true&mediaSourceId=d70ff83a5a2b545176b42f6607acec18&deviceId=764292a9cdc57021e0b90ff20882b6b5b22aa035&api_key=5abab39256514736a400f8e0ac215393&Tag=38295a92f6cdebd42ec85584bfb08dff, X-Forwarded-For=MYDOMAINIP:57390, X-ARR-SSL=4096|256|C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3|CN=MYDOMAIN.com, X-ARR-LOG-ID=1285333a-80bd-4a88-bf67-de9e71995204 2018-03-03 06:48:35.547 Info HttpResultFactory: Setting range response values for R:\Recorded TV\Sorted\REAL Sports with Bryant Gumbel\Season 24\Real Sports with Bryant Gumbel Ep 251 (February 2018).mp4. RangeRequest: bytes=1558708224-1562640383 Content-Length: 3932160, Content-Range: bytes 1558708224-1562640383/1562637078 2018-03-03 06:48:35.554 Info HttpServer: HTTP Response 500 to MYDOMAINIP:57391. Time: 221ms. http://192.168.1.164:8096/Videos/d70ff83a5a2b545176b42f6607acec18/stream.mov?Static=true&mediaSourceId=d70ff83a5a2b545176b42f6607acec18&deviceId=764292a9cdc57021e0b90ff20882b6b5b22aa035&Tag=38295a92f6cdebd42ec85584bfb08dff 2018-03-03 06:48:35.596 Info HttpServer: HTTP Response 206 to MYDOMAINIP:57390. Time: 51ms. http://192.168.1.164:8096/Videos/d70ff83a5a2b545176b42f6607acec18/stream.mov?Static=true&mediaSourceId=d70ff83a5a2b545176b42f6607acec18&deviceId=764292a9cdc57021e0b90ff20882b6b5b22aa035&Tag=38295a92f6cdebd42ec85584bfb08dff Link to comment Share on other sites More sharing options...
mobamoba 12 Posted March 3, 2018 Share Posted March 3, 2018 (edited) Digging a little deeper into, it appears that when Emby is accessed behind the IIS reverse proxy, it thinks I'm using a mobile device even though I'm not (it's just a regular browser on a regular computer). Since I'm not Emby Premiere, authorization fails and thus playback fails. Why does Emby think I'm playing from mobile when I'm accessing through a reverse proxy and, more importantly, what's needed to prevent Emby from misidentifying this device? Thanks. BTW I've tried this through Chrome, Edge, and Firefox; when I access using normal port 8920, all is fine and playback starts; when I access via my IIS reverse proxy through same browsers, Emby decides I'm accessing from a mobile device and playback fails. Edited March 3, 2018 by mobamoba Link to comment Share on other sites More sharing options...
Luke 36879 Posted March 3, 2018 Share Posted March 3, 2018 @@pir8radio may have some tips. Link to comment Share on other sites More sharing options...
pir8radio 1289 Posted March 3, 2018 Share Posted March 3, 2018 (edited) Digging a little deeper into, it appears that when Emby is accessed behind the IIS reverse proxy, it thinks I'm using a mobile device even though I'm not (it's just a regular browser on a regular computer). Since I'm not Emby Premiere, authorization fails and thus playback fails. Why does Emby think I'm playing from mobile when I'm accessing through a reverse proxy and, more importantly, what's needed to prevent Emby from misidentifying this device? Thanks. BTW I've tried this through Chrome, Edge, and Firefox; when I access using normal port 8920, all is fine and playback starts; when I access via my IIS reverse proxy through same browsers, Emby decides I'm accessing from a mobile device and playback fails. EDIT: I didn't read your first post, oops. I just noticed your using IIS RP... thats a tough one to get working correctly with emby.... I actually switched to nginx from IIS ARR.. is there an option here to do that? If not it will be a long road to figure out the headers and fix your IIS config. Edited March 3, 2018 by pir8radio Link to comment Share on other sites More sharing options...
mobamoba 12 Posted March 3, 2018 Share Posted March 3, 2018 It's IIS not Nginx. Link to comment Share on other sites More sharing options...
cptbstd 0 Posted March 3, 2018 Author Share Posted March 3, 2018 Can you post your iis rules? Link to comment Share on other sites More sharing options...
mobamoba 12 Posted March 3, 2018 Share Posted March 3, 2018 My rules are super simple - it's a straight-up reverse proxy (https://emby.mydomain.com routes to 192.x.x.x:8096 and back again). Per this post, I added the HTTP_ACCEPT_ENCODING variable - https://emby.media/community/index.php?/topic/5923-using-iis-or-apache-web-frontend/?p=149166 In fact, other than adjusting the names to refer to my website and my LAN IP, it's exactly the same as that post. But where in the process is Emby deciding the request is coming from a Mobile device rather than a browser? Because that misidentification is really the issue here. Link to comment Share on other sites More sharing options...
mobamoba 12 Posted March 3, 2018 Share Posted March 3, 2018 (edited) Okay so did some more digging here in my browser Developer Tools. If the content type is identified as mp2t, it plays fine. If it's identified as mp4, it chokes and does nothing. This is irrespective of the actual content type. As best I can gather (and I may be wrong here), if the codec is H264 and the container is mp4, it identifies as mp4 and won't play. Any other combo of codec and container identifies as mp2t and plays fine. No clue if this is helpful but thought I'd pass it along. ETA: This is definitely the problem. I did the following experiment. I took an H264 in MP4 container and copied the audio and video to an MKV container (copied, not reencoded so exact same audio and video just a different container). The MKV played fine and the MP4 couldn't play at all. So... I don't know. An MP4 in an MP4 container won't play over Emby Webplayer in an IIS Reverse Proxy. Edited March 3, 2018 by mobamoba Link to comment Share on other sites More sharing options...
Dani_ 1 Posted March 4, 2018 Share Posted March 4, 2018 You need too setup your reverse proxy for wss:// or it wont work for playback on the website. I have done this with ngnix, i had try it on IIS but this didnt work well. Link to comment Share on other sites More sharing options...
Luke 36879 Posted March 4, 2018 Share Posted March 4, 2018 You don't need wss:// for playback, just for remote control. Link to comment Share on other sites More sharing options...
pir8radio 1289 Posted March 4, 2018 Share Posted March 4, 2018 Okay so did some more digging here in my browser Developer Tools. If the content type is identified as mp2t, it plays fine. If it's identified as mp4, it chokes and does nothing. This is irrespective of the actual content type. As best I can gather (and I may be wrong here), if the codec is H264 and the container is mp4, it identifies as mp4 and won't play. Any other combo of codec and container identifies as mp2t and plays fine. No clue if this is helpful but thought I'd pass it along. ETA: This is definitely the problem. I did the following experiment. I took an H264 in MP4 container and copied the audio and video to an MKV container (copied, not reencoded so exact same audio and video just a different container). The MKV played fine and the MP4 couldn't play at all. So... I don't know. An MP4 in an MP4 container won't play over Emby Webplayer in an IIS Reverse Proxy. Look into http_range and http_if_range headers, I recall having a similar issue when using IIS. Link to comment Share on other sites More sharing options...
mobamoba 12 Posted March 4, 2018 Share Posted March 4, 2018 I don't see either of those as server variables on Server 2016. Would they be called something else maybe? Link to comment Share on other sites More sharing options...
pir8radio 1289 Posted March 7, 2018 Share Posted March 7, 2018 these are headers that are probably being stripped when running through your ARR/IIS reverse proxy. Link to comment Share on other sites More sharing options...
mobamoba 12 Posted March 7, 2018 Share Posted March 7, 2018 Does Emby confirm whether or not the server accepts range headers before sending them? Link to comment Share on other sites More sharing options...
Luke 36879 Posted March 7, 2018 Share Posted March 7, 2018 What server? Emby does't interact with other severs, except via plugins. If you're referring to responding to client requests, yes we check if a Range request header is supplied before sending back partial results. Link to comment Share on other sites More sharing options...
pir8radio 1289 Posted March 8, 2018 Share Posted March 8, 2018 (edited) Does Emby confirm whether or not the server accepts range headers before sending them? When playing an MP4 your should see the request headers, here is me playing an mp4 and seeking to a specific point. Anyway, this is what I recall (its been a while) that kept me from playing mp4's when using iis arr. Also if i recall correctly if the headers are stripped the whole video has to download before it starts playing.. so let it sit for a long time and see if it starts playing, this could also be an indication that some headers were stripped. Edited March 8, 2018 by pir8radio Link to comment Share on other sites More sharing options...
Luke 36879 Posted March 8, 2018 Share Posted March 8, 2018 yes that's exactly what we check for. Link to comment Share on other sites More sharing options...
mobamoba 12 Posted March 8, 2018 Share Posted March 8, 2018 (edited) My mp4 request headers look like this. Does this help narrow the problem? Or point to a solution? Thanks. And yes after an excessively long wait, it eventually started playing. So I guess the question is do you know how to add back the http range requests to IIS using ARR since at some point Microsoft stripped those variables out or put them somewhere else? Accept: */* Accept-Encoding: identity;q=1, *;q=0 Accept-Language: en-US,en;q=0.9 Connection: keep-alive Host: x.x.com If-Modified-Since: Thu, 03 Nov 2016 16:26:33 GMT If-None-Match: "6ff4c315eb353320d4c85482a8c5f303" Range: bytes=558039040-558087227 Referer: https://x.x.com/web/itemdetails.html?id=xxxxxx&context=home&serverId=xxxxx User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 Query String Parametersview sourceview URL encoded Edited March 8, 2018 by mobamoba Link to comment Share on other sites More sharing options...
pir8radio 1289 Posted March 8, 2018 Share Posted March 8, 2018 My mp4 request headers look like this. Does this help narrow the problem? Or point to a solution? Thanks. And yes after an excessively long wait, it eventually started playing. So I guess the question is do you know how to add back the http range requests to IIS using ARR since at some point Microsoft stripped those variables out or put them somewhere else? Accept: */* Accept-Encoding: identity;q=1, *;q=0 Accept-Language: en-US,en;q=0.9 Connection: keep-alive Host: x.x.com If-Modified-Since: Thu, 03 Nov 2016 16:26:33 GMT If-None-Match: "6ff4c315eb353320d4c85482a8c5f303" Range: bytes=558039040-558087227 Referer: https://x.x.com/web/itemdetails.html?id=xxxxxx&context=home&serverId=xxxxx User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 Query String Parametersview sourceview URL encoded I'm not sure if I ever put in the time to figuring this out with IIS... I think this is one of the reasons I moved to nginx... I can tell you how to fix it in nginx... but that doesnt help you... Maybe one of the IIS guru's can help... I'll also look through my old IIS rules and see if I ever found a solution. Link to comment Share on other sites More sharing options...
mobamoba 12 Posted March 8, 2018 Share Posted March 8, 2018 Thanks I appreciate it. I'm sort of stuck with IIS because of MS Exchange and its IIS backend. Link to comment Share on other sites More sharing options...
pir8radio 1289 Posted March 8, 2018 Share Posted March 8, 2018 Thanks I appreciate it. I'm sort of stuck with IIS because of MS Exchange and its IIS backend. I didn't see anything in my old IIS rules, but I did find some notes and bookmarks from when I was troubleshooting this issue... might help? https://serverfault.com/questions/757930/iis-application-request-routing-changes-206-partial-content-to-200 https://groggyman.com/2014/10/02/resolving-http-error-416-requested-range-not-satisfiable-iis-7-5-example/ for the above link my notes said "instead of "NONE" enter "bytes"" That's all I have buddy, sorry I couldn't be of more help.. Link to comment Share on other sites More sharing options...
mobamoba 12 Posted March 9, 2018 Share Posted March 9, 2018 (edited) I totally appreciate your help - with Nginx or Apache it's so much easier, but with IIS it's a difficult mess (thanks Microsoft!) so any pointers are valuable. From my browsing around the web, it looks like things like range requests are part of ASP.NET and debugging that to find out where it's not connecting properly with Emby is way beyond anything I know how to do. Edited March 9, 2018 by mobamoba Link to comment Share on other sites More sharing options...
plessers@gmail.com 24 Posted October 30, 2019 Share Posted October 30, 2019 Hello everyone. @@mobamoba, @@Luke, has anyone found a solution for this? Dealing with the same problem. If I go to my emby-server on local network: http://192.168.4.15:8096/web/index.html#!/home.html I can see If I go to the same server via IIS ARR I can see It seems be that in this case 1. browser tries to download whole file 2. times out and swithes to transcoding In my case, my web.config of my IIS for this website is: <?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <rewrite> <rules> <clear /> <rule name="Let's Encrypt" stopProcessing="true"> <match url="(.well-known/acme-challenge/*)" /> <conditions logicalGrouping="MatchAll" trackAllCaptures="false" /> <action type="None" /> </rule> <rule name="Redirect to HTTPS" enabled="false" stopProcessing="true"> <match url="(.*)" /> <conditions> <add input="{HTTPS}" pattern="^OFF$" /> </conditions> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Temporary" /> </rule> <rule name="ReverseProxy (HOMESERVER)" enabled="true" stopProcessing="true"> <match url="(.*)" /> <conditions logicalGrouping="MatchAll" trackAllCaptures="false" /> <action type="Rewrite" url="http://192.168.4.15:8096/{R:1}" /> </rule> </rules> </rewrite> <caching enabled="false" enableKernelCache="false" /> <httpProtocol> <customHeaders> <add name="Accept-Bytes" value="none" /> </customHeaders> </httpProtocol> </system.webServer> </configuration> And for my local variables, I have HTTP_IF_RANGE HTTP_RANGE HTTP_SEC_WEBSOCKET_EXTENSIONS HTTP_X_FORWARDED_FOR HTTP_X_FORWARDED_PROTO HTTP_X_FORWARDED_PROTOCOL HTTP_X_ORIGINAL_HOST HTTP_X_PRIVATE_TOKEN HTTP_X_REAL_IP But this config seems NOT to work. Does anybody has good documentation how to configure my IIS Application Request Routing (ARR)? Any help is appreciated! Kind regards, Bart Plessers PS. I will migrate to NGIX, but in transition period, It would be lovely to have above config working. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now