Jump to content

2 Rokus Buffer, 1 Doesn't


snodrog742

Recommended Posts

snodrog742

@@Waldonnis & @@speechles you two are my f’ing heroes!

 

Edit: Better but still skipped 3 times in a 20 minute episode ☹️

 

Sent from my iPhone using Tapatalk

Edited by snodrog742
Link to comment
Share on other sites

@@snodrog742

 

Although I couldn't experience the same issue as your roku 2 on my roku ultra I did find something odd in the media you linked via PM.

 

kBMbAXP.png

 

The video track is the 23rd source, and 24th is the audio. Normally video track is 1st, and audio is 2nd. Does this make a difference? I am not sure.. lol. It just stood out to me, as none of my media has subtitles first and video/audio streams at the end. That is the only explanation I have for this since direct stream causes the issue, it has to be related to FFmpeg. Does the odd placement of the video/audio stream justify the extraction of the streams being slower, enough to cause issues in delivery? Thats the question... 

Edited by speechles
Link to comment
Share on other sites

snodrog742

I dunno either.  All I know is the Roku is unusable as mostly everything Direct Streams or Transcodes and just never know when it'll happen.  @@Luke has this just been abandoned for @@speechles and @@Waldonnis to fix?  I feel like I'm up against a brick wall here.

Link to comment
Share on other sites

snodrog742

No, have you tried the latest release of the server?

 

We are always updated to the latest beta version.  Updates each night.

Link to comment
Share on other sites

Waldonnis

The video track is the 23rd source, and 24th is the audio. Normally video track is 1st, and audio is 2nd. Does this make a difference? I am not sure.. lol. It just stood out to me, as none of my media has subtitles first and video/audio streams at the end. That is the only explanation I have for this since direct stream causes the issue, it has to be related to FFmpeg. Does the odd placement of the video/audio stream justify the extraction of the streams being slower, enough to cause issues in delivery? Thats the question... 

 

Shouldn't matter, since Emby probably maps the streams in a more "standard" order with the video being first during output.  Even still, the drive would have to be exceptionally loaded or slow for the de/remux rate to end up being slower than the native framerate.  Of course, there could be an oddity at the container level, but I doubt it would be significant enough given that this isn't a high bitrate file.

 

Still skipping isn't good, though.  Something's going on here that I can't seem to reproduce and isn't making much sense.  If the skips are smaller than 2-3secs even with keyframe-aligned segments, then it's unlikely to be a decoding issue caused by segmenting (barring some weird latency, and you'd notice any 2-3sec skips really easily if it were dropping entire segments).  Back to the bitstream and spec document I go, I guess.

 

What I don't know is what the network situation looks like here.  Are all of the Rokus on the same network or is there anything networking-wise about the skipping Roku(s) that's different than the non-skipping Roku(s)?  Not blaming anything here, just trying to eliminate factors that might contribute to it.  I suppose we could also try remuxing the file with something like MKVToolNix to eliminate container weirdness, but I'm not convinced it'll make much of a difference.

Link to comment
Share on other sites

snodrog742

What I don't know is what the network situation looks like here.  Are all of the Rokus on the same network or is there anything networking-wise about the skipping Roku(s) that's different than the non-skipping Roku(s)?  Not blaming anything here, just trying to eliminate factors that might contribute to it.  I suppose we could also try remuxing the file with something like MKVToolNix to eliminate container weirdness, but I'm not convinced it'll make much of a difference.

 

Understandable.  Same wifi and on 5 Ghz.  That's why I'm even perplexed because there's nothing environment wise that I can see.  One could argue wifi, but like you, that would be much more noticeable and most likely show a "Loading..." screen.  I have thought about converting a file too for fun.  

 

It just sucks this is the TV in my living room and not easily accessible for testing.  I could switch them out but really haven't been inclined to do so yet.

Link to comment
Share on other sites

Waldonnis

Understandable.  Same wifi and on 5 Ghz.  That's why I'm even perplexed because there's nothing environment wise that I can see.  One could argue wifi, but like you, that would be much more noticeable and most likely show a "Loading..." screen.  I have thought about converting a file too for fun.  

 

It just sucks this is the TV in my living room and not easily accessible for testing.  I could switch them out but really haven't been inclined to do so yet.

 

Exactly my thought.  If there was a network problem, it would more likely result in excessive buffering rather than just skipping bits during playback, but it would be great to rule out the location/network situation entirely regardless (no rush, but if you feel spunky, try swapping them around).  I'll keep poking at the file in the meantime, as it's probably something that I'm just missing.  Oh, one other question, is it only skipping after seeking or will it also do it if you start playback from the very beginning?  Sounds like an odd question, but it might help me narrow down what to look for when wading through the bitstream.  Also, I probably already asked, but if you happen to notice any specific time where it'll reliably skip, that would be enormously helpful.

Link to comment
Share on other sites

If you could try beta server 3.6.0.2 and let me know if that makes a difference, that would be helpful. thanks.

Link to comment
Share on other sites

snodrog742

Any results?

I finally just got to test tonight. Success! 2 episodes and no skipping. Thank you!

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

It was an issue with the server's range request responses. The great news is that the issue was limited to the beta server the whole time, except for a few days that 3.5 was live. It was then resolved in 3.5.1. 

 

Thanks.

  • Like 1
Link to comment
Share on other sites

snodrog742

It was an issue with the server's range request responses. The great news is that the issue was limited to the beta server the whole time, except for a few days that 3.5 was live. It was then resolved in 3.5.1. 

 

Thanks.

 

Thanks for figuring it out.  Has been great watching shows without issue or frustration.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...