New Artist Detail View: Sort albums by full date, not just year

[SenorSmartyPants]

Description

Only year is being used to sort, Not year-month-day. For artists with multiple releases in a year this can cause the albums to be in the wrong order. Example: The Beatles. Please Please Me should be first, not With the Beatles. (see screenshot below). Sgt. Pepper and Magical Mystery Tour are out of order as well. All albums are tagged with full dates.

Expected Behaviour

Albums should sort by YYYYMMDD when sorting by date or "year".

Platform information

• Navidrome version: 0.46.0
• Browser and version: Chrome Version 94.0.4606.81 (Official Build) (64-bit)
• Operating System: docker official image

Additional information

[metalheim]

I fully agree that this would be nice.

Navidrome currently only reads the "year" field, which technically is only supposed to be filled with a year, not a datestring (for id3 tags f.e)

So it is working as intended currently.

Maybe also reading the "releasedate" would help, but technically these can be different things and every tagger has different interpretations what to put in there.

Some taggers put the first ever release date of that album, some put the release of the physical medium (which can be completely different)

[SenorSmartyPants]

I wouldn't want to check releasedate, as you state they could be different.

Beets allows putting in the full date as does Picard it seems. So if the data is there, why not take advantage of it?

For reference here is the ffprobe output of one of the files in question.

Input #0, mp3, from 'The Beatles - With The Beatles - 01 - It Won’t Be Long.mp3':
  Metadata:
    title           : It Won’t Be Long
    artist          : The Beatles
    track           : 1/14
    album           : With The Beatles
    disc            : 1/1
    date            : 1963-11-22
    genre           : Rock And Roll, Rock, Pop
    TBPM            : 0
    compilation     : 0
    TDOR            : 1963-11-22
    originalyear    : 1963

[certuna]

Navidrome currently only extracts the year, even if the actual date field is a full date with months+days (or even time) in it.

In FLAC/Vorbis it doesn't only look at YEAR, if that's missing it will use DATE or RELEASEDATE and just take the year. I assume @deluan originally chose to do it this way because of the Subsonic API, which only supports years, so storing months/days would be useless. But of course the Web UI is not limited by the Subsonic API limitations.

I've been thinking about doing a more extensive implementation of the various date fields (release date, original date, etc) in #278 , supporting full dates can probably best be done as part of that.

More detail: in id3v2.4 there's the standardized field TDRL ("release date") which can even be a full timestamp like 2002-03-04 14:30. ffprobe maps that to date (see the output above). There's also TDOR ("original date"), which ffprobe apparently doesn't map. MusicBrainz Picard also writes a custom tag TXXX:originalyear which holds just a year.

[deluan]

Yeah, importing the full date if available makes sense. It is not a simple change, but I'll try to work on this soon. Thanks for the report.

[rombat]

What would be great too would be to have distinct albums displayed based on this full date.
For instance, I have an album with "year" tag being 1986-09-25, and another album (exact same name, different folder) with "year" tag being 2014-07-16, because it's kind of a reissue.
In navidrome, both of them are considered as one single album with duplicate tracks and 2 possible years, 1986 and 2014. I've tried adding a subtitle to them but it doesn't make any difference

[SenorSmartyPants]

Yeah, importing the full date if available makes sense. It is not a simple change, but I'll try to work on this soon. Thanks for the report.

Any updates on this?

[koehntopp]

I would like to add to this bug:

YEAR will usually have the date of the version in question, ORIGINALRELEASEDATE should get you the order of release of themaster version.

I understand the way people tag files makes a massive difference here, and finding a solution that works for everyone might not be possible.

I'd like to advocate for a configuration file option like

album_sort_tag = 'ORIGINALRELEASEDATE'

[certuna]

Problem is that it is not clear cut what the ORIGINALRELEASEDATE field should hold:

• the id3 standard says that the Original Release Date (the TDOR frame) of a track is the release date of the original song, in case of a cover version, live version, interpretation of a classical piece, remix, etc. So for a song, say, Jeff Buckley - Hallelujah the Original Release Date is "1984", when the original by Leonard Cohen was released
• MusicBrainz Picard uses this field to tag the date-of-first-edition of the release it is on, so in the case of "Hallelujah" the Original Release Date could be either 1994 (if the song is part of the album "Grace"), 2007 (if it's on the single "Hallelujah") or 2019 (if the song is on the "Hallelujah: The Songs of Leonard Cohen" tribute album)

Ideally Picard would save it in a more appropriate field like ALBUMORIGINALDATE, but unfortunately it doesn't do that.

[SenorSmartyPants]

The comments thread is getting off topic from my original issue.

Yeah, importing the full date if available makes sense. It is not a simple change, but I'll try to work on this soon. Thanks for the report.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Navidrome team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[deluan]

This now can be done, since #2162 was merged. Will take a look.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.