Strange problem: Playback stops after a few minutes – Device limit?

[Gecko 61]

On 10/21/2022 at 3:15 PM, Luke said:

Yes when transcoding it gets sliced into segments. That jump could be from seeking. Why do you think it was zero bytes?

I was not seeking at that moment, I let the movie play for itself. 200 0 means http 200 code 0 bytes in my nginx logs.

[Luke 37022]

Have you compared your setup to this?

 

[K22R8CT 24]

It's possible but unlikely that an issue with @nSGecko's nginx setup is causing the same problem I'm seeing without nginx and specific to the same browser(s).

[Gecko 61]

20 hours ago, Luke said:

Have you compared your setup to this?

 

I followed this guide closely yes but as K22R8CT said, it's also happening locally.

[K22R8CT 24]

Can the devs (or anyone else) tell me if they're looking into this or at least if they plan to?

The problem spans multiple versions of MacOS, iOS and Safari, and multiple configurations, so reproducing it should be straightforward.

But 3-4 months now with no word one way or the other.

[Luke 37022]

On 11/9/2022 at 11:16 AM, K22R8CT said:

Can the devs (or anyone else) tell me if they're looking into this or at least if they plan to?

The problem spans multiple versions of MacOS, iOS and Safari, and multiple configurations, so reproducing it should be straightforward.

But 3-4 months now with no word one way or the other.

Hi, are you still having an issue with this? Have you updated to Emby Server 4.7.11?

[Gecko 61]

Hi @Luke,

I tested during my holidays locally and through nginx. Yes it's still happening on 4.7.11 kind of randomly, so I cannot give you a proper way to reproduce on your side. I just noticed that the web app client (using safari) is requesting an out of order segment instead of the next sequentially one when the playback stops (I already told you that in another topic about the same subject).

[K22R8CT 24]

13 hours ago, Luke said:

Hi, are you still having an issue with this? Have you updated to Emby Server 4.7.11?

I'm still having the issue but it's with 4..8.0.21 (I don't run 4.7.11)

I mentioned this in another thread about safari compatibility:

 

[K22R8CT 24]

To solve this I'd imagine a process along the lines of:

1. Reproduce the problem
2. Investigate
3. Implement solution
4. Confirm

Has the Emby team completed (1) and if not, how can I and others help?

So far I've uploaded various embyserver and ffmpeg logs but I can reproduce it consistently from macOS, iOS and ipadOS if something more is needed.

Is there an Emby equivalent to this Jellyfin demo site where those of us affected could test and you'd have access to the full diagnostics, eliminating the back-and-forth of uploading log files and the possibilities of server and network misconfiguration?

EDIT: Can a moderator please move this thread from Emby Server > General/Windows to Emby Apps > Web App? I didn't realize it was a client problem when I posted it.

Edited January 12, 2023 by K22R8CT

[Gecko 61]

@Luke, @K22R8CT,

 

I looked into this issue again and found out a possible solution : I modified my nginx configuration and added a new location targeting the path used to retrieve hls chunks (emby/videos). I copied/pasted the config for my root location and simply added the following :

 

location /emby/videos {

      proxy_pass <your Emby server url>; ## Enter the IP and port of the backend emby server here.

 

      [...] # usual nginx config as found in this forum

 

      proxy_hide_header Cache-Control; # remove any cache header that the server initially sets (-> public)

      add_header Cache-Control "private, no-transform"; # specify that the response must be private to the origin (proxys cannot store in their cache) and cannot be modified along the way

}

 

So far, videos that were failing previously are now stable on Mac OS Safari and iOS Safari but maybe those additional cache directives may have other negative impacts... I'm not a proxy expert but at least, they are strictly limited to hls chunks.

 

Hope this helps ! 

 

 

[visproduction 122]

On 1/11/2023 at 1:07 AM, nSGecko said:

Hi @Luke,

I tested during my holidays locally and through nginx. Yes it's still happening on 4.7.11 kind of randomly, so I cannot give you a proper way to reproduce on your side. I just noticed that the web app client (using safari) is requesting an out of order segment instead of the next sequentially one when the playback stops (I already told you that in another topic about the same subject).

Out of order segments happen with the TCP buffer size settings.  Apple has setup an optimized version that is apparently quite different from how Windows handles this issue.  It looks like they have tuned video streaming to work for Apple and related sites and it can run into issues with other 3rd party video streaming.  Here is a report about someone who has this exact issue and how they fixed it.  I remember way back in the 90's that when i setup network connection to remote world locations increasing the TCP buffer in multiples of 1460 (The TCP data packet size) helped maintain a connection that would otherwise fail and cause video to stop.  Around 2002 Window and Apple switched automatic settings that supposidly adjusted by themselves.  I think if the out of order packets are appearing due to perhaps some network issue or VPN, then the automatic buffer can error out and cause a video stream to stop.  This will be different for Apple OS versions versus Windows versus Linux.

Maybe that is part of the problem.  Here is the page of users who complaining this happens in Apple OS.

https://www.wowza.com/blog/hls-latency-sucks-but-heres-how-to-fix-it

Hope that helps.

[Luke 37022]

13 hours ago, nSGecko said:

@Luke, @K22R8CT,

 

I looked into this issue again and found out a possible solution : I modified my nginx configuration and added a new location targeting the path used to retrieve hls chunks (emby/videos). I copied/pasted the config for my root location and simply added the following :

 

location /emby/videos {

      proxy_pass <your Emby server url>; ## Enter the IP and port of the backend emby server here.

 

      [...] # usual nginx config as found in this forum

 

      proxy_hide_header Cache-Control; # remove any cache header that the server initially sets (-> public)

      add_header Cache-Control "private, no-transform"; # specify that the response must be private to the origin (proxys cannot store in their cache) and cannot be modified along the way

}

 

So far, videos that were failing previously are now stable on Mac OS Safari and iOS Safari but maybe those additional cache directives may have other negative impacts... I'm not a proxy expert but at least, they are strictly limited to hls chunks.

 

Hope this helps ! 

 

 

If you remove that, do they start acting up again?

[Gecko 61]

On 1/20/2023 at 4:33 AM, Luke said:

If you remove that, do they start acting up again?

@Luke,

yes but my solution is not enough to solve entirely the issue

I also tried to add gzip compression to the m3u8 as recommended by Apple and forbid entirely the usage of cache to safari but I still have the issue on the first streaming session after safari has been started.

i’m out of ideas once again.

[Luke 37022]

On 1/19/2023 at 8:41 AM, Gecko said:

@Luke, @K22R8CT,

 

I looked into this issue again and found out a possible solution : I modified my nginx configuration and added a new location targeting the path used to retrieve hls chunks (emby/videos). I copied/pasted the config for my root location and simply added the following :

 

location /emby/videos {

      proxy_pass <your Emby server url>; ## Enter the IP and port of the backend emby server here.

 

      [...] # usual nginx config as found in this forum

 

      proxy_hide_header Cache-Control; # remove any cache header that the server initially sets (-> public)

      add_header Cache-Control "private, no-transform"; # specify that the response must be private to the origin (proxys cannot store in their cache) and cannot be modified along the way

}

 

So far, videos that were failing previously are now stable on Mac OS Safari and iOS Safari but maybe those additional cache directives may have other negative impacts... I'm not a proxy expert but at least, they are strictly limited to hls chunks.

 

Hope this helps ! 

 

 

@pir8radio do you see any reason not to add this to some of our response headers?

Actually @Gecko is your caching configured to ignore the query string? That might be your issue. Because if the query string is part of the caching, then no-transform would not be necessary. Why - because every play session has a unique query string value.

[Gecko 61]

4 hours ago, Luke said:

Actually @Gecko is your caching configured to ignore the query string? That might be your issue. Because if the query string is part of the caching, then no-transform would not be necessary. Why - because every play session has a unique query string value.

I'm sorry I did not understand your question, how and where could I configure to ignore the query string ?

FYI, I switched to CaddyV2 since this post because I thought the culprit was the http/1.1 connexion. Unfortunately, I have the same behavior with http/2 anyway. I think there is no caching mechanism by default with Caddy. Safari is stock default aswell. I don't use cloudflare either.

[pir8radio 1292]

14 hours ago, Luke said:

@pir8radio do you see any reason not to add this to some of our response headers?

Actually @Gecko is your caching configured to ignore the query string? That might be your issue. Because if the query string is part of the caching, then no-transform would not be necessary. Why - because every play session has a unique query string value.

cache can be controlled in the proxy.   But my config for emby isn't caching anything, it just transparently passes traffic to/from emby.    I don't think this user used my full config, i suspect they grabbed chunks of the config and added to theirs..     If i was @Gecko i would look into "tcp_nodelay"  make sure its set to on in the http block first. 

but if its happening locally using the local ip of the embyserver (not the remote or domain name) and they are truly bypassing the nginx proxy, then, no clue. 

Edited February 6, 2023 by pir8radio

[Luke 37022]

37 minutes ago, pir8radio said:

cache can be controlled in the proxy.   But my config for emby isn't caching anything, it just transparently passes traffic to/from emby.    I don't think this user used my full config, i suspect they grabbed chunks of the config and added to theirs..     If i was @Gecko i would look into "tcp_nodelay"  make sure its set to on in the http block first. 

but if its happening locally using the local ip of the embyserver (not the remote or domain name) and they are truly bypassing the nginx proxy, then, no clue. 

I think what he's got going on is his caching is ignoring the query string, and then as a result some cached resources are getting reused from one playback session to the next and that shouldn't happen.

If I'm right, then it's really an issue in the proxy caching configuration but I'm still happy to make these response header adjustments if it will help make setup easier.

[Gecko 61]

8 hours ago, Luke said:

I think what he's got going on is his caching is ignoring the query string, and then as a result some cached resources are getting reused from one playback session to the next and that shouldn't happen.

If I'm right, then it's really an issue in the proxy caching configuration but I'm still happy to make these response header adjustments if it will help make setup easier.

Can I check your theory from dev tools in Safari or emby logs?

I assume I should check for a request made by the browser with a different query string when it stops or is there any other way ?

[Gecko 61]

8 hours ago, pir8radio said:

cache can be controlled in the proxy.   But my config for emby isn't caching anything, it just transparently passes traffic to/from emby.    I don't think this user used my full config, i suspect they grabbed chunks of the config and added to theirs..     If i was @Gecko i would look into "tcp_nodelay"  make sure its set to on in the http block first. 

but if its happening locally using the local ip of the embyserver (not the remote or domain name) and they are truly bypassing the nginx proxy, then, no clue. 

I could sent you my whole config but yes I copy pasted everything in yours + some additional bits like wol and geo-filtering and yes, only happening in safari with emby local ip. (tcp_nodelay on indeed).

What also helped reduce the issue is setting Emby in host mode instead of bridge in docker. But this could just be a placebo effect

[Gecko 61]

Triggered the issue this morning with detailed logs (after rotation) using the local ip of emby.

Like I said in a few weeks ago, the requested .ts chunks are in a weird order jumping from 44 to 431.

Hope this can help

 

 

embyserver-4.txt ffmpeg-remux-820b1898-296d-4986-ad7c-554b2381fb3e_1.txt ffmpeg-transcode-a16da9e8-194a-40c0-9cc2-fa70e3d7eaca_1-2.txt ffmpeg-transcode-d5ae5900-88b5-462d-80ca-5a67acd2ef06_1.txt ffmpeg-remux-0643e673-eb26-4a16-b405-f5c2b7c49115_1.txt

[Luke 37022]

On 2/7/2023 at 4:01 AM, Gecko said:

Triggered the issue this morning with detailed logs (after rotation) using the local ip of emby.

Like I said in a few weeks ago, the requested .ts chunks are in a weird order jumping from 44 to 431.

Hope this can help

 

 

embyserver-4.txt 124.93 kB · 3 downloads ffmpeg-remux-820b1898-296d-4986-ad7c-554b2381fb3e_1.txt 16 kB · 2 downloads ffmpeg-transcode-a16da9e8-194a-40c0-9cc2-fa70e3d7eaca_1-2.txt 636 kB · 1 download ffmpeg-transcode-d5ae5900-88b5-462d-80ca-5a67acd2ef06_1.txt 130.52 kB · 2 downloads ffmpeg-remux-0643e673-eb26-4a16-b405-f5c2b7c49115_1.txt 13.12 kB · 3 downloads

Can you try our hosted web app at http://app.emby.media

Please let me know how that compares. Thanks !

[Gecko 61]

5 hours ago, Luke said:

Can you try our hosted web app at http://app.emby.media

Please let me know how that compares. Thanks !

@Luke,sorry there are 2 topics about the same subject. Same issue using the hosted web app, playback stops itself with safari.

[Luke 37022]

On 2/21/2023 at 6:11 AM, Gecko said:

@Luke,sorry there are 2 topics about the same subject. Same issue using the hosted web app, playback stops itself with safari.

@Gecko are you sure? I thought you said in the other topic your issue was resolved in the hosted web app. Can you try again? Thanks.

[Gecko 61]

3 hours ago, Luke said:

@Gecko are you sure? I thought you said in the other topic your issue was resolved in the hosted web app. Can you try again? Thanks.

It was an old reply weeks before you fixed the issue in web app 4.7.11.10

 

don’t worry @Luke, last friday, the fix was still working to me even so the version number is way past .10