Okay this database stuff with jEmplode is getting a little crazy. I previously reported that I was getting warnings about something wrong with my DB. Well I upgraded to 32 and today instead of a warning I got "1 errors were fixed. Synchronize to save the fixes." Emplode isn't finding anything wrong with it... Is jEmplode's database checking somehow stricter than Emplode's? After turning debug up I see the line "There was no tune or playlist that has ID 272" and I think that might be due to the fact that an Emplode sync crashed and I had no recourse but to reboot while my drives were still RW. I'm still assessing whether any damage was done... But why wouldn't Emplode find this too?

By the way I did the drag and drop again with debug turned up and I'm getting an OutOfMemory error:

1016664710723: Recursing playlist repair/check: Soul (fid 29792)

1016664710723: Finished recursion of playlist Soul (fid 29792)

1016664710723: Finished recursion of playlist Urban (fid 26192)

1016664710723: Finished recursion of playlist Singles (fid 29968)

1016664710723: Finished recursion of playlist All Music (fid 256)

1016664710723: There was no tune or playlist that has ID 272

1016664710723: Finished tree->Repair() recursion

1016664710723: Checking reference counts

1016664710723: Finished checking reference counts

java.lang.OutOfMemoryError

	<<no stack trace available>>

.

Any idea? I've got 256 MB physical and some 512MB swap, task manager reports a boatload of free memory... Is there a way to give the JVM more memory to play with, or does it automatically take what it needs to take?

Sigh. My next step is to try JDK 1.4 and see how things roll with that. I'll keep you posted.

Update:
Well I installed JVM 1.4, rebooted, and same behavior. The folder I'm drag-and-dropping contains about 570 MB, but it's not like it should be allocating 570MB of RAM at once... Right?