[4.1.5.1715] Database disk image is malformed

[uziubalmy]

my db is corrupted!!

Could not retrieve data "SELECT Songs.*
FROM Songs, Medias WHERE Songs.DateAdded>41911.336550984 AND Songs.Rating>=16 AND Songs.IdMedia=Medias.IDMedia ORDER BY Medias.ShowLabel, Songs.SongPath COLLATE USERLOCALE
" : database disk image is malformed (11, 11).


Could not retrieve data "SELECT Songs.*
FROM Songs
WHERE ( Songs.TrackType in (0,4) )
" : database disk image is malformed (11, 11).


i've about 8TB of tracks (I can't see how many they are becouse the db is corrupted! i think more than 500.000 and less of 1.000.000)

Yesterday I've added about 300GB of tracks.

now the db is corrupted!!

please help!

[Lowlander]

http://www.mediamonkey.com/support/inde ... -malformed

[uziubalmy]

Thanks, but as you can imagine I perfectly know that I can delete the db.

But I have hundreds of playlists and thousands of playcounts that aren't tag in the file and the ratings in the db not Always are the same of the file.
For me make a db from zero is not a choice.

I've a backup of ten days ago, but in these days I've do a lot of things on the added tracks.... I know that it's my fault that I don't have a back up (1,6GB of dayily backup can happen that the space is not enough sometimes and the backup stops for few days)

so I tried to use sqlite3.exe, I can dump perfectly all the sql. The problem is the IUNICODE collation is not supported and I can't remake the db.

So I tried softwares that can load the dll with the IUNICODE collation like SqliteBrowser and SQLiteSpy.

SQLiteSpy can't export/dump the db/sql.
SqliteBrowser can do the dump with no problem, can make a new db, but when I try to execute the sql exported it crash (its 1,3GB of sql file, I don't know if it's the size or other...)

and hower also with SQLiteSpy that is fully supported with the mediamonkey.dll gives an error reading the db (unkown tokenizer: mm) on a table (songstext)

reading on internet seems that if there were not all these specific things (like the custom collation) people can restore a corrupted db with sqlite3.exe.

it' scandalous that in 2014 for a simple writing error there are engines that corrupt the db.

opensource enginees of my in then BallmerWorldOfSqlCEOrSqlServer would never have happened.

[Lowlander]

http://www.mediamonkey.com/forum/viewto ... DE#p395025

[uziubalmy]

http://www.mediamonkey.com/forum/viewto ... DE#p395025

as I told before I already try to use the dll with the collation

however, after a day spent trying to repair the file, magically now it works. I can't say what it fix it, I think this

http://stackoverflow.com/a/5274326
shell$ sqlite3 some.db
sqlite> begin immediate;
shell$ cp some.db some.db.backup
shell$ exit
sqlite> rollback;

that was one of the script that I've tried at the begin, but it gave me errors on the rollback so I think what it fix it it's simply
sqlite> begin immediate;

otherwise I really don't know...

what really makes me worry is that it could happen again at any time.

[Lowlander]

From my experience this happens mostly when MediaMonkey is closed (normally forcefully) during a database operation (commonly Maintain Library). If the database is important make sure you back it up often. Mine is and I do a nightly backup as well as a weekly sequential backup (so I can go back several weeks in case there is a lingering corruption).

If Playlists are important you still should do the database backup, but you can also backup Playlists by exporting them. Export/Create Playlists 4 Child Nodes can do this automatically: http://www.mediamonkey.com/forum/viewto ... d+playlist

Also see: http://www.mediamonkey.com/forum/viewto ... lit=backup

[uziubalmy]

from 2010 i'm using mm and I never had this problem before. I just think that sqlite is not enough robust for make large db with so sensible data (in my case ratings playcount and playlists, data linked to a songs table that contains too much rows... in fact the performance when the songs are 2-3-400.000+ are really bad)

for making backup I simply syncronize every day the mediamonkey folder that contains mm.db, and all the times that I've restored a mm.db it Always worked, however thanks for the help.

[rusty]

fyi, re. performance, we've found that it's a question of how much memory you have. i.e. as you scale up with the number of tracks, you'll need more RAM to maintain the same level of performance.

Unfortunately, I can't tell you exactly how much memory--it really depends on how you use MM.

-Rusty

[uziubalmy]

I don't think I have ram problems. My cpu is an athlon x6, not very fast i know but the ssd with 500MB r/w on where the mm.db is locate make the difference.

I think the only thing I could do for make MM more fast is buy an i7 and make a RAID0 with 2 or more ssd.

obv. the other way is that the MM develop team optimize MM in fact I made a request in the wishlist about the filters for the autoplaylist.

but i.e. thera are case where MM freeze becouse of too much songs/artits/albums/genres..., like when you open the property dialogs of a track, automatically MM load all the lookup of this fields. for 30-60seconds you have to wait that mm finish to load them(I think it make a DISTINCT on the songs table for the artits/albums/genres... so in fact I never open the property dialog, with the com library i made a program for edit the tag.