MediaMonkey forum

I am running 5.0.0.260

It offers to import my db from MM4. I agree. It then gets an exception during the import (details sent to you: AFCFEA7D, also see below).

A windows pop up offering to start MM in "safe mode"

I agreed; pressed Restart

At this point the MM5 ini file (in C:\MediaMonkey 5\Portable) is left pointing to the production MM4 database, So any testing done with MM5 now affects the MM4 database.

MM4 gets upset. Lots of Errors: "Cannot load query data: Could not find condition ID: 46"

Exception:
-----------------------------------------------------------
2.1 Date : Mon, 6 Feb 2017 16:54:10 +1000
2.2 Address : 0052D754
2.3 Module Name : MediaMonkeyEngine.exe - (MediaMonkey)
2.4 Module Version: 5.0.0.2060
2.5 Type : EInOutError
2.6 Message : The specified file already exists.
2.7 ID : AFCFEA7D
2.8 Count : 1
2.9 Status : New
2.10 Note :
2.11 Sent : 0

Thanks. There are actually 2 issues ... added as 13985 and 13986.

Good, thanks for the confirmation.

Any advice how to repair my MM4 db?

I get an error dbox, with the error message mentioned in my 1st post. It happens 8 times every time I start MM4. Also once every time that I change nodes, or re-sort a grid. MM pauses until each dbox is responded to ... so it is fairly annoying.

This situation also happened to me last week, but I didn't expect any MM5 involvement at that point. I googled it, and concluded that had caught a dose of db corruption ... Before I could attend it it, the problem just went away.

When I noticed that my MM5 tests were affecting my production db I concluded that MM5 was involved. I re-initialised MM5 to verify this, causing MM4 to start misbehaving again.

Will the problem go away again ... or do I have try and find whatever affected the repair last time?

Looks like it's related to any condition (in auto-playtlist or collection) ... check them.

PetrCBR wrote:Looks like it's related to any condition (in auto-playtlist or collection) ... check them.

That's it. Thanks.

I remember now that I had to make an alteration to a custom collection that was something like LastPlayed > 900 days AND LastPlayed is Known.

The collection started including unplayed tracks. So I changed the last clause LastPlayed > 1/1/1960.

This fixed the collection, and probably was what fixed the damage done by MM5 (or maybe it was fixed just by altering a collection specification)

I have altered the collection again, and the problem is gone again.

This seems to mean that MM5 db is not backwards compatible to MM4 as you asserted in a post elsewhere?

Is there some change in the handling of null dates, or in the expression "not known"? ... ie why did the MM4 database collection contents change after the db had been acted on by MM5?

Hi, you seem to be true, the condition ID: 46 is MM5 only, it is a new condition for "Date" format that was previously threated as integer in MM4.
So you are true that adding this condition by MM5 to an auto-playlist causes the auto-playlist be unreadable by MM4.

Ludek wrote:Hi, you seem to be true, the condition ID: 46 is MM5 only, it is a new condition for "Date" format that was previously threated as integer in MM4.
So you are true that adding this condition by MM5 to an auto-playlist causes the auto-playlist be unreadable by MM4.

Thanks, I guess that you may be correct, but that's not as I remember it.

IIRC what happened was:
* the index was created and functional in MM4 ... it was created years ago, hasn't been altered since
* I opened and updated the MM4 db in MM5 unknowingly, due to the bug in the MM5 alpha ... nothing to do with the index .. I just added a few more tracks using MM5 I think
* the index, in MM4, suddenly started returning unexpected tracks (ie. tracks which had never been played) ... MM4 also got the annoying error 46 error dbox ... I didn't connect these 2 events at the time ... but I started to think that MM5 had some impact on MM4 dlls or something
* I changed the index specification using MM4 ... away from "IS NOT NULL" to "IS > 1/1/1960" ... this fixed the index ... and also seems to have fixed the error dbox problem ... again I didn't recognise the connection, as I was doing a lot of things to try and resolve the problem (ie. db re-orgs ... opening MM4 and opening MM5 at the same time ... then closing MM5 cleanly, then closing MM5 (as I was having quite of few situations where MM5 hung, and had to be killed off by the Task Manage)r, etc etc)

If this the above sequence is correct, the error wasn't created by a change that I made in MM5 ... it was caused by MM5 opening and updating the MM4 db.

Barry4679 wrote:MM4 also got the annoying error 46 error dbox

This means that you run MM5 database within MM4. The auto-playlist condition for date format was created in MM5 (or the auto-playlist edited in MM5?) so you are right that in this area the DB is no longer backward compatible. I will look what can I do about it.

But your issue was caused by http://www.ventismedia.com/mantis/view.php?id=13986 , i.e. instead of copying your MM4 production DB to MM5/Portable/ it started to use MM4 DB instead. i.e. the database was shared (which was the serions bug fixed as #13986 by Petr)

PetrCBR wrote:Thanks. There are actually 2 issues ... added as 13985 and 13986.

I confirm that the issues that I reported are fixed in alpha release 2061.

There is a potential point of confusion though.

The MM4 db and MM4 configuration are now imported into C:\MediaMonkey\Portable\
And updates made with MM5 now update just that MM5 database copy.

But the imported MM ini file (C:\MediaMonkey\Portable\MediaMonkey.ini) retains my MM4 database location override pointing to my MM4 database, ie.
[System]
DBName=D:\xxxxx

I'm not sure why this isn't confusing MM5, but it would be confusing to anyone looking at the ini file wouldn't it?

Does an db location entry in the ini file get ignored in the Portable directory if there is also a copy of MM.db in that directory?

Currently database from portable folder is always used.