snodrog742 31 Posted June 23, 2018 Share Posted June 23, 2018 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 More sharing options...
Luke 36886 Posted June 24, 2018 Share Posted June 24, 2018 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 More sharing options...
tidusjar 55 Posted June 24, 2018 Share Posted June 24, 2018 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 More sharing options...
Luke 36886 Posted June 24, 2018 Share Posted June 24, 2018 Yes I will, thanks. Link to comment Share on other sites More sharing options...
LindsayCole 0 Posted June 24, 2018 Share Posted June 24, 2018 Thank you @@tidusjar @@Luke - this is affecting Emby server quite harshly. I appreciate the attention to it. Link to comment Share on other sites More sharing options...
snodrog742 31 Posted June 29, 2018 Author Share Posted June 29, 2018 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 More sharing options...
Luke 36886 Posted June 29, 2018 Share Posted June 29, 2018 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 More sharing options...
speechles 1912 Posted June 29, 2018 Share Posted June 29, 2018 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 More sharing options...
snodrog742 31 Posted June 29, 2018 Author Share Posted June 29, 2018 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 More sharing options...
Jdiesel 1112 Posted June 29, 2018 Share Posted June 29, 2018 Are you testing all the Rokus in the same location? Wired or Wifi connections? Link to comment Share on other sites More sharing options...
tidusjar 55 Posted June 29, 2018 Share Posted June 29, 2018 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 More sharing options...
Jdiesel 1112 Posted June 29, 2018 Share Posted June 29, 2018 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 More sharing options...
speechles 1912 Posted June 29, 2018 Share Posted June 29, 2018 (edited) 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 June 29, 2018 by speechles Link to comment Share on other sites More sharing options...
tidusjar 55 Posted June 29, 2018 Share Posted June 29, 2018 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 More sharing options...
Luke 36886 Posted June 29, 2018 Share Posted June 29, 2018 EnableTotalRecordCount=false is an optimization you can apply when you don't need to know the total count. 1 Link to comment Share on other sites More sharing options...
snodrog742 31 Posted July 2, 2018 Author Share Posted July 2, 2018 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 More sharing options...
Luke 36886 Posted July 3, 2018 Share Posted July 3, 2018 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 More sharing options...
snodrog742 31 Posted July 3, 2018 Author Share Posted July 3, 2018 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 More sharing options...
Luke 36886 Posted July 3, 2018 Share Posted July 3, 2018 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 More sharing options...
snodrog742 31 Posted July 3, 2018 Author Share Posted July 3, 2018 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 More sharing options...
LindsayCole 0 Posted July 3, 2018 Share Posted July 3, 2018 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 More sharing options...
snodrog742 31 Posted July 3, 2018 Author Share Posted July 3, 2018 (edited) @@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 July 3, 2018 by snodrog742 1 Link to comment Share on other sites More sharing options...
Luke 36886 Posted July 4, 2018 Share Posted July 4, 2018 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 More sharing options...
snodrog742 31 Posted July 4, 2018 Author Share Posted July 4, 2018 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. 1 Link to comment Share on other sites More sharing options...
Luke 36886 Posted July 4, 2018 Share Posted July 4, 2018 Ok that's different, I thought we were just talking about buffering here. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now