MediaMonkey forum

nynaevelan wrote:1. Question: I seem to have duplicate filters now based on the ones that are in MM prior to the import,

When have you got duplicate filters, before or after import? The script checks names of the existing filters and imports only those with different names, so it should not be the cause for duplicates.

nynaevelan wrote:would it be possible to have an option where the script clears the filter table prior to the import? Or would it be a best practice to delete the filters prior to the import?

Well, I already though to add the option to clear Filters table before import, but I wouldn't do that because there are some predefined ones made by program itself, and I don't know in advance which ones would be added in the future. You see, there is no any field in the Filters table which is saying that some filter is built-in and that should not be removed. I suppose that it would be a best practice for you to delete the unnecessary filters manually before the import.

nynaevelan wrote:2. Request: When I recreate my new db, MM doesn't always put my videos and audiobooks into the correct 'Type", would it be possible to add an option in the import to change the Type to what the file is in the import db?

I would do that if I think up where to put that option and not to enlarge the dialog box which is already too big in my opinion.

nynaevelan wrote:Or would it be better to make sure the Type is correct before an import??

Who should ensure that the Type is correct? A user or the script?

ZvezdanD wrote:

nynaevelan wrote:1. Question: I seem to have duplicate filters now based on the ones that are in MM prior to the import,

When have you got duplicate filters, before or after import? The script checks names of the existing filters and imports only those with different names, so it should not be the cause for duplicates.

I think the duplicates actually occurred prior to the import, this may be due to MM having the music and audiobook filters hard-coded somewhere in the programming. I assume this is so because I cleared the filters table but when I re-opened MM the two filters were still showing up. But to double-check I am going to go back to my original db and do some cleanup to fix them before trying another import.

ZvezdanD wrote:

nynaevelan wrote:would it be possible to have an option where the script clears the filter table prior to the import? Or would it be a best practice to delete the filters prior to the import?

Well, I already though to add the option to clear Filters table before import, but I wouldn't do that because there are some predefined ones made by program itself, and I don't know in advance which ones would be added in the future. You see, there is no any field in the Filters table which is saying that some filter is built-in and that should not be removed. I suppose that it would be a best practice for you to delete the unnecessary filters manually before the import.

This is throwing up an error when the filters table is cleared, here is what it is stating:


restoreplayhistory empty filter table by nynaevelan, on Flickr

To get around it I just created a fake filter and then deleted it after the import.

ZvezdanD wrote:

nynaevelan wrote:Or would it be better to make sure the Type is correct before an import??

Who should ensure that the Type is correct? A user or the script?

I would prefer if the script decides which Type is correct since it is getting the Type from the original db.

Once again thanks for this feature, now I can create a new db without any major losses.

nynaevelan wrote:I think the duplicates actually occurred prior to the import, this may be due to MM having the music and audiobook filters hard-coded somewhere in the programming. I assume this is so because I cleared the filters table but when I re-opened MM the two filters were still showing up. But to double-check I am going to go back to my original db and do some cleanup to fix them before trying another import.

Even if you have duplicates in the backup database they would not be imported. That could happen only if you have them already in the current database before the import.

nynaevelan wrote:This is throwing up an error when the filters table is cleared, here is what it is stating:

Thanks for the info. I will fix that with the next update.

nynaevelan wrote:I would prefer if the script decides which Type is correct since it is getting the Type from the original db.

Do you suggest that the script should import the Type every time when it is started, even without any setting from the user? I don't like such kind of automation, I prefer if a user has a choice if/when that would be imported.

ZvezdanD wrote:

nynaevelan wrote:I would prefer if the script decides which Type is correct since it is getting the Type from the original db.

Do you suggest that the script should import the Type every time when it is started, even without any setting from the user? I don't like such kind of automation, I prefer if a user has a choice if/when that would be imported.

I was thinking of having an option box such as the fields in the songs table section, which is something each user can choose whether to use or not.

nynaevelan wrote:I was thinking of having an option box such as the fields in the songs table section, which is something each user can choose whether to use or not.

OK, but what is a difference of that suggestion with the previous one: "would it be possible to add an option in the import to change the Type to what the file is in the import db?" I gave you an answer for that suggestion, I would add it if I think up where to put that option box.

That makes sense.

nynaevelan wrote:This is throwing up an error when the filters table is cleared

There is the new release: v3.0.2 - 2012-01-25
* Fixed: error on import/export of filters when Filter table is empty.

There is the new update, v3.1 - 2012-04-04:
* Added: option Clear Filters table first (also Views & NodeViews for MM4 db);
* Added: option to import/export Bookmark, Start Time, Stop Time, Skipped # and Type fields [MM4];
* Fixed: error with Update tags in files as well.

Wow its great..I was not aware of this addons...

Maybe you're already working on this, but is there a chance to automate the backup on a schedule?

Also, is there a way to save our settings (would be needed for the above request of course) but it's also just convenience.

gggirlgeek wrote:Maybe you're already working on this, but is there a chance to automate the backup on a schedule?

I suppose it wouldn't be too hard to add such thing, but I am not sure if it is really needed since there already exists the another add-on which could do that. I added that option (Backup) just because it was so easy and because it could help users to not think where the MM.DB file is actually located for the current OS or MM version.

gggirlgeek wrote:Also, is there a way to save our settings (would be needed for the above request of course) but it's also just convenience.

I don't know on what kind of settings you are talking about. The states of the controls from the dialog box are automatically saved in the .ini file after you apply the export or import. However, if you are talking about the presets with stored several different settings, then I am not sure again if it is really needed. Could you please give me some example why you need such thing?

ZvezdanD wrote:

gggirlgeek wrote:Maybe you're already working on this, but is there a chance to automate the backup on a schedule?

I suppose it wouldn't be too hard to add such thing, but I am not sure if it is really needed since there already exists the another add-on which could do that. I added that option (Backup) just because it was so easy and because it could help users to not think where the MM.DB file is actually located for the current OS or MM version.

I'm annoyed with "Backup 5.8" because the settings dialog doesn't appear correctly unless you are using a very high resolution like 1920x1080. I don't like nose prints on my screen. He has been notified about this by me and others numerous times.

In addition, your extension does more than just replace the MM.db. Backup 5.8 only replaces MM.db and the Mediamonkey settings. I can do that myself. My files are all in the same place because I use Mediamonkey portable.

It is my understanding that Restore/Sync actually overwrites the restored tags onto the the files (if asked to do so.) So if I could do a daily TAG backup I could restore them to files that were backed up 4 months ago. The files would be exactly the same as the lost files.

I only get new music 2-3 times/year and I don't change my folder structure very often, so there is no need to back up the files with every tag update... and frankly, files are easily replaced, tags are not! We're talking 15 years worth of work here. Since the tags' database backup is so small I can put it anywhere. It is much more difficult to backup 100Gb of files, so I don't do it often.

Essentially, I only need 64Mb of space to back up my tags. I can put it on Dropbox.com,... put it on my Android,... I can email it to myself,... I can put it anywhere. I can't do that with 100GB of music files. So I like the idea of backing up my tags separately from backing up my files.

gggirlgeek wrote:Also, is there a way to save our settings (would be needed for the above request of course) but it's also just convenience.

I don't know on what kind of settings you are talking about. The states of the controls from the dialog box are automatically saved in the .ini file after you apply the export or import. However, if you are talking about the presets with stored several different settings, then I am not sure again if it is really needed. Could you please give me some example why you need such thing?[/quote]

Strange: It's saving my settings now. The first time I used it and made a backup, my settings were cleared out when I opened the dialog box a minute later. I restarted MM, did another test-backup, and closed the dialog. They were cleared again when I re-opened the dialog. I assumed it was that way for everyone. Now it's working fine. The only difference is that I've rebooted since then. Probably something on my end.

gggirlgeek wrote:It is my understanding that Restore/Sync actually overwrites the restored tags onto the the files (if asked to do so.) So if I could do a daily TAG backup I could restore them to files that were backed up 4 months ago. The files would be exactly the same as the lost files.
...
So I like the idea of backing up my tags separately from backing up my files.

I am not sure that we understand each-other. This add-on writes tags to the files only if you choose Import option, after importing metadata from the external (backup) database file into the current database. Also, I already told you in PM that this add-on works only with whole database file. It needs whole backup database file if you choose Import or Export option to be able to restore playlists, playing history, tags or anything else. If you choose the Backup option, the whole database file will be saved, it doesn't matter what settings you have in the add-on's dialog box. So, there wouldn't be such thing as "a daily TAG backup". Even if I add an option to automatically save backups, it would still save whole database, not only tags or even just the table with tags (Songs). Beside of the size concern, I cannot see any other reason why somebody would want to make a backup of just some part of the database instead of whole database. As I told you, the Songs table is taking the biggest part of the database file anyway, so you would not get too much smaller file if I modify add-on to save only some new database file which would contain just that table.

gggirlgeek wrote:Strange: It's saving my settings now. The first time I used it and made a backup, my settings were cleared out when I opened the dialog box a minute later. I restarted MM, did another test-backup, and closed the dialog. They were cleared again when I re-opened the dialog. I assumed it was that way for everyone. Now it's working fine. The only difference is that I've rebooted since then. Probably something on my end.

The settings are saved only if you choose Export or Import. They are not saved if you choose Backup. As I said, the Backup option is independent of the settings from the dialog box, it saves the whole database file, and because of that I think there is not too much sense to save settings if user choose that option.

By the way, the Backup add-on's dialog box is not too much larger than mine. I just installed it to check it out. Are you sure that you didn't think about the Advanced Duplicate Find & Fix? When I search for your posts in the Forum I could find only complain about the size for Bex's Find & Fix script.

I'm just writing to say that this add-on worked perfectly for me, letting me import Play Counts from one installation of MM4 into another, on the same PC. Thanks for the contribution!

Hello everyone,

I am so glad for this script to exist. I seem to have a corrupted database (3.2) with apparently no hope for fixing it, whatever I try. My plan is to rescan folders and run the script. Database corruption shows when doing db maintenance (full only) and during attempts to update to 4.x. Error message is "error executing sql statement "VACUUM" constraint failed '19,19). Mm crashes and cannot recover, have to kill it.

The db file is huge : 630 mB. MM takes care not only of my music files (80k) but also my .cdg/video karaoke library (25k) and midi songs/drum loops. Total amounts to 230k entries, with lots of playlists, both auto and static and heavy custom fields usage. Database was created in MM 2.something. It sits on a ramdisk to ease on hard disk access.

MediaMonkey 3.2 works fine and performs admirably despite db size. I have messed up the tree panel somewhat with magic nodes, using it for advanced auto playlists and some more. I suspect this script does not like the tree panel being tampered with. I will report more details as I go through the process.

Currently trying to start with a clean slate and restore my auto playlists. First attempt failed with a message about custom fields (no such column). It could be related with having a magic node entry in the playlists node . Removing magic node script from program folder does not seem to help: I suppose I will rebuild a backup db with magic nodes off and post as I make progress.

In the meantime, may I ask if someone has some input about this script interacting with other scripts altering the tree panel ?