by lizardo » Wed Dec 28, 2011 2:51 pm
OK, I believe you. I checked, and I did have Scan on Startup set to On. However: a) that doesn't answer my concerrn/complaint, b) it raises more questions, c) it doesn't answer my question about the "new version" notification, and d) it doesn't address the larger behavioral issue.
Namely: Even if MM does start a scan (because of the user's settings with the previously installed version), why should that erase some of the info in the database?
What seems logical (to me) is that MM would first check for a MM.db file. If it finds one, it would be smart enough to say, "OK, this user has a db, let's not screw with that"; if it does not find an existing db, then it would say (to itself), "OK, this user has no db, so we can set all 'Added' values to 'Today.'"
In other words, if there's a db on the computer, why in the holy heck would MM overwrite any values in that db? If it finds new tracks, great, add them; but don't mess with the existing info for existing tracks.
At an absolute minimum, if a scan is going to overwrite info in the db, the user should be warned that it's going to happen before it does.
The new question related to this:
If I understand you correctly, if I had not had Scan on Startup set to On, then MM would not have scanned when the install was complete. Fine. But what if I had initiated a new scan 5 minutes later, via the Ins key? Would my existing values (e.g., Date Added) have been overwritten in that case?
If your answer is No, then why is that scan different than the Automatic scan?
If your answer is Yes, then see my previous paragraphs: What's the logic for overwriting *anything*, if a MM.db file already exists?
Finally, you did not address my question as to why I was alerted to an available update, when in fact I'd just installed that version.
Look, I'm not trying to pick a fight -- I'm just trying to offer a (frustrated) user's perspective as to how the update process could (imho) be improved.
OK, I believe you. I checked, and I did have Scan on Startup set to On. However: a) that doesn't answer my concerrn/complaint, b) it raises more questions, c) it doesn't answer my question about the "new version" notification, and d) it doesn't address the larger behavioral issue.
Namely: Even if MM does start a scan (because of the user's settings with the previously installed version), why should that erase some of the info in the database?
What seems logical (to me) is that MM would first check for a MM.db file. If it finds one, it would be smart enough to say, "OK, this user has a db, let's not screw with that"; if it does not find an existing db, then it would say (to itself), "OK, this user has no db, so we can set all 'Added' values to 'Today.'"
In other words, if there's a db on the computer, why in the holy heck would MM overwrite any values in that db? If it finds new tracks, great, add them; but don't mess with the existing info for existing tracks.
At an absolute minimum, if a scan is going to overwrite info in the db, the user should be warned that it's going to happen before it does.
The new question related to this:
If I understand you correctly, if I had not had Scan on Startup set to On, then MM would not have scanned when the install was complete. Fine. But what if I had initiated a new scan 5 minutes later, via the Ins key? Would my existing values (e.g., Date Added) have been overwritten in that case?
If your answer is No, then why is that scan different than the Automatic scan?
If your answer is Yes, then see my previous paragraphs: What's the logic for overwriting *anything*, if a MM.db file already exists?
Finally, you did not address my question as to why I was alerted to an available update, when in fact I'd just installed that version.
Look, I'm not trying to pick a fight -- I'm just trying to offer a (frustrated) user's perspective as to how the update process could (imho) be improved.