LMS uses TDOR rather than TDRC as track.year, causing compilation albums to display historical track years

[meehab]

Description

I encountered an unexpected date-handling behaviour while validating metadata for a compilation album:

Various Artists — Music Of The Millennium 2

The compilation was released in 2000, but contains recordings originally released in various earlier years.

The files deliberately preserve both pieces of information:

TDRC = 2000

TDOR = historical/original release date of each individual track

The intended semantics are therefore:

TDRC:
Date/year of the particular compilation release being catalogued.

TDOR:
Original/historical release date of the constituent recording.

Observed LMS behaviour

LMS successfully parses both fields.

However, investigation of the resulting LMS database showed that LMS uses the TDOR/original-date value as track.year rather than TDRC.

It subsequently derives disc/album year information from those historical track years.

In this example LMS consequently presents historical years including 1966 and 1973 for discs within Music Of The Millennium 2 rather than the compilation release year of 2000.

I performed a complete LMS clear/reimport and reproduced the same result.

This therefore does not appear to be stale scanner or cache data.

The canonical files continue to expose TDRC=2000 correctly.

The same canonical music library is also consumed by Emby, which displays the compilation release date as expected.

Related existing discussion

I searched the existing slimserver Issues and Discussions before reporting this.

Discussion #1380, "Extending Lyrion's use of tag metadata to enhance ways in which users can browse / interact with their music via Lyrion", discusses support for metadata including originaldate, originalreleasedate and originalyear:

#1380

That appears relevant to the broader metadata model, but I could not find an existing report describing this specific TDRC/TDOR behaviour.

Steps to reproduce

1. Take tracks belonging to a compilation released in a particular year, for example 2000.
2. Set TDRC to the compilation release year: 2000.
3. Set TDOR on individual tracks to their actual historical/original release years, for example 1966, 1973, etc.
4. Import the files into LMS.
5. Examine the resulting track/album years in LMS and/or the corresponding LMS database values.
6. Clear and reimport the library to confirm the behaviour.

Observed:

LMS uses the historical TDOR value for track.year, and these historical track years influence the year associated with the compilation/discs.

Expected:

The primary year for the particular release being catalogued would come from TDRC (2000), while TDOR would remain separately available as the original/historical date of the recording.

Why this distinction matters

For compilations, reissues and potentially other release types, TDRC and TDOR describe different facts.

For this example:

TDRC = 2000

answers:

"When was this compilation release issued?"

while, for example:

TDOR = 1966

answers:

"When was this recording originally issued?"

Using TDOR as the primary track/release year effectively causes a single compilation release to acquire multiple historical years.

It also means users who deliberately preserve both pieces of metadata cannot retain that distinction in LMS's normal year handling.

Expected / suggested behaviour

Would it be possible for LMS to retain the two concepts separately?

For example:

• use TDRC as the normal year/date for the particular release represented by the files;
• retain TDOR separately as original date/year;
• derive the album's release year primarily from its release-date metadata rather than the constituent tracks' original dates.

This seems related to the metadata expansion discussed in #1380, particularly its discussion of original-date metadata.

If the current TDOR-over-TDRC behaviour is intentional, this may be better classified as an enhancement rather than a bug. Either way, I wanted to report the concrete behaviour because it produces surprising results with compilation albums carrying both values.

Additional observation

During the same investigation I observed that LMS reads the physical TALB values on these files containing [Disc 1] / [Disc 2] suffixes.

I have not established that this is causally related to the date behaviour, so I mention it only as an observation rather than suggesting a causal relationship.

Additional evidence available

I can provide:

• representative metadata dumps showing TDRC and TDOR;
• LMS scanner information;
• resulting LMS database values;
• representative files if required.

I have deliberately not modified the otherwise-correct canonical metadata merely to force LMS to display 2000.

Environment

Lyrion Music Server:
9.1.1 - 1779815526 @ Wed Jun 17 12:31:42 UTC 2026

Operating system:
Ubuntu - EN_GB - utf8

Platform architecture:
x86_64-linux

Database:
SQLite

Perl:
5.38.2 - x86_64-linux-gnu-thread-multi

Audio::Scan:
1.10

DBD::SQLite:
1.76 (SQLite 3.46.1)

IO::Socket::SSL:
2.085

Net::SSLeay:
1.94 - OpenSSL 3.0.13 30 Jan 2024

Hardware/host:
x86_64 unRaidNUC

Browser:
Not relevant — behaviour occurs during server-side metadata scanning/database handling.

[michaelherger]

Please describe your finding in ten lines. Then ask Claude to fix it. Should be easy.