christopher102994 3 Posted May 20, 2022 Share Posted May 20, 2022 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 Link to comment Share on other sites More sharing options...
Luke 37098 Posted May 21, 2022 Share Posted May 21, 2022 Hi, how did you come to the conclusion about the URL Params? Link to comment Share on other sites More sharing options...
christopher102994 3 Posted May 21, 2022 Author Share Posted May 21, 2022 @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) Link to comment Share on other sites More sharing options...
Luke 37098 Posted May 22, 2022 Share Posted May 22, 2022 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. 1 Link to comment Share on other sites More sharing options...
christopher102994 3 Posted May 22, 2022 Author Share Posted May 22, 2022 Thanks for your research @Luke hopefully they fix it soon! 1 Link to comment Share on other sites More sharing options...
christopher102994 3 Posted July 15, 2022 Author Share Posted July 15, 2022 @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? Link to comment Share on other sites More sharing options...
Luke 37098 Posted July 15, 2022 Share Posted July 15, 2022 That's great. I think it will. We'll get it into a 4.7.X release next month once they've published. 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