XMLTV playback interruption on change

[doffactory 3]

What I think it is that in the transcode-temp folder emby creates a file aaaaaaaaaaaaa.ts and starts its playback. While playing this, it is already creating bbbbbbbbbbb.ts, and so on. At some point emby fails to play one of these intermediary files, and exits with black screen. 

[Luke 37049]

Well  yes, but i think the problem happens earlier - the transcoding process fails when the program changes, and thus, the stream characteristics change.

[doffactory 3]

I have an update. I digged out an earlier version of emby with which I had no issue with LiveTV (v3.4.0.0), and there is a setting "Auto-loop live streams". As soon as I tick it, my playback is fine. Without it it stops random, usually in 20-40 minutes once. Can you explain this behaviour and what does this setting do with ffmpeg? This setting is missing in newer versions of emby.

 

EDIT: typos

Edited February 16, 2020 by doffactory

[Luke 37049]

Can we look at log examples of the two servers to compare? Thanks !

[softworkz 3335]

I have an update. I digged out an earlier version of emby with which I had no issue with LiveTV (v3.4.0.0), and there is a setting "Auto-loop live streams". As soon as I tick it, my playback is fine. Without it it stops random, usually in 20-40 minutes once. Can you explain this behaviour and what does this setting do with ffmpeg? This setting is missing in newer versions of emby.

 

This has been dropped deliberately because overall it did a lot more bad than good. For example, it allowed to continue in cases where users had overused their stream limits (or bad guys had stolen heir IPTV credentials from logfiles that users had posted). But the continuation often lead to repetitions in the tv recordings, or - even more subtle - created recordings playable on some devices but failing on others. 

The point is: when an incoming stream is not reliable and not properly adhering to mpegts and tv broadcast standards, it will cause problems at some point. That's why we're raising the bar a bit with regards to the incoming stream quality instead of trying to save to disk whatever we get.

 

I don't know what's happening in your case, though. We'd need to take a look at the logs to proceed.

[softworkz 3335]

@@doffactory - would you be able to show some logs? (you can PM these when you prefer)

[doffactory 3]

@@doffactory - would you be able to show some logs? (you can PM these when you prefer)

Yes, during the weekend I might be able to create a new docker container and extract the logs. Sorry guys, I am working

[Luke 37049]

@@doffactory please don't forget this. Thanks !

[doffactory 3]

Hi, finally had some time to test. I set up a docker with emby v3.4.0.0 and loaded the same m3u from dockerized tvheadend as with the dockerized emby v4.3.1.0. Unfortunately, unlike my previous remarks, the transcoding breaks after a while with my streams (they must be somehow special) also in v3.4.0.0. I attach logs with both versions, also the logs from dockerized emby v4.3.1.0 (no idea why the .ts links differ, they refer to the same source coming through from my ISP iptv) with the same issue. After 10-20 minutes of continuous playback in Firefox the stream breaks (black screen with controls still visible on mouse movement). I try the playback from Firefox as my PC connected to tv is a linux box, so I wonder whether recent changes in Firefox might be the issue or what. I do not have similar issues with the same streaming server with the (mobile) Android client. Any suggestions are welcome as it drives me crazy when I watch the evening news, and it goes black when the most important message is being said.

emby-3.4.0.0.log

emby-4.3.1.0.log

[doffactory 3]

Attaching another 3 error logs. I literally cannot watch a livetv film, as I get various errors from Emby every 10 minutes or so. If I watch a movie (ie. full film, not livetv), everything works fine. Can anybody explain this to me?

interruption.log

error.log

after interruption.log

Edited March 27, 2020 by doffactory

[Luke 37049]

@@softworkz will take a look at this. Thanks.

[doffactory 3]

One more observation. I am using a dockerized emby container with the built-in ffmpeg provided within the container by you. However, my NAS (Asustor AS3202T) also comes with its own ffmpeg version. When I use the emby and ffmpeg provided by the NAS manufacturer, the transcoding does not appear to have the issue described above. I did not have a chance to test extensively though.

[Luke 37049]

How do you even accomplish that?

[doffactory 3]

By installing it through the Asustor NAS App Central (url: https://www.asustor.com/app_central)

[Luke 37049]

No I mean how do you get Emby Server to use a different ffmpeg? 

[doffactory 3]

I meant I had an earlier apk from ASUSTOR App Central, and there you had the option to select the ffmpeg path.

[Luke 37049]

Right ok, well @@softworkz is looking into this. Thanks.

[doffactory 3]

OK, finally I had some time to play with this myself. As much as I tried to use this with Emby and its web player, I ended up putting tvheadend in front of my iptv streams and defined a profile that does the transcoding of live tv streams for Emby. As a result, Emby now does not transcode the streams just directplays them, which seems to work. Tvheadend does the transcoding (with the help of iGPU, same setup as with Emby before, ie. /dev/dri/render128), and it uses less memory for doing this compared with Emby. The whole thing seems to be now stable enough and also the change in aspect ratio on certain channels seems to be solved when using tvheadend. 

 

Overall, this whole endeavour made me wonder whether there is something wrong with Emby's implementation of ffmpeg, or how ffmpeg is built for Emby... Tvheadend also uses ffmpeg, and over there it seems rock solid. Just a food for thought.

[softworkz 3335]

@@doffactory - Thanks for your investigations.

 

There are substantial changes in the works regarding IPTV, so please excuse that I can't look into this more closely as it wouldn't make a lot of sense :-)