Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support extra (behind the scene...) #463

Open
zoriya opened this issue May 1, 2024 · 3 comments
Open

Support extra (behind the scene...) #463

zoriya opened this issue May 1, 2024 · 3 comments
Labels
api enhancement New feature or request front Change on the front-end side of the app scanner
Milestone

Comments

@zoriya
Copy link
Owner

zoriya commented May 1, 2024

Feature description

No response

@zoriya zoriya added enhancement New feature or request front Change on the front-end side of the app scanner api labels May 1, 2024
@zoriya zoriya added this to the Backlog milestone May 1, 2024
@zoriya zoriya modified the milestones: Backlog, v5.0.0, v5.1.0 Aug 8, 2024
@Arthi-chaud
Copy link
Collaborator

Specs for Extra support

Video Extras are bonus videos related to a resource (a movie or a show). Jellyfin and Plex support video extras. It's time for Kyoo to support them as well!

The first challenge with supporting video extras is that there is no standard way of identifying an extra. For example, Plex identifies any file ending with -behindthescenes|featurette|interview| (full list here) as an extra. Jellyfin works in a similar way: it uses the name of the parent folder (eg ./Extras) or looks for a keyword in the file name.

Even though Jellyfin is more flexible than Plex, these two service share a similar point of view regarding extras: no configuration is needed for parsing Extras. This align's with Kyoo's 0 configuration policy.

Extra Types

We should be able to classify extras by type. I think adding new types in the future should be a straight-forward task, so let's not worry about handling all of them straight away. We should be able to handle the following extra types:

  • Trailers
  • Interview
  • Behind the Scenes
  • Deleted Scenes
  • Bloopers
  • Other
    • It would serve as a fallback type when we cannot identify the nature of the extra.

In a second time, we should handle all extra types Jellyfin and Plex do.

Relationships

At least, extras should be related to movies or shows.

However, extras can be season specific. For example, we do not want to mix season one's bloopers with season 2. We should discuss whether implementing this from the start is reasonable.

As a bonus, Extras could be collection-specific, but I do not have an example of why it would be necessary.

It is not possible to have extras without having the related movie or show scanned beforehand.

File Architecture (& Configuration)

Let's say we have a movie or show A, we should consider all extra files in the same folder as A or in an Extra folder next to A to be extras of A.

(I do not know what we should expect for season-specific extras)

NOTE: One should be able to configure the name of the Extra folder. We could set an env var in the .env file, with a default value.

Scanning Process

When the scanner finds files to scan:

  • If the file is an extra, wait for the other files to be scanned
    • So that we do not try to link an extra to a movie that has not been parsed yet
  • Otherwise scan it
  • The scanner should be able to parse the extra's name and type and push the data to the API
  • Question: How to generate an extra's thumbnail?

Front App Layout

As a source of inspiration, here is what Extras look like on Plex and Blee:
image
image

@zoriya
Copy link
Owner Author

zoriya commented Aug 12, 2024

Guessing if a file is an extra should be handled by guessit (I think they already have (partial?) support of this). We should not have a magic folder name for this to work.

Where should the extra's name be retrieved from? Just the file name? If so, it's way simpler than what I anticipated.

Thumbnails would be handled by the transcoder (eagerly via a queue I think), there is plan on handling some files eagerly with #344 (and files from #549 would fall in this category too).

For the front side, since kyoo doesn't have a season page I don't know how we could handle seasons extras.



There is still another question regarding this: specials.
Some series have recap episodes or extra content (for example, Frieren has 1 recap & 12 short episodes extra).
Some episodes are also placed in the "special" season when database admins didn't want to create a season, for example for movies between two seasons or for weird shows (like monogatari).

I'm thinking of handling specials like normal episodes/movie if they should be watched w/ the show (aka if absolute number != null). How should we handle other specials (recaps & mini episodes in this case)?
Note that TVDB also has a "type" metadata for specials but this is not yet exposed in the API, i just made a feature request thetvdb/v4-api#350

@Arthi-chaud
Copy link
Collaborator

Guessing if a file is an extra should be handled by guessit

I don't think that's a good idea. I couldn't find any info about guessit handling this kind of media.
I tried running guessit with some Extras I have (that are Plex- and Jellyfin-complient), and the result is not satisfying:

Output of guessit on one of those files
$ guessit Breathless\ \(Music\ Video\)-other.mkv 
For: Breathless (Music Video)-other.mkv
GuessIt found: {
    "title": "Breathless",
    "release_group": "Music Video",
    "alternative_title": "other",
    "container": "mkv",
    "mimetype": "video/x-matroska",
    "type": "movie"
}

See how type, release_group and alternative-type are all wrong

Unfortunately, since there is no standard for handling extras, I don't see how we could handle them properly without being a little opiniated.

Where should the extra's name be retrieved from?

Yeah, doing a bit of parsing by hand is doable. If we design a proper (but as flexible as Jellyfin) way of finding an extra's type through its title, parsing its name is easy.

There is still another question regarding this: specials.

I think handling specials and extras as a single thing would be a mistake. Mixing them together would not make sense (I wouldn't want a trailer to be next to a recap episode). Moreover, we can rely on guessit to identify specials, but not extras.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api enhancement New feature or request front Change on the front-end side of the app scanner
Projects
None yet
Development

No branches or pull requests

2 participants