Jump to content

IIS ARR 3

cptbstd

By cptbstd
in General/Windows

 Share

Recommended Posts

cptbstd

cptbstd 0

Posted
Posted (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 is
https://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

post-76669-0-02619200-1486720950_thumb.jpg

post-76669-0-69424400-1486720954_thumb.jpg

server-63622195200.txt

Edited by cptbstd
  • 1 year later...
mobamoba

mobamoba 12

Posted
Posted

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: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.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

 

mobamoba

mobamoba 12

Posted
Posted (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 by mobamoba
pir8radio

pir8radio 1312

Posted
Posted (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 by pir8radio
mobamoba

mobamoba 12

Posted
Posted

It's IIS not Nginx.

cptbstd

cptbstd 0

Posted
  • Author
Posted

Can you post your iis rules?

mobamoba

mobamoba 12

Posted
Posted

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.

mobamoba

mobamoba 12

Posted
Posted (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 by mobamoba
Dani_

Dani_ 1

Posted
Posted

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.

Luke Emby Team

Luke 42078

Posted
Posted

You don't need wss:// for playback, just for remote control.

pir8radio

pir8radio 1312

Posted
Posted

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.  

mobamoba

mobamoba 12

Posted
Posted

I don't see either of those as server variables on Server 2016. Would they be called something else maybe?

pir8radio

pir8radio 1312

Posted
Posted

these are headers that are probably being stripped when running through your ARR/IIS reverse proxy.   

mobamoba

mobamoba 12

Posted
Posted

Does Emby confirm whether or not the server accepts range headers before sending them?

Luke Emby Team

Luke 42078

Posted
Posted

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.

pir8radio

pir8radio 1312

Posted
Posted (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. 

 

5aa087f7c1aab_Capture.png

Edited by pir8radio
Luke Emby Team

Luke 42078

Posted
Posted

yes that's exactly what we check for.

mobamoba

mobamoba 12

Posted
Posted (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?

 

    1. Accept:
      */*
    2. Accept-Encoding:
      identity;q=1, *;q=0
    3. Accept-Language:
      en-US,en;q=0.9
    4. Connection:
      keep-alive
    5. Host:
      x.x.com
    6. If-Modified-Since:
      Thu, 03 Nov 2016 16:26:33 GMT
    7. If-None-Match:
      "6ff4c315eb353320d4c85482a8c5f303"
    8. Range:
      bytes=558039040-558087227
    9. Referer:
    10. 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
  2. Query String Parametersview sourceview URL encoded
Edited by mobamoba
pir8radio

pir8radio 1312

Posted
Posted

 

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?

 

    1. Accept:
      */*
    2. Accept-Encoding:
      identity;q=1, *;q=0
    3. Accept-Language:
      en-US,en;q=0.9
    4. Connection:
      keep-alive
    5. Host:
      x.x.com
    6. If-Modified-Since:
      Thu, 03 Nov 2016 16:26:33 GMT
    7. If-None-Match:
      "6ff4c315eb353320d4c85482a8c5f303"
    8. Range:
      bytes=558039040-558087227
    9. Referer:
    10. 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
  2. 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. 

mobamoba

mobamoba 12

Posted
Posted

Thanks I appreciate it. I'm sort of stuck with IIS because of MS Exchange and its IIS backend.

pir8radio

pir8radio 1312

Posted
Posted

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..

mobamoba

mobamoba 12

Posted
Posted (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 by mobamoba
  • 1 year later...
plessers@gmail.com

plessers@gmail.com 32

Posted
Posted
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:
 
I can see
5db994a702dd3_30102019143705.png
 
If I go to the same server via IIS ARR
I can see
5db994c0ac93e_30102019144235.png
 
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:
5db99588f16e8_30102019145136.png
 
 
<?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

5db99653d9745_30102019145447.png

 

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.

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...