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

[spacecowboy2050 0]

I will try although I'm having other issues at the moment - I installed the beta version of the server and now it seems anything that i record using Emby will not play at all in the Enby app on my Shield.  The files play on the PC and in the Emby web app.  Other mp4 files play OK on the Shield.  I'll downgrade to the stable server and see if I can solve it first.

[ebr 14910]

58 minutes ago, spacecowboy2050 said:

I'll downgrade to the stable server and see if I can solve it first

Hi.  You will need to do a fresh install to do that so I wouldn't really recommend it.

[spacecowboy2050 0]

Somehow I seem to have it working at the moment.  I sideloaded the Androis app but that was a bit hit and miss - some played directly while others transcoded.  In the end I completely uninstalled the emby server and started again, and unistalled and reinstalled the Android for TV (Beta) from the play store on the Shield.  Emby recordings are playing Ok and seeking ok too.  PLex recordings are playing OK although seeking further forward is a little slower.  I'll keep testing and let you know if it goes wrong again!  Thank you for your support!

[spacecowboy2050 0]

Spoke too soon - back to transcoding again...

[ebr 14910]

Hi.  Can we please look at an example?

 

[spacecowboy2050 0]

This is really weird now @ebr.  Yesterday the Emby recordings were playing fine on my Shield.  All playing with Direct Play.  Today none of them play unless I untick the Direct play of TS files option (then they all transcode obviously).  Same files, nothing changed in my setup at all.  I've restarted the Shield, restarted the PC.  Same thing.  The only way I can get them to play with Direct Play now is to resave the TS file with something like VideoRedo (unedited, not reencoded, just resaved).  I don't get it - I haven't changed anything since yesterday, the PC is not under any load, all devices are on Ethernet.  Just double checked again.  TS file saved again with VideoRedo plays fine.  Original TS recording won't - just get the spinning circle then eventually transcodes with a Direct Play error identified in Stats for Nerds.

Plex recordings play with Direct Play in Enby but won't seek properly.  The Emby recording play correctly with Direct Play in the Plex app on the Shield.

It's just really odd.

Edited April 5, 2021 by spacecowboy2050

[spacecowboy2050 0]

I'm going to upload an example, one is the original TS recording, the other is a resaved VideoRedo with no editing or reencoding.

Edited April 5, 2021 by spacecowboy2050

[spacecowboy2050 0]

@ebr

VideoRedo version

https://drive.google.com/file/d/1Ld_ErLEljlpZRg3NwGtrx77Gp1Cwb-Wo/view?usp=sharing

Original TS recording:

https://drive.google.com/file/d/1TSgh6CLQtjAQMLdqjP7LJRFn57JvWLtg/view?usp=sharing

 

Edited April 5, 2021 by spacecowboy2050

[ebr 14910]

Something is goofy with the file and your re-save is fixing it.  Did you test with the mobile app Luke pointed to?

[spacecowboy2050 0]

Yes - at the time when i tested the vast majority were transcoding although I can't remember if there was a pattern to it.  I'll try it again though.

[spacecowboy2050 0]

Well this is really odd.  The Android app is playing them directly (at the moment).  The last time I tried it was definitely transcoding many if not all of them from memory.  Just tried the normal app - still no good.  Is there a cache somewhere on the server or on the Shield that gets full and needs emptying or something?  The behaviour is just not following a pattern!

[spacecowboy2050 0]

@ebr Just had a closer look at what is happening in the Android app that I side loaded.  It is actually quite random.  Some recordings are playing with a setting of 1080 60mps (auto) and showing DirectStream in Stats for Nerds.  Some files are just transcoding.  Some (such as the ones I resaved) are playing and showing DirectPlay in Stats for Nerds.  

Could it be anything to do with interlace/progressive flags?  I know some contact recorded from Freeview can be a mixture of both.  Just a thought!

 

Edited April 5, 2021 by spacecowboy2050

[spacecowboy2050 0]

UPDATE I uninstalled the Emby App (normal one) from the Shield, reinstalled it, and now the files are playing using Direct Play (even without the tick in the Allow TS files to Direct Play box).  I don't get it.  It seems to work for a while, then just stops an hour/day/week later without me changing anything.  It does seem to be related somehow though to the way the files are recorded through the Emby server.  It is making my head hurt!  I'm not going to change anything at all and see how long it lasts!

[ebr 14910]

The error being produced is:

      com.google.android.exoplayer2.ExoPlaybackException: Source error
...

	Caused by: com.google.android.exoplayer2.ParserException: Loading finished before preparation is complete.
 

The fact you say it is inconsistent may mean that it is related to some sort of timing but, I think the true cause is that something about the file is not constructed properly - something like the content length is not set in metadata and videoredo is fixing it.

[spacecowboy2050 0]

@ebr is weird though that the same file can play fine one day but not the next. It shows that Emby on the shield can sometimes cope with the file but not always! I might try a shield factory reset too! It’s only the shield that has this problem!

[spacecowboy2050 0]

Factory reset the Shield. 

With the Emby for Android TV App (although I had to sideload an older version as the Beta one in the PlayStore didn't seem to be available) - a couple of files played with Direct Play, most transcoded or didn't play

With the Emby for Android App - A couple used Direct Play, a few used Direct Stream (even those that wouldn't play in the TV app), some used Transcode.

Tried the app on my Samsung Tv (which uses the Tizen AV player) - all play fine with Direct Play.

Also just tried with my Amazon Fire TV (pendant version) - that too is having similar issues ands only playing the resaved Emby recordings directly, others have a Direct Play error.

Next I'll try the Apple TV 4K!

 

Edited April 6, 2021 by spacecowboy2050

[sjabaker 9]

Just chiming in here to say that I encounter these kinds of problems too!

My setup is a Shield TV (latest "tube" model) on the Beta app (currently v2.0.07), accessing a server running in docker on a Synology NAS and occasionally also a server running on an old Windows PC (both servers are latest stable version, and use HDHomeRuns for DVR recording). I also occasionally use a Fire TV 4K stick (stable app, not beta). Both Shield and Fire TV have the same playback problems, and have always done so. My Shield was also factory reset quite recently (for a separate reason), and the problems remained the same afterwards. The problems seem to occur pretty much the same whether I have the 'pass direct path' option enabled or not.

I too can't identify a universal pattern, apart from problems definitely being much more common trying to play HD recordings (UK Freeview DVB-T2, H.264 & AAC_LATM) as opposed to SD ones (UK Freeview DVB-T, MPEG2 & mp2) - but when trying to direct play .ts files recorded by Emby DVR I frequently get any/all of the following:

1. Spinning circle for anywhere from ~5-10 secs to nearer a minute before playback starts, with SFN immediately showing a direct play error (& hence 'transcoding', i.e. re-muxing)
2. Playback starts as direct play (per SFN), but later on - usually after a very slow skip (see #3) - it switches to transcoding and SFN reports a direct play error
3. Sometimes a skip (whether single skip, multiple quick presses, or jumping to a new point in the timeline selected from the video-preview thumbnail) will take anywhere from 5-10s up to 20s or even more before playback resumes. I think I've seen this both while direct playing and while transcoding.
4. Sometimes when trying to start playback, and very occasionally when skipping, I get the spinning circle for anywhere from maybe 30 secs or more and then the Emby app simply restarts completely. Frequently if I then exit & force-close the app entirely, or force close it and then reboot the client device, the same file will then successfully play the next time I try (though I think on most occasions still with a direct play error).
5. If 'pass direct path' is enabled, sometimes when trying to start playback the spinning circle just continues indefinitely (I've waited >2 mins on occasion) until I force close the app. Again, sometimes it will then play after a force-close &/or device reboot.

I never have any issue playing the problem files in Kodi (via Embycon), and back when I ran a Plex server simultaneously alongside Emby I could also always direct-play the same Emby recordings in the Plex client without issue, plus any I test play fine in VLC and with ffplay on a PC - so it does seem to be something that exoplayer specifically has a problem with (though I thought Plex also used exoplayer, so maybe they they found some "special sauce").

@spacecowboy2050: interested to hear how you get on with the Apple TV - with the new version just announced looking like it has a "proper" remote I'm wondering if I might buy one and switch over if it doesn't suffer the same issues ... though I believe the ATV Emby client has issues of its own, including currently lacking the -10s/+30s skip function which I'm not sure I could live without

@ebr: I wonder if it might be related in some way to the following issue I encountered when I tried to work-around this whole problem by using a post-processing script to convert all DVR recordings into .mkv format, since it seems to relate to timing information in the file?

Specifically: trying to simply remux with ffmpeg would fail for most HD recordings, at least, with "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" and "Can't write packet with unknown timestamp". Apparently using the '-fflags +genpts' option can resolves this but only works for a .mp4 target not .mkv, and ffmpeg can't put the LATM-format aac audio of most Freeview HD streams into the mp4 container - so in the end I had to just give up on that idea entirely.

[Luke 37060]

HI, can you provide a sample file for testing? Thanks.

[sjabaker 9]

Hi Luke - I'll see what I can do... none of the files will fit within the 195MB limit for posting here (typically 700-900MB if SD, or ~1.3-2GB if HD) and using my usual tool (also VideoReDo as it happens) to shorten them is likely to "fix" the problem as a side effect as noted earlier.

I'll look at if I have a way to share a very large file (or do you have a preferred approach?) - or it may take a little time to either see if I can find a different way to shorten recordings that doesn't affect the issue, or find some really short programmes in the EPG to record and just see if any of those exhibit the problem...

[sjabaker 9]

OK - it seems as though using 'dd' works to truncate the files without affecting playback behaviour, so attached are a couple of initial files where I encounter a direct play error immediately upon starting playback (one HD, one SD). I'll aim to upload a few more to form a representative sample as I hit some on different channels or giving slightly different behaviours.

Bates Motel S02E09 The Box [direct play error at start] 1st50MB.ts MacGyver S03E10 Matty + Ethan + Fidelity [direct play error at start] 1st50MB.ts

[ebr 14910]

That sample produces that same error for me and it takes several seconds to do it so I think it is something about the headers or metadata that is incorrect and Exo doesn't like it.  Perhaps with the sample we can figure out exactly what it is.   You said ffmpeg doesn't like it either, correct?

[Carlo 4330]

Both of these play very quickly for me on Shield beta.  They remux but play quickly.
ffmpeg log does show some different errors in the media however.

[sjabaker 9]

@ebr: the comment about ffmpeg was just to note that a lot of Freeview HD (but only very rarely SD) recordings exhibited a particular issue when trying to remux directly with ffmpeg - however I can't say whether those were necessarily the same files that had direct play errors upon playback in Emby of the original .ts file, or not. In fact, when I checked, the two samples I provided previously both have no problem remuxing in ffmpeg, so it's certainly not a 100% linkage. It was more semi-idle speculation that if the broadcast streams do indeed include packets "with unknown timestamp" as the ffmpeg error says, perhaps that might be linked in some way to at least part of the problem? (Or maybe that's all just a red herring?)

I've also uploaded a couple more problem samples, which exhibited the following behaviour:

• Classic Albums - first play of full original recording file: ~15 secs to start with direct play error
• Classic Albums - first play of truncated 50MB file: a few secs to start with direct play error
• HIGNFY - first play of full original recording file: spinning circle for well over a minute then app reset to Emby home screen (not the screen from which playback was triggered) without ever managing to start playing the file
• HIGNFY - immediate second attempt to play the original file: ~12 secs to start with direct play error
• HIGNFY - first play of truncated 50MB file: ~5 secs to start with direct play error

If they might help, I can upload the server ffmpeg logs for most of those playback runs?

Note: based on the above, and the earlier samples, it does seem as though the delay until playback actually starts (when direct play fails immediately) may well be at least somewhat influenced by the file size/duration - perhaps exoplayer is searching through the file looking for something and not finding it, until it either falls back to remuxing or ultimately resets the app back to the home screen?

I don't see why that would be inconsistent even on the same file, though - e.g. the two attempts above to play the full HIGNFY file, but also in another recent test a direct sequence of 3 attempts in a row to play the same file resulted in error, no-error, then error again... so some timing or other variable effect seems to be involved as well.

I'm not certain, but I don't specifically recall ever seeing a direct play error other than when starting playback or sometimes when trying to skip forward/back some time after direct play playback had successfully started - i.e. never during normal continuous playing. What operation(s) does exo do both at the start and when skipping but not during playback, in particular that involve 'searching through' the file in some sense?

Classic Albums S10E01 Primal Scream Screamadelica [1st50MB].ts Have I Got News for You S61E04 [1st50MB].ts

[Luke 37060]

Hi @sjabaker have you tried the latest update to the android tv app?

[sjabaker 9]

I haven't noticed any particular improvement through to v2.0.15 at least.  (I just checked and it's now showing v2.0.16 but I don't know how long ago that update happened - I know it'd been on .15 for a while, and saw no noticeable difference). Is there a particular version above .15 (I see the release note thread lists up to .20 now) that you specifically expect to improve things, that I should look out for?

(N.b. I haven't tried the v2.x update on my Fire TV 4K stick yet - that's not normally connected, and isn't on the beta so was still on the latest v1.x non-beta version when last tested, and was showing basically the same behaviour.)

Also: let me know if more samples would be helpful (or even if it's worth trying to figure out a way to share a full file rather than just a truncated part) - unless work stops me from watching anything in the evening I probably encounter one or two new files every day that fail to direct play. E.g. over this recent testing period >50% (of 69 HD & 33 SD recordings) got a DP-error either immediately at the start or at a subsequent skip action during playback. (6 of them, all HD, initially caused app reset)