Album version

[darrell-k]

New column albums.version and associated processing (see thread at https://forums.lyrion.org/forum/user-forums/logitech-media-server/1765250-extending-lyrion-s-use-of-tag-metadata-to-enhance-to-browse-interact-with-your-music#post1769954 )

The reason for this change is to allow users to (optionally) use an additional tag "VERSION" to distinguish different versions of the same album. This will enable future UI enhancements, for example to group together different versions of the same album. It should also make metadata matching simpler as albums.title can contain only the actual album name.

I've also made the database changes for the forthcoming enhancements to the Record Label PR, and changes to persistent track ID (see same thread above for discussion on that), to prevent forced rescans when these are done.

[michaelherger]

Please provide a summary of the changes. I tried to understand that thread, but it's pretty long, with some back and forth etc.

In particular the introduction of lms_persistent_id made me shudder at the thought of having one more "single source of truth". I fear this will not solve the underlying problem (as far as I understood it), but will introduce yet another level of complexity.

[michaelherger]

What Copilot thinks this does (which means the aforementioned lms_persistent_id is irrelevant here?):

This pull request adds support for an album "version" field in LMS (Logitech Media Server). Here’s a summary of the key changes:

Database Schema Changes:

• Adds a new column version to the albums table (both SQLite and MySQL).
• Updates track and label-related schema, including new tables and indexes for labels and label_album.

Backend (Perl) Changes:

• Updates album-related queries and logic to handle the new version field (in Slim::Schema, Slim::Control, Slim::Menu, etc.).
• Ensures the version is included when creating, updating, or searching for albums.
• Updates code to include version in favorites URLs and display strings.
• Handles version field in UTF-8 decoding and tag data extraction.

Frontend/UI Changes:

• Updates HTML templates and JavaScript (SqueezeJS) to display the album version (e.g., Album Title [Version]) wherever album information is shown.
• Adds logic to construct album display names including the version, if present.

Migration Scripts:

• Provides up/down migration scripts to add or remove the version field and related label tables.

Overall:
This PR allows LMS to store and display different versions of the same album (such as “Deluxe Edition”, “Remastered”, etc.), making album handling and display more precise and user-friendly.

[darrell-k]

On the persistent id changes, I forgot there is an issue, which I have just updated with the bare bones of a specification, which needs more thought. The new column is to give the user somewhere to store their own id if they don't want to rely on MusicBrainz. There was a consensus that this was a good idea in the Forum thread. I don't think it does any harm adding it now.

On the album version changes, it seems that Copilot can read ;)

[darrell-k]

Sorry, meant to link the issue #1372

[michaelherger]

Please add a summary to the PR description. I do understand what Copilot found in the changes. But it doesn't describe the motivation behind the change. And I won't read >85 postings which go in all kinds of directions (eg. the misleading lms_persistent_id topic) to figure out what this might be. It would be great if a reviewer could see from the PR descriptions what he's going to expect. Thanks!

[darrell-k]

I've updated the PR description in the first comment above.

[darrell-k]

Just pushed a fix to this, I had broken the album matching when version IS NULL.

Don't know how you want to proceed with this re the persistent id column: should we remove that from this PR (did you see mike's reply at #1372 ?)

[michaelherger]

I'm sorry for being slow. I'm currently travelling and find it hard to do serious reviews on a small screen...

[michaelherger]

The one question I have: why would we store the version in a separate field if we added it to the album title all the time anyway? I think it should rather be treated like the year, which can be shown or not, which is its own property where the user can customise the display etc.

[darrell-k]

Reasons mentioned in the forum thread:

1. Stuffing version into the album name can make it difficult for taggers or other metadata lookup tools to find matches on album name. I guess having a separate version tag would also make it easier for MAI, although IIRC that already tries to parse out eg stuff in square brackets.
2. People coming from other servers (eg Roon) may have a separate VERSION tag already.
3. It opens up the possibility of specific UIs (I think people are thinking about Material) grouping different versions of the same album.

See https://forums.lyrion.org/forum/user-forums/logitech-media-server/1765250-extending-lyrion-s-use-of-tag-metadata-to-enhance-to-browse-interact-with-your-music?q=version for the discussion on these things, with the filter in the URL it's only a couple of pages of comments.

[darrell-k]

PS. I can't think of a scenario where you have multiple versions of the same album but don't want to show the version text.

[michaelherger]

Ok, my initial reading that the version would included in the album title everywhere was wrong. The raw query would return it as an additional field.

Shall we bet on the request to have this field be displayed optionally? 😁

As for the schema change: I'd prefer to keep things apart, even if it means we might have yet another full rescan. Otherwise we end up with columns no-one remembers what they were supposed to be. Like eg. the hash column in tracks. Any idea what that might have been? A hash value for the file? Or full tables like pluginversion, unreadable_tracks, rescans...

[michaelherger]

I'm sorry, I just created a conflict with this PR... you'll have to rename the schema files to 27. And I must go back to the forum to warn people about the commit I pushed earlier today. Didn't think much, stupid me.

[darrell-k]

Coming back to this, I've removed the tracks table change (lms_persistent_id) and resolved the conflict. I'll test again, since it was so long ago.