That explains everything.

Check Indexes size.

I poked around with other Media Managers and realized why I had so many problems with database corruption.

When I explore my database, I go from view to view, and tend to go faster than Media Monkey on my computer can handle. I Start in a tab with a more generic list of items, and find something I want to dive into while the view is still loading, so I'll switch to another tab, or collection before it is done loading. I had no reason to think that my database would be corrupted if I'm just running a query against my database. It turns out that in Media Monkey it can. I would get strange results first, and if I didn't do a backup / Optimize I would get corruption sooner rather than later.

I discovered this when I created a new library in Music Bee and did what I always did in Media Monkey. What I found, was that the other application either loaded the alternate view so quickly that I had no opportunity to get the same behavior, or If I did manage to try a different view before the first was done loading, the program became unresponsive, and switched to a "Waiting" mouse pointer for the couple of seconds it took to finish.

So, now I've changed how I use Media Monkey, and have had no problems since.

Having looked at the internals of the database, and guessed at the actual SQL being run. You are correct. The database could be way more efficient.

600MB for 60,000 tracks comes out to about 10KB per song by my math. At 2000 characters for a page of double sided, that's roughly 10 pages of text. Allow for half of that as overhead, and 5 pages of double-spaced text is still a lot of metadata on a song, even with lyrics. Not to mention opportunities for streamlining the database.

[quote="Lowlander"]600MB doesn't strike me as odd, mine is 1.5GB.[/quote]
How many tracks do you have?

One factor which reduces my db size will be my track file names. All of my track file names are just album track numbers; eg 01.flac, 02.flac, etc

I did this to optimise capacity in my Sonos units, as they store the whole index in ROM to optimise browsing response times.

You lose nothing because none of the music clients use track file name for anything useful in their UI, and full name can be restored, by MM, if it ever becomes important to me.

600MB doesn't strike me as odd, mine is 1.5GB. Once you start adding text like Lyrics and Album Comments the database starts to grow quickly (any non-tabled field will add to the size more significantly). From what I gather a benefit that MediaMonkey has over others is that a lot more metadata is contained in the database which means it becomes searchable/usable in AutoPlaylists/Collections. This does result in a larger database as a downside and likely inevitably a somewhat slower operation (I always wondered if the SQL that's executed couldn't be more optimal). The main bottleneck will be hard drive access, something I see general on my laptop (when PC is slow it almost always is HDD access at 100% not CPU).

[quote="NewtonBoy"]I use the Backup script, and it's awesome, until you find the corruption and go to your backup, but that has the same problem. So you go back further. But it turns out that a 600MB database takes up a lot of space, .....
[/quote]

Why is your database 600mb?
I have 40,000 tracks, 3,110 hours of music. So not too far from you, according to your forum signature.
The MM database is 120mb, which reduces to just 11mb when zipped for a backup.

There is also something off about the number of database corruptions that you are experiencing.

I have my MM database open all day, every day. I do a fair amount of additions and re-tagging.
And I update it daily with imported play counts from Last.fm, as well as observations of what gets played by my Sonos system. All play details get added into MediaMonkey; around 27,000 new tracks plays every year.

I have been doing this for 6 years, and have never had a MM database corruption in all that time.

Over the past 7 years, I spend 5 to 6 hours a week using Adobe Light room, so roughly 2000 hours. I backup my Catalog Every time I close the application. I reinstall the application everytime I get a new computer. which works out to three times in 7 years.

I have spent probably a solid 100 hours over the past 3 months tagging files in Media Monkey. Before that I had a spree where I spent a good 200 hours fixing spellings and Genres. I think I remember one a few years ago where I did a general skim through all my files, that I probably had a good 40 hours in. Outside of that it's usually an hour here or there where I play with playlists. Call it 1000 hours of heavy usage, and more than that just hitting play.

I use the Backup script, and it's awesome, until you find the corruption and go to your backup, but that has the same problem. So you go back further. But it turns out that a 600MB database takes up a lot of space, and you trimmed some of the older backups, but all the ones you saved have the same problem because it was some weird thing that hadn't come up before. So, now what? You rebuild. Again. Hoping that all of the tags were saved successfully. Usually they are, but sometimes they aren't. So you have to go through your files again, and try to find the problems.

Or, something happens to the application files, and you have to reinstall. I've got 4 portable installations on my external drive right now. I don't bother backing up the application, because I don't have any major customizaton anymore, it takes too long to reproduce. I run a generic install, install the plugins I use, and make the couple of changes in settings, done in 15 minutes.

I have NEVER, [b]EVER[/b], had to restore my Light Room backup because my catalog got corrupted. I've had to do it because a drive failed, but that's why I do backups. Not because my files got corrupted from use.

I agree my DB is from 2003 and I occasionally backup MM.DB (Manually) with simple BAT File on system startup I have never experienced complete Crash. I even use Nightly builds and even sometimes compile source code to test changes which is never recommended with working DB.

[quote="terryo"]until mm.db takes it's roughly annual crap and corrupts. When forced to do a recovery, I'm fuming as I laboriously prepare by backing up all my playlists[/quote]

I don't get it either. Do you have any ideas on why your .DB gets corrupted, annually?
Do you use backup 6.0 add-on, and regularly backup media files?

Restore/Synchronize Database add-on could export/import static playlists/auto-playlists to/from backup files.

I don't know what you guys are doing, but I'm still on the same database from 2004, despite using it daily and going through most betas.

Why not create more backups so you can revert to an older database when you corrupt the current one?

The ability to export AutoPlaylists has been requested before as well as the abiltiy to export nested Playlist structure.

That's the exact reason I gave up on nested playlists.

In fact, I mostly gave up on playlists altogether because I was so tired of recreating them when I had my yearly crash.

Lately, I've had great luck in using a portable install, and running the "Backup 6" script every couple hours of use. I also run the "Full Optimize obsessively. I still have problems, but at least I don't have to go back too far to recover.

Same here. And with the 'startplaylistfromstart' to work, even when minimized.

Playlists are crucial to the my use of MediaMonkey both on the PC and on Android. I wish there were better tools for playlists. I limp along with the present capabilities until mm.db takes it's roughly annual crap and corrupts. When forced to do a recovery, I'm fuming as I laboriously prepare by backing up all my playlists one by bone, pulling apart the nested folders for individual storage, all of which is unreasonably time consuming. (Getting them setup after importing them is a pain in the ass too, but covered on a different wish list item)

Here's what would help:
-- Batch transfer of playlists to and from backup files, storage arrays and other computers.
-- Ability to delete from the playlist "Recently Added" without deleting files from the library. After recovery, my entire library is in "Recently Added."
-- Nesting (folders of playlists) that can be imported and exported and replicated properly on synced machines. I depend on one PC and two laptops to do a weekly radio show. This feature would tremendously enhance my user experience and capabilities.