Backup 6.0 - Updated 01/07/2014

[RobertSmith]

Sorry I missed that, are you sure the folders that you have setup actually exist? It looks like there is a backslash missing in your archive setup, but that could be my "old" eyes missing something. As a side note, if possible you should have your backups going to a different drive than your database drive in case of hard drive failure.

Nyn

incredible - everything works today... I have done absolutely nothing except for a good night of sleep and restarting PC. Back in business...
Nyn, could pls read/check if you found the text in Usage: FAQ post to be understandable. (I'm doing some editing now, but I guess you are still in bed )

[RobertSmith]

Trixmoto thx for a great script!

Do you think it is possible to add a timer function like this one in Export M3U/Playlists for Child Nodes 2.7 (2009-07-08)[MM2+3]. This would be very useful in case of an accidental crash and play statistics for many hours and metadata like rating is gone...

This might be to overdue it but maybe it could be a good feature to only have this timer linked to 2nd backup (no auto backup for 2nd one). When you have a "total" backup in folder 1 (auto backup) and only database and ini-file for 2nd backup controlled by the timer (manual will effect both).

The numbers of auto saved timer backups could be reduced by using a mask like:<H>< M>.zip (files will be overwritten after x number of days)

[nynaevelan]

Here are some minor adjustments to your info, but these are just based on my understanding of how the script works I am by no means an expert.

1. Most be checked if you want to keep the latest backup UNZIPPED. If you don't check this you still need to write a path since the script use this path as a temp folder for the backup zip-file.

Must be checked if you want to keep the latest backup UNZIPPED. If you don't check this you still need to write a path since the script use this path as a temp folder for the backup zip-file.

[*]Most be checked if you want a zipped backup, with above settings one zip-file will be saved on each exit and the latest will also be saved unzipped (for easy access) With the above mask the script will save a zip-file in c:\Backup with a name like:
MediaMonkey [version] - date - hour.minute.zip

Code: Select all

MediaMonkey [3.1.0.1256] - 2009-07-23 - 20.27.zip

Must be checked if you want a zipped backup, with above settings one zip-file will be saved on each exit and the latest will also be saved unzipped (for easy access) With the above mask the script will save a zip-file in c:\Backup with a name like:

[*]Check one or both option to create Auto backup. You can always do additional manual backups by clicking on Backup in the setup (tips: check Show toolbar launch button)

Check one or both option to create Auto backup either at startup of M or shutdown of MM. You can always do additional manual backups by clicking on Backup icon on the toolbar (tip: check Show toolbar launch button)

[*]?? Only useful for new database? There is also the option to check the database is at least 1Mb in size. When MM creates a new database this is approximately 800kb, so anything less than 1Mb normally means your database has been mislaid, so you don't want to backup the empty one!

Useful as a check to ensure the database is being correctly backed up. When MM creates a new database this is approximately 800kb, so anything less than 1Mb normally means your database has been mislaid, so you don't want to backup the empty one!

[*]? Most be checked so you don't mix old files with new (temp folder/unzipped backup)?

Must be checked so you don't mix old files with new (temp folder/unzipped backup)?

I am not sure of the accuracy of this statement, I do not have this option selected and my backups are not mixed with old and new data.

[*]? If you want overwrite zip files (not using a mask with date, time)?

I am not sure of the accuracy of this statement, files will be overwritten unless you have a unique mask such as using seconds.

[*]?? There are two options M3U and Mod: Nested ?

The M3U method will export the playlists in the same format which MM uses with the parent playlist being a part of the name of the playlist. They will all be exported in the same folder. The Mod: Nested method will export the playlists into folders with the same parent/child hierarcy which the playlists uses within MM.

[*]??? What other type of folder, pls give some examples...[/list]

This could vary depending on the user, for example I have mine setup to copy the folder which MM uses for the mediamonkey.m3u file but there could be many others.

[trixmoto]

@RobertSmith - thank you for your detailed post, I will try to build this into a user guide for the first post when I've got a little more time to work on it. Some comments though...

1) You can now leave this path blank if you don't want to tick the checkbox and a folder will automatically be created in the %temp% folder.
3) Yes, different drives is a VERY good idea!
5) I don't think this has ever been a problem for me with MM3, but with MM2 sometimes if the database become corrupted a new one was created (which was always less than 1Mb) and obviously you wouldn't want this new one to overwrite your backup of your actual one!
6) This primarily acts as a reminder to users that the output path will be deleted so they shouldn't point to a folder with anything else in it. Also some people wanted to do a full backup to a folder (including scripts and plugins, etc) but then they only wanted their automatic backup to include the database and the settings. Leaving this option unticked would then allow the archive zip file to include the full backup (including script and plugins) even though on the database and settings had been copied into the folder recently. Ticking the option means that if you delete a script (for example) it will also be deleted from your backup.
7) This is also really a confirmation to remind people that they might be losing previous backup files. Some people were complaining about losing files that they wanted so I put in lots of extra options so they knew exactly what the script was going to do.
9) These are other scripts which people have asked me to include so they can run them automatically.
11) I can't remember but someone requested this. If you read back through the thread you might find it. It was most likely backing up output from another script or something like that.

I've added the timer option to my list for the next version.

[RobertSmith]

@RobertSmith - thank you for your detailed post, I will try to build this into a user guide for the first post when I've got a little more time to work on it.

I've added the timer option to my list for the next version.

Thy!! I have updated Usage: with some comments though...

[RobertSmith]

I just realise (even if it's obvious) there is no point to do a manual backup if you haven't updated db. If you don't update db, you still lose metadata and playstat even with a backup. (I never remember to stop player before I start the library maintenance -> PC hangs...) Metadata saved in tags will still be there so you use scripts like add/remove playstat to fix but...

So maybe there should be a warning that tells you that current database is the same as previous (auto) backup you need to update db (manual) before you proceed with backup. With the upcoming timer maybe there should be an option to always update db before backup.

Edit: The problem with MM.db has been reported and now also localized so above warning is obsolete.

[nynaevelan]

I'm confused with this suggestion, wouldn't turning on the Tools - Options - Library - Tags & Playlists - Update tags when editing properties option prevent the loss of metadata? And no matter what options you have setup in the script, there is always a possibility to lose playstat data. Bex's Add/Remove Playstat script has helped me to recover playstats in these type of situations. And, because the maintain library function locks up my computer, I have gotten in the habit to avoid playing tracks when I am running my "cleaning" processes in order to avoid this situation. Also, other than size how would the script check for changes since the last backup and what kind of performance degradation will this cause?

Nyn

[RobertSmith]

I'm confused with this suggestion, wouldn't turning on the Tools - Options - Library - Tags & Playlists - Update tags when editing properties option prevent the loss of metadata?

To be honest I'm confused to
I have that option on so after a crash (maintenance or script...) I rescan to read metadata like rating and when use Bens's script to set lastplay as close as possible to timestamp. But my thought, maybe it's wrong, if I rescan before backup were would be no need for Bens's script since all playstat incl. metadata will be in the database, is this wrong?

Also, other than size how would the script check for changes since the last backup and what kind of performance degradation will this cause?

timestamp?

Main question, when is the database saved? Only at exit and/or rescan?
Edit: The problem with MM.db has been reported and now also localized so above warning is obsolete.

[nynaevelan]

I'm confused with this suggestion, wouldn't turning on the Tools - Options - Library - Tags & Playlists - Update tags when editing properties option prevent the loss of metadata?

To be honest I'm confused to
I have that option on so after a crash (maintenance or script...) I rescan to read metadata like rating and when use Bens's script to set lastplay as close as possible to timestamp. But my thought, maybe it's wrong, if I rescan before backup were would be no need for Bens's script since all playstat incl. metadata will be in the database, is this wrong?

I am not sure about this because I too have it on and I have very rarely lost anything other than playstat data. BUT, this may explain why some of my ratings are off on tracks that had not been played in a while. But since I use a very simplistic ratings system and I have custom nodes to identify tracks which need the ratings corrected, this is a minor loss and fix for me.

Also, other than size how would the script check for changes since the last backup and what kind of performance degradation will this cause?

timestamp?

This would not work for all users, I for one do not have the timestamp adjusted on my tracks. I actually use the RegExp script to change my timestamp to the date/time the tracks are added to the library.

Main question, when is the database saved? Only at exit and/or rescan?

Once again I am not sure about this one because I do not rescan and I have file monitoring turned on, so I assume that is doing the rescanning, if necessary. But once again, I run a manual backup before I start my cleaning processes and then again once I am finished.

Nyn

[RobertSmith]

This would not work for all users, I for one do not have the timestamp adjusted on my tracks. I actually use the RegExp script to change my timestamp to the date/time the tracks are added to the library.

With timestamp (wrong word...) I meant filedate (last modified date) on db not timestamp on tracks.

Once again I am not sure about this one because I do not rescan and I have file monitoring turned on, so I assume that is doing the rescanning, if necessary. But once again, I run a manual backup before I start my cleaning processes and then again once I am finished

I just tried a "maintain library" and this action also save db (you can check date for MM.db before and after). This mean that maintain library is an (better?) alternative to rescan. Nevertheless I still think you have to do something to trigg MM to save db otherwise it would be meaningless to save db every 30 min (since you will save same db X no of times)
Edit: The problem with MM.db has been reported and now also localized so above warning is obsolete.

[nynaevelan]

My db is being saved after all changes, for instance:

1. moved tracks from playlist, db saved
2. moved tracks to new playlist, db saved
3. used Copy/Paste of ADFF script,db saved

So unless your db was sitting idle between saves, what need is there for an option to check for changes??

[RobertSmith]

1. moved tracks from playlist, db saved
2. moved tracks to new playlist, db saved
3. used Copy/Paste of ADFF script,db saved

I don't know why, but it look likes db is updated continuously changing rating or... So it looks like it''s no need for a trigger (I must have done something wrong previous) sry...

But I'm still confused, if db is saved continuously why is playstat and rating gone after a crash?
Edit: The problem with MM.db has been reported and now also localized so above warning is obsolete.

[RobertSmith]

Hmm..
MM has been playing in the background for the last hour but for an unknown reason (same as before I guess) it has suddenly stopped to save db.

Instead of a updated MM.db there are 2 files
MM.DB-stmtjrnl (hidden)
MM.DB-journal

What kind of files are those? And could this be the reason for losing playstat after crash? NAS related problem? I have my music collection on an external USB HDD and MM is installed on laptop HDD.

No problem to play but when I close MM an error occur (message saying something like: an error has occured and the program must be closed) and playstat is gone...

When reopen MM the above 2 files has automatic been deleted, last timestamp is just before the time when the last MM.db was properly saved.

Rescan -> rated (taken from tag) files with timestamp (later when last proper db save) but no last played (could be fixed with Ben's script)...

Edit: The problem with MM.db has been reported and now also localized so above warning is obsolete.

[nynaevelan]

But I'm still confused, if db is saved continuously why is playstat and rating gone after a crash?

I'm just guessing here but I assume the db did not have a chance to save the changes so that is why they are lost after a crash.

Nyn

[nynaevelan]

Hmm..
MM has been playing in the background for the last hour but for an unknown reason (same as before I guess) it has suddenly stopped to save db.

Instead of a updated MM.db there are 2 files
MM.DB-stmtjrnl (hidden)
MM.DB-journal

Those are just temp files which MM creates when it is saving the db, they disappear after the changes are committed.

No problem to play but when I close MM an error occur (message saying something like: an error has occured and the program must be closed) and playstat is gone...

I was getting this error when I was using the shutdown option in the script, I think it was because I had too many things going on, which is why I switched to the startup option instead.