Unable to start playback

[ebr 14928]

11 minutes ago, ITGuy1024 said:

Emby doesn't build or support the players on Rokus? Interesting and concerning.

Hi. The Roku platform is probably the most restrictive one we build for (excepting perhaps some of the special TV OSes).  There is limited customization, a proprietary development language, etc.

However, that should not be concerning.  We have many, many happy users on the Roku platform.

[ITGuy1024 13]

1 hour ago, ebr said:

Hi. The Roku platform is probably the most restrictive one we build for (excepting perhaps some of the special TV OSes).  There is limited customization, a proprietary development language, etc.

However, that should not be concerning.  We have many, many happy users on the Roku platform.

I was one of them. I used Rokus for the last 5 years without issues. Not sure why this suddenly is a problem.

[speechles 1920]

3 hours ago, ITGuy1024 said:

Emby doesn't build or support the players on Rokus? Interesting and concerning.

So all Emby players don't work the same? The media plays fine on my tablet / phone / pc with those Emby players.

Imagine all the other players like normal. Where you can share code. They all use a common core (java, python, c, swift, etc) language and can compile normally and all that other stuff. It is easier because the languages can be anything used to program with.

Now on Roku there is a single language called brightscript that is only used on Roku. It has no low level access. Emby is ran inside a sandbox. That sandbox is not combined with the video player. You get memory pointers and some local variables. The main runtime runs outside the Emby instance. There is no easy (read as non-corporate partner) way to add python, or java, or any other kind of runtimes to the Emby side. You must code it all in native brightscript. Roku does not offer an NDK (native development kit) to anyone except corporate partners. This limits any ability to alter player behaviors such as speed controls and etc. The Roku requires you must start from scratch on everything since it has this unique programming language that nothing else uses.

The video player logic we built on top has fallback detection, hang detection, and some other stuff. Because of this Emby will have a better "Roku player experience" than all other Roku applications because of what Emby has built on top. But this extra video player logic we built isn't helping in your case because the player is telling us the item has finished. There is no way to program or code around that fact. The Roku player believes it has arrived at the end of playback. This could be because those EIA_608 are set as default. Those subtitles will always try to play being set as default. Maybe that is causing the failure is the subtitles fail to load and this causes the end of playback? Hard to know.

The Roku is wonky. Some Roku devices will play items in their player that other Roku devices will not. It is hard to tell rhyme or reason "WHY???!" sometimes. For the most part these failures come down to codec detection, reading support from the devices and such. But for the minor part it is due to quirks in the different chipsets each Roku device is composed of all of which Roku isn't giving us any clues about. This presents the challenge. You must be  jedi and it is hard when the Roku player is still padawan. This is where you have to trust.

The Roku player is built by Roku. How the Roku player detects the format of your media is built by Roku. The Roku is unlike other players because it loads the header of the file to check format unlike other players which check the bit streams themselves. This can lead the Roku to become confused when the header attributes do not follow standards. Other players can work around this fact because they can tell the header is wrong once they read the bit streams. The Roku doesn't even go that route. To the Roku the header is the trust. So at Emby as far as Roku is concerned we must also trust the header of the file.

What is built on the player by Emby is all the features on top. The overlay UI, the trickplay, the skip intro, the stats for nerds, and all the rest. We are trying our best to give you better than what they have presented you with. But we can only work with what we are given. All Roku developers who use the RSGA SDK are in this same boat.

Those are honest answers why you are having issues. Apologies we cannot give you a better answer.

Edited November 23, 2022 by speechles

[rotational467 31]

@ITGuy1024 in my experience with MKVs, using mkclean on the file with the --optimize switch after encoding will produce a proper MKV that the Roku (and everything else) will be happy with, and is probably the lowest-effort way to ensure you have a file that adheres to spec.

https://www.matroska.org/downloads/mkclean.html

[frankmb 27]

Thanks for the insights @speechles.

Would it be possible for the Emby server to remux on the fly and work around the Roku player issues?

[Luke 37110]

2 hours ago, frankmb said:

Thanks for the insights @speechles.

Would it be possible for the Emby server to remux on the fly and work around the Roku player issues?

That's what we do already for things that are unsupported.

Where it gets tricky though is when you have video files that look like they should direct play based on the media info, and then you don't find out that there's a problem until you actually go and try to play. Those are difficult to automatically detect.

Our usage of the Roku video player does have some error recovery where we can automatically switch to remuxing or transcoding when the Roku video player reports an error, but there are times when it does not signal anything even though the video is not playing correctly. So we do our best to handle those situations.

[frankmb 27]

I see, thanks. Maybe there could be a brute force option of "just remux everything for Roku" assuming it would not cause more problems than it solves.

[frankmb 27]

I mostly watch episodes with subtitles on. Often the subtitle track I select is not the one I see. So I need to force remuxing to see the correct subtitles on Roku. Lately I would say that one third of episodes don't play correctly. Usually because the English Forced Subs override the English full subtitles.

So I ask again: please add a brute force option of "just remux everything for Roku"

[Luke 37110]

Are you still having to do this?

[frankmb 27]

On 2/21/2023 at 12:19 AM, Luke said:

Are you still having to do this?

Yes the same problem continues. Most often with English Forced Subs overriding the subtitle track I select. I can work around the problem with "Attempt Playback Correction". I should not need to do this.

[Luke 37110]

@frankmb is this still an issue?

[frankmb 27]

Yes the same problem continues. English Forced Subs override the English subtitle track I select in the Roku client. I can work around the problem with "Attempt Playback Correction".

[speechles 1920]

29 minutes ago, frankmb said:

Yes the same problem continues. English Forced Subs override the English subtitle track I select in the Roku client. I can work around the problem with "Attempt Playback Correction".

 

What are your subtitle settings on the server for that user?

Is your subtitle mode set to show no subtitles?

Are there both "Default" and "Forced" flags showing for that subtitle?
Can you show us the Media Information section of the web app for one of those files? That will give us better clues.

Edited April 29, 2023 by speechles

[frankmb 27]

My Subtitle mode is set to Smart. Yes both "Default" and "Forced" flags are showing for the subtitle that overrides my selection in Roku. 

 

[speechles 1920]

@frankmbThat is likely the issue. I know when the media have two subtitles marked default the Roku will only allow the first default when Direct Playing. This might be the same cause. The Roku becomes confused about those flags and settles on the first default. If you remove the "Default" flag for that subtitle and leave it marked only "Forced" it should then allow you to change. Without that the only way is with Attempt Playback Correction.

We could somehow add detection for this and force transcoding to a new container. So the video and audio streams are copied. Then we can pick and choose the subtitle to merge and correctly do so. But that would involve remux your item. It will no longer Direct Play. Not sure if that is how they want to approach this.

Usually it is far easier on your server to remove the offending flag with MKVToolNix GUI making sure that item does not have multiple defaults set or a subtitle with both forced and default.

I can put this on our issue tracker so we can figure out what to do here since it is an issue.

Reference: Issue #1457: [Captions] Subtitles cannot be changed if marked with multiple defaults or default/forced is combined on any

Edited April 30, 2023 by speechles

[frankmb 27]

I see. Yes I think it should remux if the problem happens. The Roku Emby app does not play the subtitle I choose.

The Roku Emby app should always play the subtitle I choose.

[ITGuy1024 13]

The initial problem I started this thread for seems to be working better now with no changes to my media files. The files I had trouble with before played fine on the device I had issues with before.