Too Many Errors. Moving On...

[Lane03 14]

For what it's worth, I just tried playing Two Towers and got the same error as the OP. Turning off Convert Multi Channel AAC fixes it, but I currently prefer to keep that setting enabled to fix an audio sync issue that occurs when Roku direct plays AAC 5.1. A ffmpeg log was not created.

Edited December 21, 2020 by Lane03

[KiwiBean 4]

On 12/17/2020 at 4:04 PM, Happy2Play said:

Does it still happen if Roku app setting Are you still watching is disabled?

It has been mentioned that "bandwidth saver" doesn't have any affect but is Roku's version of Are you still watching.

I just tested turning off the "Are you still watching?" prompt in the Roku app, and there was no change in behavior.  The issue happens on all my 4+ hour length movies regardless of whether this setting is 'on' or 'off'.

[speechles 1917]

This occurs with transcoding? It produces an ffmpeg log? The stats for nerds shows as DirectStream/Remux/Transcode and not DirectPlay?

It occurs when Emby attempts to involve ffmpeg is what I am suspect and something in the length of the manifest or the length of the url itself is becoming the hurdle. @softworkz Have you heard of this issue coming back to haunt us recently? The Roku is quite a fickle device and refuses romance unless you do the foreplay correctly.

Edited December 23, 2020 by speechles

[KiwiBean 4]

On 12/17/2020 at 5:09 PM, lorac said:

It isn't just 4H issue as I have also seen it with The Two Towers which is 3H55M.

 

On 12/21/2020 at 2:50 PM, Lane03 said:

For what it's worth, I just tried playing Two Towers and got the same error as the OP.

 

Is it possible for the actual duration encoded in the video file to be different than the duration being reported in the Roku app?  I'm wondering if maybe the actual video is 4+ hours in length, but if the metadata reporting the 3H55M length comes from downloaded metadata.  For example, the metadata could be pulling data for the theatrical/DVD release, but the encoded video is from and Enhanced Edition Blu-Ray or something.

[speechles 1917]

You can run the file through MKClean or remux with MKVToolNix GUI and see what happens. There is no need to re-encode. You just want it to wash the header and recreate it with no cruft and no invalid/inaccurate data. With a clean header maybe the mileage goes farther than 4 hours?

[KiwiBean 4]

7 minutes ago, speechles said:

This occurs with transcoding? It produces an ffmpeg log? The stats for nerds shows as DirectStream/Remux/Transcode and not DirectPlay?

It occurs when Emby attempts to involve ffmpeg is what I am suspect and something in the length of the manifest or the length of the url itself is becoming the hurdle. @softworkz Have you heard of this issue coming back to haunt us recently? The Roku is quite a fickle device and refuses romance unless you do the foreplay correctly.

This occurs with an HEVC/AAC5.1 file and "Convert Multi-channel AAC" set to 'on'.  It attempts to transcode, but never actually fires-up ffmpeg so no log is generated.

I'm going to see if i can find a way to test the manifest length theory.  Maybe re-encode the movie without any identifiable metadata and place it a "Home Movies & Videos" library type that won't pull any metadata.

[Happy2Play 8281]

3 minutes ago, KiwiBean said:

 

 

Is it possible for the actual duration encoded in the video file to be different than the duration being reported in the Roku app?  I'm wondering if maybe the actual video is 4+ hours in length, but if the metadata reporting the 3H55M length comes from downloaded metadata.  For example, the metadata could be pulling data for the theatrical/DVD release, but the encoded video is from and Enhanced Edition Blu-Ray or something.

Duration/Runtime comes from media probing not online providers though.

[speechles 1917]

4 minutes ago, KiwiBean said:

This occurs with an HEVC/AAC5.1 file and "Convert Multi-channel AAC" set to 'on'.  It attempts to transcode, but never actually fires-up ffmpeg so no log is generated.

I'm going to see if i can find a way to test the manifest length theory.  Maybe re-encode the movie without any identifiable metadata and place it a "Home Movies & Videos" library type that won't pull any metadata.

@softworkz Ffmpeg should have started in this case. It should transcode AAC 5.1 >> AC3 5.1 and Remux the HEVC. But because it fails to even spawn ffmpeg the playback correction just stumbles through its next 3 tries thinking it can use ffmpeg in other ways to produce a workable/playable stream but cannot. It is hard to trap errors on Roku and know the cause which is why we retry on most. Roku obfuscates the actual error code and you get their interpretation of the error which is the Roku errorNumber and Roku errorName which is generic. It makes it hard on the application side to do much.

Edited December 24, 2020 by speechles

[KiwiBean 4]

11 hours ago, speechles said:

You can run the file through MKClean or remux with MKVToolNix GUI and see what happens. There is no need to re-encode. You just want it to wash the header and recreate it with no cruft and no invalid/inaccurate data. With a clean header maybe the mileage goes farther than 4 hours?

I tried both without success.  Also tried re-encoding with Handbrake to no avail.  Error persists regardless of re-encode, remux, or clean.

In all cases the file i tested with had no chapters, no subs, no extra audio tracks.  Just a single HEVC video and AAC5.1 audio file.  The file was simply named 'foo.mkv' and placed in a Library of type "Home Movies and Videos" without any metadata retrieval.

I did try one additional test with Handbrake where i encoded only the first 3H59M of the movie to see if that 4H threshold was absolute.  This generated the same error.  I then tried encoding just the first 10M of the movie, and this played perfectly.  So it seems somewhere in-between is a threshold for the error.  I'd love to trying encoding portions of the movie to find exactly at which duration it fails, but it simply takes too long for each re-encode so I'll pass.

[ebr 14910]

Seems very likely this is the same issue we encountered a while back and "avoided" by shortening some information in the manifest.

[Lane03 14]

I did more testing with some of my longer movies. The time cutoff looks to be between 227 and 235 minutes long. I never could get Two Towers Extended (235 min) to play without erroring out. I never had issues playing Laurence of Arabia (227 min). I got Dances with Wolves DC (233 min) to play once, but it looks like it took multiple "retrieving" tries before it started (I'll attach the ffmpeg log for that). Subsequent attempts with Dances with Wolves were unable to play.

Also of note, when you get that error the backdrop of Emby is stuck on the movie backdrop that produced the error until you exit the app and re-enter (see attached photos).

ffmpeg-remux-afbd1450-ec80-453f-8406-a76ed7b6af02_1.txt

Edited December 24, 2020 by Lane03
Attach FFMPEG Log

[roaku 795]

Ya, but the backdrop bug can deliver some epic team ups.

[Luke 37058]

On 12/24/2020 at 11:51 AM, Lane03 said:

I did more testing with some of my longer movies. The time cutoff looks to be between 227 and 235 minutes long. I never could get Two Towers Extended (235 min) to play without erroring out. I never had issues playing Laurence of Arabia (227 min). I got Dances with Wolves DC (233 min) to play once, but it looks like it took multiple "retrieving" tries before it started (I'll attach the ffmpeg log for that). Subsequent attempts with Dances with Wolves were unable to play.

Also of note, when you get that error the backdrop of Emby is stuck on the movie backdrop that produced the error until you exit the app and re-enter (see attached photos).

ffmpeg-remux-afbd1450-ec80-453f-8406-a76ed7b6af02_1.txt 250.85 kB · 0 downloads

In your case you've restricted transcoding access from the user so you were already made aware that it could cause playback failures.

[speechles 1917]

@Lane03 Those screenshots of yours show the toolbar ribbon in an horizontal orientation. This is the older store version of the application. The new beta version will have the toolbar ribbon in an vertical orientation on the right side of the grid.

Try the Emby Beta for Roku and you will have an application with more bug fixes and features. Beta <> Buggy. Beta <> Broken. Beta == development. Store == production. The development version can be published by us at any time. The store version must be published by Roku once the application is submitted and approved. This approval process can takes days/weeks/months depending on circumstances. The Beta will never have that slowdown in the process. Once we publish the Beta it can be immediately downloaded and updated by users.

Edited December 26, 2020 by speechles

[Lane03 14]

16 hours ago, Luke said:

In your case you've restricted transcoding access from the user so you were already made aware that it could cause playback failures.

Not sure I'm following, my user settings should only restrict video transcoding, not audio. There is no need for my users to transcode video as all are on my LAN and all their devices can direct play the video streams as is. If you mean the "convert multi channel AAC" option, the errors occur regardless of that setting when dealing with 7.1 AAC.

Edited December 26, 2020 by Lane03

[speechles 1917]

What audio codec is this? The Roku can incorrectly report it supports 8 channel audio on Roku TV and Roku models that do not support it. This is a Roku bug that it is misreporting audio capabilities channel counts with EAC3. That codec is responsible for pushing ATMOS on the Roku. When the Roku misreports this and you do not have capable equipment to decode this it can hang the Roku. The Roku will get an error. It will fallback to Remux/DirectStream. When Remux/DirectStream HEVC with the audio is when the problem happens. If instead you choose the AC3 Dolby audio stream instead of the 7.1 this problem will not happen. Apologies this is occuring. It is due to a fault with how the Roku interprets HLS with certain HEVC streams and Remux/DirectStream.

I have several Roku models and can make sure they are all properly reporting audio capabilities and any that are not we will make changes. Unfortunately this is a two man band. Roku + Emby = beautiful music. If either one of us falls out of sync you hear cacophony. Apologies. We will strive to do better. I will also see what I can rattle at Roku to get them to notice these problems.

Edited December 26, 2020 by speechles

[ebr 14910]

1 hour ago, Lane03 said:

There is no need for my users to transcode video as all are on my LAN and all their devices can direct play the video streams as is.

Except that they actually cannot (for some reason).  If you had not restricted transcoding, instead of playback failing, it would have fallen back to transcoding and probably continued on fine.

[Lane03 14]

@ebr Then how come they can direct play the movie when I select an AAC 2.0 or AC3 track? Clearly the Roku can handle the video stream and the issue is caused when Emby tries to transcode the multi channel AAC.

Edited December 26, 2020 by Lane03

[ebr 14910]

Just now, Lane03 said:

Then how come they can direct play the movie when I select an AAC 2.0 or AC3 track? 

Because it is being delivered in an entirely different manner then.  The point is, you've disabled a feature that will help in these odd situations - so you aren't getting that help.

Why these are failing is probably related to the content or how it was created.  The Roku player is very strict on exactly how it wants things to be.  Any deviation from exact spec can make it throw up on itself.

[Lane03 14]

@ebr I'll enable video transcoding and do more testing later, however that isn't ideal as it would add unnecessary overhead on the server and it really seems to be an issue related to Emby converting 5.1 or 7.1 AAC audio on very long movies.

[ebr 14910]

Just now, Lane03 said:

on very long movies

This is a movie over 3 1/2 hoursish?  We suspect there is a defect/shortcoming in the Roku system with these when delivered via HLS (which is necessary to convert the audio).

[Lane03 14]

@ebr Correct.

 

[ebr 14910]

Okay, so at this point, there isn't anything we can do about this except for you to avoid a remux or transcode on movies that are this long.  This is some sort of deficiency in Roku that we need to identify and then see if there is any way to work around.  That won't be something that can happen fast I'm afraid.

[Lane03 14]

@ebr Understood and thanks for the follow up. I know it must be a pain as Roku seems to often break things that used to work when doing firmware updates, like the current audio sync issue when direct playing 5.1 AAC - which is what prompted me to enable the "convert multi channel AAC" option as a crude work around to avoid having to manually enable playback correction each time I play a movie. Unfortunately enabling that revealed this other issue with longer movies that I hadn't run into before as most of my movies are AAC 5.1 which my RokuTV can direct play.

@speechles Thanks, I also have the beta app and I tested that as well and it too had the same background image bug after playback fails. No need to apologize, I know you all are doing the best you can with Roku. Your efforts are greatly appreciated.

Edited December 26, 2020 by Lane03

[anujpuri85 1]

Just curious if anyone ever found a fix/workaround for this? I'm experiencing the same issues (and turning "Convert multi channel AAC" off hasn't helped).  embyserver (1).txtffmpeg-transcode-2571f30a-32ec-479e-baa8-ff882f0fed1f_1.txt