Emby suggestions

[jsc1205 47]

Would like to suggest the following updates/features for Emby:

1. Regarding collections on the Shield TV, to scroll through the various movies within a collection, the scrolling goes horizontally which cause the movies to scroll off the screen.  This not laid out this way if using Emby on an android phone.  The movies maintain the grid view and scrolling is done vertically.  Suggest that scrolling for collections is consistent and in the grid view going vertically.  Apply same with apple users.

2. Has been mentioned numerous times before but suggest giving users ability to manually edit info regarding audio format.  If Emby is not able to accurately detect and label movies with audio such as DTS X, Dolby Atmos, etc, enable a feature under the metadata settings to allow user to select correct audio codec.  

Thanks and keep up the great work!

[GrimReaper 3330]

5 minutes ago, jsc1205 said:

1. Regarding collections on the Shield TV, to scroll through the various movies within a collection, the scrolling goes horizontally which cause the movies to scroll off the screen.  This not laid out this way if using Emby on an android phone.  The movies maintain the grid view and scrolling is done vertically.  Suggest that scrolling for collections is consistent and in the grid view going vertically.  Apply same with apple users.

Select "All Items" in Collection view on your Shield AndroidTV app, that'll give you vertical view. 

[jsc1205 47]

9 hours ago, GrimReaper said:

Select "All Items" in Collection view on your Shield AndroidTV app, that'll give you vertical view. 

Thanks for the info.  What I was actually referring to when going to a collection within Emby on the Shield TV, you can see the movies if you go down using your remote.  Why not just add the vertical view there?  The movies within the collection are already down there but in a horizontal view.....  Just switch it to a vertical view without having to push the "All Items" button.  

[GrimReaper 3330]

9 hours ago, jsc1205 said:

Thanks for the info.  What I was actually referring to when going to a collection within Emby on the Shield TV, you can see the movies if you go down using your remote.  Why not just add the vertical view there?  The movies within the collection are already down there but in a horizontal view.....  Just switch it to a vertical view without having to push the "All Items" button.  

Likely because you can have different categories inside single collection (Movies, TV Shows, Videos...). AndroidTV app nicely shows them in sections, otherwise you'd have to scroll through all items to get to, for example, TV Show starting with Z, even if it was the only show in your Collection, whereas Web App just throws them all together, which kinda makes them mish-mash and tbh less-useful. Sorting by Release date makes it even harder to sift through. Besides that presenting larger number of items oncreen and scrolling on mouse wheel makes it more convenient to reach desired content in Web App. I still prefer how AndroidTV app does it: sectioned, and vertical view on demand, which is two-three clicks away. 

Edited October 4, 2021 by GrimReaper
Typo

[GrimReaper 3330]

19 hours ago, jsc1205 said:

2. Has been mentioned numerous times before but suggest giving users ability to manually edit info regarding audio format.  If Emby is not able to accurately detect and label movies with audio such as DTS X, Dolby Atmos, etc, enable a feature under the metadata settings to allow user to select correct audio codec.

Existing git ticket for same:

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

@softworkz, are there maybe any updates on ffmpeg/ffprobe regarding above? 

 

[softworkz 3349]

8 hours ago, GrimReaper said:

On 10/3/2021 at 3:46 PM, jsc1205 said:

2. Has been mentioned numerous times before but suggest giving users ability to manually edit info regarding audio format.  If Emby is not able to accurately detect and label movies with audio such as DTS X, Dolby Atmos, etc, enable a feature under the metadata settings to allow user to select correct audio codec.

Existing git ticket for same:

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

I think that over there, I have explained quite well why this doesn't work out. We can't mix functional and display-related information. The media info fields that you can see for media items in Emby Server - e.g. Audio Codec - are serving a functional purpose and we're displaying them just for reference and troubleshooting.
The lists of possible values that we use internally - like for codecs - are identical to those from ffmpeg, which is in turn the same that ffprobe knows, and that's in turn the same list that we are using in Emby Server everywhere - also for negotiating formats with clients. Allowing to enter custom values in those fields would cause a bunch of errors and wouldn't provide the slightest benefit.

Anybody who thinks that he would know better: go ahead, edit the database directly and see what you'll get!
(but please don't come and post issues about it then)

8 hours ago, GrimReaper said:

@softworkz, are there maybe any updates on ffmpeg/ffprobe regarding above? 

Dolby Standards are a pest. Especially their latest ones, "Dolby Vision" and "Dolby Atmos". Those standards are ridiculously and unnecessarily complex and wide-spread, that we'll have to accommodate with the situation that in the near future the questions about whether these would be supported by Emby, ffmpeg (and others that do not buy and use Dolby's own implementation), will not have answers of the  "yes/no" kind.
=> it will be about 'partial support' instead: which of the many variations, flavors and feature-sets from their spec will work and which won't.

It's an unfortunate and sad situation, and progress will be at small steps only - at best.

Edited October 4, 2021 by softworkz

[jsc1205 47]

@softworkz Appreciate your insight and info on this, appreciate it. 

[rbjtech 4324]

7 hours ago, softworkz said:

Anybody who thinks that he would know better: go ahead, edit the database directly and see what you'll get!
(but please don't come and post issues about it then)

lol - been there, done that - it didn't end well .. 

[softworkz 3349]

The fact that these appear as string values in the database is more due to historical reasons. When re-done today, you'd rather see numbers only representing enum constants.
Currently, the strings are converted to constants internally, which means that when you enter a string to your own liking, it cannot be converted as it's - well, unknown.
 

[rbjtech 4324]

12 hours ago, softworkz said:

The fact that these appear as string values in the database is more due to historical reasons. When re-done today, you'd rather see numbers only representing enum constants.
Currently, the strings are converted to constants internally, which means that when you enter a string to your own liking, it cannot be converted as it's - well, unknown.
 

Ah that explains it - thanks.  From memory I did see 'unused' values in the dB that could possibly be used, but of course these are not displayed anyway, so of little use for this purpose.

[softworkz 3349]

Normalization, abstraction and modularization are important measures for higher code quality and reliable results. If you have ever looked at the earlier public code for building transcoding commands (as it might still be used by other projects that had copied it) - we don't have any of that script-style code anymore where command lines are built by concatenating strings. It's done now in an object-oriented way where you'll hardly see any string literal at all. We even have an object model that is precisely reflecting ffmpeg commands, consisting of hundreds of classes for encoders, decoders, de/muxers, protocols and filters with thousands of typed properties and enums, which ensures that command lines are always correct. 

There's more, but what I wanted to point out is: these things have massively evolved here at Emby and it's a totally different story like you might see in other projects