Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bspachman]

Having already suffered one great loss when my media server melted down, I am trying to proactively avoid another loss. Here's the story:

In a nutshell, I lost all of my media files when my media server RAID suffered a 2nd disk failure while in a degraded state (actually during the rebuild of the RAID). All recovery options have given me naught. Now, although it's difficult to back up 1.5TB of data, I do have the critical files backed up, namely my CUE sheets, my APLs, and my iTunes Store downloaded music. I am in the process of restoring those files as I type.

I'm also in the process of re-ripping all of my CDs (35 down, over 600 to go...) For better or worse, I use EAC to rip the CD to an image and CUE sheet, then hand it off to Monkey's Audio to compress.

In my ideal world, I should be able to just move my newly-re-ripped APE image files back into their restored directory structure on the rebuild RAID, and MC12 will work just fine. HOWEVER..., with all of the auto-importing, auto-updating, and general helpfulness of MC, I want to be sure that my assumptions hold true before I next lose all of my MC Library meta-data because my media files have some kind of hidden ID# that cause them to be recognized as 'new'.

What kinds of experiences and pitfalls have people already found when restoring media files to an otherwise perfectly good MC Library?

brad

[benn600]

Just make multiple backups of your MC database right now...including one to a read-only medium such as a CD.  That way you can never say you were hosed.  Just restore the previous database and try again!

I would think that the file path would be sufficient for locating tracks but there is a big problem.  If you are re-ripping all your music there is a good chance that the file info will not match the previous exactly so the file path and file name, even if using the same format, probably won't line up on a certain percentage of songs.  It could be a huge project re-linking everything...basically getting the same file names as you used to have.

That has always been my big concern with re-ripping...I usually go through the songs and verify their integrity to make them as accurate as possible.  I very often change the Artist, Album, Genre, or Date and some song Names have errors so I fix those as well.  Every change from the default YADB stuff would potentially change the filename and path.  And if you update a file's info it might try to replace the older MC entry.

Not sure of an easy way to fix this.  Although MC seems to have some type of guesser that tries to figure out if a new file is just the old one renamed so that might be able to fix some for you.  What is the meta data you're saving?  Play counts?  Ratings?

[hit_ny]

If you are re-ripping all your music there is a good chance that the file info will not match the previous exactly so the file path and file name, even if using the same format, probably won't line up on a certain percentage of songs.  It could be a huge project re-linking everything...basically getting the same file names as you used to have.

File path & File name or [Filename] is the only parameter that has to match for MC to recognise the file.

If you can do that, MC will be none the wiser.

[jgreen]

Well, I did this about a year ago and survived the experience.  In my case, my backups were all over the planet--some on orig CD, some on DVD backup, and about a third sprinkled among hard drive backups, one of which failed during the restore.  Oh, and some of the data DVD's were unreadable.  I wanted to shoot myself. 

So, if you're restoring from one medium, in your case audio CD, that in itself is a blessing.  35 of 600?  Steady progress and you'll get there.  A couple of things I found:

--It was easier to bulk rip the CD's to a default directory, and then rename within MC to match the exact location specified in the MC library. 

--Also, since suddenly being without any music gave me a case of the cold shivers, I used my ratings to prioritze my restores.  This way I got my favorite music back on line faster and blasting away sooner.  Still, going for a day or two without hearing a "5" or even a "4" left a scar that I know I will bear for a lifetime.

I now use Acronis to back up the whole library to offline disks and I just buy new 500 gb drives as I need them.  IMO, and I know this is heresy, but RAID 5 is a goat-rope.  Spend the money to completely mirror your data, and for better protection do it in JBOD.

[Alex B]

bspachman,

Assuming that all library files are offline and only present in the library the following should work for you.

- Change the Filename field values in the library to e.g.

[base path]\Album Artist (auto)\Album\01.apl
[base path]\Album Artist (auto)\Album\02.apl
[base path]\Album Artist (auto)\Album\03.apl
etc

I.e. use the track number as the only filename rule in the "Rename Files From Properties" options.

Perhaps add folders for CD1, CD2 etc when needed.

- Rip the CDs. Fill only the main Album and Artist fields. You don't need to query or write the track names.

- Create the APL files with the separate APL tool from the Monkey's Audio 3.99 package (I consider this better than the integrated tool in the Monkey's Audio 4.0.x beta program)
Configure the naming rule so that it creates filenames like this:
01.apl
02.apl
03.apl
etc

- Move the APL & APE files to the correct location (if you didn't already use it in the EAC folder options)

- Open MC and do: "Update Tags From Library" and after that "Rename Files From Properties".

BTW, you don't need to rip in wave format when you use EAC. Just install the Monkey's Audio 3.99F package and select in Compression Options: Wave format > Monkey's Audio 3.99 DLL and select your preferred compression level. EAC is fully compatible with Monkey's Audio. Even the cue files have automatically correct filename references (with the .ape extension). You can also use it for burning audio CDs of your MA + cue disc image files without decompressing the files first.
http://www.monkeysaudio.com/files/MAC_399F.exe

EDIT

As you said, you may want to disable the Auto-Importer before proceeding.
Also, in any case, you are not going to lose your old metadata because you have a library backup file in a safe place, haven't you?

EDIT 2

I do have the critical files backed up, namely my CUE sheets, my APLs, and my iTunes Store downloaded music. I am in the process of restoring those files as I type.

I didn't read your post well. If you really have the APL files that makes the process a lot easier. You just need to take care that the APE filenames are correct.

[hit_ny]

IMO, and I know this is heresy, but RAID 5 is a goat-rope.  Spend the money to completely mirror your data, and for better protection do it in JBOD.

Not heresy at all, JBOD's mirrored is what i've done since ages, best part is it re-uses the older drives that have squat resale value anyway.

[JimH]

I had to look up JBOD at wikipedia.

[jgreen]

Hitman, I'd be happy backing up to wax phonograph disks in order to save a buck, but consider this:  a purpose-built JBOD array.

Say your target data size was 2tb.  Set up a JBOD of four 500gb drives, 0,1,2,3.  Populate with data.  Now, set up a second JBOD of four 750 gb drives, 0a, 1a, 2a, 3a.  You're using bigger drives for the mirror so you can do incremental images, via Acronis or other software.  This way your mirror is offline and immune to driver error, while at the same time you have the luxury of incremental backups that would allow you to restore from a distant date, if necessary.  The key to this, IMO, are JBOD arrays whose drives exactly correspond to each other.  Postiion 0 on the data JBOD is fully containable in position 0 of the backup JBOD.    If position 0 goes down, you know exactly which drive to restore, etc etc.

Of course, I'm not that well organized currently, but that's my future game plan. 

[jgreen]

Quoting JimH:

"I had to look up JBOD  at wikipedia."


JimH, I'm a bit worried this thread's going to devolve into Cleese's "Dead Parrot" skit.  Could we just not go down that road?  Didn't I give you guys enough to work on in the Beta Forum?

[hit_ny]

Hitman, I'd be happy backing up to wax phonograph disks in order to save a buck, but consider this:  a purpose-built JBOD array.

True, but as your collection grows..it gets harder to have identical sizes to backup, but then a target of 2TB..hmm..that would last me a very long time, good ten years at least (maybe longer), provided you don't get too much into video. But its gonna be pricey..especially those 750GBs.

Not seeing why the backup needs to be bigger tho, a third as much according to your figures.

No need for incrementals as don't write back to the files for over a yr now. This way i can use checksums which get run before sync to ensure every file is good to the byte(!). I'll admit "knowing" the library is kosher can be challenging but the benefits are worth it.

The only drive imaged is the c-drive which is under 3GB for system+apps. I'm glad i don't have much video, life would be much more challenging.

[jgreen]

Good points, Hitman.  To clarify, I'm currently still spread out over a randomly-sized jbod while migrating to the 500gb's.  Why the 500's?  Because they're the current sweet spot for price/capacity, and they look like they'll be available for a while into the future.  So i bulk up on the 500's now, and worry about the future mirror set when I get to it. 

750 gb is a figure I pulled out of my, er, hat.  I agree it's overkill but I need something bigger than 500 to allow for tag changes, etc.  I just recalled that you're not writing tags anymore, but that's not for me.  Plus, incremental backups allow for greater recovery from driver error.  Say I mistakenly overwrite the extended version with the radio edit, thinking it's a dupe just because it's the same name.  With a robust inc backup, I can get the old version back again.

By the time I get the 750's they'll be cheaper than the 500's are today, so I'm not much in the sweating mode on costs.  But after kicking the tires of dedicated server appliances for two years now, I can see that the need for a complex RAID scheme has gone out the window, along with the 24-drive box.   

[benn600]

Phwew...I only have 16 drives...not 24!!!  Although I seriously considered it I would have paid thousands more.  Jbod is junk on its own remember. I cringed when I read a statement above that jbod provides redundancy.  The reason I chose raid 6 is because of the failure rate with 16 drives. Drives are more likely to fail while rebuilding so one failure can easily lead to another.  Plus, errors are very common so double parity can help correct them.  I haven't had any of these drives fail yet!!  They range from 2-12 months in age.  On iPhone...slow writing!

[bspachman]

An update...

Well, the last of the CDs was ripped today. Slow and steady does indeed win the race.

Thanks for all the advice. It does seem that making sure that my APE file matches the existing MC Library pathname is all I need to worry about in terms of making everything link up.

Some judicious use of the IsMissing([Filename]) expression helped me find the double handful of APE images that I misnamed or mis-filed.

I'm now 75% of the way through transcoding all of the APE/APLs back to m4a files for use with my iPod. Again, since I have all of those files in the library as well, I'm hoping that matching up the paths will take care of everything.

Whew! Thanks again!
Brad