Jump to content

Movie stream stops and won't resume


Happy2Play

Recommended Posts

Happy2Play

Anyone else having an issue with streaming movies just stopping in random places and won't resume on Roku (different spots on different movies).  TV episodes play fine it is just movies and this doesn't happen if the movie is being transcoded.

 

Pretty sure this is beta server related, started a couple days ago.  Only other change was Roku Firmware update.

 

 

Official and Neon Blue

Edited by Happy2Play
Link to comment
Share on other sites

Waldonnis

I've run across this as well since the firmware update to 7.2, but only while direct streaming media files that contain a DTS audio stream (even if it's not selected for playback) - which is over half of my media (doh).  In my case, removing the DTS stream from the files let them play normally, as did transcoding/remuxing the file to only provide the AAC 2-channel audio stream that is present in all of my media.

 

After a very light investigation and some trial and error, it seems to be on the Roku side, as the video player is crashing ~20 mins or so into the stream with a vague "unknown error" code (-3, for the dev types reading) and the server logs indicated that the client closed the connection.  Since most of my media is in MKV containers, I thought the Roku's known-to-be-shaky MKV support was to blame, but even swapping containers to MP4 didn't help.

 

Edit side note: Even the new Scene Graph Video node crashes on the same files in the same exact spot with the same error code (I've been playing with Roku coding lately).  I forced an HLS stream of the same media (while testing something else) and it played fine.

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

Happy2Play

@@speechles - are you seeing anything like this?  It is sort of random, tonight one movie played without issue and the other stopped about halfway in, both are h264/AC3/mp4.

Link to comment
Share on other sites

@@speechles - are you seeing anything like this? It is sort of random, tonight one movie played without issue and the other stopped about halfway in, both are h264/AC3/mp4.

No, I experienced crashes when rewind/fastfwd with the pre 7.2 firmware. My roku would crash back to the homescreen. Since the firmware update my roku has been rock stable. I am using the stable server version 3.0.9572.0.

 

Never had movies stop partway through unless its me doing it. Make sure your hdmi setting is AUTO. This has been known to cause the problem according to plex.

Edited by speechles
Link to comment
Share on other sites

Waldonnis

@@speechles - are you seeing anything like this? It is sort of random, tonight one movie played without issue and the other stopped about halfway in, both are h264/AC3/mp4.

I haven't seen crashes with ac3 tracks yet, but I've been busy toying with the new firmware to watch my movies [emoji2] I'll queue up a few tonight and see if I experience the same problem with ac3.

 

Sent from my Nexus 6 using Tapatalk

Link to comment
Share on other sites

I most of the time, use the developer app I sideloaded rather than the roku store app. Let me start watching via the public app space, instead of the developer app space. Maybe that makes a difference. Ive read that when the rokus available free swap space falls below 25MB the video player interface no longer buffers and the kernel goes into "panic mode". Usually it just locks up, then shortly after the roku reboots through its dancing, spinning, umbrella falling logo splash and have to restart the app.

 

I also factory restored my roku with the 7.1 firmware because my remote would no longer sync, about 3 weeks ago. If you factory reset your roku with firmware 7.2 it might solve the issue. It means you have to wipe the device, reboot. Then the roku factory resets itself and gets all the apps you had again automatically. You lose the roku system settings you made, every apps settings within each app, and you have to unlock developer mode, all that fun stuff again, but this may solve the problem. The update and factory-restore zips are different. One is the OTA patch, the other is the full install.

 

Sent from my Nexus 7 using Tapatalk

Edited by speechles
Link to comment
Share on other sites

Waldonnis

I haven't done a reset (yet), but it doesn't happen on every file with a DTS audio track - only certain ones. I even found one that crashed the player object within the first 5 seconds of playback (Thor), which made me laugh since I started watching it while working on another file that was halting.  I'm still trying various combinations of things to see if I can find what exactly triggers the bug or at least a workaround. Given how strange the results of some of my latest tests are, I wouldn't be surprised if files with AC3 tracks could cause a crash as well, but I have yet to find one that does.

Link to comment
Share on other sites

Waldonnis

To satisfy intellectual curiosity, I did a factory reset on the Roku - didn't help at all.

 

I've noticed that the movies that are failing also have DTS-HD MA tracks on their discs (but not all DTS-HD movies are having problems).  I just tried recopying the DTS-HD MA audio stream from one of the discs and muxed that into my test file instead of the DTS core - the resulting file seemed to play okay.  I extracted the DTS core from the same DTS-HD track using ffmpeg, then muxed that into the file - which crashed the player as expected.  It's just plain strange, doubly so since I'm not even playing the file with the DTS track selected (the data is still being received by the player, though). For grins, I even tried disabling track lacing in the resulting mkvs, thinking the lacing might be producing some bug-tripping data sequence, but to no avail.  I'm trying manually converting the file with both audio streams to m3u8 (HLS) now to see if it's the transport or the data/arrangement itself, but that's not a quick process and I'll have to check back in with the results.

 

It's likely that some data sequence is hosing the Roku video player that just happens to show up in some files (if this is true, any codec could probably cause issues in some circumstances).  Even though the DTS core track I tested with is identical byte-wise to what can be extracted from the DTS-HD MA track, the arrangement in the file is not, which could explain why the DTS-HD track worked but not the core audio.

 

Someone please stop me before I start doing a byte-by-byte analysis on 6-31GB files...

Link to comment
Share on other sites

farside847

I am seeing the exact same issue. after 23min the movie stops and goes back to emby movie screen. resuming the movie plays for 1 second and stops again. attached is a clean log if it helps. Always at the same place. This movie used to play all the way. Converted tv shows seem fine, although they a smaller.

 

If I select the next chapter from the movie screen it will continue to play for a while, but will stop again later.

 

I am using an old version of the server, I stopped the auto update a while back when it was going to do a big database update. Never turned it back on. Currently running server 3.0.5786.0 and the latest roku app 2.24 (it still auto updates.)

 

Roku firmware 7.2.0 build 4100-04 on an original roku 3.

 

movie info:

 

578078dd003f5_mediainfo.png

 

Update:

It's Complicated stops at 23min

Avengers stops at 12 min

Force awakens (with dts) at 11min

 

All my movies are AC3 except force awakens which has dts-hd. All my movies direct play. All my movies seem impacted.

server-63603604158.zip

Edited by farside847
Link to comment
Share on other sites

farside847

Ok, more details.

 

Seems to only happen on HD movies from BluRay sources. Mine are converted via handbrake. Movies recorded from TV or DVDs seem to play fine. 

 

These two movies play fine, Armageddon is a DVD, Pan a TV recording.

57809dca3081b_w1.png

57809dd657e7d_w2.png

 

 

 

All these movies converted from BluRay fail after 10 to 25 minutes

 

57809e02ded92_mediainfo.png

57809e74e7408_f1.png

57809e7fc170d_f2.png

 

This bug is kinda a big deal for me. Let me know if more details would help!

 

thanks!

Link to comment
Share on other sites

Happy2Play

At least I am not the only one experiencing this issue.  So we are probably at the mercy of Roku for another firmware update.

Link to comment
Share on other sites

farside847

Ug, that could take forever. Have you tried an earlier firmware? I have never tried it but I think there is a way to use the pervious firmware in the secret menu.

Link to comment
Share on other sites

I would try dropping to the app's default bitrate of 3mbps, then gradually increase as you see positive results.

Link to comment
Share on other sites

Waldonnis

I've noted the same about Blu-Ray sources, farside, although mine are typically much lower bitrates (I re-encode the video to all but eliminate transcoding and bandwidth saturation for me and my one offsite user).  All of the DVD-sourced media that I've looked at seems to work fine.

 

Forcing a transcode may work.  Since my test cases all have multiple audio tracks, and the inclusion of a DTS core stream along with the AAC stream seems to trigger it for me, simple transcoding to HLS (and mapping just one audio stream to the output transport stream) does allow it to play as it is just providing one audio stream.  Also, splitting my first test file to just include the first 30mins of the movie allowed it to play past the usual crash point even with the DTS core/AAC combo, so the segmenting alone may do it.  I would be curious to see if forcing a straight-copy HLS transcode of a problematic file that just has an AAC track would allow it to play.

 

I definitely second Luke's recommendation, as reducing the bitrate threshold will likely trigger a transcode on BR-sourced media and answer the transcoding workaround question for files with only one audio stream.

Link to comment
Share on other sites

farside847

Ya, i am sure dropping the bitrate to force transcode would allow the movie to play. i will test this out tonight and report back. my movies are pretty high bitrate, maybe even excessive. but this set up has been working wonderfully for over a year. my roku is wired connection, i dont think anything has changed on my network.  Is the assumption here that the new roku firmware somehow reduced the bitrate that can be streamed to emby?

 

just for fun, i downloaded one of the suspect movies to a thumb drive and played it on the Roku Media Player app, played fine. mode data to add to the pile.

 

thanks for you help guys. :)

Link to comment
Share on other sites

Happy2Play

Will try stepping bitrate setting also but know transcoding or remuxing prevents the issue.  Only happens with Direct Play (only movies). 

 

All/majority my media is encoded h264/ac3/mp4

 

57815da99fcc5_encode.jpg

Link to comment
Share on other sites

Waldonnis

Ya, i am sure dropping the bitrate to force transcode would allow the movie to play. i will test this out tonight and report back. my movies are pretty high bitrate, maybe even excessive. but this set up has been working wonderfully for over a year. my roku is wired connection, i dont think anything has changed on my network.  Is the assumption here that the new roku firmware somehow reduced the bitrate that can be streamed to emby?

 

just for fun, i downloaded one of the suspect movies to a thumb drive and played it on the Roku Media Player app, played fine. mode data to add to the pile.

 

thanks for you help guys. :)

 

In my experience, a hard-wired Roku 3 will play bitrates up to around 30Mbit just fine, provided it's a fixed bitrate.  With VBR (variable bitrate) content, it can get more complicated since bitrate spikes can/do happen that may cause buffering pauses.  I've managed to push even higher average bitrate (but still VBR) content through my two Roku 3s, but have seen some (rare) buffering if the bitrate spikes are sustained for more than a second or two.  I wouldn't generally recommend anything over around 24Mbit to most people, and even less if it's wireless, as things get less consistent above that with so many variables in play.  For most uses, a good compromise between video quality and bitrate concerns can be arrived at with a more carefully crafted Handbrake/ffmpeg encoding profile anyway, so it's often not necessary to risk playback issues due to bitrates.

 

As for RMP playing the file, that's expected and something I wouldn't usually think to test unless I'm not sure the device can handle the codecs/encoding parameters at all.  Filesystem reading is just different and easier to handle than reading/buffering a network stream that may be less predictable. I'm glad to hear it did play properly that way, though.  Answers the question of file format/layout and means that the demuxing code is not likely to be the culprit.  Stream handling or buffer reads, though...who knows.

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.

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

Happy2Play

That is what I have been doing when this happens, "Force Transcode"

 

Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (ac3 (native) -> ac3 (native))

 

 

Link to comment
Share on other sites

Waldonnis

I thought about reporting it, but I'm doubtful that DTS itself is the cause...and likely isn't since we have reports for AAC and AC3 as well.  I also have yet to be able to produce a small test case, since splitting/segmenting the files eliminates the issue as well.  Besides, the usual Plexbots will inevitably come out and say "just use Plex and it'll transcode it", which I don't feel like dealing with  :P

 

The fact that the DTS core is being extracted properly from the DTS-HD MA stream (that incidentally played well) led me to believe that the demuxer is fine and DTS itself isn't really the issue - rather that some data or buffering/read function is broken (or if they read it as a string, is it being escaped properly).  RMP playing a crashing file well confirms that as best we can.  Also, I'm seeing this on both of my Roku 3s even with the AAC stereo track selected for playback.  Only one of them is connected to an AVR anyway, so it's not dependent on DTS playback capability, but rather the presence of the track in tandem with the AAC track.  It's also not *every* file that includes a DTS track for me, just a common element in my test cases.  As noted above, it seems to be happening with files that solely contain an AAC track as well, so I'm leaning even more towards their stream data handling (or possibly buffer I/O) code being at fault.

 

Of course, most of my investigation is academic.  The only workarounds that I've found all end up involving transcoding, so for practical purposes, that's likely the best way to deal with it until either Roku fixes it or I happen upon a better workaround.  I'm mostly looking into it to see if there are possibilities for making the player more robust, which isn't easy given how scant the Roku docs are and how little we know about their underlying code.

Link to comment
Share on other sites

Interesting.. it didnt want to copy the audio at that 640kb bitrate and instead dropped it to 448kb. The roku "officially" supports 384kb sec as the max. This is the same as appleTV since the hls authoring spec mentions this too. The fact 448kb is used is odd, when this transcodes to HLS it should be 384.

 

The new firmware "touches" many interfaces, among them the video player in both SGnode and regular. This also adjusted how audio can be used and introuduces the new roku TextToSpeech interface. I tested out having the roku "talk to me" and it is weird. You have to purposely misspell words to make them sound right. So roku is thinking forward, but I suspect adding the mixer to allow a voice and layering of effects to have caused the issue with the audio. Firmware 7.2 gives the UI the possibility of having videogame type sound effects layered over your playing music while it speaks to you as you use the remote. So there is an advantage to scene graph not imagined before beyond just the graphics. We need to take advantage of all this cool stuff..:)

 

Edit:

 

yep, just confirmed, the fact HLS uses 448 makes the sound eventually drop out. Just had this happen with HLS, about 10-11 minutes into the movie. But because it was using HLS and not direct play I just lost sound. Had to resume and got sound back so I would say the video player is much much pickier now about the max bitrate used. This affects all audio codecs.

 

30 minutes into the movie, sound has dropped 6x. So I assume this is the flaw also present in HLS too. We need to drop the max audio bitrate to 384kb/sec. This is indeed ridiculous. I havent experienced this with direct play, yet.

Edited by speechles
Link to comment
Share on other sites

Waldonnis

yep, just confirmed, the fact HLS uses 448 makes the sound eventually drop out. Just had this happen with HLS, about 10-11 minutes into the movie. But because it was using HLS and not direct play I just lost sound. Had to resume and got sound back so I would say the video player is much much pickier now about the max bitrate used. This affects all audio codecs.

 

30 minutes into the movie, sound has dropped 6x. So I assume this is the flaw also present in HLS too. We need to drop the max audio bitrate to 384kb/sec. This is indeed ridiculous. I havent experienced this with direct play, yet.

 

Hehehe, yeah, it's gotten much more fickle with HLS stream bitrates, although I didn't think it was restricted that much.  Maybe the new firmware's resource requirements have allowed less power to handle audio stream decoding, forcing it to be closer to their recommendations.

 

I doubt the audio drops are related in this case, though, since at least the entire video didn't stop and error out (I'm assuming you're just transcoding to a single transport stream that includes both audio and video).  Aside from DTS tracks, every failing video listed by others has an audio bitrate lower than 384kbps, so I doubt that's a cause of the original stops/crashes (and even still, not all of my higher-bitrate DTS-stream-included files crash the player process).

Link to comment
Share on other sites

farside847

Ok, OCD is kicking in :)  - more research = more data to try and find the cause.

 

Problem statement

  • bluray movies that have been converted to mp4 to direct play fail after 10 to 30 minutes, like someone clicked the back button. 
  • dvd conversions and tv recorded conversions seem to work fine

 

things I have ruled out

  • network issue - raspberry pi streams fine. plus it does not buffer - it just closes
  • file corruption - tries multiple movies. movie plays on RMP
  • bitrate - I have tried files from 22000 to 5000 bitrate, same issue
  • DTS audio - same issue with AAC
  • HD issue - other 1080p files recorded on TV work fine
  • bif file error - saw something in the log about the bif file, tried playback without the bif file, same issue

 

To date I have tried:

  • the easy stuff
    • reboot the emby, the server machine, router, switch, roku, etc
  • Encoding testing - i took one of the movies and re-encoded with handbrake from the original source:
    • my original quality was set to 15 - stopped playing at 12 min just like before (16871 kbps)
    • next quality set to 22 - stopped playing at 16 min (4222 kbps)
    • next I re-did all my handbrake settings using the recommendations from rokoding.com (5041 kbps), this made a few changes like constant framerate and strict anamorphic and less b-frames. stopped at 36min
    • still trying some other combo's - will report back
  • Tested on another roku
    • I have two rokus, one hooked up to a fancy sound bar through HDMI passthrough that supports all the fancy sound formats. the other is a simple hdmi connection direct to the TV with built in stereo speakers. Both on 7.2. Both do the same thing
  • try to rollback the roku firmware
    • tried the secret menu, when I select update firmware it just reapplied 7.2. Grr.

 

things yet to try:

  • try to re-encode the movie in mcebuddy since the tv shows coming from it seem to work fine
  • try to update my emby server - been putting this off since I know it will take time.

 

I am still going, trying to get to root cause. If anyone is interested in logs, mediainfo files, etc. let me know :)

 

thanks for listening, this is my therapy.

Edited by farside847
Link to comment
Share on other sites

Waldonnis

thanks for listening, this is my therapy.

 

Welcome to my world  :D

 

There is definitely something going on with file size, as you've noticed by now.  I re-encoded one movie three times with different quality levels and it would stop in different places with each (the smaller the file, the longer it would run before stopping).  It doesn't explain one of my movies that dies within the first 5secs, but it's an interesting observation.

 

I've even tried bypassing Emby altogether and just using Apache to serve the files to the player (that's how some of my other, unrelated experiments are done anyway) - no change.

Link to comment
Share on other sites

farside847

I've even tried bypassing Emby altogether and just using Apache to serve the files to the player (that's how some of my other, unrelated experiments are done anyway) - no change.

 

So streaming directly with apache, the file stopped just like emby? What app did you use? I have been debating on installing another app to test this too.

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