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

Download and get help for different MediaMonkey Addons.

Moderators: Peke, Gurus

svenni
Posts: 87
Joined: Wed Feb 16, 2005 6:14 pm

Post by svenni » Fri May 23, 2008 9:46 am

looks like a useful script. but it still puts files in f:\Music\Music, if I choose f:\Music, as my backup folder.
Music is great!
MM with:
AutoAccRate 2.4.2, Blue Monkey 2.1, Backup 5.1, AutoAlbumDJ 3.5, Last100.. node, ClearNowPlayingButton 1.2, Monkey Rok, Last FM DJ and Scrobbler that scrobbles!

nynaevelan
Posts: 5559
Joined: Wed Feb 07, 2007 11:07 pm
Location: New Jersey, USA
Contact:

Post by nynaevelan » Fri May 23, 2008 10:42 am

svenni wrote:looks like a useful script. but it still puts files in f:\Music\Music, if I choose f:\Music, as my backup folder.
Just choose f:\ and it will put them in f:\music.

Nyn
3.2x - Win7 Ultimate (Zen Touch 2 16 GB/Zen 8GB)
Link to Favorite Scripts/Skins

Join Dropbox, the online site to share your files

MoDementia
Posts: 1321
Joined: Thu Jun 15, 2006 3:26 pm
Location: Geelong, Victoria, Australia

Post by MoDementia » Fri May 23, 2008 3:09 pm

That will work but it is probably more correct to leave the backup directory as
F:\Music
and
Check Shorten Path\Filename length by excluding string...
and enter Excluded Directories in backup path ...
Music\

See first page for example.
Without the option Checked
D:\Backup\My Music\
with the option checked
D:\Backup\

svenni
Posts: 87
Joined: Wed Feb 16, 2005 6:14 pm

Post by svenni » Fri May 23, 2008 3:57 pm

hey
thanks for answering quickly. It works better with the checkbox checked (I did'nt understand what it was :oops: )

The PC works sslow during copy, and with check for missig bakcup checked it is not useable. Is this normal/suppposed to be like this?

Yes this is my first complete backup with about 4000 files but still, normally, copying files does'nt kill my computer completely.

Thanks
Music is great!
MM with:
AutoAccRate 2.4.2, Blue Monkey 2.1, Backup 5.1, AutoAlbumDJ 3.5, Last100.. node, ClearNowPlayingButton 1.2, Monkey Rok, Last FM DJ and Scrobbler that scrobbles!

MoDementia
Posts: 1321
Joined: Thu Jun 15, 2006 3:26 pm
Location: Geelong, Victoria, Australia

Post by MoDementia » Fri May 23, 2008 4:07 pm

Yeah the first backup takes ages cause its running from a script (or something) :(

But subsequent backups are very fast (depending on how many changes have been made) :)

I'll check the checkbox thing soon (maybe because you haven't done a backup yet)

[EDIT] Check for missing backup tracks should only be checked if you think you have accidentally deleted some of the backup tracks.
i.e. It wont recopy them if no changes have been made since the last backup.
The check also checks that the physical file is there.

MoDementia
Posts: 1321
Joined: Thu Jun 15, 2006 3:26 pm
Location: Geelong, Victoria, Australia

Post by MoDementia » Fri May 23, 2008 4:38 pm

svenni wrote:hey
... and with check for missig bakcup checked it is not useable.
See previous post

But basically with it checked and no previous backup it is doing alot more work checking if it exists as well as the copy.

nynaevelan
Posts: 5559
Joined: Wed Feb 07, 2007 11:07 pm
Location: New Jersey, USA
Contact:

Post by nynaevelan » Sun Jun 15, 2008 7:47 am

MoD:

Is it posssible to add an option for the user to select a custom field to copy the Track Identifier information to? I would like to use Trixmoto's Custom Report to run some reports on the backup information.

Nyn
3.2x - Win7 Ultimate (Zen Touch 2 16 GB/Zen 8GB)
Link to Favorite Scripts/Skins

Join Dropbox, the online site to share your files

MoDementia
Posts: 1321
Joined: Thu Jun 15, 2006 3:26 pm
Location: Geelong, Victoria, Australia

Post by MoDementia » Sun Jun 15, 2008 9:17 pm

nynaevelan wrote:MoD:

Is it posssible to add an option for the user to select a custom field to copy the Track Identifier information to? I would like to use Trixmoto's Custom Report to run some reports on the backup information.

Nyn
Technically, Yes
Practibility, No

The information is in the TrackBackup table. It would be much better to make use of the data already there rather than duplicating it.

Of course this depends on how you want to see/use the information.
e.g. SQLviewer could give you a simple list.

nynaevelan
Posts: 5559
Joined: Wed Feb 07, 2007 11:07 pm
Location: New Jersey, USA
Contact:

Post by nynaevelan » Sun Jun 15, 2008 9:26 pm

Yes it would but it would not be able to give me a list that I could export and use in Excel. Although there are custom node scripts which might be able to help, since they are based in the Songs table, the info is not available. The same with the autoplaylists. So therefore I need some way to get the data out besides the sql viewer, because I cannot do anything with the data with sql viewer.

Nyn
3.2x - Win7 Ultimate (Zen Touch 2 16 GB/Zen 8GB)
Link to Favorite Scripts/Skins

Join Dropbox, the online site to share your files

MoDementia
Posts: 1321
Joined: Thu Jun 15, 2006 3:26 pm
Location: Geelong, Victoria, Australia

Post by MoDementia » Sun Jun 15, 2008 10:28 pm

Here is a modified version of CustomReport. (Identifier is the last column on the list.)
Maybe Trix can optionally add it in a release version.

http://users.ncable.net.au/~modemen/Med ... Report.vbs

nynaevelan
Posts: 5559
Joined: Wed Feb 07, 2007 11:07 pm
Location: New Jersey, USA
Contact:

Post by nynaevelan » Mon Jun 16, 2008 4:53 am

Thank you, although I don't think TM needs to make official changes just for me. 8) If you tell me what lines you changed, I can update the newer versions when they come out.

EDIT: Nevermind I found them, I can just add back the customizations when a new version is released, the same as I do for my custom playlist counts. Thanks again for your help.

Nyn
3.2x - Win7 Ultimate (Zen Touch 2 16 GB/Zen 8GB)
Link to Favorite Scripts/Skins

Join Dropbox, the online site to share your files

trixmoto
Posts: 10024
Joined: Fri Aug 26, 2005 3:28 am
Location: Hull, UK
Contact:

Post by trixmoto » Mon Jun 16, 2008 1:52 pm

I'll see about getting this into the next release of "Custom Report".
Download my scripts at my own MediaMonkey fansite.
All the code for my website and scripts is safely backed up immediately and for free using Dropbox.

nynaevelan
Posts: 5559
Joined: Wed Feb 07, 2007 11:07 pm
Location: New Jersey, USA
Contact:

Post by nynaevelan » Mon Jun 16, 2008 2:48 pm

trixmoto wrote:I'll see about getting this into the next release of "Custom Report".
Thank you :P 8) :P

Nyn
3.2x - Win7 Ultimate (Zen Touch 2 16 GB/Zen 8GB)
Link to Favorite Scripts/Skins

Join Dropbox, the online site to share your files

MCSmarties
Posts: 248
Joined: Tue Dec 06, 2005 8:01 pm

Ultimate backup - idea to improve the script

Post by MCSmarties » Sat Jun 28, 2008 11:11 pm

MoDementia, thanks a lot for coming up with this backup mechanism. I love your idea!

However, I am reluctant to use it for the same reason that I'm afraid to use other automated backup mechanisms:
What if something goes wrong and I end up destroying my good backup with a corrupted/bad modification?

Don't take this statement as implying that I don't trust your script, there are a lot of things that can and will go wrong when manipulating a large database:
- MM crashes, corrupting the tags of the last file
- I mistakenly apply a modification to a whole bunch of songs instead of only one
- I find/rip a "better" version of a song and delete the old version, realizing too late that the new version has a problem
- I try out a new script (specially a "batch" script) that misfires and messes up a whole bunch of songs
- etc... (all the above happened to me at one time or another)

Now just imagine I run the backup (either manually, or it happens automatically when I restart MM) before I realize there' s a problem...
oh, the sheer horror - I just replaced my supposedly safe "backup" with garbage!!! :o

OK, the easy solution is to keep a backup of the backup - but two full backups take a lot of space, not to mention it gets messy (which backup can I trust now?)

So, what to do? Well I think I just had a brain wave:

The solution is to automatically store up to two versions of each song, but only if necessary!

Basically, if a song that already exists in the backup is modified, a separate backup of the "old version" is created.
All other songs will have just one backup, thus keeping the size of the separate backup very small.
If the same song is modified again (creating 3 versions), a message pops up asking which of these 3 versions can be deleted and acts accordingly.

Let me explain what should ideally happen in concrete situations (each example summarizes the content of each location in blue)

1. BACKUP MECHANISM
***************************


ADD NEW SONG TO DATABASE
------------------------------------
<Mediamonkey>: Version 1


RUN BACKUP
---------------
- simply copy song to backup

<Mediamonkey>: Version 1 ---> <Backup>: Version 1


MODIFY EXISTING SONG
----------------------------
- copy existing version from <Backup> to <Backup 2>
- copy new version to <Backup>

<Mediamonkey>: Version 2 ---> <Backup>: Version 2 ---> <Backup 2>: Version 1


MODIFY EXISTING SONG FOR A SECOND TIME, REVERTING TO PREVIOUS VERSION
-----------------------------------------------------------------------------------------------
- same mechanism as above: copy existing version from <Backup> to <Backup 2>
- copy new version to <Backup>

<Mediamonkey>: Version 1 ---> <Backup>: Version 1 ---> <Backup 2>: Version 2



MODIFY EXISTING SONG FOR A SECOND TIME
-----------------------------------------------------
- now there is a problem! only 2 different backups are allowed (to prevent ballooning)
- ask which version to DELETE (show differences between files/tags of all 3 versions side-by-side)

<Mediamonkey>: Version 3 ---> <Backup>: Version 3 ---> <Backup 2>: Version 1
OR
<Mediamonkey>: Version 3 ---> <Backup>: Version 3 ---> <Backup 2>: Version 2
OR
<Mediamonkey>: Version 2 ---> <Backup>: Version 2 ---> <Backup 2>: Version 1
OR
<Mediamonkey>: Version 2 ---> <Backup>: Version 2 ---> <Backup 2>: Version 3
OR
<Mediamonkey>: Version 1 ---> <Backup>: Version 1 ---> <Backup 2>: Version 2
OR
<Mediamonkey>: Version 1 ---> <Backup>: Version 1 ---> <Backup 2>: Version 3

(as you can see, only two versions are maintained in the end, one is discarded)

2. RESTORE MECHANISM
*****************************


RESTORE SONG TO DATABASE
-----------------------------------
- simply copy song from backup to media monkey

<Backup>: Version 1 ---> <Mediamonkey>: Version 1


RESTORE SONG WITH TWO DIFFERENT BACKUPS TO DATABASE
--------------------------------------------------------------------------
- ASK which version to restore (show differences between files/tags side-by-side)
- copy this version to the database
- still KEEP the other version in <Backup 2> of course! (just as a safety - never trust the user :wink: )

<Backup>: Version 1 ---> <Mediamonkey>: Version 1 (<Backup 2> contains Version 2)
OR
<Backup>: Version 2 ---> <Mediamonkey>: Version 2 (<Backup 2> contains Version 1)


3. CLEANING MECHANISM
******************************

- goal is to clear <Backup 2> (<Backup> will always remain)
- ASK whether the version currently stored in <Backup 2> can be safely deleted (again, highlight differences)
- if the user answers no, ask whether <Backup 2> should be restored to the Mediamonkey database (see restore mechanism)

<Mediamonkey>: Version 1 ---> <Backup>: Version 1 (<Backup 2> containing Version 2 has been deleted)
OR
<Mediamonkey>: Version 2 ---> <Backup>: Version 2 (<Backup 2> containing Version 1 has been deleted)

As you can see, this would only require user intervention in a few specific situations.
That' s just a coarse overview, details may require tweaking:
- automation
- assume some changes are always desired and silently replace the backup (such as adding a value to an empty tag field or modifying the rating)
- preferences, for example maximum size of <Backup 2>(prompt cleaning when exceeded) or which changes to accept automatically, etc...

All this of course while still using your original idea, e.g. tracking a song by a unique ID to avoid redundancy.

What do you think? It seems to me that your script already does most of the work, it only really needs a couple of additions:
- a block to discriminate what action is required and run the backup routine a second time for the concerned songs
- a dialog to highlight the differences between 2 files to the user and ask for input.

MoDementia
Posts: 1321
Joined: Thu Jun 15, 2006 3:26 pm
Location: Geelong, Victoria, Australia

Re: Ultimate backup - idea to improve the script

Post by MoDementia » Sun Jun 29, 2008 12:42 am

MCSmarties wrote:MoDementia, thanks a lot for coming up with this backup mechanism. I love your idea!

However, I am reluctant to use it for the same reason that I'm afraid to use other automated backup mechanisms:
What if something goes wrong and I end up destroying my good backup with a corrupted/bad modification?

Don't take this statement as implying that I don't trust your script, there are a lot of things that can and will go wrong when manipulating a large database:
- MM crashes, corrupting the tags of the last file
- I mistakenly apply a modification to a whole bunch of songs instead of only one
- I find/rip a "better" version of a song and delete the old version, realizing too late that the new version has a problem
- I try out a new script (specially a "batch" script) that misfires and messes up a whole bunch of songs
- etc... (all the above happened to me at one time or another)

Now just imagine I run the backup (either manually, or it happens automatically when I restart MM) before I realize there' s a problem...
oh, the sheer horror - I just replaced my supposedly safe "backup" with garbage!!! :o

OK, the easy solution is to keep a backup of the backup - but two full backups take a lot of space, not to mention it gets messy (which backup can I trust now?)
Cut ---------------------------------------- Cut
As you can see, this would only require user intervention in a few specific situations.
That' s just a coarse overview, details may require tweaking:
- automation
- assume some changes are always desired and silently replace the backup (such as adding a value to an empty tag field or modifying the rating)
- preferences, for example maximum size of <Backup 2>(prompt cleaning when exceeded) or which changes to accept automatically, etc...

All this of course while still using your original idea, e.g. tracking a song by a unique ID to avoid redundancy.

What do you think? It seems to me that your script already does most of the work, it only really needs a couple of additions:
- a block to discriminate what action is required and run the backup routine a second time for the concerned songs
- a dialog to highlight the differences between 2 files to the user and ask for input.
Hi MCSmarties,

Thanks for your comments.
I will certainly think about your suggestions, the ability to implement them, there usefulness, etc
However here are my intial thoughts, comments.

The biggest (only?) concern I do have is if the actual rip is corrupted and makes its way into the backup i.e. your example:
- I find/rip a "better" version of a song and delete the old version, realizing too late that the new version has a problem

This is why I also have a secondary backup on DVDs and of course the original CDs, Cassettes, Vinyl etc. or an external drive in a safe; well not really in a safe nor an external drive :)
I'm pretty sure I also have most of my album art exported to another drive or DVD somewhere too (I scanned a considerable amout of it). Also easily done with a script.

All other tag infomation can be restored by maintaining regular database backups (I believe Trixmoto's backup is a must for all MM users)

So I hope that you can see that the script is primarily designed to restore my a library very quickly after a HD format or an unfortunate HD crash.

The script doesn't care what changes are made, only that it has been modified so some of your comparision requirements are not currently available. Not that it isn't possible, just that it's a real pain in the %&$# to script.
It is also not automated for some of the reasons you have concerns about.
Any changes I make I let sit for a week at least before running a backup (Unless they are additions) so I have a chance to spot/listen to corrupted tracks.

Due to my listening habits I doubt even 5 backup copies would save me from a corrupted file before I listened to it and found a problem.

I hope this clarifies some things for you, and hopefully you decide to make use of the script :)

Post Reply