Movie stream stops and won't resume

[jhs39 13]

Yes the firmware was the cause of the bug and Roku has acknowledge it.  And Plex users reporting the same issue in the Roku forum.  You may got the firmware update late, who knows.

I must be amazingly lucky then because I'm watching 2 or 3 movies on Plex every day and I haven't been having that issue.  It hasn't happened a single time in Plex.

[Waldonnis 148]

Plex never completely stops playing where it throws you out of the film and requires you to restart like Emby and it never freezes more than once during a film.  The freeze only happens maybe 10% of the time and I figured it was an issue with my old computer setup rather than a Roku-related bug, but I suppose it could be the way Plex deals with the Roku issue.

Once Plex starts remuxing, it doesn't ever stop remuxing until the film is done, so you would only see a buffering pause once. If they had tried to go back to direct streaming before the next 4GB boundary, you would see more than one pause.  You may not always see a brief pause anyway, depending on file size; sub-4GB files aren't affected by the bug at all, so they'll direct play start to finish.

 

Was the firmware update that caused the problems recent? I never encountered this issue in Emby until two or three weeks ago.

Yep, 7.2 (build 4100) is the culprit and it was pushed out a couple of weeks ago now. Some Rokus received it faster than others since they deploy their updates over several days, so it's entirely possible that yours didn't download the buggy firmware until after others had already run across this.

 

Just to explain the distinction between a remux and a full transcode...

 

Your video files (MKV, MP4, etc) are actually containers that "contain" one or more individual "streams" - such as a stream containing the video, one or more audio streams, subtitle streams, etc.  Remuxing basically means that you're taking those streams and just copying them as they are to a new container.  So, converting a file from MP4 to MKV without altering those streams would be what we call a remux.  Even adding new streams to existing files can be a remux (I recently added DTS audio tracks to all of my existing files, for instance), since we aren't converting any streams to another format - just copying the existing streams into a new container (or file).  Likewise, taking a MKV/MP4 and streaming it via HLS is pretty much just copying the streams into a new container, since we're not altering them at all.  Copy operations are very "cheap" processor-wise.  It's not much different than copying a file on your hard drive to the processor, really - all it has to do is read and write, but not modify the data itself.

 

Let's say, however, that your existing file wouldn't normally play on your device because the resolution is too high or the video or audio codecs aren't supported.  In this case, we would need to convert the streams themselves to something we can play.  This type of operation is what we would consider a transcode in this context.  For example, if your file has only a DTS audio track, but your Roku isn't hooked up to a receiver that can decode DTS, we would need to convert that audio track to AAC (and likely downmix it to stereo).  These operations are more processor-heavy, as they require the CPU to actually decode the existing stream(s) and re-encode them with another codec (lots of math), and why you definitely notice when a movie is being transcoded (especially on older hardware).  Just transcoding audio streams is almost always easier on the processor than video transcoding, but both require more processor power than remuxing would.

 

Apologies if you knew all of this!  I just wanted to clarify the terms in case you didn't, and explain more about why remuxing may not be noticeable load-wise compared to transcodes.

[jhs39 13]

Once Plex starts remuxing, it doesn't ever stop remuxing until the film is done, so you would only see a buffering pause once. If they had tried to go back to direct streaming before the next 4GB boundary, you would see more than one pause.  You may not always see a brief pause anyway, depending on file size; sub-4GB files aren't affected by the bug at all, so they'll direct play start to finish.

 

Yep, 7.2 (build 4100) is the culprit and it was pushed out a couple of weeks ago now. Some Rokus received it faster than others since they deploy their updates over several days, so it's entirely possible that yours didn't download the buggy firmware until after others had already run across this.

 

Just to explain the distinction between a remux and a full transcode...

 

Your video files (MKV, MP4, etc) are actually containers that "contain" one or more individual "streams" - such as a stream containing the video, one or more audio streams, subtitle streams, etc.  Remuxing basically means that you're taking those streams and just copying them as they are to a new container.  So, converting a file from MP4 to MKV without altering those streams would be what we call a remux.  Even adding new streams to existing files can be a remux (I recently added DTS audio tracks to all of my existing files, for instance), since we aren't converting any streams to another format - just copying the existing streams into a new container (or file).  Likewise, taking a MKV/MP4 and streaming it via HLS is pretty much just copying the streams into a new container, since we're not altering them at all.  Copy operations are very "cheap" processor-wise.  It's not much different than copying a file on your hard drive to the processor, really - all it has to do is read and write, but not modify the data itself.

 

Let's say, however, that your existing file wouldn't normally play on your device because the resolution is too high or the video or audio codecs aren't supported.  In this case, we would need to convert the streams themselves to something we can play.  This type of operation is what we would consider a transcode in this context.  For example, if your file has only a DTS audio track, but your Roku isn't hooked up to a receiver that can decode DTS, we would need to convert that audio track to AAC (and likely downmix it to stereo).  These operations are more processor-heavy, as they require the CPU to actually decode the existing stream(s) and re-encode them with another codec (lots of math), and why you definitely notice when a movie is being transcoded (especially on older hardware).  Just transcoding audio streams is almost always easier on the processor than video transcoding, but both require more processor power than remuxing would.

 

Apologies if you knew all of this!  I just wanted to clarify the terms in case you didn't, and explain more about why remuxing may not be noticeable load-wise compared to transcodes.

Actually, I'm not a techie so your explanation was very helpful.  I wasn't aware that Plex or Emby remuxed files in that way.  I guess I thought if anything was being changed that meant a transcode of the file was being performed.  Thanks for the clarification.  

[Waldonnis 148]

I'm glad the explanation was useful

 

Hopefully, Roku gets this bug fixed soon, as it really benefits all of us (Plex users included).  I have a bunch of workarounds for it at this point, but none of them are solutions that I would recommend to anyone, as some have some annoying side effects or just require some manual effort/programming knowledge.  I really wish Roku considered this worthy of an emergency hotfix - sadly, there's no indication that they do and it seems to be something they're going to just include in the next release.

 

On the positive side, it's exposed that the Emby Roku channel needs better playback error handling - adding that to my list of things that I might be able to help with/contribute, since I'm exploring and tweaking the code anyway.  I wasn't aware of how Plex handled playback errors before your posts, so I'm thankful to you for making me curious enough to check that out.

[speechles 1917]

The code to fallback to remux/transcode during directplay is there. It could do that, if direct fails, choose remux, if remux fails go to full transcode. There is already code in place to do just that. That code is ineffective because it also checks for directplay/directstream flags before allowing it. This extra check breaks the fallback. We can remove the extra check and have the app fallback to remux/transcode immediately after directplay fails. This will of course, require the user has transcode rights on the server. It also depends on, use auto detection be used in the blueneon app. I can make the app work like plex does quite easily. I just didnt because the original emby roku app doesnt either.

 

Plex is using MKV with mpeg-dash for streaming. This requires a custom video player. Emby isnt there yet, we still use HLS with m3u. Mpeg-dash in MKV allows better control over audio-streams and subtitles. Whereas HLS leaves some room for improvements.

Edited August 2, 2016 by speechles

[Waldonnis 148]

I saw the fallback code in there, but didn't really read through it at the time and wasn't sure if it was complete or just left over from before.  Thanks for confirming that it does exist and that I'm not misremembering.  I've been busy moving furniture and dealing with brand new appliances that don't work, so I just haven't had time to look at the code lately to be sure.  Even watching a 2hr movie lately takes 4hrs+ thanks to interruptions...grrr.

 

It sounds like removing the extra check would be a pretty easy "fix"/feature addition, but can you think of any additional issues that may pop up if we do?  Granted, I can see the case where transcoding is disabled for a user, but that could probably be checked directly (assuming there is a server query for transcode permission state - I haven't looked) and dealt with in another way that's TBD.  At the very least, showing some type of "error during playback" notice may be nice to add so people aren't just scratching their heads if playback fails at some point after it's been started.  I know it sure confused me when it happened the first time Even if it was fairly generic text that included the error code that the player process returns, it would probably be helpful for others during troubleshooting.  If a user can't transcode due to permissions, such an error message may suffice and could suggest enabling transcoding if possible.

 

Thoughts?  Not pushing work on you, speechles (and welcome back from holiday)!  I'd be happy to work on this, but it may be a few days before I can get to it.

[speechles 1917]

https://forums.roku.com/viewtopic.php?f=34&t=95617&p=537740&sid=68bd9d989448fe76a05b86e618b51547#p537740

 

Roku is now running public beta tests of the updated firmware that fixes this issue. It should be available "in the wild" soon. This is a good thing.

 

Sent from my Nexus 7 using Tapatalk

[Happy2Play 8242]

Well there is a confirmation on link above that the beta firmware fixed the issue.    So it is a matter of how long we will have to wait for a official release.

Edited August 21, 2016 by Happy2Play

[jhoff80 87]

Is anyone else seeing this same behavior when transcoding?  I've dropped the bitrate down to even 500kbps SD and the server is definitely transcoding, but I'm getting the exact same behavior (playback stops, on a permanent 'Loading...' screen, at different places in every movie, but consistently in the same place in the same movie).

[Happy2Play 8242]

I haven't seen this issue since I started "Force Transcode" of all movies in Neon Blue app.
 
Looks like Roku may be holding onto this update until regular release cycle.
 

Currently the only way to get the new firmware is to send a pm to either myself, or rokushawns.
rokudale

[Happy2Play 8242]

I requested and received firmware update build 4139 and it resolved the issue.

[mediacowboy 438]

Requested the beta. Will wait and see when I get it. This is pretty big deal for me and my users. Even a friend I converted to Emby has quit using the Roku apps because of this bug and is streaming stuff to his Xbox by DLNA.

Edited September 24, 2016 by mediacowboy

[jhs39 13]

I got the beta firmware.  It worked for a couple of movies then I started having problems with ANYTHING I watched with Emby.  Movie, TV episode, porn--it doesn't matter. 

[speechles 1917]

I got the beta firmware. It worked for a couple of movies then I started having problems with ANYTHING I watched with Emby. Movie, TV episode, porn--it doesn't matter. Whatever I try will play for a couple minutes then I get an error message on the Roku to wait like it's having trouble transcoding or something. The problem is my computer CPU shows 7% and ram shows 32% so Emby isn't transcoding anything and the video never resumes. I gave up and went back to Plex. Everything that freezes on Emby (which is everything, now) plays perfectly on Plex, so this isn't an issue with bad files or with my computer. Emby was initially working with the beta Roku firmware so I don't know if a beta update on the server side broke functionality or not, but it seems like a giant waste of time to even use Emby considering how buggy it is.

You just have sour grapes. I read your posts on plex. I also remember you stating before you were just going to plex. This was a year ago or more. So I can see where you were headed as soon as I saw the nickname. I know emby works fine on the roku, and even better with the blue neon app. It is the "ROKU FIRMWARE" issue which is out of our control when roku will update it. So blame the right product for the problem.

 

Maybe you should give emby another try, and this time compare when using the blue neon app on your roku. With emby server 3.0.7200.0 and rebuilding my library db from scratch entirely. I can say, OMG the server is fasssttt. It makes the roku app even better when the server is instantly responsive with results. I am impressed at how fast it is. Ridiculously fast == /me impressed. Good job @@Luke

Edited September 24, 2016 by speechles

[jhs39 13]

I already have the beta Roku firmware that is supposed to fix the problem.  I don't have sour grapes. 

[Happy2Play 8242]

Sorry but after the firmware update I have played about 20 movies and haven't had an issue.  As for how long it took to get the update, well I PM'd RokuDale on  Friday the 16th and got the update on Sunday the 18th.

[jhs39 13]

I got Emby to start playing videos again on Roku by rolling back from the latest Beta Build to the stable one.  Of course, the geniuses who code Emby have made this as difficult as possible for no obvious reason.  There used to be a menu item in settings to choose the type of build you were on but they got rid of that.  Trying to install the Stable Build over the Beta just reverts back to the Beta Build.  Uninstalling Emby and reinstalling the Stable Build also results in Emby immediately reverting back to the Beta Build.  The only way to change the build that I could find was to go to  C:Users/UserName/AppData/Roaming/Emby-Server/config, opening the system.xml file and changing the line <System Update Level> from Beta to Stable.  After I did that I was able to install the stable version and it stayed the stable version.  I would love one of the many Emby apologists to explain why it should be necessary to do all this to change the build you are on from Beta or Dev back to Stable.  I'm not a computer programmer so having to go through all this to do something as simple as install the stable build of Emby makes zero sense to me.  

[Luke 37010]

I got Emby to start playing videos again on Roku by rolling back from the latest Beta Build to the stable one.  Of course, the geniuses who code Emby have made this as difficult as possible for no obvious reason.  There used to be a menu item in settings to choose the type of build you were on but they got rid of that.  Trying to install the Stable Build over the Beta just reverts back to the Beta Build.  Uninstalling Emby and reinstalling the Stable Build also results in Emby immediately reverting back to the Beta Build.  The only way to change the build that I could find was to go to  C:Users/UserName/AppData/Roaming/Emby-Server/config, opening the system.xml file and changing the line from Beta to Stable.  After I did that I was able to install the stable version and it stayed the stable version.  I would love one of the many Emby apologists to explain why it should be necessary to do all this to change the build you are on from Beta or Dev back to Stable.  I'm not a computer programmer so having to go through all this to do something as simple as install the stable build of Emby makes zero sense to me.  

 

If you look at Chrome for example, you just pick stable/beta/dev at the time of installation. It is now the same with Emby Server.

[Scott750 29]

Where's my devid in the roku info? Was trying to request the beta patch. Also how do install it?

[mediacowboy 438]

Devid is your serial number.

When approved for the beta it will auto install.

[speechles 1917]

Where's my devid in the roku info? Was trying to request the beta patch. Also how do install it?

Roku homescreen >> Settings >> System >> About

 

Your device ID is the serial number. Once you ask rokudake for the beta firmware it takes a day or so. Once your roku is approved for the beta firmware it becomes available. The roku automatically updates itself every 24 hours. You can manually update via Settings >> System >> System Update.

[Scott750 29]

Devid is your serial number.

When approved for the beta it will auto install.

Roku homescreen >> Settings >> System >> About

 

Your device ID is the serial number. Once you ask rokudake for the beta firmware it takes a day or so. Once your roku is approved for the beta firmware it becomes available. The roku automatically updates itself every 24 hours. You can manually update via Settings >> System >> System Update.

Great, thank you!

[pclausen 41]

Will have to send a note to rokudake.  I have 3 Roku 3's that all have this issue I think.

 

In my case, it only happens during movie playback (not TV Episodes).  My movies are all Blu-Rays muxed via MakeMKV to only contain the primary video track and the best Audio track (TrueHD/Atmos, or DTS-HD and even a couple of DTS-X titles now).  I never transcode any of my Blu-Ray titles using Handbrake or the like.  Just pull out the best video and audio tracks and leave them untouched otherwise.  Everything playback flawlessly on my main HTPC.

 

All 3 Roku's are hardwired and all are set to 30Mbps.

 

When playing back TrueHD and DTS-HD titles, the audio is always transcoded, and in some cases, like with Atmos titles, all the way down to 2 channel AC3.  Anyway, the issue is what after about 10 minutes, it is as if someone hit the back button and I'm taking back to the movie info page.  I can then chapter skip and manually rewind to just after where the glitch happened, and then continue watching for another 10 minutes or so, and then repeat until I make it through the movie.  This is VERY annoying.

 

Fingers crossed the beta firmware will fix the issue.

 

I'm probably going to pick up one of the new Roku Ultra's that was just released to see if it will improve the audio transcode issue I'm having with the HD audio formats.  Its a real shame the Roku's don't support audio bitstreaming.

Edited October 11, 2016 by pclausen

[Happy2Play 8242]

Yep that is the issue the firmware update/patch will fix.

[Scott750 29]

How long does it take for that admin to send me the beta patch? I requested it yesterday.