Backup MM Tracks v2.7 (01-11-08) [MM3]

[MoDementia]

No Longer Available

[MoDementia]

I have only tested this with a handful of files.
I will be using it for a full backup but I have to reorganise my disk space and I'm not looking forward to fixing the mess other backup programs have made (many many duplicates).

The intial backup will take some time, as all files will need to be copied.
Subsequent backups should be relatively quick as it will only copy changed/moved tracks.

I suggest creating a playlist as a subset of your library and backing them up until you are happy with how it works before doing a full backup.

I just realised that external editors may not trigger a backup (the way I have written it) not sure if rescan/sync tags will change the trackmodified date.

If you edit files outside of MM please report if the files then get backed up. I can easily add some code to cater for it if not.

[trixmoto]

Any reason for the "zzz" on the end of the link?

Looks like a useful script now I've got a laptop with two harddrives big enough to backup everything!

[MoDementia]

Yeah I realised I forgot something, will post again once i fix it

[Bex]

Great idea and useful script, thanks!

PS I saw that you are indexing the primary key. That's not a good idea:
http://www.sqlite.org/cvstrac/wiki?p=PerformanceTuning

Indexes on INTEGER PRIMARY KEY columns (don't do it)

When you create a column with INTEGER PRIMARY KEY, SQLite uses this column as the key for (index to) the table structure. This is a hidden index (as it isn't displayed in SQLite_Master table) on this column. Adding another index on the column is not needed and will never be used. In addition it will slow INSERT, DELETE and UPDATE operations down.

Also, you should always use COLLATE IUNICODE on all your text fields so you don't get any strange results due to Unicode characters.

[MoDementia]

Bugger, was just about to release it

Ok I'll fix the index and the unicode stuff wtf could take a little while

If anyone has the original ...Bex... please uninstall it and wait for the new one

[Bex]

Just use DROP XX IF EXIST to delete the index. You can do the same with the table but then you need to give the new corrected table it a new name.
These drop statements should also be present in the uninstall sub together with one for the trigger as well as a additional one for the new table. (Haven't checked the uninstall sub so it might already be there.)

[nynaevelan]

Being a backup junkie, I am looking forward to seeing the updated version of this script. I have a minor question, will the continued use of my backup program (Syncback) interfere if I decide to use this script?? I also have two versions of my backups, which would you suggest as the best to use, my primary backup or my secondary backup?

Nyn

[MoDementia]

Ok deleted the index and added COLLATE IUNICODE to the CREATE TABLE TEXT Fields

Hope that was all ?

[MoDementia]

The uninstall has the drop code, as long as you answer yes to remove it

@ Nyn
It probably will especially if you try and use it to restore in between backups
Backup 1
SyncBack (just guessing)
Backup\Artist\Title.mp3

Script
Backup\Artist\Title.mp3

Backup 2
SyncBack (just guessing)
Backup\Artist\Title.mp3
Backup\Artist\NewCaseChangeTitle.mp3

Script
Backup\Artist\NewCaseChangeTitle.mp3

So if you try and restore Backup\Artist\Title.mp3 using SyncBack Backup 1 it won't be there

And this is why I gave up trying to use "normal" backup software on my music
From 60gig database I eneded up with a 200gig backup

[Bex]

What I meant was that if people had installed the script then they would have the table, index and trigger created in the database. To delete those you need to add some code to remove them. Such code should also be present in your uninstall sub, they might already be there I haven't checked.

But you need to do it in a smart way so the code doesn't delete the newly corrected table. I would do it by giving the corrected table a new name. But then you need to correct the trigger which leads to that you need to rename that as well. So you need to do the same thing with the trigger as with the table.

The drop statement for the index can always be present.

Or you can just hope that no one installed the script the first time!

[MoDementia]

Or you can just hope that no one installed the script the first time!

There is a slim chance that someone got the file before i changed the link to zzz, I hope they reread this post and uninstall and reinstall the current link

[Bex]

[nynaevelan]

@ Nyn
It probably will especially if you try and use it to restore in between backups
Backup 1
SyncBack (just guessing)
Backup\Artist\Title.mp3

Script
Backup\Artist\Title.mp3

Backup 2
SyncBack (just guessing)
Backup\Artist\Title.mp3
Backup\Artist\NewCaseChangeTitle.mp3

Script
Backup\Artist\NewCaseChangeTitle.mp3

So if you try and restore Backup\Artist\Title.mp3 using SyncBack Backup 1 it won't be there

And this is why I gave up trying to use "normal" backup software on my music
From 60gig database I eneded up with a 200gig backup

Thanks for the explanation, I think I will give this a try, because like you I end up having to cleanup my backups more times than necessary. Especially since Bex keeps updating the TI and ADFFscripts and thanks to Trixmoto's Backup script, I have lots of backups to revert back to.

Nyn

[nynaevelan]

I like the potential of this, I will run it overnight for my entire database. One more question, once I've completed my initial backup and I add files to my library, and then rerun the script will it only look at any new or changed entries or will it reevaluate the entire database? Also, will it make any updates to changed files automatically or will it need to be run by the user? Sorry for my ignorance

Nyn