Jump to content

Movie stream stops and won't resume


Happy2Play
 Share

Recommended Posts

Happy2Play and Waldonnis - what roku are you using? I am wondering if this is related to only the original roku 3. Maybe roku 4's work and thats why others can not reproduce?

Link to comment
Share on other sites

I only have two original Roku 3s (4200), as I have no 4k monitors here and no reason to "upgrade" to a 4.  If anyone has a newer Roku 3 or 2 (4230 or 4210 respectively), I'd be curious to see if they're experiencing the same, since they are all identical hardware.  If the 4 plays the same files that a 3 crashes on, that would definitely be good to know.  Sadly, my cable company sucks and I can't invite someone to my server to test some stuff on a Roku 4 (yay double NAT, and I have no interest in setting up a VPN just for this).

 

Apache-wise, there are a few portable "installs" out there.  I just picked one at random that seemed to be truly portable.  You could also set up a RPi to do it, if you have one available and your media is available via NFS or SMB.  I'm planning to retask my old pi for that, but haven't gotten around to it (it's one of the original batch, so it's limited anyway).

Link to comment
Share on other sites

Rmp isnt the same. It is using the usb pathways through the process. This isnt the same as the video player resolving sources over http.

 

No matter what I try I cant get this to happen to me. Not that I am angry at that fact, just curious. My setup does not support DTS. Not sure if it matters, hdmi is auto, audio is detected as DD. In the blueneon app, shows as DD only too. Roku is over ethernet

 

Rather than lower the bitrate to force the video to transcode, because its not the video part that is the issue. It is the audio that is the problem. In HLS it appears the issue isnt present. So choose "force transcode" in the blueneon app. Is the problem still present doing it this way? This should just copy the streams into an m3u8 playlist and use HLS.

 

The roku does try to extract the dts core from dts-hd enabled files. It might be doing this part wrong.

 

http://forums.roku.com/viewforum.php?f=34

 

If you post about the issue in this section you should get a reply. You need to give as much information as possible, and ask a roku* moderator to forward to their internal developer bug list. Then it will get the attention it deserves.

 

Looking deeeper I found this:

http://forums.roku.com/viewtopic.php?f=34&t=95617

 

This is the exact issue already posted.

 

Thanks speechless, I posted my research to the roku forum, maybe will get a reply. I'm curious, what roku do you use?

Link to comment
Share on other sites

Thanks speechless, I posted my research to the roku forum, maybe will get a reply. I'm curious, what roku do you use?

I have an old roku3 when the roku3 first came out in 2013, and a 2014 roku3. They behave identically for me. I cant make movies stop for me, but mine are mostly lower bitrate rips. I can make HLS dump audio on me for several videos I have. This means the audio just drops out and never recovers, only silence. But I can resume and play past that point with sound. It happens during loud explosions and such with AC3. Its predictable and happens same place, same exact, every time. So we just have to wait for roku to fix it.. again. Hopefully they expidite a fix this time and it isnt left waiting for the quarterly firmware update that occurs every 3 months. Edited by speechles
Link to comment
Share on other sites

I have an old roku3 when the roku3 first came out in 2013, and a 2014 roku3. They behave identically for me. I cant make movies stop for me, but mine are mostly lower bitrate rips. I can make HLS dump audio on me for several videos I have. This means the audio just drops out and never recovers, only silence. But I can resume and play past that point with sound. It happens during loud explosions and such with AC3. Its predictable and happens same place, same exact, every time. So we just have to wait for roku to fix it.. again. Hopefully they expidite a fix this time and it isnt left waiting for the quarterly firmware update that occurs every 3 months.

 

Interesting. So we have the same Roku.

 

Do you think the AC3 sound issue you mention is the cause of my error too? The behavior is different. Yours continues to play with no sound, mine stops playing and will not resume.

 

Can you share your encoding settings for one that worked? I would like to try it.

Link to comment
Share on other sites

I tested a couple older movies in my library that were H264/AC3/mp4 with lower audio bitrates and they played without issue.  And current encodes with audio at 640 fail around 20-30 minutes.

 

So will have to test a new movie encoded with lower audio.  As all of these worked prior to 7.2 firmware.

Link to comment
Share on other sites

All of my AAC tracks are 360kbps (a bit under the recommendations); DTS/AC3/TrueHD/DTS-HDMA are all at their standard rates.  Some fail, some don't, and in every case I've tried where DTS fails, the extracted-on-the-fly DTS-HDMA core works (same exact data and bitrate, but one works and one doesn't).  I actually wouldn't suspect a "passthrough" stream bitrate to have anything to do with these issues, since the device isn't really processing them anyway - barring bitrates that would overwhelm the stream buffer's capabilities, demuxing code, or HDMI capabilities, but we would likely see other issues in those cases and the demuxer would fail even with RMP if that was the failure point.

 

In cases where an HLS stream is supplying a high-bitrate AAC audio stream that overwhelms the device's decoding capabilities, then I'd expect audio dropouts like speechles has seen.  Worth a test, but not something I can even try in my case since it's not like I can re-encode a DTS stream with the tools I have here  :lol:

Link to comment
Share on other sites

Go figure that the one file that failed to play immediately is the one file I didn't really look at...and may have been the key to everything.

 

While watching range requests in my apache log, I noticed that one of my test files failed when the Roku requested the range starting around the 4GB mark. Looking back over my "failed immediately" Thor file, I noticed that it was barely over 4GB.  Reflecting on my previous experience with file size affecting the timing of the failure, I trimmed Thor down to just a 3KB over 4GB and it failed almost immediately.  Trimming it down to 3.99GB and it's playing beautifully!

 

I looked at the first Amazing Spider-Man movie, which played fine (unlike the sequel which died 20mins in) - of course, it was under 4GB.  Eyeballing the size of one of my other crashes and knowing the length of the movie, I wouldn't doubt that the failure on that aligns with that "4GB remaining" point in the file.

 

So, I'm wondering how many files that are failing are over 4GB and if anyone has seen one fail that's under that.  If it's only 4GB+ files failing, we have a winner, and some valuable info to hand over to Roku's engineers.  Also, if the 20GB+ files some of you have that are failing are also failing later on if you scrub past the failure point, I would love to know if they do so at predictable intervals (notably 4GB, 8GB, 12GB, etc).  I'll test for the same shortly with an untouched BR rip mkv I have here.

 

Update: 

To test my theory, I checked Fellowship of the Ring (total size 12.8GB) and scrubbed to roughly where the 4GB boundaries would be. The movie predictably died at three points corresponding to the 12, 8, and 4GB points in the file.  Note: these are 12, 8, and 4GB from the end of the file, not the beginning, so you may have to do some rough calculations to figure out where the boundary would fall in min/secs when testing locally.

Edited by Waldonnis
  • Like 2
Link to comment
Share on other sites

So, I'm wondering how many files that are failing are over 4GB and if anyone has seen one fail that's under that.  If it's only 4GB+ files failing, we have a winner, and some valuable info to hand over to Roku's engineers.  Also, if the 20GB+ files some of you have that are failing are also failing later on if you scrub past the failure point, I would love to know if they do so at predictable intervals (notably 4GB, 8GB, 12GB, etc).  I'll test for the same shortly with an untouched BR rip mkv I have here.

 

Genius!

 

I can confirm that all of my movies that are under 4GB work (I have tested like 50) and files over 4GB fail (I have tested like 20). I will try to cut down a few of my files to smaller sizes, while maintaining all the same quality and encoding settings to test this further.

 

Does anyone else have files over 4GB that work, and on what Roku model?

Link to comment
Share on other sites

I was following your post on their forums and was happy to see RokuDale file the bug report.  Thanks for doing that!

Link to comment
Share on other sites

A small update: RokuDale posted in a different thread on their forums that they've been able to reproduce this issue in their lab, not that I'm surprised.  It's encouraging, though, since it means we'll likely see a fix in the future.  I'm hoping they don't wait to push a fix until the next quarterly, but we'll see.

 

Also, choosing "Force transcode" in Blue Neon doesn't apparently request a simple remux, but rather forces an audio transcode to AAC as well (at least for DTS; haven't tried an AC3 or EAC3 yet).  If I can find some time this week, I'll look into fixing that - unless speechles beats me to it, which is likely since my time is a bit limited for a few days and I have to fight for time on the AVR-connected Roku  :D.  Just a heads-up for folks using HLS to work around the 2^32 file size issue but want to play surround audio tracks.

Link to comment
Share on other sites

@@Waldonnis The problem is DTS isnt allowed with HLS using m3u. Has roku changed this restriction? Unless they have we cant remux DTS as is, it can be transcoded as AAC, MP3, or AC3. You can choose how this is handled in the app preferences. You can set everything to AC3, and use force surround setting on top. This will assure the roku always makes use of the right codec when transcoding. By default when transcoding audio, the blueneon app will default to AAC.

 

Thanks for the info about roku being aware of the problem too. That means they can correct it. It doesnt mean that is all the issues on their plate. I bet because of the sheer volume of issues reported they wait for a quarterly update. You can get a sooner taste and test firmware nightlies for them by signing up for the roku beta insider program and sign their NDA.

Edited by speechles
Link to comment
Share on other sites

@@Waldonnis The problem is DTS isnt allowed with HLS using m3u. Has roku changed this restriction? Unless they have we cant remux DTS as is, it can be transcoded as AAC, MP3, or AC3. You can choose how this is handled in the app preferences. You can set everything to AC3, and use force surround setting on top. This will assure the roku always makes use of the right codec when transcoding. By default when transcoding audio, the blueneon app will default to AAC.

 

Thanks for the info about roku being aware of the problem too. That means they can correct it. It doesnt mean that is all the issues on their plate. I bet because of the sheer volume of issues reported they wait for a quarterly update. You can get a sooner taste and test firmware nightlies for them by signing up for the roku beta insider program and sign their NDA.

 

Streaming DTS via m3u seems to work fine for me here, but independent verification would be great.  I adapted one of my test channels to play two of my "must watch with DTS sound" movies using HLS and they're playing with the proper DTS audio track, so I just kept that side-loaded on that Roku for now.  Godzilla's roar is just not the same when downmixed, after all!

 

I thought about going the beta tester route, but have to consider it a bit first.  I was employed as QA a while back for a company, so if I can't devote the time to properly test, I don't bother (and their NDA is ridiculous, in my opinion, but that's another matter).  I'm content to wait for a fix, personally, and I know that the Roku 4 issues being reported alone are a lot to deal with.  I just hope it doesn't take forever....

Link to comment
Share on other sites

  • 2 weeks later...

I'm having the exact same problem and ended up switching to Plex because it plays everything without any issues.  I prefer the Emby Roku interface but if it isn't going to play movies without stopping there's no point in using it.  I've read all the posts and obviously this is a known issue but I'm not clear on something--is this considered an Emby issue or a Roku issue?  Since Plex plays everything fine I'm assuming this is an Emby issue but some people are referring to Roku being aware of the problem.

 

Is there an ETA on a fix so I know when I can use Emby again? 

Link to comment
Share on other sites

I'm having the exact same problem and ended up switching to Plex because it plays everything without any issues.  I prefer the Emby Roku interface but if it isn't going to play movies without stopping there's no point in using it.  I've read all the posts and obviously this is a known issue but I'm not clear on something--is this considered an Emby issue or a Roku issue?  Since Plex plays everything fine I'm assuming this is an Emby issue but some people are referring to Roku being aware of the problem.

 

Is there an ETA on a fix so I know when I can use Emby again? 

 

It is most definitely a Roku firmware problem.  4GB+ files will stop playing even when bypassing Emby entirely and direct streaming from a web server using a custom-written Roku channel.  A few unrelated posts on Roku's forums suggest that Plex is working around the issue by forcing remuxing/transcoding at least larger files (or everything, as some reports seem to indicate) until the bug is fixed - which is making some of their users equally unhappy.  I haven't had the time nor been curious enough to fire up Plex and find out what they're doing exactly, though.

 

Roku (as always) has given no ETA but since it's been reproduced by them and a known bug at this stage, I would suspect a fix is coming in the next firmware update (quarterly seems to be the popular theory).

  • Like 1
Link to comment
Share on other sites

It is most definitely a Roku firmware problem.  4GB+ files will stop playing even when bypassing Emby entirely and direct streaming from a web server using a custom-written Roku channel.  A few unrelated posts on Roku's forums suggest that Plex is working around the issue by forcing remuxing/transcoding at least larger files (or everything, as some reports seem to indicate) until the bug is fixed - which is making some of their users equally unhappy.  I haven't had the time nor been curious enough to fire up Plex and find out what they're doing exactly, though.

 

Roku (as always) has given no ETA but since it's been reproduced by them and a known bug at this stage, I would suspect a fix is coming in the next firmware update (quarterly seems to be the popular theory).

Yeah, that's definitely not true.  I'm playing a 10GB+ movie file on Plex right now and the CPU usage on my computer is at 5%--with 5 tabs open in Chrome and a couple of other apps open to boot.  If Plex was force transcoding large videos my CPU usage would be much, much higher.  

Link to comment
Share on other sites

Yeah, that's definitely not true.  I'm playing a 10GB+ movie file on Plex right now and the CPU usage on my computer is at 5%--with 5 tabs open in Chrome and a couple of other apps open to boot.  If Plex was force transcoding large videos my CPU usage would be much, much higher.

So are you saying they are not REMUXING your file?

Link to comment
Share on other sites

Yeah, that's definitely not true. I'm playing a 10GB+ movie file on Plex right now and the CPU usage on my computer is at 5%--with 5 tabs open in Chrome and a couple of other apps open to boot. If Plex was force transcoding large videos my CPU usage would be much, much higher.

Remuxing takes significantly less to accomplish vs what most would call a transcode. I've been doing simple remuxes to hls to work around the problem locally - the cpu hit is very small for such an operation. Its basically a container change rather than a conversion, so not a lot of resources are required.

 

If they've found another way to work around the bug, I'd love to know how. Even Roku has acknowledged that there is an issue, and it affects their own player implementations (Emby uses one of them; I've tried both of Roku's interfaces while testing this personally).  I can think of a few ways they *could* be working around this that doesn't involve remuxing or transcoding, but I'm not sure if the Roku firmware would even allow that level of customisation within their player implementations.  In fairness, Plex's main Roku channel developer seems to know quite a few undocumented functions, so they may have found another way.  Roku's API docs are...incomplete (which is putting it very kindly) and nothing would surprise me less than to find out there are ways to manipulate specific data inside of the player process that they didn't document for one reason or another.

 

I may have to fire up Plex again and see what's really going on.  I don't doubt your experience at all - I was just relaying what I had read from others which made sense in the context of my own testing, so I don't have enough first-hand knowledge to speak to exactly how they do it.  Guess I should find out, since now you've got me curious :D

 

Edit: Just updated and fired up Plex. Their channel seems to try to direct stream for as long as possible, but when it ran into the first 4GB "break point" on the two test files I used, their channel notified the server that it encountered an error and the server subsequently started to remux from that point on relatively seamlessly (small buffering delay due to the bitrates of the files in question).  Basically, it's definitely remuxing, but not until the player process returns an error.  The difference is that their developer(s) have written more error handling to "fall back" to transcoding/remuxing in the event of a Roku playback error, whereas Emby has rudimentary code to do so, but I don't think it's complete (I haven't reviewed that section of the code that much yet).

 

The spawned PlexTranscoder.exe process is, as expected, very light on resource use since it appears to be just a remux (sub-1% CPU on my system), but it's definitely not present until after the first 4GB boundary is hit  The logs even indicate a transcode but only after the error point.  I still have to review the log in more detail to know more about the fallback process, but that answers the question.  Basically, we're both right, since they don't transcode everything, but do fall back to remuxing when/if they run into a problem.  It makes sense for them to do so, and isn't a bad approach in the face of this particular bug (as well as being a good catch-all approach for dealing with other unrelated playback failures).

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

Small side note...

 

I never mentioned this before, but it's important to note that the Roku player process returns a playback error code "long before" the playback actually stops in these cases (relatively - we're talking 1-4secs for most files).  It'll play out it's buffer before halting playback entirely, but the error occurs when the Roku requests the next chunk of the file for buffering.  This is why things may seem like no error happened at all on Plex with some videos - lower bitrate files/segments would probably start remuxing fast enough to allow buffering the new stream before the old buffer data was finished playing/exhausted.  In my case, buffering was noticeable, but my CPU load was fairly high at the time (on purpose, actually) and the bitrate on one of the videos is near the max of what I would play through a Roku anyway.

Link to comment
Share on other sites

So are you saying they are not REMUXING your file?

I don't know the difference between remuxing and transcoding in this context.  I know that if a file is not direct playing and is transcoding my CPU usage is around 90% or higher because I have an old computer with a relatively slow processor.  If the CPU is under 10% then the file must be direct playing.      

Link to comment
Share on other sites

Small side note...

 

I never mentioned this before, but it's important to note that the Roku player process returns a playback error code "long before" the playback actually stops in these cases (relatively - we're talking 1-4secs for most files).  It'll play out it's buffer before halting playback entirely, but the error occurs when the Roku requests the next chunk of the file for buffering.  This is why things may seem like no error happened at all on Plex with some videos - lower bitrate files/segments would probably start remuxing fast enough to allow buffering the new stream before the old buffer data was finished playing/exhausted.  In my case, buffering was noticeable, but my CPU load was fairly high at the time (on purpose, actually) and the bitrate on one of the videos is near the max of what I would play through a Roku anyway.

I thought of that and lowered the max bit rate on the Emby app to the same as it is on the Plex app.  It didn't make any difference.  Emby still stops playing without warning.  I will say that occasionally Plex will freeze for a few seconds during a movie and then start playing again, but that only happens once during the entire course of the film and doesn't happen with all films.  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.  Since I only watch movies on the one device I can't compare playback on something else.  I had Emby on my Firestick for a while but with all the buffering issues that was a complete nightmare, so I gave up on using Emby on that device.  Was the firmware update that caused the problems recent?  I never encountered this issue in Emby until two or three weeks ago.      

Link to comment
Share on other sites

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

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.

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
 Share

×
×
  • Create New...