Jump to content

2 Rokus Buffer, 1 Doesn't


snodrog742

Recommended Posts

snodrog742

I'm stumped here.  I have 3 Rokus and an Apple TV.  Apple TV has been fine but the Rokus are outsmarting me currently.

 

One Roku is a Roku 3, others are Roku 2's.  For testing I used both Roku 2's.

 

The Rokus that buffer seem to be Direct Streaming while the one that doesn't buffer is Direct Playing and comes down to the "container".  I used the same file in both tests though.

 

Server log for Roku playing and never buffering in 20 minutes:

 

Log-2.txt

 

Server and ffmpeg log for one of the Rokus that does buffer constantly:

 

Log-3.txt

Log-4.txt

 

 

 

Both were set at 6 Mbps bitrate.  I've tried lower and made no difference and 6 Mbps worked fine for the first Roku and never buffered once.  What am I missing?

Link to comment
Share on other sites

Hi @@snodrog742, you have software called Ombi that is hammering your emby server with tens of thousands of requests over a short period of time:

2018-06-22 22:25:45.303 Info HttpServer: HTTP GET http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d3112fe830647b621b11bf8945dfd1a. UserAgent: Ombi
2018-06-22 22:25:45.308 Info HttpServer: HTTP Response 200 to 192.168.1.5. Time: 6ms. http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d3112fe830647b621b11bf8945dfd1a 
2018-06-22 22:25:45.316 Info HttpServer: HTTP GET http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d3130c803d11c76cdd13ec5bf821f65. UserAgent: Ombi
2018-06-22 22:25:45.321 Info HttpServer: HTTP Response 200 to 192.168.1.5. Time: 6ms. http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d3130c803d11c76cdd13ec5bf821f65 
2018-06-22 22:25:45.330 Info HttpServer: HTTP GET http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d313f9b97e279d43f018b5626209dfa. UserAgent: Ombi
2018-06-22 22:25:45.334 Info HttpServer: HTTP Response 200 to 192.168.1.5. Time: 4ms. http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d313f9b97e279d43f018b5626209dfa 
2018-06-22 22:25:45.343 Info HttpServer: HTTP GET http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d317c8dbca6bec079cb0581a66b9d08. UserAgent: Ombi

Try shutting down Ombi and keep it shutdown, then restart your Emby Server. Thanks.

Link to comment
Share on other sites

tidusjar

Hi @@snodrog742, you have software called Ombi that is hammering your emby server with tens of thousands of requests over a short period of time:

 

2018-06-22 22:25:45.303 Info HttpServer: HTTP GET http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d3112fe830647b621b11bf8945dfd1a. UserAgent: Ombi
2018-06-22 22:25:45.308 Info HttpServer: HTTP Response 200 to 192.168.1.5. Time: 6ms. http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d3112fe830647b621b11bf8945dfd1a 
2018-06-22 22:25:45.316 Info HttpServer: HTTP GET http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d3130c803d11c76cdd13ec5bf821f65. UserAgent: Ombi
2018-06-22 22:25:45.321 Info HttpServer: HTTP Response 200 to 192.168.1.5. Time: 6ms. http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d3130c803d11c76cdd13ec5bf821f65 
2018-06-22 22:25:45.330 Info HttpServer: HTTP GET http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d313f9b97e279d43f018b5626209dfa. UserAgent: Ombi
2018-06-22 22:25:45.334 Info HttpServer: HTTP Response 200 to 192.168.1.5. Time: 4ms. http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d313f9b97e279d43f018b5626209dfa 
2018-06-22 22:25:45.343 Info HttpServer: HTTP GET http://192.168.1.3:8096/emby/users/1140baa320a643f0a2f14cd63aec1eda/items/6d317c8dbca6bec079cb0581a66b9d08. UserAgent: Ombi
 
Try shutting down Ombi and keep it shutdown, then restart your Emby Server. Thanks.

Hey Luke, regarding this are you able to response to this: https://github.com/tidusjar/Ombi/issues/2230

 

It would be good to see what you recommend, so I can resolve this.

Link to comment
Share on other sites

snodrog742

Hey all,

 

Finally did some more testing tonight on two of our servers.  Again on Roku 2.

 

First test, first server with Ombi running - Direct Streams file and buffers after 10-15 seconds. Logs:

 

Log-2-JG-with ombi.txt

Log-JG-ffmpeg-with ombi.txt

 

Second test, same server without Ombi - Direct Streams and buffered once and then played for 20 minutes except with pixelation throughout episode. Logs:

 

Log-5-JG-no ombi.txt

Log-JG-ffmpeg-no ombi.txt

 

Third test, different server without Ombi - Same file but this time Trancsodes and buffered once but no more and no pixelation.  Logs:

 

Log-3-Logan-ffmpeg-no ombi.txt

https://od.lk/d/Ml8xNTg0ODM0MDZf/Log-4-Logan-no%20ombi.txt

 

Link to comment
Share on other sites

I saw Ombi committed the improvements to their dev branch so you may just want to be on the lookout for their next version.

Link to comment
Share on other sites

What are your settings for: H264 encoding preset and h264 encoding CRF? You can find these on the server dashboard under transcoding.

 

There are trade offs, buffering vs quality. If you want to end the buffering use "Ultrafast" for preset and 25 for CRF. If you want quality, there is "superfast" and 21. I tend to use "superfast" and 25 which is always quick to start and clean enough to watch without distracting macroblocking.

Link to comment
Share on other sites

snodrog742

I saw Ombi committed the improvements to their dev branch so you may just want to be on the lookout for their next version.

We have already pulled the new version. @tidusjar was updated.

 

What are your settings for: H264 encoding preset and h264 encoding CRF? You can find these on the server dashboard under transcoding.

 

There are trade offs, buffering vs quality. If you want to end the buffering use "Ultrafast" for preset and 25 for CRF. If you want quality, there is "superfast" and 21. I tend to use "superfast" and 25 which is always quick to start and clean enough to watch without distracting macroblocking.

 

I will check this.  Thanks!

Link to comment
Share on other sites

Jdiesel

Are you testing all the Rokus in the same location? Wired or Wifi connections?

Link to comment
Share on other sites

tidusjar

I have made the improvements, but there are still things that i'd like to do. You have a super large library, the api call to get your movies i'm assuming is putting a lot of load on the server. @@Luke is there a param I can pass for paging? e.g. skip 0 take 500? So the size returned is smaller, but with a few more calls

Link to comment
Share on other sites

Jdiesel

I can't recall what the default ombi sync frequency is but I changed mine to run once every 24 hours at 3:00am with no noticeable loss in functionality. 

Link to comment
Share on other sites

is there a param I can pass for paging? e.g. skip 0 take 500? So the size returned is smaller, but with a few more calls

 

There is startIndex and Limit. When omitted startindex is assumed 0. So &limit=200 .. first 200.. &startindex=201&limit=200 .. next 200 ... etc

 

to know the total, you need to include &enabletotalrecordcounts=true in the query .. then look for totalrecordcount... this is if you want to know after the first fetch of 200, that there is only 450 to get, so you can do the next 200, and after that the last 50...entirely doable

Edited by speechles
Link to comment
Share on other sites

tidusjar

Not sure if enabletotalrecordcounts is needed, seems to return the TotalRecordCount property without that.

 

Thanks for the info though!

Link to comment
Share on other sites

EnableTotalRecordCount=false is an optimization you can apply when you don't need to know the total count.

  • Like 1
Link to comment
Share on other sites

snodrog742

What are your settings for: H264 encoding preset and h264 encoding CRF? You can find these on the server dashboard under transcoding.

 

There are trade offs, buffering vs quality. If you want to end the buffering use "Ultrafast" for preset and 25 for CRF. If you want quality, there is "superfast" and 21. I tend to use "superfast" and 25 which is always quick to start and clean enough to watch without distracting macroblocking.

 

Thanks again for this.  I've tried quite a few settings and currently at "Slow" and "18" to test and the best SO FAR.  I still get episodes that "glitch" or skip just a few seconds with no buffering but super annoying as you miss a line or two of dialogue.  Any ideas on this?  Buffering has disappeared though, currently.

Link to comment
Share on other sites

Have you tried instead to reduce the in-app quality setting? i would suggest doing that first and leaving server transcoding settings on defaults. thanks.

Link to comment
Share on other sites

snodrog742

Have you tried instead to reduce the in-app quality setting? i would suggest doing that first and leaving server transcoding settings on defaults. thanks.

 

Yes, but who wants to watch something at 1 Mbps and like 480p quality when a Roku right next to it can play 720p 6Mbps on the same server.  This ONLY happens on Direct Stream vs Direct Play...

Link to comment
Share on other sites

direct stream will have a little bit more overhead than direct play and that's why it might require bumping down the setting.

Link to comment
Share on other sites

snodrog742

direct stream will have a little bit more overhead than direct play and that's why it might require bumping down the setting.

 

So you're going on record to state it is normal and completely acceptable for a show to just skip entire scenes without buffering (ie: no "Loading" screen) just because it Direct Streams?  I'm pretty sure that's the most cop out excuse I have ever read.

Link to comment
Share on other sites

LindsayCole

So you're going on record to state it is normal and completely acceptable for a show to just skip entire scenes without buffering (ie: no "Loading" screen) just because it Direct Streams?  I'm pretty sure that's the most cop out excuse I have ever read.

 

@@Luke - I just want to put this out there to make sure we are on the same page. This is on a dedicated server, with a passmark of 14k (dual cpu Xeon). 6GB RAM, no other services on machine other than base OS. This occurs when no other streams are happening as well.

 

Something funky is happening here, we just want to figure out why. I can replicate @@snodrog742 locally on my Roku. This is not a bandwidth related issue, nor is it a capacity issue.

 

Thanks for everyones help!

Link to comment
Share on other sites

snodrog742

@@Luke - I just want to put this out there to make sure we are on the same page. This is on a dedicated server, with a passmark of 14k (dual cpu Xeon). 6GB RAM, no other services on machine other than base OS. This occurs when no other streams are happening as well.

 

Something funky is happening here, we just want to figure out why. I can replicate @@snodrog742 locally on my Roku. This is not a bandwidth related issue, nor is it a capacity issue.

 

Thanks for everyones help!

 

I'll echo this again.  My response may be a bit aggressive, I'll admit.  But, I've submitted every log requested without being asked and this Roku is where I spend very little time other than lunch breaks and just want to watch a show to try and relax for a few minutes.  I could switch it to a different device but would like to be helpful as well and diagnose these issues as I know how difficult it can be.  Just wanting to figure out what and why its happening.

 

Thanks.

Edited by snodrog742
  • Like 1
Link to comment
Share on other sites

I'm aware that you probably don't want to hear this but I think it is a network problem of the data just not being sent quickly enough. Whether that is due to your network or the network adapter on the roku I am not sure.

Link to comment
Share on other sites

snodrog742

I'm aware that you probably don't want to hear this but I think it is a network problem of the data just not being sent quickly enough. Whether that is due to your network or the network adapter on the roku I am not sure.

 

I would totally accept that answer if there was any sign of buffering.  That's been eliminated.  The file literally skips scenes somewhere with no buffering or network logs showing issues.  Unless I'm missing a line indicating this in the logs?  And again, you forget, one of the EXACT identical Rokus does not do this.  Sure, one could argue a defect on one Roku doing it but pretty doubtful.

 

Again, this comes down to Direct Stream vs Direct Play.  Every time Direct Play gets used, NO issues.  Direct Stream - issues occur.  My understanding is Direct Play would use similar if not the same/more amount of bandwidth and works fine.  Direct Stream re-packages (or whatever) the container and then sends, resulting in the issue.  That definitively points to some software/muxing/ffmpeg/etc. issue and not network.

 

Correct me if my understanding is incorrect.  Thanks.

  • Like 1
Link to comment
Share on other sites

Ok that's different, I thought we were just talking about buffering here.

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...