[ale] OT: MySQL Blobs

[F. Grant Robertson]

Your media drive (or drives, or partitions..) could be mounted read only. That would save (I'd think) your media from any harm. If you ran ext3 or reiser or something on the drive containing the mysql data, you'd be reasonably sure that it could be revived easily. If that fails, mysql has ways of fixing tables. And hey, after all, this is just a stored stack of data about the files on the read only drive.. you could always just reindex them! The script I'd written would completely reindex (starting from a blank db) about 25 gig of mp3's (badly organized, with lots of dupes) in just a few minutes. A "hot" reindexing took a bit longer.. Get file meta data (id3, size, frames, md5), select from table for that md5 sum, if the sum exists, update the row.. if the sum didn't exist, insert a new one.. repeat. And, unless the thing went down while major inserts were going on, it should be pretty straight anyway. You might lose the last song you popped on to the playlist.. but the index of files wouldn't have been recently changed, therefore nothing to corrupt. I know this might not _always_ be the case, but for home hobbist use, it's really pretty solid. 

The only real problem I hadn't solved was tight integration of id3 data, where if you changed it at the db level, it would change the file to match. I'd planned to solve it in the player, between each song played check for files that got updated, if any did, write out the new ID3 data and continue playing music. Never got to that.

-G


-----Original Message-----
From: ale-admin at ale.org [mailto:ale-admin at ale.org]On Behalf Of
To: ale at ale.org
Christopher Fowler
Subject: Re: [ale] OT: MySQL Blobs

Great points.  I'll have to take this route.  The next soultion is where I 
should store the database on files to eliminate any possible corruption on
power off of the device.  

_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale