Reconsider supported media types

[Bond-009]

Currently Jellyfin has support for 9 different content types (not counting trailers, boxsets and playlists), with the majority being in pretty bad state usability wise. In my opinion we should reduce our feature set so effort can be focused on our core features (as we have done in the past, e.g. removing Game support) More specifically this would help the EF Core database migration as we would have less entities and abstractions around different media types to worry about. (https://github.com/jellyfin/jellyfin/issues/2518 for example)

Current content types: Core features:

• Movies
• TV Shows
• Music
• Live TV/DVR

Heavily related to core feaures:

• Music Videos

Remaining:

• Home Videos
• AudioBooks
• Photos
• Books/comics

I propose be remove some of the "remaining" content types, starting from the bottom as those share the least amount of code with other media types.

[joshuaboniface]

I believe all 4 are heavily used, simply by viewing the communities. I don't believe any should be removed. However their implementations could be simplified. However is this really the thing blocking EFCore library migrations? Implementing additional types should be a positive for the migration, not a negative.

[joshuaboniface]

I think te problem is that we're worrying about too many "subgategories" of a few key media types, and this is throwing off the idea.

There are 4 key media types:

Video Audio Still "Live"

TV, Movies, Home Videos, etc. are all video. Music, audiobooks, etc. are all audio. Books (including comics), pictures, etc. are all "still", IDK if that's a valid type but hopefully you get what I mean. Then there's "Live".

If the issue is we have too many abstract types, why do we not simplify into these 3 core types then build the others off of them? Basically 3 baseitems instead of 1. Would that help?

I stand by not wanting to remove types - our goal should be to add more as time goes on.

[mcarlton00]

I suspect part of it is that our subcategories don't make any damn sense currently.

Books and audiobooks are combined under the "Books" library. They don't share metadata, their playback and progress reporting methods are completely different, etc. But under the current implementation, they're basically treated as the same.

Photos and Home Video are combined under the "Photos" library. Again, really doesn't make sense, and isn't communicated particularly well.

Personally, I'm kinda of the opinion that books and comics are scope creep. I've always been under the impression that we were focusing on non-interactive media, which those two definitely don't fit under. Plus they're a bit of a gateway to those wanting us to implement zip and rar support. And it doesn't make any sense to implement support for them in the large majority of our clients. Nobody wants to read a book on their TV. If they stick around through the next iteration of the DB, I'd at least like to see them split off from the audiobooks library so things make more sense from an organizational point of view.

Photos are a weird inbetween if you take slideshows into account that I'm ambivalent towards.

Audiobooks imo should stay, as they're basically just music but with progress tracking.

Home videos seem mostly ok as a category, but dependent on having a proper file directory view instead of trying to have the parser trying to organize things.

[Shadowghost]

I agree with what @mcarlton00 said.

Comics and books would be a nice to have from the standpoint of Jellyfin being the central way to access media but apart from mobile clients I don't think they make much sense without e.g. OPDS for accessing books.

We should definitely split Photos and Home Videos and Books and Audiobooks into their own library types. Especially the latter would make it much easier to properly parse and present them correctly and from a technical pov them being one unit makes no sense as already elaborated in the comments above.

Photos do work in a usable extent as of now but a proper directory view would make them way easier to view. And I don't think we should parse any metadata for them anyway except the basic exif info and similar to properly rotate them when viewing. This view could also be used for the other library types (I'm not a fan of it but this feature is requested often enough to consider).

[thornbill]

I don't necessarily agree with your definition of interactive media @mcarlton00. Just because you pause, fast forward, skip to a chapter, etc. does not make video interactive. You are still just viewing the media and navigating through it. The same thing goes for books. Yes you do typically have to change pages manually, but you are still only viewing the media and navigating through it.

[joshuaboniface]

Yes, and I think it's a continuing flaw that we always fall back to "but we removed Games" and definitions of "interactivity" as justifications. Look, Games was a terribly thought-out, half-baked, half-implemented idea Emby had that never worked and we ditched it. Forget about definitions of media or interactivity. Everything else we support can be reasonably called "media" and I'm in favour of keeping them all.

But as I mentioned, if it makes the schema too complex, then we need to reconsider why it makes it so complex. Because the whole goal of EFCore is to have an extensible database that we can then add new features, media types, etc. to. Perhaps temporarily removing media types might ease migration, but we have to consider readding them in the future anyways, so we should do it right from the beginning.

We've also agreed that every client is not obligated to support every media type. That's fine. Kodi AndroidTV doesn't need book support, etc. But the core server should continue to support all of these with the ability to add more in the future (I can't think of any off the top of my head, but I'm sure there are). We need to make sure we can handle that optimally.

[Bond-009]

Look, Games was a terribly thought-out, half-baked, half-implemented idea Emby had that never worked and we ditched it.

The same could be said about home videos, audio books, photos and books.

For me it isn't about "is this media interactive", but how similar they are to implement, movies, series and music all have metadata that can be fetched, people that are associated with it, which we can also fetch metadata for. It can be manipulated with ffmpeg, to transcode for compatibility with clients.

Compare that with photos or books, they need different libraries to manipulate/parse, totally different things to keep track of (current page instead of watch seconds for example). It makes way more sense to have a totally different application to handle those, there just isn't enough in common.