haha, i’m glad to upload again if you need anything else.
Now i’m being the pain, i apologize, i forgot to add in the database2 folder into that zip… I can upload it separately if you would like.
I can’t seem to back up my database. I’ve been rebuilding my crates by hand (see top thread re: empty crates) which is going fine and everything loads nice, but if I try and select the back up library when I quit, it goes a bit, then says there was an error. At the end of the log file I see this:
[W] bool __cdecl libraryBackupManager::utils::isDBFile(const class QString &) Cannot read "D:\\Dropbox\\Music\\Engine [2021-10-06T14:01:42.597Z] [air.planck.library.manag]
[W] Library\\Engine Library - Shortcut.lnk\\itm.db" [2021-10-06T14:01:42.597Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::utils::copyRecursively(const class QString &,const class QString &,int &,const [2021-10-06T14:01:42.598Z] [air.planck.library.manag]
[W] int,class std::function<void __cdecl(double)>,class QString &) Cannot copy from "D:\\Dropbox\\Music\\Engine [2021-10-06T14:01:42.598Z] [air.planck.library.manag]
[W] Library\\Engine Library - Shortcut.lnk\\itm.db" to "D:\\Dropbox\\Music\\Engine Library Backup Temporary\\Engine [2021-10-06T14:01:42.598Z] [air.planck.library.manag]
[W] Library - Shortcut.lnk\\itm.db" [2021-10-06T14:01:42.598Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::LibraryBackupManager::backupAndProcess(enum libraryBackupManager::LibraryBackup) [2021-10-06T14:01:42.598Z] [air.planck.library.manag]
[W] Failure while trying to copy from "D:/Dropbox/Music/Engine Library" to "D:/Dropbox/Music/Engine Library Backup [2021-10-06T14:01:42.598Z] [air.planck.library.manag]
[W] Temporary" [2021-10-06T14:01:42.598Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::utils::removeRecursively(const class QString &) Failure while trying to remove [2021-10-06T14:01:45.726Z] [air.planck.library.manag]
[W] "D:/Dropbox/Music/Engine Library Backup Temporary/Engine Library - Shortcut.lnk" [2021-10-06T14:01:45.726Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::utils::removeRecursively(const class QString &) Failure while trying to remove [2021-10-06T14:01:45.727Z] [air.planck.library.manag]
[W] "D:/Dropbox/Music/Engine Library Backup Temporary/Engine Library - Shortcut.lnk/exiftool.exe" [2021-10-06T14:01:45.727Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::utils::removeRecursively(const class QString &) Failure while trying to remove [2021-10-06T14:01:45.727Z] [air.planck.library.manag]
[W] "D:/Dropbox/Music/Engine Library Backup Temporary/Engine Library - Shortcut.lnk/ffmpeg.exe" [2021-10-06T14:01:45.727Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::utils::removeRecursively(const class QString &) Failure while trying to remove [2021-10-06T14:01:45.728Z] [air.planck.library.manag]
[W] "D:/Dropbox/Music/Engine Library Backup Temporary/Engine Library - Shortcut.lnk/ffplay.exe" [2021-10-06T14:01:45.728Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::utils::removeRecursively(const class QString &) Failure while trying to remove [2021-10-06T14:01:45.728Z] [air.planck.library.manag]
[W] "D:/Dropbox/Music/Engine Library Backup Temporary/Engine Library - Shortcut.lnk/ffprobe.exe" [2021-10-06T14:01:45.728Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::utils::removeRecursively(const class QString &) Failure while trying to remove [2021-10-06T14:01:45.729Z] [air.planck.library.manag]
[W] "D:/Dropbox/Music/Engine Library Backup Temporary/Engine Library - Shortcut.lnk/flac.exe" [2021-10-06T14:01:45.729Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::utils::removeRecursively(const class QString &) Failure while trying to remove [2021-10-06T14:01:45.729Z] [air.planck.library.manag]
[W] "D:/Dropbox/Music/Engine Library Backup Temporary/Engine Library - Shortcut.lnk/metaflac.exe" [2021-10-06T14:01:45.729Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::utils::removeRecursively(const class QString &) Failure while trying to remove [2021-10-06T14:01:45.730Z] [air.planck.library.manag]
[W] "D:/Dropbox/Music/Engine Library Backup Temporary/Engine Library - Shortcut.lnk/NTUSER.DAT" [2021-10-06T14:01:45.730Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::utils::removeRecursively(const class QString &) Failure while trying to remove [2021-10-06T14:01:45.730Z] [air.planck.library.manag]
[W] "D:/Dropbox/Music/Engine Library Backup Temporary/Engine Library - Shortcut.lnk/Reflect_Install.log" [2021-10-06T14:01:45.730Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::utils::removeRecursively(const class QString &) Failure while trying to remove [2021-10-06T14:01:45.730Z] [air.planck.library.manag]
[W] "D:/Dropbox/Music/Engine Library Backup Temporary/Engine Library - Shortcut.lnk/sort.ps1" [2021-10-06T14:01:45.730Z] [air.planck.library.manag]
[W] bool __cdecl libraryBackupManager::utils::removeRecursively(const class QString &) Failure while trying to remove [2021-10-06T14:01:45.731Z] [air.planck.library.manag]
[W] "D:/Dropbox/Music/Engine Library Backup Temporary/Engine Library - Shortcut.lnk/_2021-09-09" [2021-10-06T14:01:45.731Z] [air.planck.library.manag]
[W] void __cdecl libraryBackupManager::LibraryBackupManager::cancelDatabaseCopyingProcess(void) Failure while removing [2021-10-06T14:01:45.731Z] [air.planck.library.manag]
[W] temporary databases [2021-10-06T14:01:45.731Z] [air.planck.library.manag]
Not sure if this is related, but just in general when the app starts up and reads my db, I see a tooon of messages like these:
[W] Tag is corrupted - unknown type (repeated 478 times) [2021-10-06T13:54:33.816Z] [SeratoDB ]
[W] Tag is corrupted - unknown type [2021-10-06T13:54:33.816Z] [SeratoDB ]
[W] Track was not found in analysis progress queue. Universal track id: 412 [2021-10-06T13:54:33.816Z] [air.planck.analysis ]
I have a feeling they are harmless, as I don’t use Serato (notice it says “SeratoDB” after the timestamp: Furthermore this ONLY appears in the log for SeratoDB), Rekordbox, Traktor, iTunes, or anything besides purely Engine Prime. Never have never will, too messy. Anyway, the above probably isn’t an issue or part of the problem but figured I’d post it just in case.
I have tried nuking the Database2 folder and retrying but it doesn’t help (just re-analyzes it all and results in the same thing). LMK if there’s more log info you want.
Edit: In case there was a permission issue regarding the errors in the log I posted, I added the EP folders to the dropbox exclusion list, and then also quit dropbox entirely. I also added the EP folders to my windows and malwarebytes virus exclusions lists. Also quit them as well, just in case some other process was interfering. Same results (nothing new to add log-wise). I forgot to mention that after the attempt to backup the db fails it tells me that I have a corrupted database.
I think I found the cause and solution of my db issues! So after migrating from 1.6.1 to 2.0, I noticed that it no longer uses “m.db” and “p.db” in the root “Engine Library” folder, and instead just uses a single “m.db” which also contains the performance metadata from “p.db”. I opened up m.db in my database editor and I found that for my crates that were all missing files, if I opened the “PlaylistEntity” database table, I noticed that the empty ones contained a value of “0” for the column “databaseUuid” whereas the ones that I had by hand fixed contained an actual UUID for this field (the db UUID is the same for it all, like I said, I don’t use anything but Engine Prime). This UUID being of course the sole entry in the “Information” table which in my case is 5f40819f-96d5-43f7-87cd-c4d74c30c552.
I went back to the “PlaylistEntity” table, and ran a SQL query to update everything in the “databaseUuid” column with a value of “0” to my DB UUID and all my crates were fixed and back to normal!!!
The weird thing is that for the crates that I had “fixed” by hand (3 of them), the EP software didn’t update or fix the existing entries in “PlaylistEntity”: It actually created a duplicate crate with the exact same “listId” value and just simply filled in the correct db uuid, meaning I now had 2 duplicate entries in my database for the same crate ID. This causes a violation of the table’s unique clause(s) as well as being invalid, so I deleted the entries in this case with a value of 0 fixing that problem.
TL;DR: I fixed this by updating everything in the “PlaylistEntity” table column name “databaseUuid” with the DB UUID from the “Information” table for all fields that previously only contained a value of “0”.
While this fixed the problem of my crates being empty, it still hasn’t solved my problem with being unable to back up my db on exit, I get the exact same log entries. Linked is a zip with the latest log after having fixed my db by hand, as well as the 1.6.1 versions of m.db and p.db if you would like them for testing purposes. It was too large to upload here: Dropbox link to files
Also in case it’s of any use, here’s 2 snippets of what my pre fixing db version 2 looked like showing how I had 2 crates with identical IDs but one had a value of 0 for the db uuid and the other was correct.
1 Like
@codemov same problem me too… i don’t know what to do … i think i will go back to 1.6.2 with Engine Prime if you don’t find the problem.
Hi all, same here. Did an upgrade from 1.6.1.(all working fine) to 2.0,which afterwards gave me a corruption error message (Engine Library on C: is corrupt). Already reran the job with removing the Database2 folder. Do you need me to upload any database/trace file? And if so, where can I drop these?
- Database files are on C:\users\username\Music\Engine Library\ (m.db, p,db etc,
- Logs from C:\Users\username\AppData\Local\AIR Music Technology\EnginePrime\Logs
- Anything else?
Wondering if it is possible to use the database files from the Denon Prime’s 4 internal disk, as a backup scenario? Can these be place locally and run the upgrade again? Most of the Crates/Songs stored locally are already exported to the Prime 4 so they are in its external db already. This would lessen the time to recreate all Crates/Playlists if the corruption cannot be repaired locally.
Many thanks,
Jack
Did you by any chance back up you c:\users\bla\Engine Library\m.db etc files before the upgrade? If you did, you could always nuke the contents of your Engine Library and replace these. You’ll still probably run into the 2.0 upgrade issue but could always stick with 1.6.1. If you did not, you could with some finagling use your Prime 4’s internal drive as a backup. The only real issue is the path mapping: The file structure is stored differently (in most people’s cases) on the exported drive than your main pc drive. Basically on the exported drive the path format is Music/Album Artist/Album Name/Track Name.mp3, with the caveat that because it assumes lowest common denominator for the drive format (FAT32), special unicode characters get replaced. Like Umlauts become…I don’t recall, it was some other symbol, and various other non-ASCII characters are replaced with pure ASCII. You could try to uninstall 2.0 then reinstall 1.6.1 and see if you can’t sync back your Prime 4’s contents with the older app (and while you’re at it, take this time to 100% back up that Prime 4 drive just in case). For me, syncing didn’t work at all in 1.6.1 and I wrote a tool to import wholesale the contents of my external db, but I was only using Engine Prime, I didn’t also use Serato or Traktor or iTunes. Sooooo I guess what I’m saying is try this:
- Backup right now your Denon Prime 4 internal disk, the entire thing
- Just in case, backup the contents of your C:\users\bla\Engine Library, the entire thing
- Uninstall 2.0
- Nuke the contents of your Engine Library folder
- Reinstall 1.6.1
- Run 1.6.1 once then quit: This makes dummy/initialized databases
- See if by using 1.6.1 you can sync back the data from your Prime 4 drive
- If that all fails, and you’re only using Engine Prime for your data management, feel free to message me and I can see if the tool I wrote would work in your scenario to get your stuff back and working at least for 1.6.1.
- Another option is if you’re comfortable with SQL or editing databases, you could use a tool like “DB Browser for SQLite” and write a query or by hand fix your paths. The paths are contained in the m.db database (or im for itunes sm serato etc) in the “Tracks” database table. Just throwing it out there. The databases are surprisingly not too complicated and aren’t encrypted at all.
1 Like
Hi, Thanks for the info. I indeed had a backup, so reverted to 1.6.1. I am now using the Engine sync tool on 1.6.1 to make a copy of my songs, crates and playlists to an external drive. When done, I will remove the local database files and hook up the external disk, and sync it back. This way I hope to have a clean database to get migrated to 2.0. I could have used the Prime 4 to get it synced back, but always handy to have an extra backup.
I previously had some records in the Track table pointing to earlier added songs. The folder/location for these files were changed but the Engine "cleanup job did not remove them. With the tool SQLiteStudio I removed these entries and tried the 2.0 upgrade again. This did not succeed. So now doing the Engine Sync as a workaround. I will keep you updated.
Jack
Hmm… I was under the impression I could sync back from external drive to local, but this is only for changed cue points etc. I’ll try to see if restoring via Prime 4 will work.
In the meantime I did some consistency checks and also vacuumed the m and p databases. What I noticed is that my p.db has a corresponding p.db-journal file. and these are about the same size, 4.8Gb in size. Compared to all the other *.db and *.db-journal this p.db-journal one is very large.
Temporary I removed this p.db-journal file from the Engine Library folder. Then I did upgrade to Engine 2.0. This gave me the corruption error. Engine 2.0 did not exit as it did each time after upgrade, but kept working/active. I guess because I had the external disk attached with a 1.6.1. database present. So I am suspecting something wrong in the p.db file, causing p.db-journal to grow(like transaction logs being used with other versions of SQL). When I look back at my backups created per version, I see the size of the journal file already being large as from version 1.3.2
Well, I now have a working external 2.0 Music disk, exported via 1.6.1. and converted it with Engine 2.0. How to get this 2.0 data back to the local disk (c:)? Sync does not allow me to get it synced back to local drive.
Please let me know if I still need to upload my original 1.6.1. database/logs/etc for your investigation.
Kind regards, Jack
It was to be expected that Syncing from the Prime 4 did not work either…
Went back to 1.6.1., restored DB for 1.6.1 and … So before you follow below steps, Backup Backup Backup!!
For the fun I picked the p.db from my Prime 4, and replaced the p.db file on
C:\users\Username\Music\Engine Library
Started Engine Prime 1.6.1, and hey, all my ratings, crates and playlists were still there. Trackinfo is stored in m.db, so ratings, crate/playlist info is kept after replacing the p.db. Maybe someting to try out when having corrupt p.db files.
The only mismatch I initally saw was that my analysis was from the wrong song. This can be fixed by choosing “Re-analyse Tracks” in Engine Prime.
If I look at the p.db tables, I also see CUE/Loops and referrals to Serato and Recordbox so these can be mismatched/gone when swapping out the p.db
Running the upgrade with the Prime 4 p.db in place, still gave me the same error 2.0 corruption error.
Jack
OK so I did another attempt at this and I fixed even my inability to backup my database problem: the one where it kept saying that the db was corrupt but ONLY when I tried to backup my database. So here’s what I did. Starting back with my post from 6 days ago where I explained my missing database UUIDs (the one w/ the 2 images), I backed up the entire Engine Library folder. I then uninstalled 2.0 and totally nuked the Engine Library folder. I also went into my %appdata%…\Local folder (%appdata% on windows by default takes you to the “Roaming” subfolder) and noticed that it kept around the “AIR Music Technology” folder which I also manually deleted. I then reinstalled 2.0 and ran it once so that it could create/initialize blank databases and then I quit.
I looked at the new Engine Library folder and realized that the new databases are all just stored in the Database2 subfolder: there were no longer any files in the root Engine Library folder like where 1.6.1 used to place its files. Whereas if you had done an upgrade from 1.6.1 to 2.0 it would have left all your 1.6.1 related files in the directory above at the base Engine Library folder.
ANYWAY, I then copied over my “m.db” file from my aforementioned fixed edits I had made on my previous 2.0 install and lo and behold: no more errors upon trying to back up my db or export to my usb drive! So I don’t know if the problem was the files that 2.0 left around (I highly doubt this: the time stamps never changed so it wasn’t modifying them), or if the other db files themselves had some sort of corruption, and that by doing a reinstall and a fresh run to create blank databases, I fixed the issues with the other files I wasn’t using anyway.
I don’t know if this would work for everyone, since I don’t use other library software, so that’s how I was comfortable knowing that all I needed to copy back over was “m.db” and none of the other files, but I’m posting this as a potential clue for the devs as I have now solved ALL my issues with my dbs and 2.0. LMK if you want any of the log files from this fixed process. They’re not really that informative, they just don’t include the errors about having file issues with the backup folder.
Edit: One thing that’s different that I noticed with this fixed situation is that the new 2.0 database named “hm.db” doesn’t contain data, whereas when I migrated from 1.6.1 to 2.0 it contained like some random chunks of data, maybe a few dozen entries out of the 615 tracks I have in my library. I don’t know what “hm.db” is but looking at it, it looked like it contained some duplicate info that “m.db” already provides like paths and album art. I’m assuming the “h” is for history? I don’t know if that was an issue. Just providing another data point for diagnosing.
Okay, so we can all roll back to 1.6.1… Status says [[CONFIRMED]]. Does that mean a fix will be available shortly, or do we have to wait a few months before Denon releases a new Engine version? I already bought the USB<>DMX cable, so i am eager to get my hands on 2.0 (no, I am not going to recreate all crates and playlists. It all worked fine in 1.6.1.)
I am willing to test any SQL script or other related code piece to get it solved. Hope to hear,
Kind regards, Jack
@Jacksan I’m actually on 2.0 after the fixes I made with a non-corrupt and totally working 2.0 db migrated from 1.6.1 now. Were you only using the Engine Prime software (either on PC or on your device)? If so, you could try this as it worked for me. Firstly though, what’s the state of your database? Do you have a working db in 1.6.1 that the desktop Engine Prime app can open? If yes, try this:
- Backup your Engine Library folder (Which I believe you already did)
- Upgrade to 2.0 and get yelled at about database issues
- Can you see your tracks at least in the main collection crate? In my case I could see some of my tracks but the crates were all mangled. If you CAN NOT see any/some of your tracks proceed to step 4, if you CAN see your tracks just fine proceed to step 5
- Open your Database2\m.db file and look at the “Path” column in the “Track” table. Look at the relative paths listed: this is where all your tracks are located RELATIVE TO THE ENGINE LIBRARY FOLDER, not the Database2 folder. Are these paths valid? If they aren’t, you need to fix it so that these paths point to the correct location of your tracks. And if the “Filename” column also doesn’t match what you have on your desktop you gotta fix that too. Why might the paths and filenames look weird af? If you fixed your db by importing from your external drive, it tends to name things differently on the external drive than the desktop. You just need to make sure the desktop db is cleaned up and valid: if it is, exporting auto handles any path/file name changes needed as per the format (FAT32/exFAT) of the external drive. Anyway, point is, get your path/filename columns pointing to where your files are on your desktop. When you’re done with that, hop over to the “PlaylistEntity” table and look at the “databaseUuid” column: Are any of these blank or say NULL or 0? I had like a few dozen that did which prevented a bunch of tracks from showing up. If you’ve only been using EP and not other programs to manage your music, then have a look at the “Information” table, column “uuid”: If you’ve only used EP you should only have 1 row. Copy this UUID: that’s the id of your EP based database. Now go back to “PlaylistEntity” and set this UUID to the entire UUID column. Commit your changes. Now open up Engine Prime 2.0: Are your tracks now showing up? If not, abort, as I have no idea what’s up with your set up and revert to 1.6.1 with your backed up database. You may actually at this point be all good to go (I was NOT however, I still got database corruption issues when I tried to back up my DB). Try doing a database backup within the app (it’s in settings): If that suceeeds fine you should be good and can stop reading. If you get a database corruption error doing this, proceed to step 5.
- Backup all the “.db” files in your new Engine Library\Database2 folder (you no longer have need of the files in the directory above, those are from 1.6.1). No need to back up the TIDAL and other sub directories or the .lnk file.
- Uninstall 2.0
- Delete your entire Engine Library folder so that it doesn’t exist in the music folder.
- Look at C:\Users\Jacksan’s User Name On Their PC\AppData\Local and if you see an “AIR Music Technology” folder, delete it.
- You now have no EP software on your PC or traces of it. Install 2.0
- Run 2.0. This will create initialized and blank databases in the 2.0 format. Obviously no tracks appear. Yet. Quit 2.0.
- Take the “m.db” file that you either fixed or didn’t need fixing, from your 2.0 backup in step 5 and copy that to your new Database2 folder, overwriting the existing one. Do not copy any of the other databases over.
- Run 2.0: If you’re db issue was like mine, you should have a working 2.0 with everything fixed and no corruption errors even when you go to back up your database and exporting to your play drive should work fine.
1 Like
Hi, many thanks for all your help in this. It already keeps stuck at step 3. When the corruption message is shown and clicking OK, Engine Prime closes itself so nothing to be viewed.
But… Checked the logs in the Air Music technology folder. This came up for the upgrade: … [C] Error in StatementSqlite::executeForNextResult: StatementSqlite (0.000.01C.370.6ED.BC0), Status: Error
- Main db [2021-10-17T08:07:28.987Z] [air.planck.librarian ] [C] filename: m.db
- Query string:
CREATE TEMP TABLE listTrackChildren AS
SELECT [2021-10-17T08:07:28.987Z] [air.planck.librarian ]
[C]
ListHierarchymerge.listId, LTD1.orginTrackid… - Error: SQLITE_NOMEM ( out of memory) [2021-10-17T08:07:28.987Z] [air.planck.librarian ]
Well, had 16GB on board and inspecting the memory usage, it used up about 96% when upgrading the DB. Also had some stability issues during that time.
Upgraded my machine to 32 GB. Reran the upgrade. Observed the memusage via TaskManager and it kept about 95% (26GB max). Quite a lot, so was suspecting memory leakage… The upgrade worked as expected, so problem solved for me. The upgrade can consume quite a lot of memory, depending on the size of your collection I assume.
Before the upgrade, I also did remove all the incorrect file paths and added the correct DatabaseUuid in the 1.6.1. database. So it still can be a combination of incorrect info in the database and needed memory.
Everyone thank you for all your help! Hope this helps others as well.
Whoah that’s crazy about the memory usage! I have 32gb so I didn’t notice but that’s a good data point that hasn’t been mentioned/looked at yet. Out of curiosity, how many tracks are in your collection? I have like 600 something, not a lot. Given that you and I both had issues with the db uuid being incorrect/missing I’d say that’s a common point for the team to look at.
I have about 39000 songs. Well, the “out of memory” in the logs said it all. Thinking it will be different from what you have.
Almost all of the music in my collection does not contain MP3 Tag info, Album or Cover art. Artist/Title fields are always occupied, but the other fields hardly contains any data. The obsolete fields are normally removed with mp3tag.
With previous standalone Numark IDJ2/ Stanton SCS4DJ gear, this lowered the search time for finding a song on the libraries involved. The processing capabilities were not that high on those machines. I can imagine that it can play a part when running an upgrade. Now I looked into your trace files and see quite a lot of “tag is corrupt” message. Don’t know if this because of the tag in the database are being checked or if your music files being checked again.
For 600 numbers, you can easily test if the taginfo in the MP3 info causes issues. Backup these 600 files to another location. Use mp3tag to strip off all unnecessary Tag info from your mp3/other files. You can do this in batches, if you want to know which files are causing this. Function is called “Remove Tags” Mp3tag also has functions, to create tags from filenames or vice versa. So when you have removed the tags, you can convert the artist/title tagfields back from the Filename. I always use a file notation like “artist - title.mp3” When changed, there is always an undo function, so you can easily revert back to how the tags were before. Just try it for yourself. I hope I am clear enough. Another handy tool for checking your mp3 files on things like streaming errors etc. see mp3diags.sourceforge.net.
Hope this gets you further.
1 Like
Is this also a valid solution for people experiencing the 2.0 software not starting up after install? (seeming to start up for 1-2 seconds and then closing again) I have to admit this is all very complicated for an old school dj like me.
I admire your persistency!
Personally I don’t know as that’s not something that I’ve experienced so I can’t safely comment on that. What I’d suggest is to once again futilely start up 2.0, wait for it to close. Then go find the latest log file that it made, which is gonna be located (on Windows) here: C:\Users\nbraeckm’s user name on their computer\AppData\Local\AIR Music Technology\EnginePrime\Logs. The logs are named by date. Anyway, post the contents of that log. It may or may not have anything to do with your database at all. I actually had that issue with several versions of 1.x a while back which turned out to be related to some operating system weirdness (that’s about all I can figure out, since the issue cleared up when I had to for other reasons reinstall Windows).
Hi All,
Engine DJ v2.0.2 has just been released, which addresses the database corruption issues that some people experienced after updating to Engine DJ 2.0. Please download this version and try updating your 1.x drives again.
https://community.enginedj.com/t/engine-dj-v2-0-2-now-available/37126/2
1 Like
Hi, just tested the conversion from 1.6.1. to 2.0.2. and had no issue. Still I was running with 32GB and seen that Engine souped up about 26GB of memory.
With 2.0.0 and 2.0.2 I have seen that a few playlists were empty after converting. When trying to delete these from Engine Prime, you see the round cursor(showing you have to wait) for 1-2 seconds. Then the Engine program exits. Windows Eventviewer shows the following(XML):
1000
0
2
100
0
0x80000000000000
21914
Application
JAKBAK
Engine DJ.exe
2.0.2.51330
61809717
ucrtbase.dll
10.0.19041.789
2bd748bf
c0000409
000000000007286e
8f4
01d7dc5b5748a36e
C:\Program Files\Engine DJ\Engine DJ.exe
C:\WINDOWS\System32\ucrtbase.dll
39d25050-dc75-48ee-b7d0-fb002fdd361b
If needed I can drop some extra logs/tracing etc. Just let me know.
Kind regards, Jack.
Hi all, I can confirm that my playlist issues after upgrading from v1.6.1 to v2.0.1 / v2.0.2 are solved by upgrading from 1.6.1 to 2.1.0.
Issues I had:
- Some playlist converted from 1.6.1 were empty
- Some playlists cannot be deleted(these empty ones)
Good work Denon!! Thanks for all the hard work.
Regards,
Jack
4 Likes