pymedusa / Medusa

Automatic Video Library Manager for TV Shows. It watches for new episodes of your favorite shows, and when they are posted it does its magic.
https://pymedusa.com
GNU General Public License v3.0
1.77k stars 275 forks source link

Proposal: Create an open standard file format to store release file metadata #6245

Open ratoaq2 opened 5 years ago

ratoaq2 commented 5 years ago

Proposal: Create an open standard file format to store release file metadata

When managing media libraries (movies, tv series, etc), it's very common to move and rename files. Copying them to a different volume/disk, different filesystem. When renaming them, it's very usual to remove some important release information (source/format, release group, video codec, screen size, etc). This kind of information is very important when organizing your files, like when you try to find a subtitle for it that fits that release. People usually also changes their media organizer software. Moving from couchpotato to radarr, or from SickRage to sickchill or medusa, from a simple filebot to a more complete media organizer like sonar, radarr, bazarr, sick*, medusa. All these organizers keep the release information in their database, that's completed detached from the media file. If you move from one app to another, you lose that info. If for some reason you start from a fresh install, you lose that info. And sometimes you also want to integrate with other tools, like to download/manager subtitles using subliminal, bazarr, subzero. What I see is that each of these apps and tools try to solve the same problem in different ways. And an open standard could just facilitate these things.

Some common solutions to store file metadata are:

  1. filesystem extended attributes
  2. database
  3. separate (hidden) file/directory

Option 1 is completely dependent on the filesystem and when moving/copying files around you can just lose your metadata Option 2 is exactly what all these apps do. If you change app or reset your db/config, you lose your metadata Option 3 is similar to the common standard about storing subtitles alongside media files. All the media organizers handles these associated files correctly during renaming and moving. If you start from scratch or move to a different application, your metadata is just alongside your file and you can easily copy and move your library to different volumes/filesystem/disks.

My proposal is to create an open standard file format to store release file metadata, similar to the way external subtitles are stored. Some initial ideas is to have the file as follow:

My Media - Some Title.mkv
.My Media - Some Title.xattr

and also to support:

My Media - Some Title.mkv
My Media - Some Title.xattr

xattr name is just inspired by the filesystem extended attributes (xattr) And inside this file we could store key/value pairs about the release metadata, such as:

release.name=My.Media.1080p.Some.Title

We should standardize all the keys under release namespace. And each media organizer could keep/use any custom/vendor keys under their namespace. E.g.:

subliminal.subtitle_provider=opensubtitles
medusa.provider=rarbg

My proposal is to keep the standard and conventions as simple as possible:

I'm opening the discussion to see whether people think there's a need for it. People won't be oblige to use it. It's just an additional available option when managing their media libraries. After the discussion to define the standard, devs from all these Apps: medusa, sonarr, radarr, sick* forks, couchpotato, bazarr, subliminal should add minimal support to it (make sure that these associated files are move/copied/renamed together with the media file). Then some of them could add additional support to have an option to write/read from these files to give their users a better experience.

I'm a developer and contributor for several projects, including subliminal, guessit and medusa and for long time I see a need for such thing. I'm opening a github issue for each of these projects to start a discussion and check if there's any interest/need for it. If the feedback is positive, I'll later centralize the discussion in the subliminal project.

sinnlosername commented 3 years ago

Is this still open for debate? If so, here are some of my thoughts about it.

Some common solutions to store file metadata are:

  • filesystem extended attributes
  • database
  • separate (hidden) file/directory

A fourth option would be the usage of existing metadata inside media files. MKV files for example have a lot of useful default tags (titles, episode number) as well as support for custom tags. The main advantage of this would be that metadata is almost never lost. Disadvantages would be the often very rare library support as well as possible performance problems (tho this might be a problem with all file-based solutions).

A metadata format could also support multiple of the above solutions, as it's basically just a (tree-based) key-value structure. So it doesn't really matter whether you save it into an own file or attach it to an existing one. Libraries will just convert it.

The content is a very simple key=value (no quotes, no escapes. Keys cannot contain non visible characters and cannot contain =. Everything after = is a value, including spaces, quotes and any visible character)

I think it would be better to use a well-known format like JSON. It's probably easier to parse than the simplest key-value system because almost every project already has a JSON library integrated. Also it would already take care of all the exceptions like special characters and stuff.

I'm opening the discussion to see whether people think there's a need for it

In the few months I'm using software like Medusa or Sonarr I've already had a ton of problems with that detection of file metadata, so I'd say it definitely is.

Additionally if such a metadata format would find support from some of the bigger projects release groups might also start adopting it. So instead of guessing episode names, numbers & co, we'd know it from the start.