Jump to content

Playback fails with specific files


PlzLessSerious
Go to solution Solved by speechles,

Recommended Posts

PlzLessSerious

With some specific files Emby playback on Roku fails. The same files play fine through the browser on a Windows PC.

When the files are started up on Roku, the video stalls while initially loading (progress bar) and never starts up. This also leaves an ffmpeg process running on the NAS which consumes a bunch of CPU although nothing is being shown.

 

This has happened a bunch of times but I only lately started to document which kind of files are affected. Currently this includes the following files:

 

Joker.2019.1080p.AMZN.WEB-DL.DDP5.1.H264-CMRG
Info: 8 818 kb/s @23.976 (24000/1001) FPS, Audio E-AC-3 , 640 kb/s , 6 channels
Video Codec: H264 - MPEG-4 AVC (part 10) (avc1)
Audio Codec: A52 Audio (aka AC3) (a52 )
 
Midway.2019.1080p.BluRay.x264-AAA
Info: 1920x808 @ 23.976 fps - 8 387 kb/s, English Dolby Digital (AC3) - 6 channels @ 640 kb/s
Video codec: H264 - MPEG-4 AVC (part 10) (avc1)
Audio codec: A52 Audio (aka AC3) (a52 )
 
Video and audio codec seem to be the common things here. 
I am not looking to troubleshoot the issue - I will just download different versions of the files. Just making a bug report for you.
 
Link to comment
Share on other sites

  • 1 month later...
PlzLessSerious

Not sure how this thing is supposed to work but.. cannot the device then request a transcoded stream in a format that is acceptable? Right now whenever I start up such H264 - MPEG-4 AVC (part 10) stream, Roku just hangs in loading screen. even if I go to the homescreen again, the stream keeps running in the background as I can see from the Emby server dashboard.

 

Is this classified as a known bug/issue or is this a feature and works as expected atm? Or is there some configuration change I can do to force transcoding? I have tried changing the playback resolution in the Roku Emby player settings but they seem to have no effect in this case.

Link to comment
Share on other sites

It is supposed to work that way. But if the header of the media cannot be interpreted by the player sometimes it has this problem. If you repackage/remux these with ( https://mkvtoolnix.download/downloads.html ) MKVToolNix GUI does it fix them? That should be all you need to do. There are multiple reasons the header can cause the Roku to refuse to play and hang the player. Remux with the tool above always solves them.

 

Let us know if simple remux does not solve this as it should. Thanks. ;)

Edited by speechles
Link to comment
Share on other sites

PlzLessSerious

I processed the file using MKVToolNix. Opened the file and in the Multiplexer/Input tab just pressed 'Start multiplexing job. All the options in the right side panel were disabled and I saw stuff like 'Determine auitomatically', 'dont change' etc there. I have no experience processing videofiles so I do not know what this process was supposed to do as I executed it. It ran for about 2m30sec and resulted in a file which increased the original 14GB by about 90 bytes. The resulting file had the same issue in Roku. This time the server just kep streaming and did not time out even, so I needed to restart the Emby server to get my CPU usage down again.

 

The Roku Ultra is running Emby software version 3.0.212

Emby Server v4.4.2.0-1 is running on Synology NAS 

 

I sent the Roku Emby player log to developers about 5 minutes before posting this message.

Emby server log (40MB) is available on google drive: https://drive.google.com/file/d/1m34h7UzRkt0bme1QIRQyZkQN_fUdCbhG/view?usp=sharing

 

The movie in question is:

Star Wars 4 - A New Hope (1977).mkv

Video

    Codec: H264 - MPEG-4 AVC (part 10) (avc1)

    Video resolution: 1920x816

    Frame rate: 23.976215

Audio

    Codec: DTS Audio (dts )

    Channels: 3F2M1R/LFE

    Sample rate: 48000 Hz

 

Please let me know if I can provide any more information

Edited by PlzLessSerious
Link to comment
Share on other sites

Hi.  Can you please show us the media info for the item as it is displayed on the web app detail page?

 

Thanks.

Link to comment
Share on other sites

PlzLessSerious

Not sure if this is what you meant but I grabbed this screenshot from the lower part of the movie information page of Emby in my browser

 

5e9c65703e213_mediainfo.png

 

 

Something else I noticed. The Emby server dashboard properly shows when Roku is streaming the video.. Seconds are counting down etc. Even though the Roku Emby player itself is hanged in loading screen. Now - the STOP button of the Server Dashboard works differently in 2 situations:

- If the Roku Player is still hanged in the loading screen, the STOP button immediately stops the video stream and brings also Roku out of the hanged loading screen.

- If I first break out of the Roku Emby player loading screen by pressing the 'Home button' on Roku remote, the STOP button in the Emby Server Dashboard no longer works and the stream just keeps going.

Edited by PlzLessSerious
Link to comment
Share on other sites

Does it produce an ffmpeg log or is this direct playing?

 

Do you have the media information from a different file that does not play? So we can see what is similar?

 

I am guessing it is 1 of 3 things:

1) The reference frames are 1 while the level is 41. I have seen Roku players choke on this combination for Roku2/3 and we account for this.

2) The DTS audio is set to incorrectly pass-through on your Roku when the Roku should be set to Stereo.

3) The force subtitles are causing the video to transcode the entire video stream too slowly (if you have the setting to burn subtitles set in the Roku settings)

 

To solve this we need to know what to watch for that causes it. This is why we would need to see a second or third or any media information from files that cause the same behavior. Then we can see in the media information what is the same and find the root cause and confirm it. Can you show us similar media infomation? Thanks. ;)

Edited by speechles
Link to comment
Share on other sites

It has to at least be doing a remux due to the DTS-HD audio.  There should be an ffmpeg log...

Link to comment
Share on other sites

It has to at least be doing a remux due to the DTS-HD audio.  There should be an ffmpeg log...

 

Actually.. we will try to pass-through the DTS core audio from the DTS-HD audio if the Roku reports support for DTS and support for 8 channel (which the newer Roku ultras will). The problem is the pass-through of the DTS core from DTS-HD audio probably hangs the Roku.  That might still be the issue with DTS.

 

 

@@ebr when you play DTS-HD through your Roku does it pass the DTS core? I do not have equipment to test DTS with. If it does not we can reduce the 8 channels to 6 channels and transcode that audio and change our profile for the time being. Supposedly DTS-HD is supported on newer Roku ultra but we never got that working properly. 

 

Remember this?

https://community.roku.com/t5/Roku-Device-Features-Settings-Updates/The-Reason-Roku-Does-Not-Support-Lossless-Audio-Playback/td-p/435801/page/5

 

But the others with AC3 and EAC3 should be playing correctly. We need more information to deduce what is going on. 

Edited by speechles
Link to comment
Share on other sites

PlzLessSerious

OK I gathered some more information.

 

1. First of all, about the Star Wars file (and Tomb Raider)

 

It does not in-fact completely hang the Roku. It just keeps processing something. This time I left it running in the background and I noticed that while the loading bar was stuck at about 30%, every 2 minutes or so the loading bar briefly dropped to 0% and quickly filled up to 30% again. This was very regular, I timed it. After the internal reload happened 5 times, at about 10+ minute mark of the loading process, Roku gave up trying top load the file and exited to the previous screen, displaying a red error message at screen bottom. I will add a screenshot of the error message below.

 

I found another movie file which exhibited exactly the same behavior - reload cycles and error message at about 10 minute mark. Codec information from VLC player and Emby details page in screenshots below.

File 2: Tomb Raider (2018).mkv

5e9c88ae336b3_tombridervlc.png

5e9c88c050a95_tombraider.png

 

 

The error message for Tomb Rider and Star Wars files was similar. Attached here:

 

5e9c89ccd266c_tombraidererror.png

 

 

2. Slow but not hanging files

There were several files which hanged for different period of time at 30% just like SW and Tomb Rider. I will attach the Codec information of these files below, but please note that the amount of time they hanged before starting up, increased with their file size:

 

  • Justice league  4741 MB, loaded 45s
  • Home alone     6711 MB, loaded 1m25s
  • The Doors        8136 MB, loaded 1m45s

Now - the files exiting in error were over 10GB both. It would make sense for them to load over 2 minutes. However because they restarted their internal load after about 2 minutes, perhaps they just never got the chance to finish loading? In any case these slow loading files seem to be linked to the files which do not load at all. Now the codec information for the slow files:

 

5e9c92ae86aba_slowjusticeleague45s.png

 

5e9c92c2a04d9_slowhomealone1m25s.png

 

5e9c92d4b384c_slowthedoors1m45s.png

 

 

3. Fast files with seemingly similar codecs?

Most files however load fast with 3-7 seconds, with no perceptible hang at 30%. I will attach some codecs here which are also from files using H264, one with lvl 40, another with lvl 41. I am sure I am missing something about their codec data but anyways - these files load fast without problems and are also in the 6-8GB range:

 

5e9c938cb6ba0_fastadastra6sec.png

 

5e9c93a5deea2_fastparasite6s.png

 

 

4. Something else

 

Another note about the Server side of all this. Even though Roku abandoned trying to load the Tomb Raider file, Emby Server still stuck at 90+% CPU usage. The weirdest part about it was that when I did an Emby server restart from the Emby web-app, the server load dropped to about 15% but when the server came back up, the CPU usage went to 90+% again. This seemed to indicate that the work was just not some orphaned process on the server side but was actually requested by someone. So I specifically exited the Emby Roku app using the remote and choosing 'Exit' when prompted but even that did not stop the Server CPU load. The only way to stop the 85+% ffmpeg process under Emby server was to restart the Synology NAS. 

 

I will keep my eyes open for more stuff, but please let me know if you need anything else specific

Link to comment
Share on other sites

PlzLessSerious

There was also a question earlier about subtitle extraction and my Roku audio configuration. Here are my Emby Server transcoding configurations and my Roku configurations.

 

5e9c967b1e85e_transcodingconf.png

5e9c99e3d5827_rokuconf.png

 

5e9c99f95c86f_rokuembyvideo.png

 

5e9c9a0862b09_rokuembyaudio.png

Link to comment
Share on other sites

PlzLessSerious

Sorry to flood you with the screenshots but I wanted to give a server side view of what is happening as well. These are screenshots from the Synology resource monitor during the timeperiod when I try to Start up the Star Wars movie via Roku.

 

1. Initially the CPU showed a pretty low load of under 10% (I guess it does not factor the io wait into the % shown to user)

2. When The first 'reload cycle' at about 2 minutes hit, I exited the Roku loading screen by pressing the Roku Home button. To my surprise I saw that teh server was still working at the lo <10% CPU usage.

3. While sitting confused and trying to understand why it is different this time from last time, the CPU suddenly jumped to 90+% and stayed there although Roku was sitting at homescreen, doing nothing

4. In order to see if the load returns after Server restart, I did an Emby server restart via web panel. The CPU load dropped while the restart happened, but after a hile the load came back up.

5. In order to identify if Roku was causing the load, I then unplugged the Roku from power outlet. The CPU load on the server remained. Emby server restarts after that point did not affect the CPU load and it remained high. I had to restart the NAS to get it down.

 

Screenshots of the resource panel tabs below:

5e9ca1ce7a5f7_servercpu.png

 

5e9ca1ed6fe95_servermem.png

 

5e9ca1fc5d3df_servernet.png

 

5e9ca20b3e76b_serverdisk.png

 

5e9ca216a5ced_servervolume.png

 

5e9ca223e8db3_serverservices.png

 

5e9ca22ef093f_serverprocesses.png

Link to comment
Share on other sites

PlzLessSerious

Sure. I started up the Star Wars movie in Roku and waited the 10+ minutes until exited the loading screen with an error message. Since the NAS was at 100% CPU at that ime I did an Emby server restart. The CPU load dropped briefly and went back up when the restart ended. 

 

At that point I saved the following log files I link here now:

https://drive.google.com/file/d/1L8qjRIX9c4aSh6h5lbPUMvioNlLsEBHp/view?usp=sharing

 

Please note that I started up the movie only once - the extra ffmpeg logs were generated as the loading screen went through the reload cycles described in my earlier post. Overall these are the only logfiles with today's timestamp. The tests took place from about 10:20 log time.

Edited by PlzLessSerious
Link to comment
Share on other sites

Please note that I started up the movie only once - the extra ffmpeg logs were generated as the loading screen went through the reload cycles described in my earlier post. Overall these are the only logfiles with today's timestamp. The tests took place from about 10:20 log time.

 

That is the error fallback in the app.  An error loading is generated by the player so the app tries to play it in a different way (with more transcoding each time) until it just gives up.

Link to comment
Share on other sites

At that point I saved the following log files I link here now:

https://drive.google.com/file/d/1L8qjRIX9c4aSh6h5lbPUMvioNlLsEBHp/view?usp=sharing

 

Transcode speed is abysmal.  What is the hardware involved on the server here?  Is it possible you've got a failing hard drive or some other hardware moving very slowly?

Link to comment
Share on other sites

  • Solution

It is suffering transcoding for both the video stream (to burn subtitles into) and the audio stream (to convert DTS surround to AAC stereo).

 

Likely it is the subtitle burning eating up the CPU.

You need to edit that file and remove that forced flag on the subtitles.

 

 

 

How to edit MKV headers using MKVToolNix
  1. Open mkvtoolnix-gui and click the Edit Headers section.
  2. Open the MKV video file whose headers you want to edit. ...
  3. To edit a particular header field, drill down to it and click on it. ...
  4. After you are done, we need to make sure that the resulting header is valid. ...
  5. If validation passes, choose from above Header editor → Save.

 

Also why are you using 720P? Is it because your TV is 720P? The Roku will downscale on device to get there. You DO NOT need to transcode. You should set your Roku up as 720P on the TV. Then set the Emby app as 1080P and let the Roku downscale on the device for your TV. This will allow you to direct play (in your case remux as it will copy the video stream and convert the audio) and the Roku will handle downscaling the video stream.

 

The only Roku device that will not downscale properly is the Roku express.

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

PlzLessSerious

Transcode speed is abysmal.  What is the hardware involved on the server here?  Is it possible you've got a failing hard drive or some other hardware moving very slowly?

 

Synology NAS DS1019+. 

 

5e9db4cf1feb3_system1.png

 

5e9db4da24eaf_system2.png

I would assume it should be fast enough as Emby offers a dedicated package for this system. 

Link to comment
Share on other sites

PlzLessSerious

 

It is suffering transcoding for both the video stream (to burn subtitles into) and the audio stream (to convert DTS surround to AAC stereo).

 

Likely it is the subtitle burning eating up the CPU.

You need to edit that file and remove that forced flag on the subtitles.

 

How to edit MKV headers using MKVToolNix
  1. Open mkvtoolnix-gui and click the Edit Headers section.
  2. Open the MKV video file whose headers you want to edit. ...
  3. To edit a particular header field, drill down to it and click on it. ...
  4. After you are done, we need to make sure that the resulting header is valid. ...
  5. If validation passes, choose from above Header editor → Save.

 

Also why are you using 720P? Is it because your TV is 720P? The Roku will downscale on device to get there. You DO NOT need to transcode. You should set your Roku up as 720P on the TV. Then set the Emby app as 1080P and let the Roku downscale on the device for your TV. This will allow you to direct play (in your case remux as it will copy the video stream and convert the audio) and the Roku will handle downscaling the video stream.

 

The only Roku device that will not downscale properly is the Roku express.

 

 

I have noticed that if the video files contain 'graphical' subs, that may cause the video to stutter in case of larger files. This is the reason I have disabled 'allow subtitle extraction on the fly' and always use text based subtitles. Do I understand correctly that there is actually an additional subtitle affecting setting and it is not available through Emby GUI - instead it is inside the Video file itself and instructs the player to transcode the video on the fly while playing and somehow burn the subtitles into the video stream? Sounds.. weird.

 

But I will happily try to update the header. Will post how it turns out.

 

As to why I am using 720p. The TV supports 2K, but as I was trying to force the server to transcode the stream (I was assuming that the problem was in the original format, not the transcoding process itself), I just picked a resolution which was lower than the original videofile. Also I assumed that transcoding to a lower quality stream uses less resources. I will set video reso stuff to Auto now.

Link to comment
Share on other sites

I have noticed that if the video files contain 'graphical' subs, that may cause the video to stutter in case of larger files. This is the reason I have disabled 'allow subtitle extraction on the fly' and always use text based subtitles. Do I understand correctly that there is actually an additional subtitle affecting setting and it is not available through Emby GUI - instead it is inside the Video file itself and instructs the player to transcode the video on the fly while playing and somehow burn the subtitles into the video stream? Sounds.. weird.

 

But I will happily try to update the header. Will post how it turns out.

 

The "forced" flag is usually for languages where it is not the primary language in the film. So a part where they speak Chinese in an English movie would allow the forced subtitles to appear for that Chinese section showing English subtitles. Then during normal English parts there are no English subtitles shown. That is what is supposed to happen with forced.

 

Sometimes "rippers" include subtitle flags that are not appropriate. Adding the "forced" flag for the subtitles to appear even when they speak English. Forcing a French film to always have English subtitles forced. Things like this. That isn't what the "forced" flag was meant for and this is why you must correct the header.

 

The "default" flag is assigned to the subtitle most often chosen. Then you just enable subtitles and the default shows. Some people also abuse the default flag and these are incorrect and use Russian or Thai. The "default" flag should always be set to the region the BluRay/DVD was ripped from. That regions dialect is default. Any other default is incorrect.

 

The Roku expects the header to be correct. If you make these changes you will get the behavior you want.

 

As to why I am using 720p. The TV supports 2K, but as I was trying to force the server to transcode the stream (I was assuming that the problem was in the original format, not the transcoding process itself), I just picked a resolution which was lower than the original videofile. Also I assumed that transcoding to a lower quality stream uses less resources. I will set video reso stuff to Auto now.

 

It is the bitrate that sets the resource use, not the resolution. This is why it is confusing to some. The bitrate is what the consumption will be over the wire. The resolution is only a suggestion to the server and it can choose to reduce resolution even more depending on factors.

 

To force the server to transcode simply use "Playback Correction" and it will simulate an error and recover. It will recover using various forms of transcoding. You can use Playback Correction multiple times.

Edited by speechles
Link to comment
Share on other sites

Okay, the specs of that NAS indicate it will not be able to transcode much at all.  Given that, the best thing you can probably do is to look to create versions of your media that will direct play on all devices - modest bitrates, simple audio and text-based subs.  Our convert feature should be able to help with that.

Link to comment
Share on other sites

Ok so basically the Roku cannot direct play the file, but then the NAS is also not fast enough to transcode it either, thus leaving it unplayable on Roku.

Link to comment
Share on other sites

PlzLessSerious

Removing the 'Forced' flag for the subs in the file header fixed the loading problem. It starts up now in 4 seconds, fast forwards incredibly quickly etc. 

 

I also changed my Roku and Emby Player Audio and Video settings all to 'Auto'. I had lowered them during testing various problematic video files in the past but I guess having them at a lower than supported format can actually cause more problems than it solves. So maybe that also helped with this file.

 

Just wanted to note about the Synology NAS that it is really disappointing that it is unable to handle transcoding videos. Going through the NAS selector wizard on Synology website, selecting 'multimedia center' type models with '4K transcoding support', gives a result page with the DS1019+. It is supposed to be pretty much the most capable of Synology NAS-s for video transcoding. The compaison page (https://www.synology.com/en-us/products/compare/DS1019+/DS620slim) actually lists the CPU specs which can leave one pretty hopeful:

 

5e9df3de5006b_cpu.png

 

Thanks for all your support. At least I can now fix my problematic videos myself.

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