M3U TV Tuner Plugin stripping m3u arguments

[christopher102994 3]

Hello,

When Emby transitioned to the M3U TV Tuner architecture some of my live tv channels stopped working properly and I'm just now getting around to debugging it.

The m3u is generated by a project I started: docker-toonamiaftermath that scrapes the associated website and builds a m3u playlist and XMLTV file.
The m3u playlist works perfectly fine in VLC and had been working fine in Emby until a few months ago.

OS: UNRAID
Runtime: Docker
Container: linuxserver/emby:beta
GPUs: 2x NVidia 1060 6gb (no other applications utilize these)
Version When Logs captured: 4.7.0.40 beta
M3U TV Tuner Version when Logs captured: 1.0.13.0
Note: I have tried switching to the stable branch and continue to get the same errors.

Details:

Essentially the way their streams work is that it's the same URL for EST and PST channels but the PST has a stream delay argument of 3 hours (180m) post '.m3u8' extension and I believe that some of these arguments are getting stripped for whatever reason making it default and play EST (while Emby thinks it's playing the PST channel).

Exact URLs I am scraping (from the m3u file):

EST: http://api.toonamiaftermath.com:3000/est/playlist.m3u8?useHttps=true
PST: http://api.toonamiaftermath.com:3000/est/playlist.m3u8?streamDelay=180&useHttps=true

This happens for the other (working) channels in the M3U as well.

ffmpeg-directstream-69eecc61-17b4-4624-bbd8-7e9140361407_1.txt ffmpeg-directstream-f49827c1-f0ab-4817-ae87-143db52a9167_1.txt embyserver.txt ToonamiAftermath.m3u

[Luke 37022]

Hi, how did you come to the conclusion about the URL Params?

[christopher102994 3]

@Luke because without the parameters in the PST then it plays the EST channel. In the log anything after streamDelay is absent (from what I saw)

[Luke 37022]

OK I can confirm this although unfortunately the issue is not with us but in the .net runtime. What's new is that we're now reading the m3u ourselves instead of having ffmpeg do it. The server hosting the m3u is doing something a bit non-standard, which is that is has both transfer-encoding:chunked and content-length in it's response headers. Usually those two things don't go together because if you're using chunked encoding, it's typically because you don't know the content length.

Anyway I found some open issues about it:

https://github.com/dotnet/runtime/issues/34402

https://github.com/dotnet/runtime/issues/68581

The good news is that it looks like they're trying to get it resolved sooner rather than later and then backported into the .net version that we're using.

I don't expect many people will run into this issue because most severs are not using chunked responses.

[christopher102994 3]

Thanks for your research @Luke hopefully they fix it soon!

[christopher102994 3]

@Luke It looks like https://github.com/dotnet/runtime/issues/68581 is now fixed. Do you know if the work performed will fix this functionality?

[Luke 37022]

That's great. I think it will. We'll get it into a 4.7.X release next month once they've published.