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

[csimon 4]

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

 

Oops, LOL!

[speechles 1917]

Oops, LOL!

 

It is just interesting. I mentioned before we need "Jukebox" like features for music in the app. Now here comes the moment.

 

More use of album art in song/track listings. Use of huge(read as detailed) album art when on the music detail screen. An artist screen that comes up when playing music queues/playlists that looks just like a jukebox attract mode. All of this has been discussed. This might be the time. You might be here at the right time. The right place the right time.

 

If I could show you screenshots of how this looks you would ask "Why isn't this in the app right now???"

 

Because we test ideas. It may not be ready for prime time. We toss around new design themes time to time. Push what is possible today and what could be possible tomorrow. Not everything makes it. This might be one of those things that should be pushed today rather than tomorrow. Time will tell. Music will get better. We will explore more in that area.

Edited May 13, 2019 by speechles

[ebr 14913]

and jukebox-style queuing.

 

Hi.  Can you please tell us exactly what you mean by that?

 

Thanks.

[csimon 4]

Hi.  Can you please tell us exactly what you mean by that?

 

Thanks.

 

I play music videos in the same way as I play my music, e.g. browsing through them (in browse hierarchies I have set up in the library) and then queue them one by one, either appending them to the queue or inserting them as next to play. Then having a Now Playing screen, with playback controls, which can be toggled to see the current queue, and then being able to rearrange items in the queue before they're played or removing them from the queue.  Maybe also creating and saving Playlists that can be recalled. Basically, just think of any reasonable music player on a phone, and how the Now Playing queue is handled.

 

For a living room scenario, this would be best done from a handheld client/remote control really while the videos actually play on another device. I'm envisaging the Emby app on a tablet for browsing and queueing while the actual video is sent via DLNA to a TV or another instance of Emby on the TV or a streaming box such as Roku. Of course, you could also play the videos locally to the device you're browsing on rather than sending them to another device such as a TV.

 

I haven't got as far as investigating what facilities there are in Emby for doing this already (for either music or music videos), as I'm assuming the browsing structure isn't there for what I'd want to do anyway. JRiver is working perfectly for me for this purpose at the moment! :-)

Edited May 13, 2019 by csimon

[ebr 14913]

Thanks.  For music, we do have most of what you requested there already.

[Luke 37065]

I guess the question is should we stick the (1) at the end using the server, and have that in every app, or just make the roku app deal with it since it's only a problem there.

[csimon 4]

I guess the question is should we stick the (1) at the end using the server, and have that in every app, or just make the roku app deal with it since it's only a problem there.

 

This is something that will be seen by the end user, i.e. on the track menus? It might be reasonable to assume that since this is a Roku problem then the workaround should only affect Roku users, however if you prefix the track name with the track number, e.g.

 

1. English Dolby 5.1 (Default)

2. English AAC Stereo

3. English AAC Stereo

4. English AAC Stereo

 

then it actually helps all users to differentiate between tracks where they have the same name, as I assume all clients will have the same visual problem (even if the non-Roku apps do actually play the correct track). It prevents trial and error when trying to select, e.g. the Director's Commentary, as you will probably know which order you put the tracks in when doing a rip/conversion.

 

It also helps prevent confusion when the tracks are displayed in reverse order, though it will look a little odd with the numbers in decreasing order. It's not actually obvious that they are being shown in reverse order, when you just have the name. It could have been alphabetical order in this case. And within alphabetic order, which order would the ones that have the same name be shown in...track number, reverse track number, or random? There's no way to tell and therefore which one to pick when you want, e.g. the Director's Commentary.

 

So basically, I think I would argue for having the track number appended server-side, so that it happens in all clients.

 

Handbrake allows you to assing a custom name to the track too,as well as the non-amendable encoding format that is currently displayed in the Emby apps. Do you have access to that name? If so, and it is present in a track, can you use that instead of the generic name?

Edited May 15, 2019 by csimon

[ebr 14913]

This issue is unique to Roku and I believe that is where it should be handled.  All the other apps work off of index numbers now but Roku uses a program specified "ID" and we just aren't using a good enough one in the app.

[speechles 1917]

Piggy-backing on what Eric says above. This only affects direct play. This is the Roku having the limitation to switch when in Direct Play because it is introduced a list. In that list it stops at the first one that matches. When ffmpeg is involved during DirectStream, Remux, or Transcode the problem goes away. I understand you want Direct Play support. I just make this statement to let other users know that this issue is directly related to the Roku choosing to use ID rather than Index. Emby itself always uses index on the Roku and that is how ffmpeg makes it work. It is Roku who chose to use a silly method to iterate lists looking for text rather than using index numbers. Because of that mistake Roku made we have to work-around it.

 

This is where I agree with @@ebr again. If the Roku is only device with an issue why should the server burden all apps with a change? When just the Roku deserves it. Do you spank ALL your children when ONE does something wrong? no. You discipline according to child. This is the same we discipline the device. It is misbehave. The server shouldn't have to make new rules for all children for one misbehaving. The server in this case is the parent. You don't correct the parent. Correct the child.

Edited May 16, 2019 by speechles

[csimon 4]

I'm aware of the reasons why you only want to treat Roku differently, howver I'm pointing out that there is an opportunity to make things better for other devices too, as if you make the fix for Roku only, users of all other devices will still have no way to differentiate (visually) between audio tracks of the same type. Doing the fix sever-side will not any way make things worse for other devices.

 

If the parent has multiple children with different issues but you can solve all of them by modifying parent behavior then that solves more problems across all children. In some cases, it's not right to punish children, you jsut alter the way you deal with them to encourage them to behave better.

 

I'm a developer too and support analyst, I don't need these types of analogies.

[speechles 1917]

I'm aware of the reasons why you only want to treat Roku differently, howver I'm pointing out that there is an opportunity to make things better for other devices too, as if you make the fix for Roku only, users of all other devices will still have no way to differentiate (visually) between audio tracks of the same type. Doing the fix sever-side will not any way make things worse for other devices.

 

If the parent has multiple children with different issues but you can solve all of them by modifying parent behavior then that solves more problems across all children. In some cases, it's not right to punish children, you jsut alter the way you deal with them to encourage them to behave better.

 

I'm a developer too and support analyst, I don't need these types of analogies.

 

Why you rolled perfectly with it. You argument makes sense. Train the parent and they correct themselves which produces correct children. In this case, to get you what you want sooner I would do it in the app. Then if later anyone wants to change it on the server it would also work on the roku. The Roku will only apply what I make it do when there is similar. The same. If the server were to later make this different well the Roku wouldn't apply the fix. The fix will just work to make things dissimilar.

 

audiostreams = CreateObject("roArray")

For each text in audioStreamsToAdd

    t = text

    For each child in audiostreams.getChildren()

        if t = child then t += "*"

     next

     audiostreams.push(t)

next

 

Probably something as simple as that. Why does it have to be {1} {2} {3} that is so old.

 

AAC*

AAC**

AAC***

 

Or would you rather than {1} or {2} or {3} on the end. Those braces look horrible and scary in text.

 

like that below? eww...

audiostreams.push(t.substitute("*****","{5}").substitute("****","{4}").substitute("***","{3}").substitute("**","{2}").substitute("*","{1}"))

 

Personally I prefer *. The little asterisk. So humble. So not proud. Just a common character.

 

This would be how it could be solved very soon.

Edited May 16, 2019 by speechles

[ebr 14913]

I'm aware of the reasons why you only want to treat Roku differently, howver I'm pointing out that there is an opportunity to make things better for other devices too, as if you make the fix for Roku only, users of all other devices will still have no way to differentiate (visually) between audio tracks of the same type. Doing the fix sever-side will not any way make things worse for other devices.

 

If the parent has multiple children with different issues but you can solve all of them by modifying parent behavior then that solves more problems across all children. In some cases, it's not right to punish children, you jsut alter the way you deal with them to encourage them to behave better.

 

I'm a developer too and support analyst, I don't need these types of analogies.

 

Yes  but you are actually talking about what is displayed to the user and that is not where the problem is here.  The problem is internal to the app and how it is deciding to tell the Roku system what track is what.  We don't use the same thing that is shown to the user for this.

[Happy2Play 8282]

Does the "Embedded track title display" setting apply to all apps?

 

 

https://emby.media/community/index.php?/topic/34573-audio-and-subtitle-track-labels-for-mkv-containers

https://github.com/MediaBrowser/Emby/issues/3397

[csimon 4]

Yes  but you are actually talking about what is displayed to the user and that is not where the problem is here.  The problem is internal to the app and how it is deciding to tell the Roku system what track is what.  We don't use the same thing that is shown to the user for this.

 

OK - if this isn't something that's displayed to the user, that's fine, it may be a separate issue the the Emby app doesn't actually display unique names for the tracks. Happy2Play above has shown an option that I didn't know about, I'll play around with that to see if that helps with at least identifying what track it is that the user is selecting.

[Luke 37065]

You may not like the consequences of that option so please make sure to pay attention to that.