Removal of the Mixed Library Type

[JPVenson]

Proposal to first retire and then remove the Mixed library type.

This type of library is by many considered legacy code, it is very prone to both User error as well as metadata lookup issues. This comes from the issue that the detection of what is series and what is film is very poorly implemented. The type is used by a very small set of users but most do eventually join on matrix and request support for it, which most experienced chat members will turn down as "Not supported". Currently and for quite some time, nobody wanted/wants to touch this feature, while it brings a lot of issues.

My proposal would be to retire that feature in steps.

1. Removal of new mixed libraries.
   This does ensure ongoing support for it while we retire this feature. A documented command line flag or environment might be added to reenable it. This could be done with the next minor version update.
2. Retirement of mixed libraries.
   Sees the removal of support for new mixed libraries. The cmd flag as well as the env. variable will be removed and an optional warning in the WebUI will overlay a warning over existing mixed libraries warning of the pending obsolescence of the type. This could be done with the next minor version update.
3. Removal of mixed libraries.
   Complete removal of the mixed library type, with only a shim using the type to ensure breaking existing systems on a code-level. While the type will still exist in code, the warning in the WebUI will be altered to a notification that the type is no longer supported and content must be sorted into Movie and Series type libraries.

[ferferga]

I agree that mixed libraries are a pain to work with, and that most people use them when they shouldn't, but there are legitimate use cases:

• Some TV Shows have episodes or specials that providers match as Movies.

• Some Documentaries are considered as Movies and some are considered TV Shows (The pain I need to deal with, yes)

It doesn't make any sense, for me and anybody, to have multiple Documentaries folders because provider's shenanigans.

In general, although it's not our fault (and Plex and all media servers I saw work this way), I think we're doing libraries bad. The whole concept of forcing users to do libraries is ridiculous for some people (like me): What if I don't want to separate my Movies? I'm forced to create a library for the "Movie" type with a name "Movies" (because why reinvent the wheel, right?)

This is why I want to experiment in Vue to remove the concept of libraries when users only have 1 library for an specific item type.

The future EFCore model in server it's already designed (or requires minor changes for this) the last time I've been thinking about this schema proposition. Key aspects:

• We point the server to folders we want to have into Jellyfin. Configurable properties for each folder:

  • (Boolean) Recursive scanning
  • (List) Media types to scan inside that folder. This would allow to speed up scans in mixed scenarios, given the folder knows in advance what to expect

• Providers are configured for each media type (in a completely different section under admin dashboard).

• Unrecognized movies and TV Shows for a folder are delisted to users. They will be viewable under admin dashboard, so admin has the chance to match that file manually using all providers.

  • For example, if a folder is only enabled for "Movies", but the admin does a manual "Identify" that matches it with a TV Show provider, "TV Show" media type will be enabled for that folder.
  • This makes identification issues more noticeable too!

• A folder can't have an specific media type disabled for it if it contains at least 1 item that it's matched with a provider. Keep reading to see more below.

• If the item doesn't want to be identified by the user with a provider, it becomes a "HomeVideo", which will be our generic video entity.

• Books, Photos and Music shouldn't be forced to be matched with any provider, since they're in formats that can provide enough metadata on their own (ID3 tags, for example). That's why they won't have a "Generic" sibling, since they're not as problematic as our big players (Shows and Movies)

With this, we already have quite a lot of advantages:

• UI/UX wise, we know better what to expect for every entity, so we can design interfaces better (i.e for movies we better know how to design the layout to better showcase the poster, cast, critics... For home video, we know it will probably better to show the credit card-shaped card design with a thumbnail or allow swipe between them (like a phone's gallery, user configurable of course).

There is still a thing to discuss:

• How much we want to be strict about the match with a provider thing? I think we can force movies to always be matched with a provider (if not, be Generic Video), while we can relax TV Shows to not be linked with a provider but have a clear Season/Episode structure parsed by the file scanner.

• To disable a media type for a folder that has at least 1 item of that media type, the admin could:

  • Reidentify it with a provider for other enabled media type for that folder.
  • Convert it to "HomeVideo"
    How that would work UI/UX wise should be studied.

We can rework the current "VirtualFolder" to be more like a "Tag":

• That will give better ACLs for users and Parental Control. We could make configurable restrictions for:

  • A user can/can't see a tagged item
  • Schedule restrictions

• A "Tag" could be created as a "manual tag" (manually managed by user) or "dynamic":

  • Based on certain fields or filters, like Parent Rating.
  • Based on the filesystem structure (for instance, the content of multiple folders can be under a tag)
  • ...probably other things I can't think about?

• Tags would be the direct migration of the current libraries.

• The only place UI/UX wise where items would be mixed and we will have to deal with will be the "Explore by tag" section. In either case, it would be more easier than nowadays: **No filtering would be needed, since the "dynamic" tag system is essentially the same functionality.

• We provide endless control to admin over which content to present and how to categorise it.

This is more less it. I probably missed some edge cases for the sake of not making a (even) bigger message, but I probably have it already covered since its a long time I've been thinking about this :). I also have more fine-grained feedback on how this can be implemented scanning-wise, but let's see what people thinks about this first!.

All in all, I hope eventually Vue provides the best playground to test people's reaction to this.

[ferferga]

lol, forgot the most important thing. The deadline I propose for this:

• Implement media-centric browsing in Vue, so we can do "live testing". Some stuff, like "Tags" would be more difficult to implement for obvious reasons.
• Server/API changes 🎉.

[JPVenson]

I tend to agree with you here.
From the administrative side, i still get the idea to seperate stuff into different libraries and from an organizational point that is something i prefer. It also makes my other workflows easier. But on the display side of things an aggregation would be better.

The desire to remove mixed libs primarily comes from the support team, as no one really wants to touch the base of that functionality and nobody can really say how it works or wants to. Also no dev seems to care about that feature so to remove it gradually would only end its demise as an feature that sometimes works and nobody from the team wants to support it.

[makuc]

This seems the most all-encompasing solution I've seen anywhere to-date. Awesome.

[barronpm]

I'm in favor of this, because not only do different media types use different providers, they are queried and displayed differently too.

For instance, here's a (simplified) query I wrote a while ago to gauge the performance we can expect from the new schema:

_dbContext.SeriesMetadata
    .AsNoTracking()
    .Where(metadata => metadata.LibraryId == 4 && metadata.Language == "eng")
    .Include(md => md.Artwork.Where(art => art.Kind == ArtKind.Poster))
    .Include(md => md.Series)
    .Select(md => new
    {
        Metadata = md,
        UnwatchedCount = _dbContext.Episodes.Count(ep => ep.SeriesId == md.Series.Id)
            - _dbContext.UserEpisodeData.Count(ued => ued.SeriesId == md.Series.Id && ued.UserId == Guid.Empty && ued.IsWatched)
    })
    .OrderBy(results => results.Metadata.SortTitle)
    .ToList();

This query returns a user's view for a tv library. It returns everything needed for a library page in a single query, with no in-memory processing by the server. This is basically impossible if we don't know what type of media to expect in a library, since we have different logic per type (TV has UnwatchedCount, movies have a IsWatched, while other types don't include any watch information on library views).

@ferferga raised the point that things like Documentaries could be either tv shows or movies, but I think that collections should be used for such groupings, and more generally, we should use different library types for semantic differences in media, while collections can be used to make logical groupings across libraries.

One place I can see that might need consideration is something like TV Shows with related movies. Often, providers will include those in the specials, but they're still mostly treated as any other episode in the UI, which isn't ideal, but mostly unrelated.

[srcrist]

I don't have quite as much to say on this issue as some of the others, but I would like to add a +1 to being in favor of a gradual phase out for the Mixed library type. The fact is that they are almost impossible to support, and they should, at the very least, not be provided to users as an equivalent option alongside more traditional libraries.

From a support perspective, the most common advice about Mixed libraries is simply not to use them because they do not function as the overwhelming majority of users expect them to function. Jellyfin's integrated metadata retrieval simply does not retrieve metadata reliably for matching media in this structure, and the use of an external metadata tool like TinyMediaManager and NFO based metadata is practically a requirement to keep this library type functional.

I think there is definitely room to explore more customizable library structures moving forward, but this particular implementation, as it presently exists, is barely functional for most users who try to use it.

[felix920506]

I do think there is a valid use case for mixed libraries, and therefore disagree with their complete removal.

I would propose the following instead:

1. Deprecate the library type in its current form. Disallow the type to be created but still let existing libraries work. Also make it clear that the current implementation is deprecated and we will not fix issues with it
2. Promised an improved version of the mixed type library. How this is to be done in a technical sense is up for debate. What I would propose would be to have 2 libraries in the backend, one of each type, then combined on the front ens (either server side or in the clients) that would display the contents of these libraries as though they were a single library. This is only my opinion and someone else might come up with a better implementation
3. Once the new implementation has rolled out, give users the time of one major release to migrate.
4. Fully remove the mixed libraries code in the next major release

[makuc]

And I would propose to simply remove the scraper and leave only NFO parser. You get rid of the imporper use of Mixed Library and the headache you are getting due to maintenance. But it will remain for those of us who properly manage it via NFO files, until you give the alternative to users.

[jpSimkins]

I agree with @felix920506

I just started using Jellyfin (long time Kodi/xbmc user) and this has been a major point of frustration. I can see the issues with it and
really would like a better system then what is provided. Seeing as it was stated it's legacy, this would explain a lot.

I think the reason it is used by a few small set is that it is a busted system. I think it makes sense to remove it but it should be replaced with something better, not just taken away.

As a new user with a decent sized library, there are many reasons to want/need a shows/movies selection. I hope there would be plans to implement a better solution to allow this in the future. Honestly, this is such an issue for me that I may just go back to Kodi as it is way too painful in it's current state with how much content I have that falls into this legacy library.

It shouldn't be expected that the user needs to redo their library and splitting apart series or documentaries that fall into this category. I would even argue that not having movie support for a TV Series is a very limiting factor to this. Battlestar Galatica is a perfect example. The user wants to see everything for the show in a single screen. Having to hop around to find it isn't just inconvenient, it's annoying to the user. Series are very similar to collections in that aspect, just they also have a Seasons section.

To continue with BSG as an example, Razor is a TV Movie. I would want to keep all the data in a single folder. I keep this inside my Series directory as this is what BSG is. I'm not against moving some stuff in the BSG folder around (like naming a folder movies or whatever) but it makes no sense to move it to another share location like Movies, it doesn't belong there.

I haven't had the chance to look into plugin development for Jellyfin yet but if this can be solved by a plugin, I can take a stab at it.

[garpernaut]

Prefacing my comment to say I have no idea how any of this works, so if my suggestion is idiotic please feel free to say so.

But we already have a feature to manually insert TV Specials into the season structure by going into metadata and clicking Before/After X season or X episode]. Would it be possible to give a similar feature to films, so that as above BSG Razor can simply be inserted manually between seasons in its correct story location? Or also, let me be even crazier here, add a HIDE from library in the metadata check boxes, so that users can add a film into a series, and then hide it from the Films library.

I found myself here because I was looking for a similar solution as above for the Bobs Burgers movie (which takes place somewhere between seasons 12-13), Star Trek films appended, as a continuation, onto the end of the ST TNG series, or various anime that have feature films nested between season arcs.

I appreciate that I'm asking for a fairly ungraceful manual process which people with gargantuan libraries might recoil at. But it's just the solution that jumped into my uneducated head.