Direct Play not working with TS files on Shield TV, works with other devices and on Plex

[sjabaker 9]

So... since I know Google can be a bit slow at releasing updates, and it looked like there was some movement around exoplayer in the last few beta versions, I thought I'd go ahead and try side-loading the very latest beta (v2.0.21).

I've only had 2-3 days' testing so far, but the evidence clearly suggests there's no improvement. (If anything, the stats are even worse with only 3 of 11 recordings both starting and then handling any skips without error-ing out of direct play - but I suspect it'll 'revert to the mean' of nearer 50/50 with a larger sample)

[Luke 37064]

HI there, are you still having an issue with this?

[sjabaker 9]

Yes, the issue appears unaffected by the latest beta versions. (Certainly v2.0.21 showed no improvement. I've only just updated to 2.0.22 but so far 4 out of 5 have resulted in 'direct play error' so likely no effect either.)

[mirdragon 15]

@Luke, @sjabaker

 

this issue with playback on Emby, is very similar to the issue i've been experiencing on my thread Direct Play Issue of Live TV (Freeview) on Shield TV as the recordings are in ts format.

 

Edited June 4, 2021 by mirdragon

[sjabaker 9]

So I've done another 'test' and used the app to 'Send Logs' in case that can help...

Test run:
Attempted playback of a Test Cricket recording starting 17:27 - playback started after ~15 secs of the spinning circle, and stats for nerds showed "Transcode Reason: Direct play error".
Sent Logs from within the playback OSD at 17:28 (12:28 Eastern Time).
Attached are: (i) the truncated first 150MB of the file being played back; (ii) the associated server ffmpeg-remux log; & (iii) the main Emby server log.

Client app: Android TV beta v2.0.22g running on an Nvidia Shield TV (2019 non-Pro 'tube' version)
Server: v4.6.2 running in Docker on a Synology NAS; files are TV recordings from UK Freeview (HD) using an HDHomeRun Quattro

1905692442_TestCricket2021_06_05_19_00_00-EnglandvNewZealand1stTestDay41st150MB.ts ffmpeg-remux-ac624a1a-3e6a-4b5a-a70f-c1c6f1c5f021_1.txt embyserver.txt

[sjabaker 9]

2nd Test:
Attempted playback at 18:24 of "The Last Leg" (truncated first 195MB attached) - started fine and SFN showed it as Direct Playing...
Then tried to skip ahead to the 5:50 mark  to the 'real show start' (after pre-record padding, adverts & show intro) - still image of the new playback position appeared but then the app froze for nearly a minute and finally just returned right back to the main Emby home screen.
'Sent Logs' from the home screen menu option at 18:26 (13:26 Eastern Time)

No ffmpeg log attached as none was produced on the server for this test run at all.
Logged in user was 'Steve' for both tests.

2127773595_TheLastLegS22E011st195MB.ts

[ebr 14913]

Hi.  This is a Shield Pro?  What else is installed and running on the box?

06-06 18:25:40.622 18993 19059 E AndroidRuntime: java.lang.OutOfMemoryError: Failed to allocate a 7240 byte allocation with 2648 free bytes and 2648B until OOM, max allowed footprint 536870912, growth limit 536870912

 

[vdatanet 1549]

4 minutes ago, ebr said:

Hi.  This is a Shield Pro?  What else is installed and running on the box?

06-06 18:25:40.622 18993 19059 E AndroidRuntime: java.lang.OutOfMemoryError: Failed to allocate a 7240 byte allocation with 2648 free bytes and 2648B until OOM, max allowed footprint 536870912, growth limit 536870912

 

 

1 hour ago, sjabaker said:

Client app: Android TV beta v2.0.22g running on an Nvidia Shield TV (2019 non-Pro 'tube' version)

 

[sjabaker 9]

As noted - no, it's the non-pro version.

There's nothing installed that runs in the background that I'm aware of, and at the time of the two tests above the only app I'd used since restarting the device not that long beforehand was the Emby app. Normally (i.e. 99.9% of the time) the only apps that show in the recent apps carousel are Emby and Kodi. (I have another 10 or so apps installed, but that are very rarely used.)

[ebr 14913]

Wow, I read that three or four times and somehow saw "non-tube version" each time... 

Okay, so, yeah, unfortunately, this is one of the limitations of that device.  It doesn't handle high-bitrate items well.

[sjabaker 9]

Weird - considering it's designed as a 4K-capable playback device it's surprising to hear it struggles with the much lower bit-rate of OTA broadcast HD.

I get that whatever's causing the fundamental issue might be causing some memory leak or similar... which might cause the very occasional "reset to the home screen" issue as happened with that Test 2 (and why that sometimes happens and sometimes doesn't with repeated playing of the same file).

What still seems unclear is why the basic problem of direct play failing (e.g. Test 1) still happens even with some SD files (544x576 broadcast channels are most definitely not "high-bitrate"), and also if it's a device-capability issue why other playback apps (e.g. Plex & Kodi) never had any issue directly playing exactly the same recording files (including on a FireTV 4K stick which I believe is a less capable device)?

[vdatanet 1549]

The memory leak is mostly manifested by playing high bitrate content, but sometimes with low bitrate content as well. In my case it only manifests itself in applications that use Exoplayer. Maybe the memory leak is due to an interaction between Exoplayer and Nvidia Shield Tube. 

The device is capable but someone from Nvidia screwed up at one point. Nvidia should give the money back to all the geeks who bought the shield (including myself)

[sjabaker 9]

It may be exoplayer - but I see similar issues with my Fire TV device so it doesn't seem to be specifically (or at least not only) a Shield-interaction issue, otherwise I'd just try a different Android TV device. (Mind you, I'm pretty sure I read that Plex also uses/used exoplayer in its Android TV app, and that plays perfectly on both devices, so maybe it's an exoplayer-EmbyApp-AndroidTV tripartite interaction?!)

I guess I have some hard thinking to do about whether I just live with the annoying playback issue or jump ship and trade the upside of proper playback performance for one or more downsides: skip-control I hate (Kodi app, Roku platform, Emby for Apple TV at the moment), bad UI (Android TV Plex, Infuse for Apple TV), and others ... ... Ho hum. 

[ebr 14913]

8 minutes ago, sjabaker said:

but I see similar issues with my Fire TV device

I can only speak specifically to the log I saw which was an out of memory error.  "Similar issues" could actually be any number of things.  If you can provide examples of those, then we can try and diagnose.

Thanks.

[vdatanet 1549]

On 6/6/2021 at 7:45 PM, sjabaker said:

2nd Test:
Attempted playback at 18:24 of "The Last Leg" (truncated first 195MB attached) - started fine and SFN showed it as Direct Playing...
Then tried to skip ahead to the 5:50 mark  to the 'real show start' (after pre-record padding, adverts & show intro) - still image of the new playback position appeared but then the app froze for nearly a minute and finally just returned right back to the main Emby home screen.
'Sent Logs' from the home screen menu option at 18:26 (13:26 Eastern Time)

No ffmpeg log attached as none was produced on the server for this test run at all.
Logged in user was 'Steve' for both tests.

2127773595_TheLastLegS22E011st195MB.ts 195 MB · 1 download

I've tested this sample using Nvidia Shield 2019 Pro, no problems direct playing and seeking.

[sjabaker 9]

@ebr I'll try to send a couple more logs from the Fire TV device over the next few days for comparison (first one just sent, see below)...
BTW: did the log for the first test (the cricket file) also show the same memory error? - That test was much more representative of the most common presentation of the issue (only occasionally does it actually fail back to the app home screen).

@vdatanet I suspect that's an unfortunate side effect of having to truncate the files to fit the upload limit. I've just re-tested both the full original file and the 195MB truncation... both start direct playing OK (as the full file did in Test 2), but when I then try skipping ahead to 5:50 it has problems in the full file but skips OK with the truncated one (probably because that's pretty close to the end of the shortened file). Does the Test Cricket sample direct play properly on your Shield Pro?

As part of that re-test I also sent a new log from the app (at 15:55 Eastern / 20:55 local) - the sequence was as follows (after closing all apps in the 'recent' carousel and then restarting the device entirely):
20:50 - start playback of full-length Last Leg file, starts OK in Direct Play
20:51 - skip ahead (using video thumbnails) to 5:50 mark, still image of target position displayed but playback freezes and app eventually resets back to the home screen
20:53 - start playback of full-length Last Leg file again, starts OK in Direct Play
20:54 - skip ahead (using video thumbnails) to 5:50 mark, long-ish pause before playback continues, SFN now shows "direct play error" as reason for transcode
20:55 - 'Send Logs' from playback OSD cog menu

Also, to confirm that the truncated version of the Test Cricket file still does have the same issue as the full file, I did a quick test using the Fire TV 4K (again, sequence below is following straight from a device restart, and logged in user is 'Steve'):
21:21 - start playback of truncated 150MB Test Cricket file -> slight pause (distinctly shorter than with the full file) before playback starts, and SFN immediately shows "Transcode reason: Direct play error"
21:22 - 'Send Logs' from the playback OSD cog menu (=16:22 Eastern time)

Thanks very much to both of you for your efforts to help!
(I'm not a programmer, but do work in IT and know this kind of inconsistent problem tends to be incredibly frustrating )

[ebr 14913]

20 minutes ago, sjabaker said:

I also sent a new log from the app (at 15:55 Eastern / 20:55 local)

That one is the out of memory error as well.

The other test (cricket) is also the same error but at a different time (during initial load).  Apparently, it is able to recover when this happens in the initial load but not during playback/skipping.

 

[sjabaker 9]

Interesting.

Since I just happened to hit the more serious "fail to play at all & reset to the home screen" issue again, but with the Fire stick this time (& a different file), I sent another log at 17:37 Eastern... 
I started trying to play "Top Gear S29E02.ts" at c. 22:29 (+/-1 min, I didn't check the time before clicking play) and just got the spinning circle until I gave up at 22:37 and hit 'back', then 'back' again and another 10 secs or so later the app restarted to the home screen. Log then sent from the home screen user menu. (Note: current app version on the Fire stick is 2.0.21a)

Assuming that one also shows a similar memory error then it looks like it's not Shield-related.

Without any insight into the details, it seems like it must be 'looking for something' in the media stream that it can't find (either doesn't exist or not detected properly) in many but not all of the DVR recordings - and it keeps searching further & further ahead building up memory use until  something kicks it over to non-direct play or else in a few cases ultimately resets the app completely. That would seemingly explain why smaller/shorter files (like SD recordings, and the truncated samples I've uploaded) are less likely to have an issue, and if they do are much quicker to fail-over to remuxing, than big/long HD files. Unfortunately that doesn't help identify what it's "looking for" that's causing all the problems (other than it's something that other players obviously either don't need to find or have a better/different way of detecting).

This mostly happens at initial load but sometimes later on at a 'skip' event - suggesting whatever the issue is with the media stream it's not constant within the same channel's broadcast, or even the same programme. It also isn't specific to any particular codec within the .ts container (both MPEG4/AAC and MPEG2/MP2 files have failed). It might have some relationship to bitrate, but a reasonable number of HD recording direct play successfully, including ones with >3 times the bitrate of an SD file that doesn't.

Are more logs &/or sample files likely to be useful? I'm happy to keep a steady trickle coming as/when I get the time if it helps...?

[ebr 14913]

16 hours ago, sjabaker said:

Assuming that one also shows a similar memory error

It doesn't.  In fact, I cannot see a crash in that log.  Did you send it right after restarting?  Sometimes we cannot see everything.

[sjabaker 9]

Yes, I would have sent the log as the first action after the app restarted...
I'll keep using the Fire TV for a bit and look to send another log or two from it when I encounter issues (at least the 'normal' failure to direct play, even if I don't see the less common 'full app restart' again immediately) - to confirm it's the same problem as with the Shield.

[sjabaker 9]

First additional log sent from the Fire TV Stick (at 16:28 Eastern)...
Started playing "Yes, Minister S02E05 The Devil You Know.ts" at 21:26/27 - usual issue of spinning circle for a while until playback then starts non-direct due to "Direct play error" - log sent at 21:28 from the playback OSD menu.

[ebr 14913]

14 hours ago, sjabaker said:

First additional log sent from the Fire TV Stick (at 16:28 Eastern)...
Started playing "Yes, Minister S02E05 The Devil You Know.ts" at 21:26/27 - usual issue of spinning circle for a while until playback then starts non-direct due to "Direct play error" - log sent at 21:28 from the playback OSD menu.

This log appears to show direct playback.  I do not see any error or restart to remux or transcode.  Was a transcode log produced?  

However, I also see it isn't the item you indicated.  It is "The Conjuring: The Devil Made Me Do It".

[sjabaker 9]

Attached is the remux log produced on the server.

The filename I noted was most definitely the one played (as seen in the remux log). It's not some really freaky coincidence of a different log sent at approx the same time with a somewhat similar filename?! (I checked the main Emby server log in case it might show that it was mis-matching the recording with the show name you're seeing even while recording to the filename I see - but neither "conjuring" nor "devil made" appear anywhere.

(The filename is what the EPG said it was, and was indeed the programme broadcast/recorded ... but sometimes I find there's been a "background" mismatch that isn't obvious because the .nfo data displayed in the UI is what the EPG had which was correct, until you later 'refresh metadata' and discover it actually thought it was something else entirely and have to re-'identify' the show! Usually this only happens where there's multiple tv shows with the same name but different years, though - and no sign of that in this case.)

ffmpeg-remux-b7c6623c-abd6-4972-acd4-d511951eb044_1.txt

[ebr 14913]

It was a freaky coincidence .  In the future, please include the name of the logged in user so I can be sure I'm looking at the right one.

I'm thinking this is related to the construction of these TS files and the way Exo handles them.  Have you tried re-muxing one?

[sjabaker 9]

Definitely a weird one  .  All my previous (& future) logs are/will be with 'Steve' as the logged in user (1-person environment here) ... I'll try and remember to always include that in the post for easy reference anyway - apologies!

I've just tried remuxing two different ways: once with ffmpeg (ffmpeg -i "input.ts" -c:v copy -c:a copy "output.ts") and once with VideoReDo (which is the GUI tool I usually use for cutting adverts, etc. for long term archiving of stuff I might re-watch). Both started out direct-playing perfectly fine, and the VRD version seemed reliable through some vigorous skipping around after that. The ffmpeg-remuxed version however couldn't skip at all - any attempt to skip forward or backwards simply restarted playback from 0:00.

Note that the ffmpeg command did produce one complaint:
"[mpegts @ 00000164e8285f00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly"
...this is the point I think I mentioned earlier in the thread that stopped me simply circumventing the issue by using a postprocessing script to automatically remux to .mkv or .mp4, since the "fix" for this of using '-fflags +genpts' only works with .mp4 but you can't put the AAC_LATAM format used in most Freeview HD programmes into an mp4 container

I therefore tried a further ffmpeg remux to .ts, this time adding the '-fflags +genpts' option - which threw out a bunch more warnings in a similar vein - but that made no difference (still direct plays OK but cannot skip at all).

I agree it's probably something in the construction of the particular TS files, and tried to install 'pure/basic' exoplayer to see if it's definitely that or connected to the combination of that and the way Emby uses it - but unfortunately the exoplayer app in the Google store reports as not available for the device being used (Shield), and it isn't in the Amazon store at all.

While I haven't (currently) got specific evidence that the files that throw those 'timestamps unset' errors are always exactly the ones that fail to direct-play, I have wondered if that might be what's causing the problem? Trying to find a timestamp and then searching further and further ahead when it can't find one would seem to broadly fit with how the problem manifests from the outside viewer perspective, at least. How come pretty much every other player manages to play-back and skip just fine without them, though, or what that would mean is needed to fix it in Emby/exoplayer, I have no idea.