I tried your sqlite method, but i got an error when importing the sql file. Do you think i’ll be able to recover cuepoints if i make a new library and copy my old P file?
what is the size of your file p.db?
I can try to repair manually the database next week if you upload the file
Its just above 0,3gb. But its the m.db file that is corrupted it seems like, the m file is 0,04gb.
Maybe there should be a single email address or ftp upload site given by denon or any other database specialist for all of us to send our corrupt databases to.
Maybe there’s a common factor as to why the engine prime database seems more fragile than a glass egg and as volatile as some “do not shake” liquid explosive, on a washing machine on its final spin cycle.
Like is engine prime leaving records open after writing? Is the last hot cue in the last file in a database most commonly going to corrupt? Is the corruption more likely to happen if a hot cue is deleted (shift + hot cue pad)? Is the corruption more likely (or only) on the remotely connected networked player not the player with the hard drive plugged in? Does corruption happen when the mixer is doing something in particular (as the mixer is the network hub for separate primes)? Does searching for songs confuse the writing back to the database? Does writing to the played history file foul up the database writing to the individual music files? A file is only considered “played” if it’s been playing for 30 seconds - so if a different database action is performed in this 30 seconds, does that writing to the played history file get askewed? We often DJ through midnight… from one day into another… so if database record is opened on 16th May but isn’t closed until 17th May, does that confuse things? What if we Start to play a track at 15 secs before midnight and the played history 30 seconds then happens 15 seconds into a totally different day… does that corrupt things? Like this stupid muscle memory thing, where the cue point changes to being the end of the track because we pressed cue to stop the song playing when we’ve mixed out of it, somehow set the cue point to a negative value, when the databse only wants absolute positive values?
Maybe the debug route is to have a whole list of database actions with on/off switches in the preset menus and switch all of them off bar one (at a time), use the players at home (we’re all at home now right) and see who gets a corrupt database when they’ve only got the “erase deleted got cues” option switches on etc, to narrow down the database event that’s causing so much corruption.
Indeed, given the capricious state of the database,
Denon should schedule a test each time it starts, a single command line “PRAGMA INTEGRITY_CHECK”.
Test OK: Nothing to do.
Test Not OK: Restoring the backup.
When switching off, test “PRAGMA INTEGRITY_CHECK”:
Test OK => Automatic backup.
1 Like
Well Graham.O fixed it, i dont know how but you saved me a lot of time, thank you! I also wanna thank everybody else who took their time to try and help me.
2 Likes
Nice one @Graham.O.
There were a lot of rows/indexes missing or not? Fix was a manual task? I’m no DBA, so thanks for the assist.
Import table by table.
All the rows must be present, but with the table import manually, some analysis curves or images can be disturbed (Some characters are not liked in databases).
Remember to never use exotic characters in file names, it avoids worries 
Okay, but you’re talking about the p.db. I tried to auto fix the m.db. Also tried to import to an empty m.db, which failed also.
Hadn’t tried table by table.
Again, all above if someone has nothing else.
Order is simple to determinate.
if you see “FOREIGN KEY” in the schema, it’s necessary to import the reference table before Example : CopiedTrack => FOREIGN KEY(“trackid”) REFERENCES “Track”(“id”) => IMport before table “Track”
The first table to import is “AlburmArt”,
Second “Track”,
Third “List”
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.