Restore/Synchronize Database 3.1.2 (2013-08-31) [MM3+]

[Rojer]

It seems my backup db is corrupted in a way that make the script fail at Playlists import.

I removed all scripts but this one and tried to maintain backup db. Same error message : "vacuum etc." Fresh db maintains just fine.

The restore process seems to fail at playlists import with message (in french, translation is mine):

Code: Select all

"Problem in database query:
Error executing SQL "SELECT GROUP_concat'Dstlists.ID) from backujpDb.Lists INNER JOIN LISTS as DstLists.Textdata=DstLists.Textdata WHERE Srclists.IdListType = 3 AND SrcList.ID IN (Occasion)
" :No such column:Occasion (1,1)

Occasion is not a custom Field. I build AutoPlaylists with the "occasion" field (as a mean to setup relevant sets for my live gig.

Importing everything but autoplaylists returns:

Code: Select all

Error executing SQL "SELECT Songs.*
From Songs
WHERE INSERT Into Filters (Pos, Name, Cond, View, Player, ContentType) SELECT 11, SrcFilters.Name, Cond, View, Player, COntentType FROM BAckupDB.Filters AS SrcFilters WHERE SrcFilters.Name = "Evalué" GROUP BY SrcFilters.NameID 5SELECT SongsID FROM DBSync
": near "INSERT" Syntax error (1,1)

"Evalué" is a filter I created yesterday and is not linked to db corruption. Interesting that it would the last created filter though. Next error message reports "Line 2170, column 12".

Running import without filters... Success, Import in 13.42 seconds (I'm impressed)
Full maintenance passes, which is a relief. restoring Magic Nodes: OK.
What I Should have now is a healthy Db without autoplaylists or filters.
Only, filters show just fine. And some AutoPlaylists are there. Will recreate the rest manually.

I'm more than happy with the process : db now passes maintenance and I have recovered most of my data.

As for the impressive performance (have no idea how such speed can happen), it probably should be noted that MM runs with the SQLiteSafety=0 switch and both db's sit on a ram disk. Computer is a core i7 with Xp Sp3.

I would welcome any input on what might have happened. I'm willing to start over if you're interested in detailed debugging. using custom fields along with "occasion", "mood" and other fields in both autoplaylists and filters probably has something to do with the errors.

[testfinger]

Last year I accidentally deleted my Disc # off everything. I have an old database with this information.
I tried to import but it only matched 9 tracks that were in a different folder outside the main music folder.
I have tried to auto organise all my tracks so they have a similar path to the old database but I can not get any matches.
Any idea what I am doing wrong?

[ZvezdanD]

The restore process seems to fail at playlists import

Thank you for the report and cooperation with the database file. There is the new release, v3.1.1 - 2012-05-31:
* Fixed: error on restoring auto-playlists with the condition: Tempo/Mood/Occasion/Quality "is" ... (broken since v3.0);
* Fixed: error with Update tags in files too.

[flippertie]

Just want to say - Thanks for this script!

I'm in the process of moving from an XP box running MM 4.0 to win7 running MM4.1 portable so I can sync with my phone. At one point I found myself with 3 installations all with different histories - and was worried I was going to lose the data from 2 of them.

Then i found this and (so far) it all seems to have synced and merged without any problem

[ZvezdanD]

There is the new update, v3.1.2 - 2013-08-31:
* Fixed: error when restoring both Static and AutoPlaylists with Clear Playlists option turned on, if backup DB is from MM 4.0 and current DB is from MM 4.1 or vice versa;
* Fixed: finding of matched tracks in some cases.

[wutzin]

Hi,

thanks for this wonderful script! It has saved my ass millions of time and helped me preserved info in my MM db I spent hundreds of hours on...
I mostly use it to fix corrupted databases. I don't know why I get so many corruptions (despite default, ie hightest sql security level) - maybe because MM is running inside a virtual machine.

So my usual process is this:

When I get a corrupted database error, I start a new DB (re-scanning my music folders), then import all the info from the old, corrupted DB.

In the past, your script has done an awesome job at matching tracks from a corrupted DB. However, I had a corrupted DB yesterday and tried the above process with the newest version of your script - and out of my 60k music files, I got ZERO matches...
(even though MM can find all the tracks in the corrupted DB - maintaining DB also worked; just on re-scanning a certain folder, MM would complain about malformed DB image).
I then installed the previous version (3.1.1.) and was able to match 58k files and restore the info.

So it seems to me that changes in the last version have dramatically lowered the matching abilities (down to zero out of 60k files, in my case at least).

If my DB files would be of help for de-bugging, let me know. And again, thanks for your script!!!

[ZvezdanD]

So it seems to me that changes in the last version have dramatically lowered the matching abilities (down to zero out of 60k files, in my case at least).

If my DB files would be of help for de-bugging, let me know. And again, thanks for your script!!!

That is interesting, I though that I have fixed a bug when matching tracks with the latest update, not otherwise. Yes, of course it could help if you send your files. Please pack your backup and current database files with Zip and upload that package into some file server like Mediafire, then send me PM with the file link.

[wutzin]

So it seems to me that changes in the last version have dramatically lowered the matching abilities (down to zero out of 60k files, in my case at least).

If my DB files would be of help for de-bugging, let me know. And again, thanks for your script!!!

That is interesting, I though that I have fixed a bug when matching tracks with the latest update, not otherwise. Yes, of course it could help if you send your files. Please pack your backup and current database files with Zip and upload that package into some file server like Mediafire, then send me PM with the file link.

thanks for looking into that! I uploaded my DB and sent you the link as PM...

[ZvezdanD]

thanks for looking into that! I uploaded my DB and sent you the link as PM...

Thanks for the report and databases. Unfortunately, or maybe better said fortunately, I cannot reproduce the problem. I got info saying: External db v4.1: 56904, current db: 55445, matched tracks: 52543

Are you sure that you didn't turn on Restore playhistory/metadata only for tracks in collection or for selected track(s)?

[wutzin]

thanks for looking into that! I uploaded my DB and sent you the link as PM...

Thanks for the report and databases. Unfortunately, or maybe better said fortunately, I cannot reproduce the problem. I got info saying: External db v4.1: 56904, current db: 55445, matched tracks: 52543

Are you sure that you didn't turn on Restore playhistory/metadata only for tracks in collection or for selected track(s)?

Yes, I'm sure I didn't restrict the script only to the selected tracks(s) - but I did run the two versions in two different installs (I run MM inside virtual machines) - I thought they only differed in the version of the scripts, but if you can't reproduce the problem, then something else must have tripped off the matching process... I'm stumped - but glad that it's not the awesome's script's fault!

[ZvezdanD]

I did run the two versions in two different installs (I run MM inside virtual machines) - I thought they only differed in the version of the scripts, but if you can't reproduce the problem, then something else must have tripped off the matching process...

It would be nice if you could find some pattern when this happens, so I could fix the script (if it is the reason of the problem). If you have time, you could try with the two databases that you sent me to see if you will get the same matching as I did.

[mzfckr993]

I tried moving my MM DB to another computer, but I'm running into an issue with playlists. The thing is that on my old pc, I just dropped the mp3 files into my music library folder and MM auto organized them to a folder structure of Artist\Album\xxxx.mp3, however, when I import my old DB with this script, all the songs in my playlists remain gray, because their location is not correct, in fact, it appears as if there had not been any auto organization at all, e.g., the location of songs in playlists under properties shows that they are in the root of my music library folder instead in the auto organized folder structure. In addition, the location of playlists' songs does not show the correct drive letter - in its place is just a "[]".
Basically all of my music files are in C:\Music\Artist\Album\xxxx.mp3, but, in playlists, their location shows up as []\Music\xxxx.mp3.

I tried setting up auto organization in MM preferences in the same structure as they currently are (Artist\Album\xxxx.mp3), but to no avail. I also have tried clearing playlists and filters in the script, but also that did not work.

Could you suggest how could I fix this? Duplicating the same playlists manually for more than 4000 songs would be a nightmare...

EDIT: Accessing the other computer is not possible anymore, because I do not have with me. Also, I wanted to point out that the gray tracks appear in the "Music" section of MM as well, but they are right next to their corresponding non-gray tracks, which are playable, for example:
Song A [grayed out]
Song A
Song B [grayed out]
Song B
and so on...

However, in my playlists, all the tracks are grayed out, unlike the music section.
I hope that this made some sense and that it's possible to correct this. Thanks!

[ZvezdanD]

Here is a general advice to all having problems with this add-on: please pack your backup and current (before import) database files with Zip, upload that archive to some file server like Mediashare and send me a link to it in PM. so I could try to reproduce the problem by myself.

By the way, if all you media files before and after changing of hard drive/computer are different only in their base folders, then you could try my Update Location of Files in Database add-on first. For example, if you had all files in c:\Documents and Settings\My_name\My Music\ (and its dub-folders) and now they are in d:\Music\ (and its sub-folders that has the same hierarchy as before) then you could use the Update Location add-on.

However, if you changed the hierarchy of sub-folders, e.g. if you didn't have the Album sub-folders, but now you have added them, then even this add-on could have troubles. Please read the first post of this thread and you will see which of the conditions should be satisfied if you have files with different paths before and after the upgrade.

And one more advice, if you want to be sure that this add-on will work 100% when you change paths and even if you modify their tags: before you make any modification to the files do generate checksums in the database. This is rather slow process but, as I said, it will reduce problems for transferring data to minimum. Matching of files by their checksums is the most reliable and fastest method for this add-on.

[mzfckr993]

I finally managed to fix the problem after many, many tries. What did I do? Downgraded from MM4 to MM3 and ran this script, it worked instantly and perfectly. I wanted to thank you for this wonderful script!

[chrisjj]

The problem is with Bex's script, and it is manifesting with many static playlists, not only those restored with my script. I suppose that it is not his fault, but the program itself or some another script which is creating playlists using SQL. Here is the explanation if you are interested about it. There is the IsAutoPlaylist field in the Playlists table which has a value of = 1 when a playlist is an auto-playlist, and by default it has a value = NULL if it is not an auto-playlist, but your database and some databases which I got from another users have some static playlists with empty value for IsAutoPlaylist field, i.e. it is not 0, nor NULL. I don't know whose fault is that, but it is not mine, my script doesn't create playlists with such values (except when restoring playlists from databases that already have such values).

Anyway, if you want to enable Bex's script to work even with such databases and since he is busy and hasn't time for the script's update, you could open it in Notepad and replace all occurrences of IsAutoPlaylist=0 to IsAutoPlaylist<>1.

This puzzles me. "Property Get isAutoplaylist As Boolean" so why would anyone test IsAutoPlaylist for a numeric rather than bool?