Roku playing the same audio track regardless of which is selected

[Grimmer 2]

I have seen several threads about a similar issue.  However, most of them concluded that there was more than one audio track marked as default.  This is not my case...

Regardless of which audio track is selected on the Roku, it always plays the not default audio track.  For example, there are 3 tracks.  Default = 5.1 DTS English, 2.0 English, 2.0 Spanish.  No matter which is selected, it always plays the spanish track.  And when I display the "stats for nerds" it doesn't show the spanish track as what is supposed to be getting played.

When I select "attempt playback correction" I get the correct audio, but it also starts transcoding the video at double the bitrate:

(By the way, I note that the Emby Activity log indicates that the show has stopped playing on the PC Emby Web, yet it is still shown in the "Now Playing" space.)

Here is the media info from Emby:

Based on what I've read in the older threads, I verified with ffprobe that only one audio stream is marked as default:

AudioTrouble_FFPROBE_Output.txt

(Note that the handler_name inherited the "Surround 7.1" descriptor from the original DTS HD MA on the bluray and I was too lazy to manually edit the name in Handbrake for every stream of every episode when transcoding.  As I understand it, this is just a name assignment and doesn't actually matter much for functionality.  I wish the audio selection routines were more detailed and more functional (I told it not to allow DTS HD and it still does, so I had to manually change to the second audio stream which was plain DTS 5.1 with DTS passthrough for each episode, there are a lot of episodes... - If someone can help me get that part to work better, I'd appreciate it, as well as getting the selection behavior for subtitles to burn in only the forced parts of a normal subtitle stream.  I can manually check the boxes, but can't get them automatically checked from the selection behavior).

Here is the Emby ffmpeg transcoding log (although only the most recent one):

ffmpeg-transcode.txt

Any ideas why I'm not able to select any of the available audio streams from the Roku?
Why does it start transcoding the video after a "playback correction" at double the frame rate (and double the bitrate)? 
Where I can take a class for interpreting the Emby ffmpeg log?  I wonder about that last one for an unrelated issue where I was experimenting with an MKV container and it had to transcode the video to add graphical subtitles and had a nice little nugget in there that said something to the effect of "Hardware subtitle overlay disabled do to selected diagnostic options".  It was not able to keep up with a 1080p video transcode while there were a couple of other transcodes also going on at the same time. 

Which leads me to another question... why does Emby jump straight to the transcode option for audio and/or video, when that playback device can also receive direct play?  For example, I disable that user account's permission to watch transcoded anything, yet that exact same video file still plays just fine on that same end device?  And why even though it has a stereo stream built in, does it still transcode 5.1 to stereo (instead of just serving the stereo stream)? I would really like to force it to not transcode anything unless it truly is absolutely necessary since my Emby server isn't running on the most powerful hardware ever made.

Lots of questions, I would appreciate any help that's available for any or all of them...

 

 

Edited February 22, 2023 by Grimmer

[pwhodges 1531]

Is there a "forced" flag on the track?

Paul

[Grimmer 2]

I do not see any indication that there is a forced flag on the Spanish track (although I may not .  However, I did just note that the others are AAC and the Spanish is AC3.  There is also a strange "Side Data" that none of the other tracks have.  Perhaps this is overriding the "Default" flag that is on the English 5.1?

I also was able to test it last night on a different model of Roku player and that model worked as expected (by respecting the audio track selection).  However, only a few titles on my Emby server have this issue.  Most of them work fine on either model of Roku.  What's even stranger is that I have no idea where or how that Side Data on the Spanish track came from.  When I get back to the server, I'll figure out how to change/remove that Metadata with ffmpeg without transcoding.  (I've downloaded and looked over MKVtoolkit, which may not work on the mp4?, but it is completely foreign and counter intuitive so far and I haven't had the time to invest in overcoming the learning curve.)

[Luke 37071]

Let us know how you get on. Thanks.

[speechles 1919]

  Stream #0:4(eng): Data: bin_data (text / 0x74786574)
    Metadata:
      creation_time   : 2023-01-20T04:17:16.000000Z
      handler_name    : SubtitleHandler
Unsupported codec with id 100359 for input stream 4

 

MP4 does not support TXT subtitles. If you removed that unsupported item from the container it will probably fix this issue. Since different Roku firmware work differently in this regard.

There are Roku models that do not support "Secondary Audio Streams" and yours may be a model number we do not know about yet. If you can play the same item on a different Roku model and change audio tracks this might be the case. What is the model number of the Roku that cannot change audio streams?

Edited February 23, 2023 by speechles

[Grimmer 2]

That stream is not actually a subtitle stream. From what I understand it is a data stream that contains the chapter information. Seems that the way ffmpeg handles it is considered a bit of a bug from some of what I've read about it. Boils down to if the container is mp4 and there is chapter information, that data stream is always created. In VLC if you activate that "sub title" stream it simply says "Chapter 1", etc. 

Before I looked into it more I tried stripping it off with negative mapping and blocking all subtitle inputs but ffmpeg always creates it. Sometimes I've seen it add a second one.

I will look up the specific model numbers when I get home. However, the two that are ignoring the language selection are the higher end ones since I require them to have the ethernet connector. The one that did respect the audio selection is outside the range of the cabling so it is wifi and likely less expensive. I'll confirm and post it later. 

... Maybe I can see it in the Emby device list or even my Roku account ... 

[Grimmer 2]

Roku account shows me the serial numbers, but not the model info... It'll be a bit before I can get it. 

[Grimmer 2]

I checked the Roku models:

4670X:  Ignores audio selection

4660X2: Ignores audio selection

4670X: Honors audio selection

Since one unit honors the audio selection and another unit of the same model ignores it, I looked deeper at the firmware versions as well as the Emby app versions.  Both the same on both 4670X units.  All of the audio and video options in the Roku menus are the same for both.  Using the same Emby user account on both.  But still getting different results.

One other thing I checked is that the offending Rokus always ignore the audio selection.  I only noticed it on the occasions title that also has Spanish audio.  But testing the audio selection between 5.1 and stereo also made no difference.

So far, the only difference I have found is the physical connection on the one that honors the audio selection is direct to the TV's HDMI; whereas, the other two were tested through an A/V switching home theater system.

For a different title a while back, I simple re-transcoded it and the Roku assumed the correctly marked default audio stream.  However, going back to that same title, it was also ignoring the selection.  I tested a re-transcode of the Star Trek TNG episode, but the new mp4 is still serving the Spanish stream only (and contains the "Side-Data - Audio Service Type: Main" issue.  When I used ffmpeg to remove the side data from that audio track it did stop serving the Spanish stream instead of the default (Eng 5.1) stream.  However, it was not a fast copy, it was transcoding something since it ran at 8x instead of the typical 100x for a straight copy.  At that speed it would be easier for me to just transcode all of the episodes from the original rips.

But the real question still remains.  Why am I getting two different outcomes on the same model / firmware...?  The situation is temporarily fixed by doing an "Attempt Playback Correction" in the Emby app.

If Emby is sending the file as ""Direct Play" then all of the audio streams are present?  Or does Emby only send the selected audio stream?  If they are all present, then perhaps the Sony A/V system is selecting the wrong audio to broadcast over the speakers.  I'll have to experiment with some mix and match wiring setups.

Based on any of the above, should I be focusing on the server side or the client side? (Roku Emby app settings vs Emby server settings vs Emby User settings, etc.)

 

 

Edited February 24, 2023 by Grimmer

[ebr 14913]

16 hours ago, Grimmer said:

So far, the only difference I have found is the physical connection on the one that honors the audio selection is direct to the TV's HDMI; whereas, the other two were tested through an A/V switching home theater system.

If that is the only difference then that very well could be it.  The Roku player tries to make its own "intelligent" selections of tracks sometimes and the way this is hooked up is probably giving the device different information about what is supported or not - which could then influence this selection logic inside the player.

Can you try swapping the devices and see what happens?

[Grimmer 2]

I experimented by connecting this unit directly to the TV (which then fed the audio via eARC back to the stereo).  I did not find any setting in the stereo relevant to a "preferred language".  When the Roku was connected directly to the TV, the input on the stereo was different as expected, but didn't help either.  I should try again with the TV speakers instead of the stereo.  However, I had the same results of it ignoring the track selection.  I have also played several other titles and the audio track is being ignored on all of them.  There are only a few that appear to favor the Spanish track.  However, it is the entire ST TNG TV show.  I re-transcoded some episodes and it still is putting that weird side data and favoring the Spanish track.  I haven't found another title that favors the Spanish yet (to see if it also has that weird Side Data).  I wonder why TNG transcoded with that side data using the same HD profile in Handbrake that I use for most everything.

What is driving me crazy is that other unit of the 4670X connected to a different TV is working just fine.  I'll try brining that one down to this TV and various setups after work.

Normally I would be figuring it is purely a Roku thing by now, but "attempting playback correction" alters the stream from Emby and then it works just fine, even though the video and audio were reported as already being direct playback.  So I'm still open to it being server side.  As a quick test just now, I disallowed any transcoding for that user, restarted the Roku Emby App and it still plays the Spanish track.

[ebr 14913]

6 hours ago, Grimmer said:

but "attempting playback correction" alters the stream from Emby and then it works just fine

That would be because the item is being completely re-packaged by ffmpeg on the server in that instance.

[speechles 1919]

On 2/25/2023 at 8:49 AM, Grimmer said:

As a quick test just now, I disallowed any transcoding for that user, restarted the Roku Emby App and it still plays the Spanish track.

That means the problem is not Emby.

You can probably fix this issue by remux with MKVToolNix GUI and repackage as MKV. That will build a new header that the Roku can properly parse and you will get Direct Play. The MOV_TXT subtitles cannot be inside MP4 or they confuse the Roku. Remux into MKV should solve your problem.

https://community.roku.com/t5/Features-settings-updates/How-to-mux-subtitles-in-an-mp4-file-so-RMP-will-detect-them/td-p/744943

What I think is happening:
There is no DTS showing on your example. Track 1 shows as default and is 5.1 surround in AAC (which an Emby Roku AAC setting can force to transcode automatically). Track 2 is Stereo in AAC. Then there is a Spanish AC3 track. You want to select the First English AAC track. Which might be impossible to do in Direct Play depending on the Roku model. Which is why we have the option to "Convert 5.1 AAC" option inside the settings of the Roku app. You may want to make sure that option is disabled. It will then convert on your Roku device to convert the 5.1 AAC to 2.0 AAC. Roku cannot play back 5.1 AAC it must be converted by the Roku unit itself during direct play or your Emby server while transcoding.

Lets use your two Roku 4670. Both must have stats for nerds enabled. One you said honors audio and the other does not. With stats for nerds enabled we can see what is actually happening. You can also watch the Emby server active devices section on your dashboard. My guess is that one of these Roku has a transcode reason right off (likely due to audio channels exceed maximum because of the Emby Roku AAC setting) and since it is repackaged can correctly select the audio stream. But the one Roku that ignores the audio selection is Direct Playing. To make both your Roku 4670 work the same we need to know that both are using the same play method. I am guessing here that they are not and that is the difference.

With this setting set to YES: Will Transcode using your Emby server and change the AAC 5.1 audio into AC3 5.1 audio.
With the setting set to NO: Will Direct Play the AAC 5.1 into your Roku which will then strip it back automatically and output AAC 2.0 stereo.

The Emby Roku AAC setting is required for users to keep surround sound. But it comes at the expense of transcoding audio.

 

Edited February 26, 2023 by speechles

[Grimmer 2]

There were a handful of the episodes retranscoded to down mix the DTS to regular 5.1.  The example posted must have been one of them.  I will transcode one with AC3 instead of AAC and see if that helps the poor Rokus sort it out.  I'm surprised to learn that the Roku cannot read AAC 5.1.  I presumed that the units were new enough (and expensive enough) that they would have packed them more functionality.

I have used the MKV container on a different show where we wanted to have subtitles, but that forced it to transcode and burn in the subtitles, which was unwatchable.  It also reported in the Emby ffmpeg log that the hardware subtitle overlay was disabled due to the selected diagnostic options.  Is that the expected behavior?  Is there a way to get it to allow the hardware subtitle overlay?  None of my other titles have subtitles in them, including ST TNG; however, as mentioned above ffmpeg is adding a data track that is being called "Subtitles" for the chapter information.  99% of the titles have zero issue with language selection in the presence of the chapter info data track.

I am hopeful that the AAC vs AC3 will be the issue.  However, I was just looking at the Emby dashboard and it says that it is transcoding from AC3 into AAC for a Roku.

I will go back and double check, but if I recall correctly the "Stats for Nerds" always displays the English 5.1, even when it is speaking Spanish.

I am transcoding an episode with AC3 DTS and AC3 5.1 to see if they are better behaved on this Roku.  It seems that my stereo is always showing 5.1 or DTS, I don't recall seeing it report the signal as 2ch stereo from the Roku when 5.1 was expected.

[Happy2Play 8282]

10 minutes ago, Grimmer said:

It also reported in the Emby ffmpeg log that the hardware subtitle overlay was disabled due to the selected diagnostic options.  Is that the expected behavior?

I believe that is how 4.7 is setup and will change in 4.8.  But will need to see the ffmpeg logs as image suggest device not reporting 6 channel AC3 support.

As for the MOV_TXT issue only the devs can comment further.

 

[Grimmer 2]

On the 4670X (not honoring unit), I flipped the convert multi-channel AAC setting to YES.  It then performed the transcode as you indicated:

However, when I switched it to AAC Stereo, I got conflicting info on the Stats for Nerds AND the audio was Spanish, not English.

After selecting the Spanish Track, the Stats for Nerds continued to display the AAC 5.1 Direct, with the Spanish audio.

[Grimmer 2]

It appears that the Roku doesn't know what to do with any AAC stream.  Too bad I had no reason to think that Roku would struggle with AAC as it seems that AAC was the default fallback option for Handbrake.  So everything I have downmixed was probably done as AAC instead of AC3.  Not sure it is worth switching the AAC to the AC3 in the server files themselves since all other playback devices haven't had any issues.  Luckily, I still have the BluRay rips for ST TNG. (I'm always reluctant to delete any TV show rips with 150 episodes, until temp HD space is a real problem.)

For further testing of the MOV_TXT, I'll have to redo the transcoding of that title since I killed the version with the MOV_TXT in an MKV container and replaced it with MP4 and SSA files so that it could at least be watchable.  Would be nice to get the hardware overlay working.  Might be able to include the MOV_TXT for a lot more titles.  That would make it a lot easier to setup the transcodes.  Currently I have to find the forced (foreign language) subtitles and have Handbrake burn them into the video images, then verify that is all went as planned before I can delete the rip. Any other subtitles I've ever used have been SRT or SSA getting fed as text by Emby.  If I could use an MKV container, I could just include all of the English subtitles in the transcode and leave it at that. 

[Grimmer 2]

Missed the edit window... 

It appears that the Roku doesn't know what to do with any AAC stream so it latches onto the closest matching AC3 stream, which in this case has always been the Stereo Spanish stream (since the ST TNG BluRay Spanish track started out as AC3.  I only down mixed the DTS HS MA so that it would use less bandwidth than the HD video stream. Even the core DTS stream was still 1.5mbps, so I down mixed it to the ordinary 5.1 at 640kbps (unfortunately as AAC). I create a downmixed Stereo channel in every title for compatibility on devices that don't have the benefit of the Emby server transcoding it.

[Grimmer 2]

@speechles, thanks for the info.  I only wish I'd heard about it 6 months ago.  I've been upgrading 480p rips to 1080p rips ever since Black Friday landed me with a much larger and higher resolution TV which made a lot of the 480p rips look like crap compared to the older smaller TV.  Probably most of them will need to have ffmpeg transcode from AAC to AC3 to avoid having to rip the discs again.

[Luke 37071]

Hi, are you still having an issue with this?

[Grimmer 2]

Yes. After a quick check, the Roku is still ignoring the audio track selection. 

[Luke 37071]

Hi, can you try the latest update to Emby for Roku and let us know how things compare? Thanks.

[damien_c2 7]

On 5/13/2023 at 1:49 AM, Luke said:

Hi, can you try the latest update to Emby for Roku and let us know how things compare? Thanks.

@Lukei was answer to this thread. 

 

im having same issue. 

Edited January 7 by damien_c2

[Luke 37071]

4 minutes ago, damien_c2 said:

@Lukei was answer to this thread. 

 

im having same issue. 

Can we please look at an example? thanks.

[damien_c2 7]

3 minutes ago, Luke said:

Can we please look at an example? thanks.

Im not sure it what you need: I have one file in AAC (English and French) on mp4 and even if we select French the roku keep playing english. 

[Luke 37071]

35 minutes ago, damien_c2 said:

Im not sure it what you need: I have one file in AAC (English and French) on mp4 and even if we select French the roku keep playing english. 

The information requested in 

How to Report a Problem

Thanks !