is my expectation wrong or my setup?

[mamema]

after several days of song analyzing i´m now ready to go.
But i must say, my mixes are underwhelming

Because of that i´m asking here.

imagine the following.

• Creating a playlist based on similarity
• choosing Ludovico Einaudi. This is a piano player which creates smooth instrumental songs based on classical genre.

when i use this approach i get a playlist with a wide mix regarding genre. i even get folk/rock songs or blues songs.

My expectation would be: instrumental songs and smooth mood songs.

why do i get this large varities regarding mix style?

[NeptuneHub]

Hi and thanks for the feedback. The functionality Playlist from similar song analyze your library based on the Musicnn machine learning model that output a 200 size embbeding vector. Based on this vector AudioMuse-Ai return the most similar song to the one you selected based on cosine similarity.

This means that:

• is not genre based. two song that sound similar, still satisfy the match.
• how much similar? it depends from you library. It return the most similar.

Just to say I just did a test on my 180k+ song library with a random song of Ludovico Einaudi, that is a relaxed piano song with a female vocie. Some song returned are similar because was relaxed and made with piano. Some song are similar because have female voice relaxed voice. Some are relaxed, with piano and with female voice.

So in short a song is a "composition" of different pattern that the model is able to identify and find the similar to. Is not just a find the same genre algorithm.

[mamema]

i just mentioned genre to describe the song pattern. i just was suprised that a instrumental piano song led to a irish folk rock band with a male singer (Waterboys).
Is this configurable somehow so that more instrumental piano stuff would show up?

[NeptuneHub]

There isn't any configuration: the algorithm return to you the most similar song that is able to find in your library based on Muscinn model and consine similarity.

[mamema]

am i using the whole solution wrong?
I´m fairly new to the whole topic. Audiomuse AI offers a lot options to select music playlist.
Is there any other approach to come to a more "alligned" playlist according to my example?

[NeptuneHub]

How many song do you have in your collection?
Did you tested with multiple different song a part from this ?

I’m asking this because it work good when you actually have multiple similar song in your collection among which the algorithm can chose.

If you have a very small collection and/or your song are to distant between them is easy that it give as “nearest song” a song that is far.

Then some outlier can always happen, by the end is a probabilistic approach. But if you say that multiple test you always get bad result the only idea in my mind is that your are searching similar song of something not well represented in your library.

[mamema]

i am at the beginning of my testing. i have 170.000 songs and quite a lot instrumental piano stuff.
the interesting observation is that on every "Ludovico Einaudi" "Cadenza" https://www.youtube.com/watch?v=8Sn8gvzu-3A test somewhere in the 25 song list "The Waterboys" are coming up.
This song "Ain´t leaving i´m gone": https://www.youtube.com/watch?v=JiG9Y8KZsNw

those two songs have so much NOTHING in common. My AI is drunk!

[mamema]

Lyrion itself has a ´delete db and make a full scan‘ option. So this is not a disaster option, it is just part of the lyrion scan options. This option is then the killer function to break audiomuse ai.
What are my options now? Reanalyze everything?
Can you rethink the logic what id of reference is used in the future?
as db deletion and recreation is an integral part of lyrion.
Perhaps writing to the flac files itself like musicip has a good cause.

[NeptuneHub]

First do a backup.
Second You can try in Admin > Provider migration if migrating from Lyrion To Lyrion rematch the id. Some time ago an user did Jellyfin TO Jellyfin because he reinstalled, so maybe we are lucky and work also on Lyrion (or in case of bug on this share the log).

@rendyhd do we never test Lyrion to Lyrion provider migration ? (And at this point also Navidrome to Navidrome and Emby to Emby just in case)

I can’t use different reference from the ID. I need to process an index of your entire music collection, that could be of million song, and then recover the song in milliseconds. ID is the only way, if you drop the id for any reason it stop working.

[rendyhd]

I can't remember if I tested Lyrion - Lyrion specifically, but I see no reason why it shouldn't work.
But I agree, @mamema try running the migration. After deleting your database, you'll always have to do that.

Regarding the logic of track ID that's tricky:
All other media providers we support don't need to wipe their databases for regular maintenance, and track ID is the common way to refer to a track everywhere. I think it's just a Lyrion quirk we'll have to live with for

[wirrunna]

Wow! A Lyrion "Clear library and rescan everything" is common practice after doing an album delete due to change of tags etc. It only takes an hour on my 200,000 track library. The initial AudioMuse-AI scan has been going for days, although the second half of the scan will be quicker as I added a few extra workers.
I will do a backup as soon as the analysis is complete.

Being a long time user of SqueezeBox server - now Lyrion, I have used MusicIP (MIP) for 20 years and will be comparing MIP to AudioMuse-AI for my local home server.
When using MIP years ago, Amplify had the central server running so the local music server running MIP analysis would query the central server and where possible it would download the analysis data thereby saving considerable time.
The addition of the AudioMuse-AI central server lookups would hopefully speed up analysis locally for Lyrion users (I know it is available for other music server systems).
Obviously I am more than willing to share my soon to be completed analysis data to your central database.
MIP also would optionally archive the analysis data in the file tags of the song, so maintaining a second server was a simple copy new songs and re-analyse which was quick as the analysis data was on the file tags and would only have to be added to the MIP database. Depending on the size of the AudioMuse-AI analysis data for a song, archiving the analysis data in the song file tags may be a viable way forward for server copies.

One last point, there is now an AudioMuse-AI plugin for Lyrion -
https://github.com/JameZUK/lyrion-audiomuseai-plugin

[rendyhd]

I get that it's frustrating, I just don't think there is much we can do about it.

• Use the migration feature so you don't have to analyze everything again, here we have built automatic matching and do our best to match tracks, however, there is a dependency on path and how the provider matches the metadata (so if there's differences between full db builds this might be impact it).
• We use the API, where we recognize a track by its ID. From any database perspective, it's not a good practice to let your ID change, it's how we identify something. So it boils down to the following:
  The incremental scan is very unreliable so Lyrion users have to apply a bandaid by wiping their db and rebuild - both waste in compute and time. This is not because wiping your db is a best practice, but a workaround because incremental scan is unreliable. Then when that db gets rebuild, an id doesn't get generated from the filehash but randomly allocated.
  It doesn't give us much to work with. We build the migration feature to help people migrate between instances, and basically, every time you do a complete wipe, you start from fresh.
• we don't have access to the files directly, we get them via provider APIs.

[mamema]

we don't have access to the files directly, we get them via provider APIs.

but this is just an software design decision. my musicip solution has also access and the musicip fingerprint is written to the files. i would happy to porovide file access to audiomuse ai also.
I now make an lyrion to lyrion migration and report back.

[NeptuneHub]

The Mission of AudioMuse-AI is Sonic Analysis free and open source for everyone. So I'm very happy to support Lyrion, and in the future I would like to support other famous music servers if possible.

Here are the possibilities I see:

• AudioMuse-AI user awareness: Users should know that dropping the Lyrion DB will require a new AudioMuse-AI analysis and stop doing it. I really don't know why Lyrion implemented this functionality, but I hope you can avoid using it and instead perform a normal scan that doesn't change all the IDs. This is not safe, but in case of an accidental drop, a Provider Migration could help (I also suggest a backup of both AudioMuse-AI and Lyrion).
• Lyrion improves this behavior like the other music servers: for this, I opened an Issue on the Lyrion repository asking if all AudioMuse-AI Lyrion users can share their support: Clear library and rescan everything lose the song id LMS-Community/slimserver#1590

The reasons to don't change AudioMuse-AI are multiple:

• All the other music server like Jellyfin, Emby and Navidrome already work by ID correctly. So it will be a really ad Hoc implementation.
• Every AudioMuse-AI architectural implementation is designed to cover up to a 10 million song music collection. Even if I don't have such a huge collection, removing the ID will for sure slow down the architecture. Actually with proper hw it do a similar song search in millisecond using a proper index.
• AudioMuse-AI, by default, is not the owner of the data. I don't like the idea of directly modify them. I even don't know if AudioMuse-AI can change such information by API.
• Changing this would be a huge implementation with a high risk of regression.

[mamema]

you can browse the lyrion forum and you will find a pletora of reasons why a db deletion is needed. also audiomuse proposed a deletion of the audiomuse db after introduction of new functionality. this happens in lyrion also.
analyzing 170.000 files again is the core problem, as it is slow as hell by design. not every user has 90 cpus at hand like i have here. But besides of that, the energy bill skyrocket if i do need a reanalyzing every other month.

Would be a "write to file" migration task not as mandatory but as an option for those people who needs it be an solution?

[NeptuneHub]

You already have a backup functionality that write the entire DB to a file AND a provider migration that migration to the same exact music server, without file path change, should have a good success rate.

Please have a check and let me know, if it work too bad we can check this and eventually find a fix.

Anyway your are not describing “a day by day functionality”, but a rare case where you update the music server and the music server introduce distruttive change that need a rescan. In this rare case (where rare I suppose not each week, but maybe even not each month) I think that Provider Migration could already be the right solution.

[mamema]

i have done the provider migration, the outcome is:

• file playlist in audiomuse and lyrion are now thew same.

what still is not that great, that the "not suitable" title (regarding similarity based on piano instrumental) still show up. now on both sides, audiomuse and lyrion.

before the provider migration the similarity regarding piano instrumental was given on the audiomuse side, but then the playlist on lyrion side has the unsuitable Songs Rock/Folk with male singer introduced.

this happens now on both sides.

so the provider migration has cleared the differences between the two systems, but has used the "wrong" file as master, as the similarity which was at least on the audiomuse side before the migration, is now gone.

[NeptuneHub]

but migration matched all the song?
After migration, did you run the analysis ? it should be fast and recreate all the index.
Did you have some error in the log when you do simialr song that you can share?
Which version of AudioMuse-AI and Lyrion do you have?

You need to help me to help you.

[mamema]

sure, i will try to anwser all your questions:

• running latest docker imasges from audiomuse-ai which has the backend version 2.1.4
• after migration i ran the analysis to recreaste the indexes
• there is no error in the log, just the entries that the playlist was generated with the id numbers
• lyrion has Version: 9.1.1 - 1779815526

from my understanding the following has happend. assumption

• before migration:

in audiomuse:
piano song 1 - id 1234
piano song 2 - id 5678

in lyrion
piano song 1 - id 1234
piano song 2 - id 5678

• then recreating lyrion db

in audiomuse:
piano song 1 - id 1234
piano song 2 - id 5678

in lyrion
piano song 1 - id 1234
piano song 2 - id xyz - now references an Rock song

• after migration

in audiomuse:
piano song 1 - id 1234
piano song 2 - id xyz - now synced with lyrion side

in lyrion
piano song 1 - id 1234
piano song 2 - id xyz - now references an Rock song

---

so if my assumption is correct the provider migration synced one way from lyrion -> audiomuse, but in my case or in the case of the lyrion db recreation the migration should be audiomuse -> lyrion.

the second assumption could be:
everything is fine, the selection of an Rock Song is just a AI error. But this assumption doesn´t explain why atr first there was no Rock Song in the audiomuse mix and the mix seems smooth all the way for 25 songs.

[NeptuneHub]

So you do everything expected.

The flow is always AudioMuse-AI -call-> Lyrion to get information (the new id, new album, download song to analyze) never the vice-versa. The only moment in which audiomuse-ai write information on lyrion is only when it create playlist.

To confirm that analysis did it's index recreation good you should have:

• in worker: multiple string that say that the index is rebuild => if you can cut and past them here just to doublecheck;
• in flask: multiple stirng saying the index ir reloaded => if you can cut and past them here just to doublecheck.

As extra test, after saving the above log, you can try to restart the flask container to force another reload of the index (but this assume index are rebuild correctly).

If everything is good, some outlier could happen, if all are outlier especially on multiple query, it doesnt' make sense. Especially if you say that after the migration the result on audiomuse-ai changed and are now wrost then before. If this happen means that for some reason something wrong happen. Maybe here you can check if the cleaning task find something to clean.

Here the issue I think is that when you changed the id (by dropping the database on lyrion) you could have done additional analysis that start to dupplicate the album. Then the migration didn't solve this dupplication so maybe a cleaning after the migration could help (remember that by default it clean max 100 album per round).

In short the process: All the ID changed => migration to re-allign the id should work if you do one after the other. Buyt if you change all the id, then you do some analysis in the meanwhile, you could have duplicated id and create issue. But this is only an hypothesis. I mean if before it was working and after the cleaning it stop working, something should have happen.

[wirrunna]

Over in LMS-Community/slimserver#1590, Michael Herger (chief developer of Lyrion) has suggested using "urlmd5" as the track ID as it it could be calculated from the url value. It's a simple MD5 hash of the url value.

I suspect that MusicIP uses urlmd5 as its fingerprint tag. It may be worthwhile looking at the MusicIP plugin in Lyrion.

This means that going forward mamema and I will be doing a new analysis of our libraries. If we provide your team with a copy of our database backup, could you extract track analysis data and add it to your central database? Then, if the Lyrion AudioMuse-AI integration would use the centralised database lookup routine developed for Jellyfin and others it should significantly shorten the analysis time from weeks to days.

[NeptuneHub]

So Provider Migration functionality should already check song by Path, Title and Album.
So if you're in similar scenario you should:

• do a backup just in case;
• do a provider migration lyrion to lyrion
• do a new analhysis after the migration to rebuild all the indexex

And then should already work because provieder migration already mathc Path + Title + Artist + Album of the song against lyrion API.

I don't know why for mamema is not working, my suspicious is that for other reason (still not clear) the index rebuild is failing/crashing.

If you have similar problem, you can test and share the feedback will help.

[mamema]

The flow is always AudioMuse-AI -call-> Lyrion to get information (the new id, new album, download song to analyze) never the vice->versa. The only moment in which audiomuse-ai write information on lyrion is only when it create playlist.

Yes understood this. But my point was. Lyrion db is the master. as long it isn´t recreated. but in this case the master switched to audiomuse. my assumption was audiomuse (master) -> lyrion could be used within the provider migration. In the following way.

• if lyrion db was deleted and audiomuse not (master changed to audiomuse side)
• the id validation works the other way around
• not lyrion id -> song gets saved, the audiomuse id takes precedence

i do not know what exactly gets compared, so my assumption:
lyrion id, song file path, album, title gets normally to:
(yrion id will be audiomuse id, song file path, album, title

this could be changed with a flag which can the user set, in case the lyrion db was deleted to work like:
on lyrion side
song file path, album, title, is lyrion id
on audiomuse side
song file path, album, title, is a different id (validate something here.... search real id or don´t change id, whatever suits better)

If everything is good, some outlier could happen, if all are outlier especially on multiple query, it doesnt' make sense. Especially if you >say that after the migration the result on audiomuse-ai changed and are now wrost then before. If this happen means that for some >reason something wrong happen. Maybe here you can check if the cleaning task find something to clean.

yes this is the case, as described, the assumption is, a "good" song with his id on audiomuse is now linked to the same id on lyrion wqhich has a "bad" song behind. the provider migration has the id back synced to audiomuse, so logically everything is correect now, but the bad song is now on both sides. hence my proposal above to make a different comparision in case of db deletion of the lyrion db.

---

logs for analysis process

• started on worker:
  [INFO]-[10-06-2026 14-01-28]-[MainAnalysisTask-291ed64c-e71e-4a66-903c-e8dc7ca94d88] 🚀 Starting main analysis process...
  [INFO]-[10-06-2026 14-01-28]-DEBUG: MUSIC_LIBRARIES config value: 'music'
  [INFO]-[10-06-2026 14-01-28]-DEBUG: Target paths for filtering: ['music']
  [INFO]-[10-06-2026 14-01-28]-Scanning Lyrion library for albums in configured folders (limit: all)
  [INFO]-[10-06-2026 14-01-28]-Counting Lyrion albums with and without 'sort:new' to decide pagination mode (analysis of all albums)...
  [INFO]-[10-06-2026 14-03-04]-Albums with sort:new = 5000, albums without sort = 13564
  [INFO]-[10-06-2026 14-03-04]-Albums without sort are more numerous; proceeding with unsorted pagination for Lyrion.
  [INFO]-[10-06-2026 14-06-50]-Worker 57117fc6b8cb4bf099240c24e03d0b62: cleaning registries for queue: default
  [INFO]-[10-06-2026 14-17-20]-Worker 57117fc6b8cb4bf099240c24e03d0b62: cleaning registries for queue: default

logs for flask startup

ENTRYPOINT: now waiting on supervisord pid 46
[INFO]-[10-06-2026 14-33-56]-Starting AudioMuse-AI Backend version v2.1.4
[INFO]-[10-06-2026 14-34-04]-Loaded mood centroids for similarity: happy(35), sad(46), aggressive(41), party(42), relaxed(42), danceable(43)
[INFO]-[10-06-2026 14-34-04]-Loaded mood centroids: happy(35), sad(46), aggressive(41), party(42), relaxed(42), danceable(43)
[INFO]-[10-06-2026 14-34-05]-Attempting to load Voyager index from database into memory...
[INFO]-[10-06-2026 14-34-10]-Voyager segmented index (5 parts) with 173989 items loaded successfully into memory.
[INFO]-[10-06-2026 14-34-10]-Loading artist similarity index from database...
[INFO]-[10-06-2026 14-34-10]-Retrieved artist index from database (single row): 14701943 bytes
[INFO]-[10-06-2026 14-34-11]-Loaded artist metadata from artist_metadata_data: 11036 artists, 23489078 bytes.
[INFO]-[10-06-2026 14-34-11]-Artist index loaded successfully (11036 artists, num_elements=11036).
[INFO]-[10-06-2026 14-34-11]-Artist similarity index loaded at startup.
[INFO]-[10-06-2026 14-34-11]-Attempting to load map projection 'main_map' from database into memory...
[INFO]-[10-06-2026 14-34-11]-Map projection 'main_map' with 173989 items loaded successfully into memory.
[INFO]-[10-06-2026 14-34-11]-In-memory map projection loaded at startup.
[INFO]-[10-06-2026 14-34-11]-Attempting to load artist projection 'artist_map' from database into memory...
[INFO]-[10-06-2026 14-34-11]-Artist projection 'artist_map' with 28031 components loaded successfully into memory.
[INFO]-[10-06-2026 14-34-11]-In-memory artist component projection loaded at startup.
[INFO]-[10-06-2026 14-34-20]-CLAP index loaded from database with 173989 items.
[INFO]-[10-06-2026 14-34-20]-CLAP text cache loaded from persisted index.
[INFO]-[10-06-2026 14-34-20]-CLAP text search cache loaded at startup (embeddings only).
[INFO]-[10-06-2026 14-34-20]-CLAP model will lazy-load on first text search (~1-2s delay, saves 3GB RAM).
[INFO]-[10-06-2026 14-34-20]-Ensured text_search_queries table exists
[INFO]-[10-06-2026 14-34-20]-Loaded 50 top queries from database
[INFO]-[10-06-2026 14-34-20]-Loaded top queries from database (defaults).
[INFO]-[10-06-2026 14-34-30]-Lyrics index loaded from database with 173989 items.
[INFO]-[10-06-2026 14-34-37]-Lyrics axes index loaded from database with 173989 items.
[INFO]-[10-06-2026 14-34-37]-Lyrics search cache loaded at startup (voyager index + axis matrix).
[INFO]-[10-06-2026 14-34-51]-SemGrove index loaded: 173989 items, dim=968.
[INFO]-[10-06-2026 14-34-51]-SemGrove merged index loaded at startup.
[INFO]-[10-06-2026 14-34-51]-Starting background map JSON cache build.
[INFO]-[10-06-2026 14-34-51]-Building map JSON cache (this reads the DB once).
[INFO]-[10-06-2026 14-34-51]-API request: GET /api/active_tasks
[INFO]-[10-06-2026 14-34-51]-API request: GET /api/dashboard/summary
[INFO]-[10-06-2026 14-34-51]-Background thread started. Listening for Voyager index reloads on Redis channel 'index-updates'.
[INFO]-[10-06-2026 14-34-51]-API request: GET /api/active_tasks
[INFO]-[10-06-2026 14-34-51]-API request: GET /api/active_tasks

---

...and btw. i haven´t deleted the lyrion db just for fun. it was a needed task after a simple compose stack down - pull new lyrion container image - compose stack up.
After this lyrion came back up and complained about a corrupt db. For whatever reason, but this fragility would need a re analyzing of 170.000 songs. That is not feasable.

[mamema]

First i want to say, that you are the developer, so you are defining the requirements.
if you need the md5url field an the api doesn´t provide it, then you can say: "bind mount the music share"
or "run this script first as a lyrion user to extract the field and copy the resulting file to this share"

To my problem:
I did the migrate,analyse,clean tasks again, all came back as success, no orphan files in the cleaning.
Then i made a playlist with the similar song menu. the problem with this playlist is that it is full
of non instrumental, non piano, but male or female singer with a various of genres.
This wasn´t the case with the original run after the first successfull analysis and before the provider migration.
This was a playlist with 100% instrumental and smooth mood songs.

Unfortunately i haven´t saved the playlist which was good within audiomuse-ai back then
This was the one which was generated before i made a provider migration and this was the one
which generated different songs on lyrion side.
Off course i have audiomuse db backups, but i am not sure how to use them to show you
the good working playlist

Run with current migratred,cleaned db, where the attached log files belong to:

---

1. Limbo
   Ludovico Einaudi
   Album: Echoes - The Einaudi Collection
   jazz
   Happy
   Relaxed
   0.0563
2. Morning Glory Jam
   Lee Ritenour & Larry Carlton
   Album: Dreamcatcher [24 Bit]
   pop
   Happy
   Relaxed
   0.0666
3. Barbiturik Blues
   Laurent Garnier
   Album: The Cloud Making Machine
   pop
   Happy
   Relaxed
   0.0857
4. Stealing Your Shine
   Cæcilie Norby
   Album: Earthenya [24 Bit]
   electronic
   Happy
   Relaxed
   0.0882
5. The Duisburg Blues
   The Blues Band
   Album: Fat City
   pop
   Happy
   Relaxed
   0.0896
6. Been a Long Time (Waiting on Love)
   The Black Crowes
   Album: Before the Frost...
   pop
   Happy
   Relaxed
   0.0750
7. Due Tramonti
   Ludovico Einaudi
   Album: Eden Roc [24 Bit]
   jazz
   Happy
   Relaxed
   0.0747
8. Life Goes on: and Then One Day
   Carla Bley ⁄ Andy Sheppard ⁄ Steve Swallow ⁄ Billy Drummond
   Album: Life Goes on [24 Bit]
   jazz
   Happy
   Relaxed
   0.0859
9. Then She Threw Me Like a Hand Grenade
   Matthew Ryan
   Album: Boxers
   jazz
   Happy
   Relaxed
   0.0960
10. Don't Stop 'Til You Get Enough
    Michael Jackson
    Album: The All Time Greatest Songs - 03 - R&B [24 Bit]
    pop
    Happy
    Relaxed
    0.0803
11. Let The Good Times Roll (S. Thread-F.Moore)
    Ludwig Seuss Band
    Album: Live Im Lustspielhaus
    indie
    Happy
    Relaxed
    0.0922
12. I Hear You Paint Houses
    Robbie Robertson & The Red Road Ensemble
    Album: Sinematic [24 Bit]
    pop
    Happy
    Relaxed
    0.0872
13. Lovesick (Underdog remix)
    Lisa Germano
    Album: DJ-Kicks: Kid Loco
    jazz
    Happy
    Relaxed
    0.1047
14. Everything Happens To Me
    Arne Domnérus
    Album: Jazz at the Pawnshop 30th Anniversary [SACD] (Binaural)
    indie
    Happy
    Relaxed
    0.0795
15. Goldberg Variations- BWV 988: Variatio 19. A 1 Clav.
    Johann Sebastian Bach
    Album: Bach, J.S.: Goldberg Variations, BWV 988 (Binaural)
    indie
    Happy
    Relaxed
    0.1022
16. Lady Madonna
    Tok Tok Tok feat․ NDR Pops Orchestra
    Album: Revolution 69
    indie
    Happy
    Relaxed
    0.0986
17. Blue Bayou
    Linda Ronstadt & Kermit the Frog
    Album: The All Time Greatest Songs - 04 - Country [24 Bit]
    jazz
    Happy
    Relaxed
    0.0892
18. Free Dom
    Dominique Fils-Aimé
    Album: Stay Tuned! [24 Bit]
    jazz
    Happy
    Relaxed
    0.1027
19. Hold Me
    Fleetwood Mac
    Album: Mirage [24 Bit]
    jazz
    Happy
    Relaxed
    0.1006
20. Maybe
    Aṣa
    Album: Beautiful Imperfection
    pop
    Happy
    Relaxed
    0.0974
21. The Stolen Child (Vocal Demo)
    The Waterboys
    Album: Fisherman's Box
    pop
    Happy
    Relaxed
    0.0742
22. There Will Never Be Another You
    Lester Young
    Album: The Complete Lester Young Studio Sessions on Verve
    pop
    Happy
    Relaxed
    0.0906
23. Beautiful Stranger (Live at The Symphony)
    Laufey with the Iceland Symphony Orchestra
    Album: A Night At The Symphony [24 Bit]
    pop
    Happy
    Relaxed
    0.0847
24. Så Vandra Vi
    Kraja
    Album: Brusand Hav
    jazz
    Happy
    Relaxed
    0.0901
25. Summerbreeze
    Emilíana Torrini
    Album: Love In The Time Of Science

---

_audiomuse-ai-worker8.log
_audiomuse-ai-worker7.log
_audiomuse-ai-worker6.log
_audiomuse-ai-worker5.log
audiomuse_worker4.log
audiomuse_worker3.log
audiomuse_worker2.log
audiomuse_worker1.log
audiomuse_flask.log

[NeptuneHub]

Look Provider Migration MUST work in your case, if not work we will fix.

You gave me the log after running all this action in sequence?

• provider migration
• new analysis
• final cleaning
• song similarity

Because to me seems truncatred. And to be even more clear, in 8 worker log I didn't see any of them rebuilding the index, I also didn't see in the flask container reloading the index. That is exactly what bring to "use the old index and return wrong value".

Please drop down 7 worker and keep only 1 or we become crazy today. Replicate the procedure with ONLY 1 worker then attach the log of the Flask and of the 1 worker from the beginning. No truncation. Full log.

Here or you truncated the log, or the index is not rebuiling at all for same strange reason.

[mamema]

I just can do a docker logs container-name > filename.log
If this produces truncated logs, please tell me what to do instead?
I‘m using portainer btw.

i was trying to restore an earlier version of an backup. Sql file is 1.5 gb large. Should contain 170.000 ish files, but i only see 13568. is there an additional task needed after a restore?

[NeptuneHub]

Unulky I'm not an expert of portainer.
Anyway droping down 7 out of 8 worker.
Restart 1 flask and 1 worked so you start with clean log.
Redo all the step.

export the log with: docker logs container-name > filename.log 2>&1

Meanwhile you do this, look if for any case container crash, restart, you have any spike of ram or cpu.

Just for completeness which HW are you using? have you enough ram, a recent cpu and an NVME SSD? Ok that before it was working, now it should still working, but just to know.

[NeptuneHub]

1.5GB file if you have also the lyrics embbeding analyzed, is not a complete backup.
I have around 180k song, with lyrics and is around 7-8 GB,

[mamema]

Sorry the 1.5 gb size is the zipped size. The flask and worker container run on a 32 cpu server with 320 gb ram and a rtx 3060. docker and db is on ssd.
My question remain. I restore a sql backup and then? Now i have 13.568 files. I need to get back to the 170.000 files because without this step the whole testing is useless

[mamema]

Sorry, i´m on GMT+1 (Germany). Was sleeping as you created this. But thanks for the offer for a jitsi session

[mamema]

did now several restores (doing automatic daily backups independent of audiomuse. Even the one from yestrerday with 6.8 gb does oinly show 14000 files. so additionally to my mentioned issue, restores are not working

[mamema]

I‘ve seen that with the 2.1.5 release the postgres version changed from 17 to 15. i‘m centrally running 15. Were my backup/restore problem coming from this version mismatch?

[NeptuneHub]

In the release was changed only a deployment example related to quadrlet, so the only affected user are who use quadrlet.
The error is that you can backup or restore with postgress client 16 a version 17. So it totally block at the backup creation.
So in short I don't think it will affect you.

I also don't know how is possible that a dump restore only "some song". In the flask container when you run a a restore or a backup you should have the log in /app/backup. You can check and look if there is any error that explain this.

[mamema]

reanalyzing everything because of the lyrion delete db issue. will report back as soon this is finished

[mamema]

another interesting observation.
This night 2 AM, Lyrion stopped responding. I assume this is because of the requests from audiomuse, as i didn´t had this before.
Audiomuse itself doesn´t show this in the web ui. there everything looks normal except the finished song count stayed the same.
So, i had to look into the docker logs and there were a lot of python errors.
Then i had to restart lyrion and it came back up with an error missing the fulltext table and made a rescan:

[26-06-13 10:59:33.3107] Slim::Utils::Scanner::Local::rescan (180) Discovering audio files in /music
[26-06-13 11:00:28.6458] Slim::Utils::Scanner::Local::ANON (192) Start processing found tracks
[26-06-13 11:00:28.6460] Slim::Utils::Scanner::Local::ANON (200) Connect do DB
[26-06-13 11:00:28.6461] Slim::Utils::Scanner::Local::ANON (203) Get latest ID
[26-06-13 11:00:28.6462] Slim::Utils::Scanner::Local::ANON (228) Build temporary table for deleted tracks
[26-06-13 11:00:28.6465] Slim::Utils::Scanner::Local::ANON (249) Build temporary table for new tracks
[26-06-13 11:00:28.8939] Slim::Utils::Scanner::Local::ANON (269) Build temporary table for changed tracks
[26-06-13 11:00:28.9744] Slim::Utils::Scanner::Local::ANON (292) Get deleted tracks count
[26-06-13 11:00:28.9746] Slim::Utils::Scanner::Local::ANON (299) Get new tracks count
[26-06-13 11:00:28.9762] Slim::Utils::Scanner::Local::ANON (304) Get changed tracks count
[26-06-13 11:00:28.9764] Slim::Utils::Scanner::Local::deleteTracks (407) Removing deleted audio files (0)
[26-06-13 11:00:28.9765] Slim::Utils::Scanner::Local::updateTracks (574) Rescanning changed audio files (0)
[26-06-13 11:00:28.9767] Slim::Utils::Scanner::Local::addTracks (490) Scanning new audio files (176221)

what i now do not know, is this a normal rescan or is it a full rescanb, so my id values got mixed up again

[NeptuneHub]

This is already being handled in the Lyrion issue you opened.

Please continue the discussion there, as this is not something Audio Muse-AI can fix or influence.

Audio Muse-AI only consumes the server behavior; it does not control it. What we have in our control is Provider Migration that should already work.

In case you want to share specific feedback on Provider Migration please open an issue compiling all the needed info especially clear and complete logs. Thanks.

[mamema]

haven´t opened an issue on lyrion github. What do you mean?

[NeptuneHub]

I opened one for you few days ago: LMS-Community/slimserver#1590

[github-actions[bot]]

Your discussion has its answer now, so if you like AudioMuse-AI and want to improve self-hosted music, why not consider giving us a star here on GitHub? It helps the project grow!