Plugin: EmbyIcons release.

[ISeeTWizard 29]

I see parental ratings is really crazy 

When I see what I already have to enter just for my small library 

[yocker 1247]

It's back baby!
Well.. Not really, as i still need to add the code for it but.. The setting is back!! 

[yocker 1247]

The new version is up.

Added:

Support for videos in "Home Videos and Photos" type libraries.
Clear icon cache button for when icons have changed in the icons folder - It should now work correctly, last time it didn't work when changing to a different image format, for example from jpg to png.

Changed:

Made the settings page preview dynamic and random, giving a better representation of the icons.

Download here or at Github - EmbyIcons

Edit:
Forgot to say, the whole code is available on the Github.
Do with it what you want, even make it your own, just please keep it open source!

EmbyIcons.zip

Edited July 17, 2025 by yocker

[IAmHugh 63]

5 hours ago, yocker said:

Edit:
Forgot to say, the whole code is available on the Github.
Do with it what you want, even make it your own, just please keep it open source!

Maybe someone can fix it so it works properly with Arch and Arch based distros. Thanks

[yocker 1247]

9 minutes ago, CummingCowGirl said:

Maybe someone can fix it so it works properly with Arch and Arch based distros. Thanks

Do you have the same problems with other plugins like Cover art?

[yocker 1247]

@CummingCowGirl
?
 

[IAmHugh 63]

22 hours ago, yocker said:

Do you have the same problems with other plugins like Cover art?

Yea I just installed Cover Art and I get nothing. In my case the defaults would seem to be what I want, but nothing after a server restart. Must be the fact that I don't care about formats as long as I get the quality I want in the size I want. I do not include any format info in my file names.

[yocker 1247]

1 hour ago, CummingCowGirl said:

Yea I just installed Cover Art and I get nothing. In my case the defaults would seem to be what I want, but nothing after a server restart. Must be the fact that I don't care about formats as long as I get the quality I want in the size I want. I do not include any format info in my file names.

No special file names are needed for either plugin except for the icons ofc.

I strongly believe it's a sandboxing and/or permission problem in Arch. Arch is known for being very, very strict with security!
Try and ask the Emby developers if they know how to fix it.

You can upload an Emby log with debugging enabled and i will look through it to see if i can find out precisely what's wrong, i can't promise anything though.
Other than that i don't think i can help much, sorry.

[yocker 1247]

I want you guys opinion on something.

I'm thinking of changing the detection in the plugin to be much more dynamic.
As it is right now all video and audio formats, channel count and so on are hardcoded into the plugin. I'm thinking of changing it to dynamic so new formats and even custom ones are automatically supported..
This makes it so if a new audio codec gets released called for example EAC4 then audiocodec_eac4.png will automatically just work in the future as long as Emby reports it.
This will work this way for everything, codecs, channel numbers and so on.. It will also make sure that all codecs just works and doesn't need to be added by me in the future.

Audio and subtitle languages would also just work without me having to add all languages.
They will have to be renamed to using actually audio languages like subtitle_english.png instead of the sometimes confusing 3 letter codes.

HDR, HDR10+ and Dolby Vision might be hard to implement into this because of how Emby works and most likely have to use the old method.
Unless someone knowns of a way to do it that i have overlooked.

It will all also require people to rename all their icons, hence why i ask for your opinions as this might be annoying to do.
Naming examples:
videocodec_h264.png
audiocodec_eac3.png
language_english.png
subtitle_english.png
channels_5.1.png
tag_name.png


Users can pretty much just look at what Emby reports and add icons for it them self.
It also opens op for easier integration of things in the future like aspect ratio.

What do you guys think?
Something you guys would like or would it be an absolute pain to rename the icons?

[keitaro26 22]

1 minute ago, yocker said:

I want you guys opinion on something.

I'm thinking of changing the detection in the plugin to be much more dynamic.
As it is right now all video and audio formats, channel count and so on are hardcoded into the plugin. I'm thinking of changing it to dynamic so new formats and even custom ones are automatically supported..
This makes it so if a new audio codec gets released called for example EAC4 then audiocodec_eac4.png will automatically just work in the future as long as Emby reports it.
This will work this way for everything, codecs, channel numbers and so on.. It will also make sure that all codecs just works and doesn't need to be added by me in the future.

Audio and subtitle languages would also just work without me having to add all languages.
They will have to be renamed to using actually audio languages like subtitle_english.png instead of the sometimes confusing 3 letter codes.

HDR, HDR10+ and Dolby Vision might be hard to implement into this because of how Emby works and most likely have to use the old method.
Unless someone knowns of a way to do it that i have overlooked.

It will all also require people to rename all their icons, hence why i ask for your opinions as this might be annoying to do.
Naming examples:
videocodec_h264.png
audiocodec_eac3.png
language_english.png
subtitle_english.png
channels_5.1.png
tag_name.png


Users can pretty much just look at what Emby reports and add icons for it them self.
It also opens op for easier integration of things in the future like aspect ratio.

What do you guys think?
Something you guys would like or would it be an absolute pain to rename the icons?

I think dynamic is much better in the long run. Eventually you will want to move on from this plugin running your life (hopefully not too soon!) and the more dynamic it is the more likely it is to survive.

That said, I think the naming should be abbreviated where possible. For example:
vc_h264.png
ac_eac3.png
lang_english.png
sub_english.png
ch_5.1.png
tag_name.png

 

For the HDR and such, can you not key off of some of the info Emby reports? 

[yocker 1247]

14 minutes ago, keitaro26 said:

I think dynamic is much better in the long run. Eventually you will want to move on from this plugin running your life (hopefully not too soon!) and the more dynamic it is the more likely it is to survive.

That said, I think the naming should be abbreviated where possible. For example:
vc_h264.png
ac_eac3.png
lang_english.png
sub_english.png
ch_5.1.png
tag_name.png

 

For the HDR and such, can you not key off of some of the info Emby reports? 

Haha you are right though i'm thinking of doing this mostly for user customization reasons.

Good point and i like the abbreviation and think i will use that but the other naming scheme might be easier for some to understand though.

Yeah i could use that but it will loose out of HDR10+ detection as Emby doesn't really report on that as it (in my opinion) should.


This is from a HDR10+ movie so the plugin has to use filename detection for it to work.
Guess i can just do like now and just have it still look for HDR10+ in filename while still having the other detection.
 

[keitaro26 22]

18 minutes ago, yocker said:

Haha you are right though i'm thinking of doing this mostly for user customization reasons.

Good point and i like the abbreviation and think i will use that but the other naming scheme might be easier for some to understand though.

Yeah i could use that but it will loose out of HDR10+ detection as Emby doesn't really report on that as it (in my opinion) should.


This is from a HDR10+ movie so the plugin has to use filename detection for it to work.
Guess i can just do like now and just have it still look for HDR10+ in filename while still having the other detection.
 

Not sure if it is relevant, but this says that it should be working on a version of 4.8 and the beta. I don't have any HDR10+ without DV, so I can't check my beta.

 

[keitaro26 22]

52 minutes ago, keitaro26 said:

I think dynamic is much better in the long run. Eventually you will want to move on from this plugin running your life (hopefully not too soon!) and the more dynamic it is the more likely it is to survive.

That said, I think the naming should be abbreviated where possible. For example:
vc_h264.png
ac_eac3.png
lang_english.png
sub_english.png
ch_5.1.png
tag_name.png

 

For the HDR and such, can you not key off of some of the info Emby reports? 

@yockerYou could maybe key off of the "Color Transfer" data when HDR is reported. From what I can find, HDR10+ should be smpte2094 while regular HDR is smpte2084. This would only work specifically for HDR though cause DV can have both those values too depending on the layers, so you'd need some logic in the code.

Edited July 19, 2025 by keitaro26

[yocker 1247]

2 minutes ago, keitaro26 said:

@yockerYou could maybe key off of the "Color Transfer" data when HDR is reported. From what I can find, HDR10+ should be smpte2094 while regular HDR is smpte2084. This would only work specifically for HDR though cause DV can have both those values too depending on the layers, so you'd need some logic in the code.

Maybe but in my head that would again require it to be hardcoded.
 

[keitaro26 22]

Just now, yocker said:

Maybe but in my head that would again require it to be hardcoded.
 

That's true, but since HDR/HDR10+/DV are established pretty firmly at this point, the logic is not likely to change for those, and this way you would not be relying on filenames, which may not be the same in all cases. (like me for example. I don't include the codec, etc. in my filenames)

[yocker 1247]

2 minutes ago, keitaro26 said:

That's true, but since HDR/HDR10+/DV are established pretty firmly at this point, the logic is not likely to change for those, and this way you would not be relying on filenames, which may not be the same in all cases. (like me for example. I don't include the codec, etc. in my filenames)

Yeah, hardcoding that and making others more dynamic should work, i will look into doing that.

[sh0rty 714]

7 hours ago, keitaro26 said:

For the HDR and such, can you not key off of some of the info Emby reports? 

For this to work properly, the plugin needs to take into consideration that there are naming differences when people use the MediaInfo plugin, e.g.

Emby Default

Mediainfo Plugin

 

Plus, HDR10+ detection just works when using MediaInfo plugin title data.

Edited July 19, 2025 by sh0rty

[yocker 1247]

3 hours ago, sh0rty said:

For this to work properly, the plugin needs to take into consideration that there are naming differences when people use the MediaInfo plugin, e.g.

Emby Default

Mediainfo Plugin

 

Plus, HDR10+ detection just works when using MediaInfo plugin title data.

The filename detection for HDR10+ isn't going any where as long as Emby doesn't support HDR10+ correctly.

 

[yocker 1247]

Okay so plan is:

1. Make everything dynamic except HDR detection.
2. Change the icon naming scheme to work with that.
3. While i'm at it, add support for aspect ration.



I understand having to rename the icons will be an inconvenience for you guys and i'm sorry.
At the very least i will make sure to give a good number of correctly named icons that can be used.

Edited July 19, 2025 by yocker

[yocker 1247]

Don't know why i never noticed this before but there are a lot of different aspect ratios, specially since videos tend to get different aspect ratios by different people when the videos get encoded.
So having them all covered by a dynamic system might end up having people need to use a lot of icons but it will work perfectly (and does, already have it working).

Maybe i should make it hardcoded range values for ease of use?
Downside is that some aspect ratios might be missed and for me having to add new ones as they are found.

[keitaro26 22]

12 hours ago, yocker said:

Don't know why i never noticed this before but there are a lot of different aspect ratios, specially since videos tend to get different aspect ratios by different people when the videos get encoded.
So having them all covered by a dynamic system might end up having people need to use a lot of icons but it will work perfectly (and does, already have it working).

Maybe i should make it hardcoded range values for ease of use?
Downside is that some aspect ratios might be missed and for me having to add new ones as they are found.

I think dynamic is still the way to go. People can always put multiple copies of the same icon named differently to "group" different aspect ratios. Or you could make it a toggle to group them in a hard-coded range or be completely dynamic, that way people have the choice and future compatibility isn't compromised.

[sh0rty 714]

I must confess I never understand why people want to know the AR of a movie except IMAX with changing AR. 

[yocker 1247]

11 hours ago, sh0rty said:

I must confess I never understand why people want to know the AR of a movie except IMAX with changing AR. 

Well.. You got it now.

[yocker 1247]

Here's a beta if you guys want to test.

Made detection dynamic except for HDR.
Added support for aspect ratio.
Added a button to enable or disable logging for the plugin as other wise it would make it hard to debug other stuff.

Please report back if you notice any problems.

EmbyIcons.dll Icons.zip

[keitaro26 22]

1 hour ago, yocker said:

Here's a beta if you guys want to test.

Made detection dynamic except for HDR.
Added support for aspect ratio.
Added a button to enable or disable logging for the plugin as other wise it would make it hard to debug other stuff.

Please report back if you notice any problems.

EmbyIcons.dll 2.18 MB · 0 downloads Icons.zip 660.58 kB · 0 downloads

All the dynamic is working for me, but I noticed that if there are too many icons in horizontal, they overlap. Not sure anything needs changing there as it is an easy to fix issue by rearranging the layouts, but wanted to point it out.

 

Edited July 22, 2025 by keitaro26