My MM4 db has become upgraded to MM5 somehow? [#16718]

[Barry4679]

MM5 shouldn't contain the DBName until you added it manually ?
Tracked as https://www.ventismedia.com/mantis/view.php?id=16718

I would have told you if I had altered the ini.
No, I did not alter the ini.
I installed MM5 into a new empty directory.
I just ran the install program from Rusty's forum post for the new version. ... And then used MM5 as already described.

[Barry4679]

I have a snapshot after the install, and before MM5 ever ran here ... remember I deselected the Run MM5 Now option in the installer
At that point the ini was:
[Portable]
IsPortable=1

And then when i came back I opened MM5, using the shortcut shown in previous post.

• It offered to import settings and data from MM4 ... I accepted

• It build the MM5.db in its \portable directory

• It all looked ok, I set my usual MM5 options, and then closed MM5

• I took another snapshot ... this is my normal routine

Looking at that snapshot I can see that the ini file grew from 1 to 23kb, and it included these lines
[System]
DBName=D:\Music Databases\MM.db

So it was all stuffed up before I did any of the other things described in my last post ... ie. before playing with LFM settings, and before add more music via Fil|AddScan option, etc

The file damage happened when I opened MM5, for the 2nd time, the next day ... it opened the MM4 db, and converted that also.

I think that you will find that the bug is triggered by not accepting the Start now option in the installer.

[Barry4679]

Ludek, you need to take this issue more seriously than you appear to be.

You should consider pulling MM5 version 2256. I think that is damaging tester's MM4 databases, by upgrading them to 5.0.5x.

I just installed MM5 again, and it did the same thing.

This time I allowed the installer to start MM5, so unchecking that checkbox is not the trigger.

The problem appears to be this bug, that you have fixed for the next version of MM5.

It is crashing MM5 during the 1st run ,,, and I am guessing the crash happens after it has copied the MM4 ini file into /Portable, but before it has updated it for MM5.

This means that when the user restarts MM5, it uses the MM4 database, because the ini file appears to contains what you imported from MM4, ie. in the case of anybody with a MM4 custom database location, there is this:
[System]
DBName=D:\Music Databases\MM.db

[PetrCBR]

It will be fixed in next build.

[Barry4679]

It will be fixed in next build.

Petr, some feedback regarding your responses.

Your minimalist responses make it difficult to have much confidence that you have understood what has been reported. Could you at least include a link to Mantis tracking of issues?

I am sensitive to this issue because it has damaged my MM4 database (again!), and it has been difficult to get any proper buy-in from MM, or understanding of what I am reporting, in this thread regarding this issue.

There is a saying about injury one receives:
The 1st time it should be seen as an accident.
The 2nd time is could be seen as a coincidence.
But the 3rd time it should be seen as negligence.

This is the 3rd time that this bug, or one very like it, has damaged my MM4 database, when I should be protected by using MM5 beta in portable mode.

I reported the bug for the 1st time in February 2017 here, where you reported it as fixed.

I am sure that you appreciate that it is not much fun having to recovery your production database from backup. This time I needed to restore to the 5th of June.

And I don't understand why you seem to care so little about people's databases, that you don't pull the most current version of MM5. Surely if will screw up MM4 databases for anybody who has that database in a custom location?

[Lowlander]

https://www.ventismedia.com/mantis/view.php?id=16718

[Barry4679]

https://www.ventismedia.com/mantis/view.php?id=16718

Thanks for the link. I hadn't seen Peke's latest post there.

That report does not seem to address all issues.

My major issue would be why the following is not constricting MM5 to its /portable sandbox? I don't see that addressed in the Mantis report.
[Portable]
IsPortable=1

Also the report seems to suggest that the last remaining issue is that MM4->MM5 conversion could lose the custom configuration option for database location.

My concern is customer database safety. MM5 should not be allowed to update, in place, a MM4 database ... ever! ... And specifically there needs to be protection against a half completed MM4 ini file importation, from allowing MM5 to update the MM4 database ... ie. the conversion routine should import the MM4 ini file using a temp file name, and then rename it to MediaMonkey.ini, only after it has been made safe.

[Peke]

Hi,
in 2257 Custom MM4 DB file is not touched at all. MM5 creates new library in it default paths on import. It dosn't matter if MM5 is installed as portable or not.

Future handling of custom paths to library is under discussion as MM5 handles things bit different.

[Barry4679]

in 2257 Custom MM4 DB file is not touched at all. MM5 creates new library in it default paths on import. It dosn't matter if MM5 is installed as portable or not.

OK Peke, effectively you say "trust me".

I do, but since you have burnt me three times now, I will backup my MM4 db before touching any MM5 beta again, and would recommend that anyone else do the same.

I have looked further back, and now see that this was a sloppy "accident" just waiting to happen. ... ie from 2017:


In response to:

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?

and the 8 word "trust me" response at that time was:

Currently database from portable folder is always used.

I think that I am done venting ... this would have been a very much shorter thread if MM Devs:

• pulled v2256 when it became clear that was capable of damaging a production database ... ie. any slash and burn testing was updating the MM4 db, and the MM4 database was being screwed up by being updated to MM5 format ... I see that it has been replaced with an out-of-cycle fix today

• actually accepted, or responded, to criticism

• and when they let their volunteer testers down, an apology would go a long way

[krudyp]

It's beta software and comes with a warning to backup your files. The whole point of testing out the software is to find these types of bugs.

[Barry4679]

It's beta software and comes with a warning to backup your files. The whole point of testing out the software is to find these types of bugs.

Hi,

I don't disagree. I am not complaining about the bug. Just the lack of response to suggestions and criticism. .
eg. I asked multiple times, without answer, asking them to take that version down, once it was clear that it was capable of damaging customer data.

And btw I do backup any tracks that I am about to alter with MM5 tests. But who knew that you had to backup your whole PC to be safe when testing MM5? .. ie. it reached out of its Portable sandbox, and updated a file from another application, in a different disk drive.

[Peke]

Hi,
Sorry you can read all at https://www.ventismedia.com/mantis/view.php?id=16718 it was feature that was not ported to MM5 till recently and when we ported it we missed that for custom DBName MM5 should create new file instead of using old MM4 one (eg. upgrade as you noticed the hard way).

It is fixed and now MM5 2257 do not do that but rather create MM5.DB. Further to be improved in 2258. So not trust me, but tested.

If I missed something in past please remind me and I shall try to fix mistakes.

[Barry4679]

It will be fixed in next build.

And what about the build after that one?
I have just installed it (5.0.0.2259), and it has corrupted my MM4 database again.
Petr, this is a really sad thing to witness. I am beyond words.

Observations:
1. I installed MM5 in portable mode. ... What is the definition of "portable mode"? .. I was expecting that MM would be entirely installed in the directory that I supplied, ie. including the database. ... When I started MM5 I it allowed to import data and settings from MM4. ... This seems to have overridden my request for a portable install, because it build the MM5 database outside of the directory that I nominated. ... This is unexpected. ... My MM4 installation has a custom database location. But If I then request a portable install, you shouldn't silently override that request ... agree?

2. After MM5 had started, and before I used it for anything, I closed MM5, and backed up the database that it had built (this was when I noticed it was in unexpected location) ... Then I started MM5 again ... and it flashed up the dbox saying that the db was being upgraded, ... no option to no say No ... Since the MM5 db was already built at version 5, previous experiences have taught me that you had just corrupted my MM4 database for the 4th time, with pretty much the same bug. ... I opened MM4, and this dbox message confirms it ... strange thing to note is that you have taken it just to 5.0.19 this time ... the last time you took it to 5.0.51 .. ?

I restored my MM4 db to a version from 2 days ago, and the problem is repaired.

[PetrCBR]

Even in portable mode you can define custom DB location and when you've choosed to import settings from MM4, custom DB location was imported as well.
MM should copy your MM4 database to new MM5.DB name and update ini entry for DBName so it looks like for any reason ini wasn't updated with new DBName and need to figure out why it wasn't get updated.

[PetrCBR]

I've added code to always use MM5.DB even when different name is defined in INI file to be sure MM4 database isn't used in case INI file is not updated after data import.