Support custom resolvers

[nielsvanvelzen]

Currently all library types (tv shows, movies, music etc.) have their own "resolver" to import media. They all have a certain folder structure the user should follow, and when the users does just that nothing will go wrong (mostly).

But what if the user is stubborn and has his own folder structure and doesn't want to change that?

I made some custom resolvers for myself and they work excellent, I can not import my custom structure to Jellyfin with almost no problems. But the way I did this is not officially supported and does cause some problems because the Jellyfin resolvers still work.

What I did

I made multiple resolvers but for this issue I'll use the simplest I made

I made a class MusicResolver in my own plugin that implements the IItemResolver and IMultiItemResolver interfaces. It sets the ResolverPriority to First so it will get called before most default resolvers. The ResolveMultiple function always returns null so it isn't actually implemented. The ResolvePath function checks if the CollectionType is non-null and if it equals the Music type.

Next it just does some basic stuff checking what kind of file it is resolving and returns a class extending BaseItem.

This works great! Except for the fact that files my resolver ignores will be imported by the next resolver found.

What I'd like to see changed

As Jellyfin already supports this functionality quite well I'd like to extend it with some customization. Firstly; I'd like to change the resolver(s) used from the user interface. My suggestion would be to have this work the same as metadata downloaders: The user can choose per library which resolver to use. I'd suggest to only support one per library instead of multiple.

Possible implementation

This can be implemented in 2 ways:

1. Merge existing resolvers (the "official" one for audio is 3 separate resolvers working together: AudioResolver, MusicAlbumResolver and MusicArtistResolver, see https://github.com/jellyfin/jellyfin/tree/f1fc6ef59f669abcae33b3a6db627683364eb8ff/Emby.Server.Implementations/Library/Resolvers/Audio)
2. Add a new class (lets call it "scanner for now) which contains a list/function to clarify which resolvers to use

Additional properties should be added to the resolver/scanner for identification. Just like providers a Name should be added. Additionally in some way we should define for which library types the scanner/resolver works. Providers do this using a generic.

Jellyfin should have a way to determine which scanner/resolver is the "official" default and use that. When multiple scanners/resolvers are found for a certain library type the user can change the one used in the library settings. (option is hidden by default, or a disabled input or something like that)

Use-cases

• Custom scanners for non-standard library structures
• Provide multiple structures for users (for example; the music library supports a flat-structure and a album based structure by guessing. If we separate this to multiple scanners/resolvers the user can choose their variant in the library settings)
• Improve library-scan speed because we don't have to use ALL resolvers for each library, only the one selected by the user.

TL;DR: Improve support for customized resolvers in plugins.

[JustAMan]

cc @Bond-009 and @cvium for feedback

[Bond-009]

Sounds good to me 👍
Current solution is a mess

[dkanada]

I think I prefer the second method to the first. We could just add a new plugin category for resolvers and you could have the first entry. Then you just need to implement a page somewhere to select active resolvers.

[nielsvanvelzen]

Example for a custom resolver plugin: https://github.com/nielsvanvelzen/jellyfin-plugin-resolver

I need to to some more work before I can call it stable. This PR is the one thing that is needed from the Jellyfin side to finish it.

[dkanada]

This PR is the one thing that is needed from the Jellyfin side to finish it.

You mean the configuration option listed above?

[nielsvanvelzen]

I meant "issue" instead of "PR"... it was late. Without proper support a custom resolver needs to use some hacks to get it working at the moment.

[GlassedSilver]

This is most certainly needed for anime for example.
Especially useful for stuff like extras per season, grouping the second season of an anime into one overarching show folder when the second season has a different show name (VERY common in anime and pretty annoying, but that's how it is)

[GlassedSilver]

I still don't understand why this is a discussion now.

Look, activity on this topic has dwindled and this is just how the issue is gonna slowly fade whilst the tracked issue ticket collects dust... :/

Or maybe I'm missing some recent developments on this front happening elsewhere?

[GlassedSilver]

By display I mean show the season name in the UI whilst browsing around. Not sure what you mean by display during fetching.

This is a Jellyfin issue, because all I ever see is "Season 1" "Season 2" etc under the same show name.

That's the issue. Also would be cool to get extras per season still, that as well is patently a Jellyfin UI issue to my understanding.

There just is no expectation by Jellyfin to look for a a Specials folder inside of season folders. My metadata game, even if fixed by hand with sidecar metadata files cannot fix that.

[jrb0001]

You can rename those seasons through the UI afaik?

[GlassedSilver]

You can rename those seasons through the UI afaik?

The problem is, if you wanna use the anidb plugin, the metadata lookup happens for what the Show folder is.

If a second season is listed as separate entry on anidb, to my knowledge it will not work like this.

e.g., to put it more clearly: the day I can fetch metadata for the Simpsons season 5 as its season folder is located in another show's root folder is the day I can properly fetch metadata reliably. Then make season subfolders for specials, which isn't here yet and on top of that maybe automate the displaying of a season name over "Season n" if applicable.

As for manual renaming, yes it's a thing as I just discovered thanks due to your tip. However manually renaming every season I have sounds like... pain. :D

[jrb0001]

However manually renaming every season I have sounds like... pain. :D

Well, I tried to fix the anidb plugin and the result was even more pain. You had to manually override the ID on all additional seasons. And for all non-standard episodes also on the episodes (extra special cases needed two IDs per episode). And in most cases you also had to move files around to match the very narrow requirements for specials inside seasons (which deleted all metadata you entered so far, huge pain if you notice it too late).

I did write my own plugin to make this all much more efficient and make all my corner cases work properly (which would be impossible with a fixed anidb plugin). That was like a month ago, but for some reason I still stick to my webdav share.

To be honest, I don't think this is just Jellyfin's fault. What it does at the moment works really well for movies and normal series (at least with my collection). Anime is just different (and has way too many weird special cases). Even if we did have a dedicated anime category in Jellyfin, I am not sure how useful that would really be. I really don't like the idea of having a "specials folder per season" with over 70 entries. I can't see a good automatic solution to that because all metadata sources have a flat structure and it probably also depends a lot on personal preference.

By the way you can already get most of the benefits of this "specials folder per season" by simply configuring them as "special after season" and using the sorting title (without creating that useless "specials season", if you do everything correctly). There is no clear separation between the normal episodes and those specials, but other than that it is basically the same.

[GlassedSilver]

All I wanna do is put a season folder, put the anidb ID in brackets for the season of its respective show ID on anidb and within that a specials folder.

Should be plenty enough to cover almost anything, the rest could still be manual overrides. As it is now, anything that has more than one season becomes weird as hell.

That clear separation would be nice, because not all specials I store are episodes like spin-off shorts. Some of it is openings and endings, which usuallly are different per season.

Or other stuff like promotional videos.

[BOLL7708]

I'm right now filling my JellyFin server with music from Steam. Soundtracks does not quite follow the traditional music structure, and for some games the meta data is garbage, and I don't really have the energy to go through many hundreds of soundtracks to fix things up.

A custom resolver as mentioned here would be able to solve my problem. I need one that simply put everything after a certain folder depth or for folders with cover art in an album, and that's it. Now I instead get some soundtracks that split up into multiple albums due to meta data inconsistencies. I need folder superiority!

[GlassedSilver]

This is why sometimes a staged import process, a manual one, trumps anything (semi-)automated.

Sometimes things don't go according to a given plan, what are your options then?

A custom resolver would help with ingress, but then there's the issue of your library at least having to live in two different phyiscal path locations, because one folder scans according to a specialized custom resolver and another one may work better with the usual approach. A per-media resolver override could be helpful if you ask me.

[rklrkl]

One big reason I use Grip for ripping my CDs is that it has a printf-style custom string you can give for the directory structure and filename format. I just ran Jellyfin on my dir/file structure of TV shows (which I'm never going to rename because a media server should never impose its own dir/file naming format) and it was a disaster with many shows wrongly allocated. This is a massive dealbreaker for me and I suspect many other people - DLNA works fine in my case, Jellyfin flops hard. My format is (underscores or full stops used instead of spaces between words):

First capital letter of first word of show title (skipping "A" or "The")/Show_Title_Season_#/Show.Title.S##E##.Container

The format above has that alphabetic top level structure because having hundreds of shows like I do forced me to add it to avoid a massive scroll when using DLNA clients (which tend to only list things in alphabetical order). Having a documented set of printf-style % directives is the only way you can cater for any naming scheme. In my case, the format string might look like %T/%ut_Season_%s/%pt.S%02s.E%02e.%c but we'd need separately configurable strings for movies vs. music vs. shows (and the ability to have multiple prioritised strings that are scanned in order until a match is found). Until something flexible like this is implemented, Jellyfin is sadly a no-go for me.

[BenMcLean]

What is needed to move forward on this?

[nielsvanvelzen]

There is no good way to create your own resolver without hacks. The plugin I made still works (and I still use it) but for the default resolvers for the server also run, which sometimes creates conflicts. I also need to hardcode the paths that my resolver works with because there is no option to enable it for specific libraries.
Without official server support this method can also break on any server release.

[BenMcLean]

So how do we get official support for this?
I'd assume you'd need to clean up what you've got and then submit a PR?

[nielsvanvelzen]

I don't have a server implementation, just a plugin with hacks. If you want to get official support for resolvers you'll have to convince someone (or yourself) to add the support. Personally I'd love to have the feature but don't have the time to work on it.

[BenMcLean]

OK, do you know who the active maintainers of Jellyfin are? The people who'd need to accept a PR of this if I were to make it?
I wouldn't want to invest a bunch of time to build it only to find that it will never reach users because the Jellyfin team or dev or whoever doesn't want this.

[cvium]

We are not opposed to the idea of custom resolvers, but we want a clean solution and the current resolvers are a bit hacky already. Feel free to create a Discussion outlining your intent and design

[Aeyk]

I took a stab at this, if anyone is interested in testing it out, I hardly have done any.

#13615

[breusshe]

I agree with @rklrkl under post https://github.com/orgs/jellyfin/discussions/5732#discussioncomment-3727578. A media server should not impose a folder format. It should be able to work with whatever folder format the user already has. A way to do this is to not use the folder names to glean off media information. Instead, go straight to each file's metadata. Then, in the media server database, save the actual full path to the media file. The metadata can supply all other aspects of the media identifying information. If the metadata is dirty, then the user should push their media library though something like Picard to do the standardizing.

[BenMcLean]

You are absolutely right and not only is this the case for videos but it is for music and arbitrary files and any other resource we'd want the app to serve as well. I would prefer something more in the spirit of copyparty which just happens to have Jellyfin's video playback features grafted on to it instead of the current fundamental design of Jellyfin as a Netflix alternative, imitating the Netflix mindset of what a streaming site/app should be. (design assumptions inherited from Emby and shaped by the kind of metadata and artwork that's available concerning movies and TV shows in free online databases)

If that more generic "just your files, in your folder hierarchy, named however you want or however you already have them, just with our video player" app existed, then I would have installed and started using that instead of Jellyfin years ago. It would also be great if the playback related tech was cleanly separated from the web site that organizes the videos so that anyone who wanted could adopt the video playback tech to whatever kind of custom site they wanted more eassily.

But that alternative vision of how to approach this category of application doesn't exist and making that would be a Herculean multi-disciplinary task far beyond the kind of time I have in my life to invest in hobbyist programming. I believe in not letting the perfect become the enemy of the good, so I just let the imperfect Jellyfin be the app I use for this because it's the closest thing that actually exists, much as I passionately hate significant aspects of its design philosophy. (with no resentment towards the maintainers who I know are putting in lots of work to make the features I use even possible at all)