Kodi Community Forum

Full Version: MySQL Music database empty after migration
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi all

I have a problem, all media files are on a nas as follow:
nas//tv show

So no problem with tv show and movie, but when I add music, kodi start to scan library and it found all artists/albums/songs,
but after that the library is always empty.

Please, help me to solve the issue.

THX Wink
When you say it "found all artists/albums/songs" I assume that you can see them in file view. Then you say "but after that the library is always empty".

1) Are your music files tagged. The music lib is based on the tag data within the music files that gives arrtyist, title album etc.

2) Did you answer "yes" when prompted "Do you want to scan this source into your music library" when adding the source? If unsure then select "scan to libray" from the context menu when on that source.

If neither of those solve the issue, then I will need a debug log of an attempt to scan that music source. Please upload to a paste bin and post link here.
Hi DaveBlake

1- yes music is tagged
2- yes scannded

see pictures

during scan

view file


hoping the log is ok.
thank you
Forgive the basic nature of my first questions, but sometimes the obvious is the answer. The log that you sent was not quite what I expected, it is a cash log from 22nd Dec rather than a recent debug log, but it was very helpful. Smile

When you upgraded from Jarvis to Krypton, the migration of the music database failed leaving you with a quietly broken db. It is something Kodi needs to handle more gracefully, and I am working on that. Meanwhile the work around for you is to delete all MyMusicXX,db files from your userdata/database folder, restart Kodi (that will create a new db file) and rescan your music source. Then all should be well.

EDIT: Ah sorry, you have MySQL db. You will need to delete the MyMusicXX schemas from your server, with MySQL they are not separate files and you will need to use something like PHP, MySql Workbench or Heidi to do this. I can look out more detailed instructions should you need them.
Yes, i have a MySql.db as follow


must I to delete the selected files using phpMyAdmin or I need another software?

maybe the first database N°52 is fine and can i save it?

YES I need more instructions Big Grin
Actually you could simply rename them, so they are there to go back to (although I don't think you will need too), but Kodi will start with a new empty music database.

Instructions for renaming MySQL databases using PHPMyAdmin are here https://www.a2hosting.com/kb/developer-c...l-database, but Google will find more, maybe even in your native language.

Rename all the kodnas-musicXX databases to something else.

In migrating 59 to 60 an index error occurs because more than 1 record in the artist table has the same Musicbrainz ID. This is odd, as the same index exists in 59 database, so there should not be any repeated data. It could be interesting to know if migration from earlier versions works, say from 56 (Jarvis) or 52 (Isengard), but I do not want to put you though that. Also to get the benefits of Krypton you will need to fully rescan your music files anyway, hence you may as well start with an empty library.

But it could be useful for me if you can export 59 (before or after rename) and put it on the cloud somewhere for me to download and analyse. How to export is here https://mediatemple.net/community/produc...-databases

I hope that is all clear for you.
hoping is helful

i found this videotutorial on Youtube

so, just rename all music database and rescan library from kodi, correct?

EDIT: i have this error when i try to rename a database

maybe is better if i delete them.. or not?
Thansk you for 59, I like to understand issues like this when they happen.

Yes, Kodi off. Rename all music database. Kodi on and rescan library from files view, context menu on music source "Rescan to library". Let me know how you get on.
see above
Oh dear it is fighting us! Not sure why it is complaining about a table not existing (my guess at the Italian). There is not much to be gained from most of the old data. Perhaps export 52 and 56 as you did 59 just in case, and then delete them all - if it will let you.

The strange thing is I was able to successfully migrate the 59 data you sent to 60, so I have no idea what caused the issue. If you have not already deleted everything before reading this you could try just deleting 60 and see if it is succesfull this time. But not to worry if it is too late. As I said before you need to rescan your music files anyway to get the advantage of v17.
Thank you Daveblake, problem solved.
Good. Enjoy Krypton Smile

Some notes for myself over this:

Log showed
NOTICE: Attempting to update the database music60 from version 59 to 60
ERROR: SQL: [music60] Undefined MySQL error: Code (1062)
Query: CREAT_E UNIQUE INDEX idxArtist1 ON artist(strMusicBrainzArtistID(36))

This kind of migration failure seems to be a random MySQL quirk. It is discussed on https://github.com/xbmc/xbmc/pull/11530, where it happended to another user. He thought that the index definition was the issue

CREAT_E UNIQUE INDEX idxArtist1 ON artist(strMusicBrainzArtistID(36)

But this unique index has existsed on the artist table since Frodo, db version 32, when Mbids were added to the schema. It will prevent any records being inserted or the artist table updated in any way that violates it. Hence the data should cause any problems when the same index is created in the new db after migration.

The actual error was
ERROR 1062 (23000): Duplicate entry 'NULL' for key 'idxArtist1'
this says that MySQL is rejecting a repeated NULL, not some duplicated mbid, and yet it normally allows unique indexes to have NULL values. This is very common in the artist table. Changing the index to 255 would not have avoided rejection of duplicate NULL.

The only mention I could find on Google was that a few other applications had MySQL randomly complain about duplicate NULLs, but all were fine on retry. The suggestion is db corruption of some kind solved by export, recreate, and import. That would explain why having imported it I could migrate from Hetfiled's 59 without any problem.

The index on MySQL will not allow with both aaf09f31-bb5c-43e5-9f54-bb6554c33a71 and aaf09f31-bb5c-43e5-9f54-bb6554c33a71/2a5b713c-839e-4392-b344-59829ec77613 to exist as the first 36 chars are the same (the example given on the aborted PR). But it is worth noting that SQLite does not support length parameters on indexes, so a SQLite db will allow those records to coexist, but equally they would not violate the creation of analytics on migration to a new db schema. Need to make this more consistent - either limit the field length varchar(36) not TEXT, and/or ensure that any programatic comparisons use 36 char.

We do need to see if we can change things in v18 so that the failed migration is more obvious.