Playback freezing on Fire TV

[thebnich 5]

Hello, I have a strange issue where Fire TV playback is freezing rather frequently for certain videos. What makes it strange is that the lock-ups happens only on the Fire TV -- my laptop browser and iPhone are unaffected, and they're accessing the same video on the same server through the same network. The video is direct playing to all of these devices, so this isn't related to transcoding variations.

 

Given the above, I suspected that my Fire TV might not have a good Wi-Fi connection. To put this to the test, I ran Emby Server on my Macbook to my Fire TV, playing the same video with no transcoding. Surprisingly, playback is perfect!

 

Unless I'm missing something, the only remaining possible cause would be that there's a Fire TV-specific playback bug triggered by latency/dropped packets. 

 

I sent a log at 5:51 PM EST, with user The Loves. I played the problematic video for 3 minutes, and the video froze at each of these times for 5-10 seconds: 1:24, 1:39, 2:21, 2:31, 2:43, 2:49. As a sanity check, I immediately played the same video from the same server on my laptop and iPhone, and again, playback was perfect on both. FWIW, the server generated no ffmpeg logs for Fire TV or iPhone, but did generate an ffmpeg-redux for my laptop.

 

Assuming this is reproducible on any Fire TV Stick (Gen 2), I'm happy to share an account on my server with access to this video. I'm eager to get this figured out!

[Luke 36999]

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

[thebnich 5]

Yes, I sent a log. See 4th paragraph for user/time details.

Edited December 7, 2019 by thebnich

[ebr 14902]

Hi.  It looks like the bitrate is just too high for the connection (which is remote).  What is the bitrate of this item?

[thebnich 5]

mediainfo reports an overall bitrate of 14.2 Mb/s.

 

However,

 

the lock-ups happens only on the Fire TV -- my laptop browser and iPhone are unaffected, and they're accessing the same video on the same server through the same network. 

 

would indicate that the server -> home router connection is capable of handling the load. Likewise:

 

I ran Emby Server on my Macbook to my Fire TV, playing the same video with no transcoding. Surprisingly, playback is perfect!

 

indicates that the home router -> Fire TV is also capable.

 

So it seems that server -> Fire TV should be fine, no?

[ebr 14902]

When you tested with the mac book it was also over the same remote connection?

[thebnich 5]

If you're talking about the Macbook as a server, then no, the Macbook is serving to the Fire TV over the local home network. But if you're talking about as a client, yes: both the Macbook and iPhone are able to play the same video over the same remote connection.

[ebr 14902]

I ran Emby Server on my Macbook to my Fire TV, playing the same video with no transcoding. Surprisingly, playback is perfect!

 

So the above test also eliminated the remote connection correct?

[thebnich 5]

Correct. The point of that test was to verify that a) the Fire TV is capable of processing the given bitrate, and b ) the router -> Fire TV connection can handle the load.

Edited December 7, 2019 by thebnich

[thebnich 5]

 

Unless I'm missing something, the only remaining possible cause would be that there's a Fire TV-specific playback bug triggered by latency/dropped packets. 

 

Recently, I've been able to reproduce this much more easily playing 4K content. After some tests, I can all but confirm that this caused by latency, as suspected.

 

Testing with analiti on the Fire TV, iperf3 is still showing high throughput (>100Mbps) between the Fire TV and remote server, which eliminates bandwidth as the culprit. Serving from my Macbook on the local network fixes the issue as I described before, but if I use comcast to simulate 150ms latency (typical for the remote server), the intermittent freezing happens exactly as it does when streaming from the remote server.

 

I guess I don't know if this is actually a bug or expected behavior. @@ebr, is it normal that latency would cause intermittent freezing despite high bandwidth? Since my server is in the Netherlands, I've known that the connection had relatively high latency all along, but my assumption was that this would only delay playback when starting or after seeking. Since content is buffered, why would high latency affect anything once playback has begun?

[ebr 14902]

Content is not really "buffered" these days.  We use protocols that are much more of a JIT type of delivery, delivering small segments of video at a time so latency definitely can be a problem.

 

That said, there is a setting in the app called "Player Buffer Size".  You could try setting that to Large.

[thebnich 5]

Content is not really "buffered" these days.  We use protocols that are much more of a JIT type of delivery, delivering small segments of video at a time so latency definitely can be a problem.

 

Huh, that's news to me. Why is that? Wouldn't a client-side buffer help solve a number of issues? Aside from my problem here, couldn't it also significantly improve Auto quality detection, where the max bitrate could be dynamically adjusted depending on how quickly the buffer empties and fills?

 

 

That said, there is a setting in the app called "Player Buffer Size".  You could try setting that to Large.

 

Yeah, I did give that a try. No noticeable impact, unfortunately.

 

 

Edit: Also, if content isn't buffered, what exactly would that "Player Buffer Size" setting be changing?

Edited April 20, 2020 by thebnich

[ebr 14902]

The player still buffers some amount of video ahead but it isn't like 10 years ago when you could pause a video and wait for a bunch of it to be loaded into the player and then continue from there.

 

Streaming protocols have moved to a much more efficient method of delivery (especially when expanded to all traffic on the net) than that.

[thebnich 5]

The player still buffers some amount of video ahead

 

I'm sure it varies, but around what amounts would that be? I mean, as long as the buffer is even just a few seconds ahead, that should more than cover 150ms of latency, right?

[ebr 14902]

I'm sure it varies, but around what amounts would that be? I mean, as long as the buffer is even just a few seconds ahead, that should more than cover 150ms of latency, right?

 

Actually, with HLS delivery the buffer size may not even come into play.

[thebnich 5]

OK, but every streaming protocol must have some form of buffering, right? After all, chunks can't be available instantly on even the fastest local network.

 

150ms latency isn't orders of magnitudes higher than a "good" 30-50ms latency, so I'm having trouble understanding why there should be any discernible difference. Given latency L and the next chunk play time T, the next chunk must be requested before T-L to continue smooth playback, where the buffer must be able to hold at least L*bitrate. This should hold true for all L, whether it be 5, 30, 150, or 500. I'm sure this is an egregious oversimplification, but hopefully you get my point.

 

Is this not something that can be improved in Emby? I suspect that if I were to introduce a similar latency simulation at the router level and then tried Netflix or other streaming services, everything would still work as expected (albeit with longer delays)--but maybe I'm wrong.

Edited April 20, 2020 by thebnich

[Luke 36999]

Usually the answer is reduce bitrate rather than buffer for a long period of time. That's what services like Netflix do as they have multiple copies of media readily available in a number of different qualities

[ebr 14902]

Hi.  You are assuming your latency only applies once per segment of video.  The reality is that latency exists for every request made so can have a very broad multiplier effect on actual throughput.  As Luke said, lowering the bitrate is the way this is dealt with.

 

The old style of "buffering" is an incredibly inefficient use of bandwidth - especially when applied across the entire net.  If services were still doing that now I'm sure we would have seen the entire Internet come down over the past few weeks .

[thebnich 5]

Hi.  You are assuming your latency only applies once per segment of video.  The reality is that latency exists for every request made so can have a very broad multiplier effect on actual throughput.  As Luke said, lowering the bitrate is the way this is dealt with.

 

Makes sense--thanks for the explanation. It was indeed an egregious oversimplification!

 

 

The old style of "buffering" is an incredibly inefficient use of bandwidth - especially when applied across the entire net.  If services were still doing that now I'm sure we would have seen the entire Internet come down over the past few weeks .

 

I'm not trying to push for an old style of buffering; when I say "buffer", I just mean "whatever chunks/frames are being held in memory ready to played" in the existing implementation. I assume there must be some form of "buffer" -- that's really all I was trying to show in my oversimplified example above -- although the math is obviously very wrong. If there's really no buffer at all, playback would be freezing between every single request while it waits for the next segment, right?

 

With that in mind, I was just curious why the existing buffer/queue/chunk count/in-memory-whatever-you-call-it can't be increased to mitigate higher latency. Maybe my assumption that the buffer would increase linearly is wrong, and the "broad multiplier effect" would apply to the buffer size as well, making this impractical?

Edited April 21, 2020 by thebnich

[Luke 36999]

The segments download sequentially and it will go as fast as it can, up to whatever in-memory storage limit is set by the video player. On many devices we use the platform built-in video player and therefore don't even have the ability to control this. In some cases we do, but not all, so that's why the most practical, universal answer is reduce the size of the data and then it will get there quicker.

[thebnich 5]

Ok, thanks. I prefer transcoding only as a last resort (especially when playing x265 content on a shared host with no graphics acceleration), so I suppose I should look into finding a closer host or creating smaller encodes.

[rooser11 8]

have you tried kodi/mrmc as a front end player to troubleshoot?

[danergo 28]

I'm in the same solution, where buffering can greatly help: streaming remotely from home nas. Bandwidth is quite OK, but latency might not. HLS chunk sizes are too small, so video usually breaks, stops.

 

I think buffering really helps, because I can see it is applied in the Emby Theatre in Windows, and for example in the LG TV Emby App. These players works perfectly with higher bitrate streams too.

 

@@thebnich, you could give these two a try, I think you'll be amazed how great are they. And it is simple: they prebuffer a bit at the beginning, and noone get hurt.

 

I did also tried Kodi, I think there is a combination which works, but Emby looks so much better than Kodi. (maybe it can be just the video replacement)

 

But as Android uses ExoPlayer which is brutally flexible, I think this buffering thing can be easily solved at least for the beta testers.

 

What do you guys think?

[ebr 14902]

 I think you'll be amazed how great are they. And it is simple: they prebuffer a bit at the beginning, and noone get hurt.

 

Hi.  Upon what are you basing that assumption?

 

Have you tried adjusting the "buffer" setting in the app?

[danergo 28]

The problem solved, it was actually a router configuration which prevented FireTV to keep playing. But still interesting, as some other players could play.

 

(Yes, I have tried each of the 3 buffer setting, but not much change had they brought).