[Cool enhancement] Avatar from jpegPhoto

[xyko0]

Hi guys,
Thanks for your great job, it works perfectly well on my installation.
I thought it would be really great if the 'jpegPhoto' attribute from an user account could be used as an avatar in jellyfin.
I don't know how complexe it is to integrate something like that but it would be awesome !
Have a good day.
Best regards.
Xyko0

[soupglasses]

@crobibero Would you be able to guesstimate the complexity/difficulty of implementing this feature? I have been thinking of taking a shot at implementing this myself, but I am unsure of how difficult it would be to connect up the pieces.

[crobibero]

Most of the work would be ensure you update the photo when it changes.

You could likely use the existing controller as a base and modify if needed
https://github.com/jellyfin/jellyfin/blob/release-10.8.z/Jellyfin.Api/Controllers/ImageController.cs#L106-L135

[soupglasses]

Thanks for pointing me in the right direction. I do not think i will get around to it soon, as I have yet to properly learn C#. But when i get around to doing that, this issue is one on my radar id like to help out with.

[AlphaJack]

What about adding an option for avar providers such as https://www.libravatar.org/?

for instance, if %(mail_hash)s is a placeholder of the md5 hash of the email attribute, avatars could be found at https://seccdn.libravatar.org/avatar/%(mail_hash)s

[timosturm]

Is there any update on this?

[SanseroGames]

I want this feature, so I'd be willing to spend time on this.

I had a look at the code and came up with an idea how to implement this. The easiest way would be to update the image every time, but given that there is already code that only updates the user if a change is needed, I assume for the profile picture it should behave the same.

So to check whether an update is needed I would hash the LDAP-attribute data and compare it against the hash of the current profile picture. LDAP (or at least LLDAP, which I'm using with Jellyfin) does not have a modification timestamp for a single attribute, or the user in general, which is why I would opt for something like a hash.

For the hash of the current profile picture I have three ideas:

1. Recalculate the hash every time. Would have to read the file directly from the filesystem
   • Pro: Simple implementation. Keeps filesystem the same as without the plugin
   • Con: Unnecessary overhead, hash could be cached, but I expect the overhead to be negligible, as profile pictures usually are not that large.
2. Store the hash in the filename of the image.
   • Pro: Hash is in the filename which is stored in the user object. No filesystem access needed to get the hash.
   • Con: Potential clean up problem and cluttering of the file system as each hash creates a distinct filename
3. Store hash in separate file

• Pro: New profile picture overwrite old ones, so no clean up necessary
• Con: extra file specifically to the plugin lying around. Need to read file every time.

Any thoughts on this? If the performance impact of hashing a file is not too big, I think I'd go with 1 as it is the simplest solution. If direct filesystem access from the plugin is a problem and there is already a built in cleanup mechanism, I think option 2 would be best.

Edit: 1 could also be done by just comparing the saved file with the LDAP-attribute byte-by-byte directly without hashing, which would be faster.

[crobibero]

Instead of updating the image on every login attempt, why not create a scheduled task that updates it daily by default and allows the admin to change the frequency

Still pull in the image on initial user create

To store the hash I would probably create a standalone file that contains a serialized list of userIds and image hashes

[SanseroGames]

Good point with the scheduled task, wasn't aware of them. This is actually better, as this also updates the profile image of users that stay logged in on their devices.

Regarding storing the hash, I could store it in the plugin configuration, as there is already a list of all known users. I iterate over this list anyway, so it would be convenient.
The downside of caching the hash is that we have no way of knowing whether a user changed their profile image in Jellyfin after it has been synchronized.

[crobibero]

The downside of caching the hash is that we have no way of knowing whether a user changed their profile image in Jellyfin after it has been synchronized.

I don't think it's necessary but we could hook into the user info updated event.

Putting a note on the config page to enable this new feature that it's a one-way sync