UK OTA media won't play since the switch to Exoplayer

[stuartsharp 3]

Hi,

This is a very similar issue to the one I posted about last year but didn't get resolved: https://emby.media/community/index.php?/topic/84524-streaming-issues-in-web-theatre-app/

Although I posted it as a live TV issue, it's actually the media itself that causes the problems. Basically, high definition content from a UK broadcast (either streamed or pre-recorded) won't play and causes the client to hang. This used to affect just Chromium web browsers but it now affects the Android mobile client too, since the switch to Exoplayer. I see Android TV is using Exoplayer too, but that client is able to fail over to transcoding and get the playback started after a long delay, whereas the mobile version now just hangs permanently like with the web browser issue I already reported.

The cause seems to be the container: all of our OTA media in the UK is provided with a ts container, regardless of the codec or resolution. I have a hdhomerun antenna receiver and a Linux enigma satelllite receiver, both of which produce ts files from everything they receive. It's the HD broadcasts with 1080i or 1080p resolution and H264 encoding that always fail. If I load one of these problem files into Avidemux and make a copy with an mkv or mp4 container instead of ts (and without touching the encoding) then Emby will play the copy just fine on any platform.

Please could this be looked at again? It's a much bigger deal now that it's affecting Android, because TV on a mobile device is one of our main reasons for using Emby around the home. I haven't attached any logs etc to this post yet, because there's a ton of supporting info in my old post above, including relevant media samples. I spent a lot of time trying to help work towards a solution last time, but it all came to nothing in the end.

I also have iOS clients and, so far, there's stil no issues with those......but they still have libplayer at the moment. I know Exoplayer is supposed to be better, but not for this particular media. Could the server be made to switch containers on the fly as a workaround? Plex seem to have found a solution as they also use Exoplayer, but I'm not having any problem direct playing this media in their software (on the same devices). It can be solved! Please help.

[pwhodges 1520]

I don't normally use live TV on my Android, but trying it I get a similar problem (I'm also in the UK and using an HDHomeRun).  In addition, when I do get a SD stream playing, selecting subtitles causes it to shut down on the spot - the screen goes blank, the play button appears, then the screen goes blank. (Right at the end of the log)

Paul

embyserver.txt ffmpeg-transcode-4713bf7c-1b96-44a0-891c-0f27fe4682f7_1.txt ffmpeg-transcode-dfe519a1-4bf6-4662-90e0-7be1c2618098_1.txt

[Luke 36991]

On 1/17/2021 at 3:26 PM, stuartsharp said:

Hi,

This is a very similar issue to the one I posted about last year but didn't get resolved: https://emby.media/community/index.php?/topic/84524-streaming-issues-in-web-theatre-app/

Although I posted it as a live TV issue, it's actually the media itself that causes the problems. Basically, high definition content from a UK broadcast (either streamed or pre-recorded) won't play and causes the client to hang. This used to affect just Chromium web browsers but it now affects the Android mobile client too, since the switch to Exoplayer. I see Android TV is using Exoplayer too, but that client is able to fail over to transcoding and get the playback started after a long delay, whereas the mobile version now just hangs permanently like with the web browser issue I already reported.

The cause seems to be the container: all of our OTA media in the UK is provided with a ts container, regardless of the codec or resolution. I have a hdhomerun antenna receiver and a Linux enigma satelllite receiver, both of which produce ts files from everything they receive. It's the HD broadcasts with 1080i or 1080p resolution and H264 encoding that always fail. If I load one of these problem files into Avidemux and make a copy with an mkv or mp4 container instead of ts (and without touching the encoding) then Emby will play the copy just fine on any platform.

Please could this be looked at again? It's a much bigger deal now that it's affecting Android, because TV on a mobile device is one of our main reasons for using Emby around the home. I haven't attached any logs etc to this post yet, because there's a ton of supporting info in my old post above, including relevant media samples. I spent a lot of time trying to help work towards a solution last time, but it all came to nothing in the end.

I also have iOS clients and, so far, there's stil no issues with those......but they still have libplayer at the moment. I know Exoplayer is supposed to be better, but not for this particular media. Could the server be made to switch containers on the fly as a workaround? Plex seem to have found a solution as they also use Exoplayer, but I'm not having any problem direct playing this media in their software (on the same devices). It can be solved! Please help.

Hi, can you provide a sample video for testing? Thanks.

[stuartsharp 3]

8 hours ago, Luke said:

Hi, can you provide a sample video for testing? Thanks.

Hi Luke,

Thanks for replying. Please find a 1 minute sample file attached. I've also included a server log where I've isolated one instance of me trying to play this file from an Android tablet (192.168.1.14). The first entry is when I pressed play and the last is the response time logging after I give up and back out after almost 5 minutes. The actual file is never mentioned and it doesn't generate an ffmpeg log. The IP 192.168.1.2 is just a web client that I was using to pull up the logs etc.

As I mentioned before, remuxing both the video and audio into a different container will result in perfect playback, but it can't handle the native ts file for some reason.

Countryfile 2021-01-17 - Mendips.ts embyserver.txt

[Luke 36991]

8 hours ago, stuartsharp said:

Hi Luke,

Thanks for replying. Please find a 1 minute sample file attached. I've also included a server log where I've isolated one instance of me trying to play this file from an Android tablet (192.168.1.14). The first entry is when I pressed play and the last is the response time logging after I give up and back out after almost 5 minutes. The actual file is never mentioned and it doesn't generate an ffmpeg log. The IP 192.168.1.2 is just a web client that I was using to pull up the logs etc.

As I mentioned before, remuxing both the video and audio into a different container will result in perfect playback, but it can't handle the native ts file for some reason.

Countryfile 2021-01-17 - Mendips.ts 33.97 MB · 0 downloads embyserver.txt 58.75 kB · 0 downloads

Did you verify that the problem occurs with the sample video?

[stuartsharp 3]

11 minutes ago, Luke said:

Did you verify that the problem occurs with the sample video?

Hi Luke,

Please find a 1 minute sample file attached. I've also included a server log where I've isolated one instance of me trying to play this file from an Android tablet (192.168.1.14).

Yes, I did. That's what I was trying to explain in my last post. The log file has everything from when I try to start playing the sample in the Android client to when I abort by pressing the back button. I cut out everything else apart from the header with the server info. I think there's a good chance that you'll get the same results as I do if you just put my file onto your server and try playing it from any Android mobile device (with the latest client app). I've tried from 3 different devices and they all behave the same way.

[stuartsharp 3]

Hi Luke,

I was just wondering if you found time to confirm this issue?

I haven't noticed any updates on the server or client side for a few weeks, so just wondered if you're busy working on the issue or need more help from my side?

Thanks,

Stuart

[Luke 36991]

Please try the next update to the app. Thanks.

[stuartsharp 3]

On 08/02/2021 at 17:18, Luke said:

Please try the next update to the app. Thanks.

Hi Luke,

I downloaded the update to my Android devices today. I'm pleased to say that all the TV channels are playing again now, so thank you and your team for that!

At the same time, I'm a little disappointed with the update, because performance with these ts files is now very bad compared to when the app used libplayer, or even rival apps that also use Exoplayer. The first issue is transcoding local playback of some H264 channels when it has no need to (I've attached a couple of photos which prove this point). The second issue is it's now VERY slow to start playback. I'm not moaning about a few seconds, I mean I can literally be sitting there for a full minute, and this isn't because of the transcoding - I can be waiting all of that time and then get a direct stream. Please could you guys spend a little more time on this? I would really appreciate it, because Plex are doing a much better job with the Exoplayer right now.

In my attached photos, all of the following is true:

- I have two Android clients, both fully updated with the latest (today) release of Emby and P***

- They're both being served from the same hardware, via the same LAN.

- They're both live streaming the same channel from the same HDHR tuner

- Both devices use Exoplayer

- It doesn't matter which one is the Emby client and which runs P***, the result is that the Emby device transcodes where the other doesn't. Emby never transcoded with libplayer, and still doesn't in the iOS app (I'm praying that platform will stay with libplayer until these bugs are worked out. It works so much better)!

Sorry for the crappy photo quality, but hopefully you can zoom in and get my point. I really appreciate your efforts and thank you for staying focussed on this. Have you thought about adding a 'use old player' setting in the app until the new player is free from issues? I remember Plex having that for quite a while.

[Luke 36991]

Hi, can we please look at an example?

Thanks.

[stuartsharp 3]

1 hour ago, Luke said:

Hi, can we please look at an example?

Thanks.

Hi Luke,

Thanks for the quick reply. So, I recorded you an example and when I played it back to check what it does, I get mixed results. Sometimes I get transcode and sometimes I get direct stream. I have never seen this before and can only assume there's some kind of networking performance issue going on, but I'm not having any performance issues with other media, just the ts playback. If I play the last sample I uploaded to this thread on January 24, that exact file is doing the same thing.

I'll try to produce some logs of both direct and transcoded with the same file for you. Maybe that will help reveal what's going on? I know there's more to it than just the transcoding, because it's so slow - slower than if I was on a remote connection and actually needed transcoding.

 

[stuartsharp 3]

2 hours ago, Luke said:

Hi, can we please look at an example?

Thanks.

Hi again Luke,

OK, here's some examples, if you could take a look for me, please? I've uploaded filtered server logs of 3 incidents (A,B,C) along with a copy of the test file I used.

Original filename of the test file: Bill Bailey  Limboland (2018).ts (I have renamed this to TestFile_A-B.ts)

Logs A & B are are two different examples of playing this same pre-recorded file locally with different results. I've also included logs (C) as an example of the excessively slow startup with live playback, even when it's doing a direct stream. The client and server devices are the same every time (Server@192.168.1.32, Client@192.168.1.14).

Logs (A) Results

File: Bill Bailey  Limboland (2018).ts

Time playback initiated: 22:29

Approx time until playback start: 6 seconds ( I have no problem with this, it's fine)

Playback result: DirectStream

 

Logs (B) Results

File: Bill Bailey  Limboland (2018).ts

Time playback initiated: 22:36

Approx time until playback start: 8 seconds

Playback result: Transcode

 

Logs (C) Results

File: Live stream from HDHR @192.168.1.10, Channel: ITVBe UK (MPEG2 ts 480p 1Mbps)

Time playback initiated: 22:49

Approx time until playback start: 92 seconds

Playback result: DirectStream

 

I hope that helps out. I don't know how to read the logs myself, but I can see in example (C) that communication with the client is stopping for a long time.

Thanks,

Stuart

embyserver_A.txt embyserver_B.txt ffmpeg_B.txt ffmpeg_A.txt TestFile_A-B.ts embyserver_C.txt ffmpeg_C.txt

[ebr 14897]

Hi.  Both ffmpeg log A and B are direct streams...

[stuartsharp 3]

2 hours ago, ebr said:

Hi.  Both ffmpeg log A and B are direct streams...

Understood. I was only checking the information reported by the client under 'stats for nerds'. In test A, the client reported DirectStream, but in test B, it reported transcode. I was hoping that would reveal something somewhere in the server logs.

Playback is actually working OK, even when it reports transcoding, so I'm not sure how useful another example of the actual media would be. The fact that the new client intermittently reports a transcode is just something I found while testing a media sample for you guys and thought it might be relevant. The root problem is the really slow live streaming performance. Is there anything useful in the live stream log I provided (log C)? The one where it takes over 90 seconds to start? The ffmpeg log for that one doesn't get created until after the 90 seconds has passed.

[rbjtech 4218]

I'm following this thread with interest as playback of UK OTA HD Channels from all clients is a lottery and most do not work - and lock up the HD Homerun tuner.

Recordings of the same HD Channels however appear to work ok - they sometimes playback ok in Emby but always playback with VLC etc - so the TS itself appears to be good.

I believe this is all related to the broadcasts sometimes being 1080i, other times 1080p

If you need some more examples/samples of the TS files - I can also provide, but I'll start my own thread rather than derail the OP's.

All the mpeg2 SD channels appear to be fine - it's just the h264 1080i/p channels that are causing the issue.

Thanks.

  

[pwhodges 1520]

I can confirm that UK OTA recordings from a Homerun are fine.  I rarely watch live via Emby, but recently when watching from an active recording I couldn't get the subtitles up, though they were there in the final recorded file; but I'll try reproducing that properly before making a proper report of it.

Paul

Edited March 21, 2021 by pwhodges

[stuartsharp 3]

39 minutes ago, rbjtech said:

I'm following this thread with interest as playback of UK OTA HD Channels from all clients is a lottery and most do not work - and lock up the HD Homerun tuner.

Recordings of the same HD Channels however appear to work ok - they sometimes playback ok in Emby but always playback with VLC etc - so the TS itself appears to be good.

I believe this is all related to the broadcasts sometimes being 1080i, other times 1080p

If you need some more examples/samples of the TS files - I can also provide, but I'll start my own thread rather than derail the OP's.

All the mpeg2 SD channels appear to be fine - it's just the h264 1080i/p channels that are causing the issue.

Thanks.

  

Thanks for sharing your experience. In my case all of the channels are playing live......eventually.

The problem is that it's taking a hell of a long time (sometimes over a minute) to get started, and although recordings will play by Direct Stream (container swap), live playback is doing full transcoding. None of these issues existed until late last year when the client was updated to use Exoplayer like Plex. What's weird is that the current Plex software can both play and live stream all of our TV channels in Direct Play mode  - no transcoding or container swapping whatsoever, and that's on both iOS and Android. So I can only assume that not all versions of Exoplayer are created equal.

On the positive side, iOS clients are still working perfectly fine with Emby for now.

[Luke 36991]

That's strange. I have not seen this occur, but we'll try to chase down the cause. Thanks.