Clear library and rescan everything lose the song id

[NeptuneHub]

Describe the bug
Hi, I'm the developer of AudioMuse-AI, a software that interact with Lyrion API to create automatic playlist. The interaction can be simplified in:

• Check of all the album present;
• For each album download one song at time
• Each song is analyzed and saved in audiomuse-ai database WITH the original Lyrion id
• Then an user can ask to create automatic playlist (of similar song or in different way) using the stored lyrion id

The issue shared by some user here:
NeptuneHub/AudioMuse-AI#620

Is that seems there si a scan functionality, I think named "Clear library and rescan everything", that DROP all the id. This is a big issue for AudioMuse-AI and for every app that use ID as reference because it lose all the reference.

Expected behavior
Like other Music Server like Jellyfin, Emby and Navidrome, the expected behavior is to NEVER lose the ID of already analyzed song. They only assign new id to new song. The only small impact scenario is if the user just move the path of a couple song, in this case the new analysis change the id only of those album and not of the entire library.

In short my request is to NEVER change the id of a song already analyzed that didn't had any change.

Screenshots
Not Applicable

System Information (please complete the following information):
AudioMuse-AI's users didn't share this but they claim that this is a normal Lyrion functionality, not a bug that need specific envirorment to be reproduced. What I'm asking is to improve the normal functionality.

Additional context
I don't have any other additional context.

Really thanks for your effort.

[michaelherger]

I'd say this is never going to happen. Would be too much work with too much risk to break existing integrations, and for little gain.

I don't know how you get to the IDs of a track. But we have a urlmd5 column in the database which is unique across scans - as long as you don't move a file. You could try to use that instead?

[michaelherger]

BTW: even if you can't get the urlmd5 value through a query, it could be calculated from the url value. It's a simple MD5 hash of the url value.

[NeptuneHub]

The point is that on AudioMuse-AI I need to:

• get list of all album;
• for each album download all the song
• be able to create playlist, edit playlist, delete playlist;
• be able to get last played/top played song

And as far as I know only the “normal” id (the one that change) is supported as a direct input in the signature of all those APi. If I have let’s say 1000 song (but even more) and to get the md5 I first need to do another call for each of them is not an useful solution. Did I misunderstand this?

Also I already have a Provider Migration functionality in AudioMuse-AI that could be useful to pass to a different music server but also as a fallback to recreate id on the same music server (exactly because maybe you update or reinstall). But is not something fast end error free to run each days.

I really appreciate all the work made on Lyrion, I’m just worried that this database erasure and rescan is not just a rare use case that could happen with major update but something more natural in the day by day usage of Lyrion. If this is the case become difficult an API integration where the main id to identify the song change frequently. A sonic analysis, especially on big library, could takes multiple days. So the change of id have big impact on the final users.

[michaelherger]

Most playback functions should accept the audio file URLs. Playlists are built from URLs rather than IDs anyway. You should be good. You don't even need that md5, as it's derived from the URL.

[mamema]

the problem here is, the tool audiomuse linked the id which gets mixed up with a lyrion full database rebuild. then the audiomuse ids are difffrent and the files need to be reanalyzed. which would take days to weeks which depends on the available cpu power

[michaelherger]

If Audiomuse used the file's URL (or its hash) that problem would be solved. We're not going to change the ID handling.