Jump to content

Intermittent tuning failures; ResourceNotFoundException from caching .m3u8 provider


Recommended Posts

Posted

My server is only able to intermittently tune channels from my upstream IPTV provider. I often have to try to retune dozens of times before the channel works. It will work, eventually, just have to get lucky. Upon (much) further investigation, I believe I have mapped this behavior to a quirk of my provider; nginx caching/gziping of the .m3u8 playlist.

If a server caches/gzips its .m3u8 file, emby fails to interpret it and decode the video with "ResourceNotFound" exceptions. It's not very clear from the logs why this is happening. It's a bit clearer from the behavior of the app against a server that caches/gzips its playlists. 
If you're lucky, you'll be the first to request a playlist segment before it gets cached/gzip'd. This playlist file comes back in plain-text, Emby will receive it and play back just fine. Plain-text, cache-miss response:

unzip.png.fc69c73142e0769f379cc5ae7024e1aa.png

If you're (more-likely) unlucky, then emby will receive the gzip'd playlist and fail to interpret the (binary) response correctly, resulting in this ResourceNotFoundException, even though the upstream server responded with 200OK. Cach HIT, binary response:

zipd.png.640ca915205bcee7b9f16d0ad3c5f50e.png

 

I believe this intermittent success/failure to tune in Emby is directly related to the intermittent nature of cache hits/misses from the upstream NGINX provider.

 

Let me know if you need more information. I can point you to the provider I've observed this behavior against in a PM.

 

embyserver.txt

Posted

Hi, try adding #EXT-X-TARGETDURATION up in the top section and see if that helps.

Posted

Hey @Luke, looks like that is already there on the M3U8 file(s). FWIW, this source works fine every time in the last OSS build of Emby (Version 3.5.3.0).

I don't have direct access to edit these files from this provider, working on setting up infra to run my server's requests through a MITMProxy to gunzip the cached files as they get passed down.

Posted

OK I made a small change related to this on the beta server, so for immediate relief you could always try that if you want.

Just keep in mind that if you do, any rolling back to 4.8 stable will require a fresh start.

  • Like 1
Posted

@rlyshwdo channels play or do they freeze shortly after?

Ive been trying to figure out why Emby can’t playback my content when other clients are fine and what you described sounds similar to what I think is happening my end

Posted

@irPhunky
 

Doesn’t play at all for several (or dozens) attempts to tune, until you get lucky and get a cache miss, when the upstream server (I think Google CDN in this case) sends down the full plaintext m3u8. 

Posted
On 4/11/2025 at 11:24 AM, Luke said:

OK I made a small change related to this on the beta server, so for immediate relief you could always try that if you want.

Just keep in mind that if you do, any rolling back to 4.8 stable will require a fresh start.

Running the beta now, first few tune-ins from my cached channel are working great. I'll tinker with this for a bit but seems resolved on first test. Thanks!

  • Thanks 2

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
×
×
  • Create New...