Long waittime for remote content

[henryford 11]

Hey guys,

 

when playing media through the TV app on my Fire TV I experience problem with content stored remotely. There is no problem with content that is locally available (harddrives) to the server, but whenever I select anything that is on a remote filesystem (NFS, CIFS, GDrive, ...) I have to wait up to 1 1/2 minutes until the video starts playing.

 

I tested it within the browser and the regular Android app too (which I also installed on the Fire TV to test there): There's no problem. The files take a little to load (1-2 seconds) when compared to harddrive based files (instant playback), but they play back in a matter of seconds.

 

I'm using the latest Android TV App on my Fire TV 2nd Gen and the problem appeared just recently, it worked fine two weeks ago.

[Luke 37185]

Hi there, can we please look at an example? Please attach the information requested in how to report a media playback issue. thanks !

[henryford 11]

Thanks for getting back to me.

 

I sent the logs via the menu at 9:54 (CEST).

 

Logged in User was Thomas.

 

The following actions were performed:

1. Login

2. Selection of TV Show "Scrubs" (completely stored on GDrive)

3. Selection of Season 01

4. Selection of Episode 01

5. Starting Playback

6. Popup "Experiencing Problems?" appears - selecting "No" (Yes doesn't change anything, I tried that a few times before)

7. After a long wait, the popup appears again - selecting "No" again

8. Playback starts

 

Mediainfo:

 

Video

Title480P H264

CodecH264

AVCYes

ProfileHigh

Level41

Resolution720x480

Aspect ratio4:3

AnamorphicNo

InterlacedNo

Framerate23.9760246

Bitrate2107 kbps

Bit depth8 bit

Pixel formatyuv420p

Ref frames1

NAL4

 

 

Audio

TitleEng Dolby Digital stereo Default

Languageeng

CodecAC3

Layoutstereo

Channels2 ch

Bitrate192 kbps

Sample rate48000 Hz

DefaultYes

Containermkv

Path/mnt/decrypted/media/tv/Scrubs/Scrubs.-.S01E01.-.My.First.Day.DVD.mkv

 

 

Should I also attach a log when I playback from Browser/Android App?

Edited August 8, 2018 by henryford

[ebr 14949]

Hi.  The media is encoded in an unsupported format so the app is going through several iterations of failure before finally fully-transcoding it so it will play.

 

Specifically:

E/EventLogger( 4486): com.google.android.exoplayer2.ParserException: Lacing only supported in SimpleBlocks.

We've seen this before but very rarely.

[henryford 11]

Hey!

 

Ah, you mean unsupported by the Fire TV? In that case - is there an option to enable full transcoding by default? Because as said, no other player has problems with the files...

 

That also means that remote vs local content on the server side actually has nothing to do with it?

[ebr 14949]

@@Waldonnis do you have any insight with this particular encoding issue?

[Waldonnis 148]

E/EventLogger( 4486): com.google.android.exoplayer2.ParserException: Lacing only supported in SimpleBlocks.

 

 

@@Waldonnis do you have any insight with this particular encoding issue?

 

Huh, that really is uncommon if it's what I think it is.  The only thing I can think of that might "fix" the file would be to remux it.  I quoted "fix" because there's nothing wrong with it per se, but a lot of parsers don't implement every feature of the Matroska spec (so this isn't a surprise).

 

It might require going to another container like mp4 or mpegts, then back to Matroska if that's your preferred container, since ffmpeg (and MKVToolNix/mkvmerge) often copies a lot of the old container-level data during a straight mkv->mkv remux rather than parsing the streams and recreating it from scratch.  The only way to force it to start fresh is to either mux from elementary streams (can be a pain) or use another container as an intermediary.  You can try doing a straight mkv->mkv remux like so and see if it helps:

ffmpeg -i input.mkv -map 0 -c copy output.mkv

If it doesn't, you can do a two-part remux like this (or use pipes, but that's more complicated):

ffmpeg -i input.mkv -map 0 -c copy out1.mp4
ffmpeg -i out1.mp4 -map 0 -c copy output.mkv

[henryford 11]

Thanks for helping out - I'll try to remux a few of those files (I'm fine with mp4) and see how it goes!

[ebr 14949]

Thanks @@Waldonnis!

[henryford 11]

Unfortunately, this didn't fix the problem. I'll try some more things and report back, but currently it isn't really working on the Fire TV for me (Chromecast, by the way, has none of those issues either)

[Waldonnis 148]

Unfortunately, this didn't fix the problem. I'll try some more things and report back, but currently it isn't really working on the Fire TV for me (Chromecast, by the way, has none of those issues either)

 

Hmm, that's odd.  Worst case, if I could see one of the affected files, I might be able to figure out what's going on with them.

 

Just to catch up a bit and see what else could be contributing to this, these files aren't stored locally (on a drive connected to the server) at all?  I wasn't clear about where they were physically located.

[henryford 11]

I'd be happy to provide examples for you.

 

 

I'll do some more testing tonight and get back to you, I will also test with local vs remote content.

 

(In this scenario: Yes, those are stored completely off-site (namely on a Google Drive). They are also encrypted using encfs - so the way it goes: Google Drive -> Mountpoint (provided through rclone) -> encfs -> Emby)

 

I could imagine that that setup makes problems, but it doesn't with the regular Android App (have yet to test that on the AFTV) and the Webbrowser, so it seems to be AFTV or Android TV App related. Just as a pointer - I get around 20-25 MB/s download from the GD). Also, it worked fine a few days/weeks ago - unfortunately I can't pinpoint the exact time it got borked.

 

But yesterday I experienced the same kind of problems with a locally stored mkv. When I start playback, it hangs for a while until the popup appears and when selecting "No", after a while the video appears.

 

I'll send a few more logs and at least 2/3 examples (via PM) your way tonight.

Edited August 10, 2018 by henryford

[Waldonnis 148]

Great, thanks.  It's definitely puzzling.  I was mostly curious since off-site storage of anything can sometimes cause intermittent/temporary delays when reading, but if it's happening only with a specific client and a specific subset of files, it's likely something with the files themselves or on the playback device side (or both).

[henryford 11]

Sorry, didn't make it Friday - will provide everything tomorrow evening.

[henryford 11]

Sorry again, just so busy right now. Hope to provide everything over the weekend.

[henryford 11]

I finally got to it - I sent the report at 18:45 CEST, logged in user was again Thomas.

 

This time I did the following:

1. Open app (auto login enabled)

2. Resume playing Scrubs (remote content)

3. Press No on the problem screen, video starts playing in horrible quality (you actually can count the pixels, audio is okay)

4. Stop playback

5. Start playback of Ducktales (locally stored on HDD)

6. Video playback starts immediately, but in horrible quality

7. Stop playback

8. Start playback of Shooter (locally stored on HDD)

9. Video playback starts immediately, but in horrible quality

 

I'll send you all three files in a PM in a few minutes.

[ebr 14949]

Looks like your auto bitrate test is coming up with 21kb/s - yes 21 K...

 

That's why you have horrible quality.  The two issues are probably related and due to some large latency of some sort.

[henryford 11]

That... sounds horrible. I wonder why this is - I do not have any problem with Netflix or Amazon Prime... and when using other devices neither do I with emby. Pinging from the shell using adb also results in less than 20ms latency. So something else is interfering.

 

Setting the bitrate to a fixed amount probably results in what we seen before - I reinstalled the application just to be sure before these tests. I think I had the speed set to a fixed 100mbps (which is my line speed).

[henryford 11]

And just as I posted this - I think I found the reason: IPv6 isn't working like it should on the AFTV (or my host - since Netflix, for example, uses IPv6 as well) as it seems. When I'm using curl to get a file from my server, it craps out when using my hostname (which resolves to an IPv6 address). But when using the IPv4-IP I can actually download the file. So, emby probably has the exact same problem.

 

Edit: I'll test this theory and report back shortly.

 

Edit2: This fixed it! Changed my DNS for that specific subdomain so it only return an IPv4 address and all is well again. Thanks for staying with me on this one.

Edited August 18, 2018 by henryford

[Luke 37185]

Thanks for the feedback.