Jump to content

Playback problems when direct streaming on Roku ("Loading..." shown every few minutes)


auujay
Go to solution Solved by speechles,

Recommended Posts

auujay
 
When watching rips of Blu-Ray TV shows on my Roku2 I am getting frequent "Loading..." messages when the videos are direct streaming (allowing or forcing transcoding works resolves the problem).
 
The server is running Version 3.2.17.0 on unRaid, though I have noticed the issue for a few days now and it still occurred with at least 3.2.15.0. The server log is attached and shows some exceptions that seem to align with playback.
 
Using the beta Roku app tries to direct stream the content and has the issue. I sent the logs from this app via built-in log submission at 22:18 EDT (GMT-4) on 2017-5-16 (the logged in user is 'Andrew').
 
Using the Blue Neon Night v4.16 app has the issue when in "auto-detect" or "direct" modes but when forced to transcode it works OK. The "official" Emby app v2.25 works fine as it transcodes the content (the transcode log is attached below).
 
In the server log there seem to be errors that align with the times when playing the video has errors that look like:
 Error HttpServer: Error processing request
	*** Error Report ***
	Version: 3.2.17.0
	Command line: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /config -restartpath /usr/lib/emby-server/restart.sh
	Operating system: Unix 4.9.19.0
	64-Bit OS: True
	64-Bit Process: True
	Mono: 4.8.1 (Stable 4.8.1.0/22a39d7 Mon May 15 22:31:44 UTC 2017)
	Processor count: 2
	Program data path: /config
	Application directory: /usr/lib/emby-server/bin
	System.IO.IOException: Unable to write data to the transport connection: Connection reset by peer. ---> System.Net.Sockets.SocketException: Connection reset by peer
	  at System.Net.Sockets.Socket.EndSend (System.IAsyncResult result) [0x00033] in <5641e4edad4f4464ba58c620a7b8ea48>:0 
	  at System.Net.Sockets.NetworkStream.EndWrite (System.IAsyncResult asyncResult) [0x0005f] in <5641e4edad4f4464ba58c620a7b8ea48>:0 
	   --- End of inner exception stack trace ---
	  at System.Net.Sockets.NetworkStream.EndWrite (System.IAsyncResult asyncResult) [0x000af] in <5641e4edad4f4464ba58c620a7b8ea48>:0 
	  at System.IO.Stream.<BeginEndWriteAsync>m__8 (System.IO.Stream stream, System.IAsyncResult asyncResult) [0x00000] in <dbb16e0bacdc4a0f87478e401bc29b6c>:0 
	  at (wrapper delegate-invoke) System.Func`3[System.IO.Stream,System.IAsyncResult,System.Threading.Tasks.VoidTaskResult]:invoke_TResult_T1_T2 (System.IO.Stream,System.IAsyncResult)
	  at System.Threading.Tasks.TaskFactory`1+FromAsyncTrimPromise`1[TResult,TInstance].Complete (TInstance thisRef, System.Func`3[T1,T2,TResult] endMethod, System.IAsyncResult asyncResult, System.Boolean requiresSynchronization) [0x00002] in <dbb16e0bacdc4a0f87478e401bc29b6c>:0 
	--- End of stack trace from previous location where exception was thrown ---

Does this indicate a network problem on my end?  "System.IO.IOException: Unable to write data to the transport connection: Connection reset by peer. ---> System.Net.Sockets.SocketException: Connection reset by peer" seems like something bad but I don't think I ever had this problem in the past.

 

I try to encode my Blu-Rays in a way that the Roku app can direct steam them so my server is not forced to transcode.  I don't know if this is a case where I accidentally changed my encoding settings so these files are actually different from what I used to do in the past or if Emby changed (server side or in the Roku apps) that is now causing the issue.  Going back to older episodes that I am pretty sure used to direct steam just fine now show the problem so I think this is related to an Emby change and not a change in the files I am using.

ServerLog_2017-05-16.txt

TranscodeLog_2017-05-16.txt

Edited by auujay
Link to comment
Share on other sites

That error just means the Roku closed the connection because it didn't like something. Perhaps something in the video that it didn't like, or perhaps the network connection couldn't keep up and therefore it just gave up. The 4 ref frames is on the high side for 1080p - should be OK but perhaps with a smaller margin for error. All of these apps are using Roku video player components so generally when a direct play fails it is something that will need to be reported to Roku.

Link to comment
Share on other sites

auujay

This Roku has a gigabit connection to the server so I doubt the problem is bandwidth issue on the network.  Your 4 ref frames comment is interesting, I am certainly no encoding guru and I basically just used similar setting from what I used to use on DVDs.  I really thought these used to play fine in direct mode but maybe those previously were getting transcoded on the sever and I never noticed. I have some other blu-ray presets  I use in Handbrake that don't explicitly set the ref frames, I will try re-encoding some of these with those and see if it changes it.

 

Do you recommend I actually try to file a bug report with Roku?  Maybe they had a system update or something that made it so now my player can't handle these videos...

Link to comment
Share on other sites

Maybe they had a system update or something that made it so now my player can't handle these videos...

 

It is possible. It has happened more than once in the past where system updates have caused video playback issues.

Link to comment
Share on other sites

mikeraburn

The data port on the Roku isn't a gigabyte port. 100mbps max. FYI

 

Sent from my SM-T560NU using Tapatalk

  • Like 2
Link to comment
Share on other sites

  • Solution

Its the age of those older devices. In later firmwares, Ive noticed roku changed how the video player works. On roku 3 (and newer roku2's) they have "broken" support for some things. There is an issue on these devices when refframes are 1 (see here and scroll through to my replies in the thread). There are also minor problems inherited by the 7.6 firmware update on various devices. The best suggestion is to let roku know, as luke suggested, using this link. Since roku cannot possibly test everything, they depend on users to help them debug their firmwares. They have an open beta where select users can test the new firmware prior to major release, but even this doesnt guarantee an issue wont slip by. This is where you can get them to acknowledge the issue, or deny it. They usually admit when they made a mistake and work on fixing it as fast as they can.

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

auujay

The data port on the Roku isn't a gigabyte port. 100mbps max. FYI

 

Sent from my SM-T560NU using Tapatalk

 

Fair enough, my server router are gigabit but I should have figured the Roku was less.  Anyway, this is hard wired connect on a trivial network so this is likely not a bandwidth issue.

 

I will followup with Roku and see if anything comes of it.  So far I have been really happy with my Roku as playback device that is cheap, has a hardwired network port, and IR receiver for my harmony.  If Roku does not fix this I am not sure if I would just pay $90 for a Premier+ or re-encode a bunch of blu-rays (lame...).

 

Thanks for the quick replies everyone.

Link to comment
Share on other sites

mikeraburn

I am pretty sure upgrading your Roku will not be a quick fix,

 

Do submit your issue to ROKU and just encode future media to run correct.

 

I myself have a trivial network so I feel your pain in diagnosing playback issues!

 

If you can and want to, PM me a link to one of your encodes and I will test one of your encodes on my ULTRA and low powered NAS. 

Link to comment
Share on other sites

As follow up on this end:

 

https://forums.roku.com/viewtopic.php?f=28&t=101844&p=560333#p560333

 

I have given roku details on exactly what I know. So they should be up to speed as much as I am. If anyone else with issues wants to also post their discoveries in the above thread it wouldn't hurt. We have done our due dilligence.

Link to comment
Share on other sites

farside847

Ah oh. I think I ran into this too. Every 2 minutes it said loading. I exited and hit resume and I got another 2 min.

 

So is this the reframe number that causes this? I can check my files. What is the right number?

 

What roku units does this impact?

Edited by farside847
Link to comment
Share on other sites

farside847

Hmmm, did more reading on the thread and it seems that my situation is a little different. My trouble videos have 5 refframes , but I do have an older unit (roku3 4200) that has been impacted by other firmware issues in the past.. Hmmmm. I will test out a few simple re-encodings and report back. Maybe I should use a separate thread. The funny thing is I never noticed it until I got the new app. I can test on the blue app to confirm that I suppose

Link to comment
Share on other sites

Waldonnis

Everything I encode with h.264 at 1080p has 4 reference frames and has no issues with older Roku 3 (4200) models, so I doubt it's that unless new issues have appeared in firmware (haven't seen any so far, but who knows how other models' builds may differ).  I know there was an issue with 1 reference frame in the past (not sure if that was ever resolved) and some models may not deal with 8+ very well, but 4 is pretty conservative compared to some of the files I've seen (higher numbers are pretty common in lower-resolution encodes).  If my rather poor memory serves, I believe the older Roku 2 had a lower "cap" on reference frames, but I'm pretty sure it was closer to 8 rather than being as low as 4.  Even 5 shouldn't be an issue, again unless a new bug was introduced in the latest firmware, but I haven't confirmed it locally with the newest firmware rev.  I'll try to generate some quick test files and see what goes with 5 reference frames (I have all of my test source files around still anyway from my HEVC tests).
 
I'm curious if something else may be going on with the OP's file (GOP or other issues), but the info from the logs implies that it's a rather generic encoding that should work okay: sub-5Mb bitrate (even adding the DTS audio, we're not talking a high bitrate), standard framerate, no anamorphic scaling needed, etc...basically, nothing that the decoder or demuxer would obviously be choking on from a stream perspective.  The only thing that raises an eyebrow is the "avi" in the file name.  Was this video originally in AVI and just remuxed to MKV or was it re-encoded from an AVI source file (or is the avi in the name just meaningless)?  Only reason I ask is because I remember some limitations with h.264 in AVI containers (that required some trickery to overcome), but don't quite remember what they were or if any of that would cause problems with/after a remux/container swap.

Link to comment
Share on other sites

farside847

Hmmm, did more reading on the thread and it seems that my situation is a little different. My trouble videos have 5 refframes , but I do have an older unit (roku3 4200) that has been impacted by other firmware issues in the past.. Hmmmm. I will test out a few simple re-encodings and report back. Maybe I should use a separate thread. The funny thing is I never noticed it until I got the new app. I can test on the blue app to confirm that I suppose

I need to calm down and drink less coffee. I decided I would restart the server and roku to get clean log files of my "issue", and it is no longer reproducible. I will report if it comes back. :)

Link to comment
Share on other sites

auujay

... The only thing that raises an eyebrow is the "avi" in the file name.  Was this video originally in AVI and just remuxed to MKV or was it re-encoded from an AVI source file (or is the avi in the name just meaningless)?  Only reason I ask is because I remember some limitations with h.264 in AVI containers (that required some trickery to overcome), but don't quite remember what they were or if any of that would cause problems with/after a remux/container swap.

 

The .avi file name here is meaningless, I happened to notice this lately when watching Mr. Robot which likes to get cute with their episode names (using "leet-speak" and file extensions); my fault for using a confusing example. I have made a sample file from a different show that has the same problem and hopefully will be able to send it to Roku tomorrow (once they give me the info).

 

I thought I was using pretty standard Handbrake settings that I have previously confirmed seemed to work on my Roku2 when playing direct (mainly noticeable for me because that is the only way I get surround sound).  What is the best way to check the bitrate of the file overall (not sure where you spotted 5 Mb/sec? I seem to only have this problem when the Blue Midnight app is reporting >10 Mb/sec.  In fact the other day I was watching a movie that did not show the issue until about an hour in, I wonder if it was right on the threshold and some scene pushed it over the limit and caused the issue.

Edited by auujay
Link to comment
Share on other sites

auujay

After sending a sample file to Roku and working with one of the Roku reps via PM on their board, I was able to resolve my issue by changing the display output of the Roku from 720p to 1080p.  My TV is only 720p so when I originally installed the Roku I just selected that to try and get everything to match.  Evidently the latest firmware update added changes that impaced its ability to downscale these vides to 720 so keeping them at 1080 on the Roku resolves it.

 

From Roku:

7.6 added a new feature called the universal OSD for this type of Roku (which is based on the Roku-3). This is an additional overlay plane we are now using to display various dialogs. This coupled with the additional dma required to downscale the 1080p image to 720p is causing the roku to get behind. As a matter of display resolution though, it is better to let us output 1920x1080i/p to your TV and have it downscale to 1366x768 then for us to output 1280x720p and have it upscale to 1366x768.

You should get a slightly better video display as you are getting an extra 80 columns and 48 rows using all the pixels on your panel.
Edited by auujay
Link to comment
Share on other sites

Waldonnis

That is very weird, but if it works...

 

That reply does somewhat answer a question I had about their scaler implementation, though, so I'm glad you reposted the info [emoji2]

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