Currently, discs are virtual objects, as they are only referred to by track's disc's index

From a die-hard collector point of view, in a box-set, the discs within can be differentiated using a name, an illustration etc.

Therefore, a Disc model should be developed. It would store tracks, have an optional name & illustration, a index in the parent release. This would be a little overkill in 95+% of releases

On item fetch, the 'slug' field is just a string.
It should be a proper 'Slug' object

An 'album' object can be anything from:

• Studio Recording
• Live Recording
• Compilation Album
• Remixes compilation
• Single

The 'album' metadata should include this field to sort and filter albums

On metadata parsing (#5), if there is one, the artcover should be exported to a file, whose path is built from the entry's metadata

User should be able to edit metadata

From a route, we should be able to retrieve the raw source file, for a potential front-end player

Define the way illustration are stored:

• Base folder
• Standard Format
• Path (From related entry's metadata: artist, album, release index, etc.)

From a route, we should access entries with basic metadata

• Pagination
• Sorting

Using MD5 checksum stored in the DB, extracted at first scan, we know if a source file was changed.
On change, the related metadata should be updated

Should custom error extends HttpException?
Should custom errors be catches by a custom filter, which resolves the Http status code?

Prisma's 'find' methods should be templated to get an accurate return value type

When a file's metadata parsing fail, a simple, but not detailed, there's a warning log, and the file entry is deleted.
The warning log should detail what went wrong in the parsing

The entries of the following types should be deleted if:

• An artist does not have related albums or songs
• An album does not have related releases
• A song doesn't have related tracks
• A release doesn't have related tracks

As libraries get bigger over time, many files are added,
But we might forget to set some metadata to them.

In order to keep a library as clean as possible, an audit feature would be nice.

It would parse the database, and raise any missing data and/or empty fields like a genre, a release date, an unspecified disc index, etc.

User should be able to replace or set an illustration from a URL

As #5, but on user request

On 'getMany' queries, add pagination links to allow user to navigate easily between pages

Enhance 'get' and 'getMany' method to be able to have a 'select' parameter to define what field should be returned

• Artist
• Album
• Song
• Track
• Release
• Library

On illustration extraction, the log always says the illustration has been extracted, even if it has not (because the illustration already was extracted)

the swagger should be accessible from a route

On file registration (#2), its metadata should be parsed and added to the database

On resource request, if they are requested from a parent resource, check that the parent exists, to return an error, instead of an empty list

Create a type to sort items on 'getMany' requests

• Artist
• Album
• Song
• Release
• Track
• Library

There should be a 'Playlist' feature

Back-end:

• A Playlist should have a name
• A Playlist should have an optional illustration
  • Stored in /metadata/_playlists/$slug
• There should be a relation table link a playlist with its tracks
  • The relation should include an index, for the position of the track in the playlist
• We should be able to add one item to (at the end of) the playlist
• We should be able to move items in the playlist
• We should be able to remove items from the playlist

Front-end:

• See a playlist
• Create a playlist
• Update a playlist
  • Rename
  • Illustration
  • Move items
  • Remove item
• Add item to playlist
  • Track
  • Song
• Delete a playlist

If a ParseIntPipe fails, a 'BadRequest' HTTP code should be returned

The server should register (i.e. add its path to the database, and then parse its metadata) a file if its path matches one of the RegExp provided in the settings.json file.

Add a 'select' query parameter to define which fields should be returned

• Artist
• Album
• Song
• Track
• Release
• Library

Same as #20, but the file would be transcoded, and streamed instead of downloaded

Currently, slugs are just thrown into the code, without real and solid implementation

The following modification must be done:

• A better slugify function (managing non-alphanum char and transforming them into closest alpha char. For example Élégant -> elegant)
• Models with a slug must extend a "slugifiable" class
• A Slug should have its own type, and not be a simple string

With #58, the controllers should be able to request a way to sort requested items

• Artist
• Album
• Song
• Tracks
• Releases
• Libraries

Some Track may have their own illustration, like music videos (the illustration being a thumbnail)

Therefore, the illustration file system might be adapted, it'll look like this:
/meelo/metadata/artistSlug/releaseSlug/disc-index-track-index/cover.jpg

Currently, the database Schema does not allow two different songs with the same title by one sad artist.
However, some artists have multiple songs with the same title.

Therefore, we should be able to manage two different songs with the same title.

The solution would be to use the parent album's release date to differentiate. But that would cause other issues (for exemple with compilations or live albums)

We should be able to ignore a source file (i.e. not add/delete it and its metadata from the DB) that match the RegExp

Find a way to get artists that have at least one album

With #15, The metadata could be applied to the source file

If a registered file (see #2) is absent/has been deleted, its entry and metadata should be deleted

Current ORM creates by default
timestamps column which are not used by the app, and sent in the reply on entities fetch.
These column should be removed

Create a pipe to parse identifier in requests and build 'WhereInput' objects

• Library (See #73)
• Artist (See #75)
• Album (See #76)
• Song (See #77)
• Release (See #78)