Jump to content


Photo

Movie stream stops and won't resume


  • Please log in to reply
102 replies to this topic

#21 speechles OFFLINE  

speechles

    Advanced Member

  • App Developer
  • 3972 posts
  • Local time: 03:07 PM

Posted 09 July 2016 - 07:15 PM

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, 09 July 2016 - 07:42 PM.


#22 Waldonnis OFFLINE  

Waldonnis

    Advanced Member

  • Members
  • 652 posts
  • Local time: 06:07 PM

Posted 09 July 2016 - 10:30 PM

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



#23 farside847 OFFLINE  

farside847

    Advanced Member

  • Members
  • 247 posts
  • Local time: 03:07 PM

Posted 10 July 2016 - 10:50 PM

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, 10 July 2016 - 11:46 PM.


#24 Waldonnis OFFLINE  

Waldonnis

    Advanced Member

  • Members
  • 652 posts
  • Local time: 06:07 PM

Posted 11 July 2016 - 01:34 PM

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.



#25 farside847 OFFLINE  

farside847

    Advanced Member

  • Members
  • 247 posts
  • Local time: 03:07 PM

Posted 11 July 2016 - 01:44 PM

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.



#26 farside847 OFFLINE  

farside847

    Advanced Member

  • Members
  • 247 posts
  • Local time: 03:07 PM

Posted 11 July 2016 - 01:45 PM

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?



#27 Waldonnis OFFLINE  

Waldonnis

    Advanced Member

  • Members
  • 652 posts
  • Local time: 06:07 PM

Posted 11 July 2016 - 03:12 PM

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



#28 farside847 OFFLINE  

farside847

    Advanced Member

  • Members
  • 247 posts
  • Local time: 03:07 PM

Posted 11 July 2016 - 06:06 PM

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.c...wforum.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.c...hp?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?



#29 speechles OFFLINE  

speechles

    Advanced Member

  • App Developer
  • 3972 posts
  • Local time: 03:07 PM

Posted 11 July 2016 - 06:14 PM

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, 11 July 2016 - 06:20 PM.


#30 farside847 OFFLINE  

farside847

    Advanced Member

  • Members
  • 247 posts
  • Local time: 03:07 PM

Posted 11 July 2016 - 06:49 PM

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.



#31 Happy2Play OFFLINE  

Happy2Play

    Trial and Error

  • Moderators
  • 13845 posts
  • Local time: 03:07 PM
  • LocationWashington State

Posted 11 July 2016 - 08:21 PM

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.



#32 Waldonnis OFFLINE  

Waldonnis

    Advanced Member

  • Members
  • 652 posts
  • Local time: 06:07 PM

Posted 11 July 2016 - 08:59 PM

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:



#33 Waldonnis OFFLINE  

Waldonnis

    Advanced Member

  • Members
  • 652 posts
  • Local time: 06:07 PM

Posted 12 July 2016 - 01:15 AM

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, 12 July 2016 - 01:53 AM.

  • ebr and Happy2Play like this

#34 farside847 OFFLINE  

farside847

    Advanced Member

  • Members
  • 247 posts
  • Local time: 03:07 PM

Posted 12 July 2016 - 01:12 PM

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?



#35 farside847 OFFLINE  

farside847

    Advanced Member

  • Members
  • 247 posts
  • Local time: 03:07 PM

Posted 12 July 2016 - 04:55 PM

RokuDale on the Roku forum has filed a bug for us! :)

http://forums.roku.c...=535205#p535219


  • Happy2Play and Waldonnis like this

#36 Waldonnis OFFLINE  

Waldonnis

    Advanced Member

  • Members
  • 652 posts
  • Local time: 06:07 PM

Posted 12 July 2016 - 04:58 PM

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



#37 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 124437 posts
  • Local time: 06:07 PM

Posted 12 July 2016 - 05:30 PM

Well done everyone.



#38 Waldonnis OFFLINE  

Waldonnis

    Advanced Member

  • Members
  • 652 posts
  • Local time: 06:07 PM

Posted 20 July 2016 - 04:41 PM

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.



#39 speechles OFFLINE  

speechles

    Advanced Member

  • App Developer
  • 3972 posts
  • Local time: 03:07 PM

Posted 20 July 2016 - 04:53 PM

@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, 20 July 2016 - 05:01 PM.


#40 Waldonnis OFFLINE  

Waldonnis

    Advanced Member

  • Members
  • 652 posts
  • Local time: 06:07 PM

Posted 20 July 2016 - 06:36 PM

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






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users