Emaby app on Streaming Stick+ unable to differentiate between audio tracks of the same encoding

[csimon 4]

I have found forum posts relating to multiple audio track issues with Roku but none have explained exactly what I'm seeing.

 

I have a .m4v file created from a Handbrake compression of a MakeMKV rip with several audio tracks:

 

7.1 DTH-HD MA

5.1 DD (downmixed from the above 7.1 track)

Stereo AAC (downmixed from the above 7.1 track)

Stereo AAC (created directly from the Director's Commentary track on the Bluray)

Stereo AAC (created directly from the Writer's Commentary track on the Bluray)

 

The Emby app correctly selects and plays the 7.1, 5.1 and first Stereo AAC track but any attempts to play the second or third AAC track still plays the first.  It seems to be becuase they have the same descriptions in the app (although I have given the tracks different names), only the first one is found when asked for.

 

I can confirm this by creating another file with only the two Commentary tracks in it. I am able to play only the first one even if the second is selected.

 

This is the case regardless of whether the track is selected from the movie information page before playing or after the movie has started playing by pressing the down arrow and selecting the track from the pop-up info bar.

 

The Empy app in my LG TV works fine, it is just the Roku one that doesn't work.

Edited May 10, 2019 by csimon

[Luke 37046]

Hi there, can we please go over an example? Please attach the information requested in how to report a media playback issue. thanks !

[csimon 4]

Hi there, can we please go over an example? Please attach the information requested in how to report a media playback issue. thanks !

 

Attached server and remux log files.

 

User logged in on roku Emby app: chris

User logged in on server: admin

 

19:47 Entered Emby app and navigated to Prometheus (2012). Selected the Prometheus (2012)-Commentaries.m4v file (this contains four of audio tracks as mentioned in my OP, less the 7.1 track) and started playing with the "English Dolby 5.1 (Default)" track. This would have triggered remuxing as the TV only accepts stereo.

 

19:49 Pressed down arrow and selected the first AAC track. This is the normal track wityhout a commentary. This played fine.

After a whle I pressed down arrow again and selected the second AAC track. This should have had a commentary by the directory, but after the video restarted the track without a commentary played again.

 

19:50 Pressed down arrow and selected the third AAC track. This should have had a commentary by the writers, but the video restarted without a commentary, i.e. it played the first AAC track again.

 

19:51 Stopped playback and exited Emby.

embyserver.txt

ffmpeg-remux-e3812496-96fc-4003-8029-a3be68a2519f_1.txt

[speechles 1917]

Can you try with the Emby Beta of the Roku app and see if this behavior changes.

[csimon 4]

I'm now using the Emby Beta channel but I'm afraid the behaviour is still the same.

[speechles 1917]

I'm now using the Emby Beta channel but I'm afraid the behaviour is still the same.

 

How are you change the audio stream? You can also change this on the detail screen before you play. Look above the buttons for the Audio selection. Change that prior to playback. It should work.

 

You can also use the video player and press down. This will open the on screen display. Now use the audio button (looks like a speaker with sound waves coming out) and click it. This should show all the audio choices available. If you choose from this menu in should work.

 

When you press * and use the built-in Roku feature to change the subtitles or audio it will not take into account all the available streams or be able to select them. Using the Emby methods (detail screen + video player OSD) to change these should always work correctly and take into account all available streams.

 

You can also open the OSD and choose the gear/cog icon. Then enable the stats for nerds. Here you can verify which audio stream is being played and if it is being converted to another codec.

 

We would also love to see your ffmpeg log. Can you attach it please? This will be in the same folder as your Emby log. It will be labeled with "ffmpeg" at the front. We need the relevant ffmpeg logs from an attempt to play an audio stream that you feel isn't working correctly. Then we can investigate deeper.

 

I know on Roku 2 and Roku 3 they do not allow secondary audio streams. It is possible your streaming stick+ does not either and we need to add this to our profile to match how we treat the Roku 2 and Roku 3 in this regard.

 

Seeing your ffmpeg logs will confirm what is happening. Thanks.

Edited May 12, 2019 by speechles

[csimon 4]

For the purposes of this bug report, I am changing audio streams by pressing the down arrow and selecting the audio track option from the OSD while the movie is playing. I know about selecting the track from the movie screen before starting the movie, however this has exactly the same problem. Selecting that way has an additional problem because it seems what the app shows for the track is not actually the track that is selected when you open the pull-down menu to select the track. For example, when I go into the screen, I see the 5.1 Default track. however, when I go into the pull-down list, it can show one of the other tracks with a checkmark against it. The same happesn if there are multiple versions of the file - the file pull-down list initially does not actually show the file that is the currently selected one. So there is a mismatch between what track is selected and what the screen shows initially. I didn't report this because I thought it would complicate the bug that I am reporting.  I wanted to give clear, reproducable steps without complication, which I gave in the third post above.

 

I do not use the * to change audio track as this is the Roku facility not the Emby app.

 

I already attached the ffmpeg log file in the third post above.

 

My Roku Steraming Stick+ does allow secondary audio streams as I can select the 5.1 (default) track or the first AAC track, and both work. What I can't do is select the second or third AAC track. Maybe it, or the Emby app, cannot differentiate between multiple tracks that are all called AAC.

[Happy2Play 8271]

Sounds like a media info issue but ffmpeg knows there are multiple AAC tracks.

     Stream #0:1(eng): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, 5.1(side), fltp, 224 kb/s (default)
    Metadata:
      creation_time   : 2019-05-09T20:45:19.000000Z
      handler_name    : SoundHandler
    Side data:
      audio service type: main
​    Stream #0:2(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 160 kb/s
    Metadata:
      creation_time   : 2019-05-09T20:45:19.000000Z
      handler_name    : SoundHandler
    Stream #0:3(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 160 kb/s
    Metadata:
      creation_time   : 2019-05-09T20:45:19.000000Z
      handler_name    : SoundHandler
    Stream #0:4(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 160 kb/s
    Metadata:
      creation_time   : 2019-05-09T20:45:19.000000Z
      handler_name    : SoundHandler

[speechles 1917]

For the purposes of this bug report, I am changing audio streams by pressing the down arrow and selecting the audio track option from the OSD while the movie is playing. I know about selecting the track from the movie screen before starting the movie, however this has exactly the same problem. Selecting that way has an additional problem because it seems what the app shows for the track is not actually the track that is selected when you open the pull-down menu to select the track. For example, when I go into the screen, I see the 5.1 Default track. however, when I go into the pull-down list, it can show one of the other tracks with a checkmark against it. The same happesn if there are multiple versions of the file - the file pull-down list initially does not actually show the file that is the currently selected one. So there is a mismatch between what track is selected and what the screen shows initially. I didn't report this because I thought it would complicate the bug that I am reporting.  I wanted to give clear, reproducable steps without complication, which I gave in the third post above.

 

Okay.. The detail screen might have issues. That part I did not run through with a fine tooth comb. The detail screen version/audio/subtitle has code that wasn't written by me. I can roll through that and see if there is any indication where it could be slipping through cracks. But the video player OSD one is entirely.. well.. entirely I know what is going on there.

 

The only time the video player OSD audio/subtitle change can get stuck is when playing a next up item. It will never get stuck with audio only subtitles. It might always leave subtitles on and never turn them off. You can change them but they won't let you switch them off. This is a bug I have yet to squash. It has to do with cached states of something.

 

This is audio streams you are having an issue with though. This I have tested thoroughly on the video player OSD. If there is a problem there it passed my eyes. I don't have all the right sample media in my /test collection obviously...

 

Do you have any way to share that video with me? Via dropbox, google photos, microsoft onedrive, etc.. I just need to download it and see this for myself with the development tools I have. Then I can quickly put this to rest and see where the issue is. Thanks again.

 

 

Also.. we store the index you want to change the audio to. Not the name or anything related to text. We tell Emby the index position of the audio stream we want to play it is within the media container. We aren't using text. It is using index number to pass this to Emby server.

Edited May 12, 2019 by speechles

[csimon 4]

I don't have any of those cloud services. :-)

 

I'll look into setting up a Dropbox account. Bear with me!

 

Do you have a Roku Streaming Stick+ to test it with? I'm aware that different Roku models have different characteristics.

Edited May 12, 2019 by csimon

[speechles 1917]

I don't have any of those cloud services. :-)

 

I'll look into setting up a Dropbox account. Bear with me!

 

Do you have a Roku Streaming Stick+ to test it with? I'm aware that different Roku models have different characteristics.

 

No.. but not saying that would be required. It isn't required to own every model to write code for every model.

 

Usually I can see the problem that would be there without having that device. I can see what the problem would be on it and code for that just by what users report who have that device. The rare instance that isn't possible I have to do more...and those streaming stick+ are starting to cause problems and might be worth picking one up. But presently no I lack that model. I have Roku 3, Roku ultra 4640, Roku ultra 4660, Roku 2 xd. Not saying wouldn't pick up a streaming stick+ if it helps solve this issue and future issues. If the device is going to differ from others significantly I need that differing device to test on to prevent situations just like this.

 

But maybe this is something in the media itself. This is why I would like to see the media too. Not saying it is. I just like complete information. Thanks.

Edited May 12, 2019 by speechles

[csimon 4]

I've set up a Dropbox account but the free version limits files to 2GB, my file is more than that.

 

So I've created a new file of the first 60 seconds only, it's 19MB, so actually can I simply PM it to you?

 

It has 4 audio tracks. You can verify in, for example, VLC that all 4 tracks are selectable and are different. I've verified in the Roku Emby app that it still exhibits the same problem.

 

1. AC3 5.1

2. AAC 2.0

3. AAC 2.0 - Director's Commentary. The Director starts speaking at 0:18.

4. AAC 2.0 - Writer's Commentary. The Write starts speaking at 0:04.

Edited May 12, 2019 by csimon

[speechles 1917]

I've set up a Dropbox account but the free version limits files to 2GB, my file is more than that.

 

So I've created a new file of the first 60 seconds only, it's 19MB, so actually can I simply PM it to you?

 

It has 4 audio tracks. You can verify in, for example, VLC that all 4 tracks are selectable and are different. I've verified in the Roku Emby app that it still exhibits the same problem.

 

1. AC3 5.1

2. AAC 2.0

3. AAC 2.0 - Director's Commentary. The Director starts speaking at 0:18.

4. AAC 2.0 - Writer's Commentary. The Write starts speaking at 0:04.

 

Yes.. or send me a link to that file in Pm yes. Thanks.

 

NOTE: I assume the same issue is present in the 60 second sample too.

Edited May 12, 2019 by speechles

[ebr 14910]

Please include me in this PM with the link.

 

Thanks.

[csimon 4]

OK, PM sent to both of you.

[speechles 1917]

 

OMG.. It is Prometheus.. I love that movie. But there is a problem. You gave us the beginning. There isn't any speaking in this part. It is hard to tell which track we actually have.. Lol

 

Is there a way you can give a sample more near the middle or during talking?

[csimon 4]

LOL, I'm a big Alien fan....

 

The 60 seconds is sufficient for you to see the problem.  Tracks 1 and 2 are the normal movie soundtrack, tracks 3 and 4 are the commentaries and the speaking starts in them at 0:18 and 0:04 respectively.  If you're not hearing the commentary then you're listening to either track 1 or 2.  Try viewing it in VLC - you can switch audio tracks correctly.

 

This is exactly the problem I'm experiencing I think - regardles of which AAC track is selected in the app, only the first AAC track is played, the one without the commentary.

Edited May 13, 2019 by csimon

[speechles 1917]

LOL, I'm a big Alien fan....

 

The 60 seconds is sufficient for you to see the problem.  Tracks 1 and 2 are the normal movie soundtrack, tracks 3 and 4 are the commentaries and the speaking starts in them at 0:18 and 0:04 respectively.  If you're not hearing the commentary then you're listening to either track 1 or 2.  Try viewing it in VLC - you can switch audio tracks correctly.

 

This is exactly the problem I'm experiencing I think - regardles of which AAC track is selected in the app, only the first AAC track is played, the one without the commentary.

 

BTW.. just so you know..

 

The audio streams when listed on the detail screen are listed top to bottom. The 1st track appears on top. The last track on bottom. This is because the list is a drop down selector. The list appears to grow downwards.

 

The audio streams when listed on the video player are listed bottom to top. The last track appears on top. The first track appears on bottom. This is because the list is a lift up selector. The list appears to grow upwards. The opposite of a drop down selector.

 

So to choose the last audio stream on the video player would be the top one.

 

You are aware of this? It should be intuitive this is happening.

Edited May 13, 2019 by speechles

[speechles 1917]

---- AA ----

bitrate: 2489141

subtitlestream: invalid

playmethod: DirectStream

livestreamid: invalid

playsessionid: cd32b34ea6334b88b347c384abc09aee

mediasource: unknown

videostream: unknown

audiostream: unknown

audiostreamindex: 4

canseek: true

subtitlestreamindex: -1

------------

 

 

It acts like track 4 isn't a commentary. Same with track 3. The app is picking the correct track. It is not being transcoded.

 

@@ebr Can you make heads or tails of this?

Edited May 13, 2019 by speechles

[speechles 1917]

OMG.. It is a Roku firmware bug. Has nothing to do with us...  Emby is not the cause. But Emby can fix this. Emby is the cure.

 

After you select track 4 (the top track) in the video player it will play the normal audio right? Okay... now go the gear/cog on the OSD and choose playback correction. Suddenly when it resumes the audio is now correct. Yep. This means when selecting tracks the Roku itself is using names/text not numbers/index. The title we feed the Roku is used to select. This means we cannot use titles that are the same. Each title MUST be unique.. Otherwise it iterates from 1 to end looking for the first matching title to match the audio/subtitle you select. How ridiculous...

 

@@Luke @@ebr the titles given to subtitles and audio streams must be unique when given to the Roku. Can the server add something to the end like (1) (2) etc. Like windows does when a filename is the same. This will work around this Roku firmware issue and should let us still direct play and get the correct audio/subtitle. Or should we do this comparing inside the Roku app and add the (1)(2) etc? I say let the server do this in case any other app/device/platform has this issue. It is best to nip the problem at the source rather than produce band-aids.

 

 

Works. I hear the commentary now. Both streams still direct. But ffmpeg is used to perform container swap m4v -> m3u8/ts HLS. I will make a post on Roku forums about this in a bit.

Edited May 13, 2019 by speechles

[csimon 4]

BTW.. just so you know..

 

The audio streams when listed on the detail screen are listed top to bottom. The 1st track appears on top. The last track on bottom. This is because the list is a drop down selector. The list appears to grow downwards.

 

The audio streams when listed on the video player are listed bottom to top. The last track appears on top. The first track appears on bottom. This is because the list is a lift up selector. The list appears to grow upwards. The opposite of a drop down selector.

 

So to choose the last audio stream on the video player would be the top one.

 

You are aware of this? It should be intuitive this is happening.

 

Well, I wasn't aware that it was the exact reverse but I had spotted that the tracks weren't in the order I was expecting. That caused me a bit of a problem in testing because I assumed it was no particular audio (i.e. random) therefore I couldn't be sure which AAC I was selecting - I could have simply been unlucky in choosing the original audio track each time! But it happened every time and too many times to be chance. It was also mixed up in that other problem I mnetioned in that the movie Detail screen also seems to have a problem in selecting and showing the wrong track.  Far too many variables to diagnose!

[speechles 1917]

Well, I wasn't aware that it was the exact reverse but I had spotted that the tracks weren't in the order I was expecting. That caused me a bit of a problem in testing because I assumed it was no particular audio (i.e. random) therefore I couldn't be sure which AAC I was selecting - I could have simply been unlucky in choosing the original audio track each time! But it happened every time and too many times to be chance. It was also mixed up in that other problem I mnetioned in that the movie Detail screen also seems to have a problem in selecting and showing the wrong track.  Far too many variables to diagnose!

 

yep. The detail screen change will not stick unless you play the item. Once you play it your change will stick. So if you change the detail screen drop downs to something. But do not play it. Then come back. Yep. The last play state for that item will populate. Not how you last selected those drop downs. The detail screen is in flux at the moment too. We have changes coming to that area to address some design concerns. We can also investigate the problem with the selectors on the detail screen. This is also already on our issue tracker to do. It is just a rather large upcoming feature is coming that we have been working on. This feature will allow us to show more than just English. Once we are done with that effort with translations we can move onto your issue.

 

LiveTV issues are #1. Playback issues #2. We have no LiveTV issues presently that are show stoppers. Just feature additions. Bug fixes trump most feature additions. Usually. But sometimes a feature request will help build a better audience. In which case a feature request might be done before a bug report is fixed. You never know. Each day can change things. The future is in flux. Roku could break the firmware tomorrow and force us to spend time fixing things otherwise were already working before. It is a game of catch-up every single day. We enjoy what we do so this is routine. Just another day. We will fix all these issues eventually. I just like users to know that most of the issues are not caused by us, but by Roku themselves, and we get caught in crossfire and do magic to work around them. We do this all the time. Please bear with us.

Edited May 13, 2019 by speechles

[ebr 14910]

The server shouldn't have to do anything here.  The Roku app decides what the identifiers are for each track when it builds the video item so we can be sure they are unique within the app.

 

Please wait on this until our other current project is complete though.

 

Thanks.

[csimon 4]

OK, thank you for the commitment and for being open and transparent, and glad you've been able to replicate and find the issue.  Obviously, I'm new here, but hopefully I'll be annoying you more in the future!  I'm coming from Plex having got disillusioned with the project and I'm finding Emby a breath of fresh air. My goal is for a complete networked video store, live TV and DVR,  with a "cheap" client at each TV (the Roku seems to be the most appropriate) and tablets - the search for the ideal solution has been over many years!  I only have satellite TV reception where I live so I'll probably have a TV Mosaic back-end for Sat>IP tuners - I understand that the plugin for Emby is essentially seamless and works well.  So once I've got a Linux machine up and running for use as a media server, I'll hopefully be dropping a payment for Emby.  I use JRiver for a music server (playing via DACs) as it's the only solution I've found that allows you to customise your browsing menus in whatever way you want other than the usual Album, Artist and Genre. I also use JRiver for music videos (playing via DLNA) for the same reason of customisation of categorisation and browsing option, and jukebox-style queuing.

 

Just a quick introduction - perhaps this belonged in another thread somewhere!

Edited May 13, 2019 by csimon

[speechles 1917]

jukebox-style queuing.

 

Interesting choice of words. I am sure I have seen this before. @@ebr heheh