All red (again...)

Okay, great, that’s something I can look at. I’ll run more tests next week

Another thing I noticed: when I delete the database of the target-disk, syncing goes very fast. After re-importing track-information in Engine DJ and syncing again, the process is slower, but still acceptable. But what was really slowing the process (I think) was analyzing the tracks in Engine DJ. I stopped doing that and leave it to the SC6000’s to fabricate the preview. That really helps. (Although yesterday, at a great gig, previews didn’t always show up.) So at the end I guess comparing the databases of the source and the target is what taking all the time. Does that make sence?

Could be yes, it does compare data in order to know if it should be updated. But that just makes it slower the more tracks are compared. Nothing that should spike it to extremes like 5 hours.

I’ve tried it some more but really can’t reproduce it here. I did add a small fix to the Engine database where generated waveforms (and cues added manually) on the device did not save to the database. That should be resolved so it should make the situation a bit better. You’ll have to delete the database from the device so it gets re-created though.
Uploading the new update now.

Okay, thanks! We’ll see what the future brings… Meanwhile I’m trying to fill a disk via Rekordbox (synced by Lexicon) and this is also going very very slow. It proceeds, but will take days…

Yeah another user reported that writing the RB6 database can also be equally slow like Engine (both SQLite). Can’t reproduce that either so I really think it must be hardware related.

If you can try somehow confirming that it is external drive related then I’ll buy an identical drive and see what happens here. Maybe swap the drive for another one and test the speed? Especially different USB versions would be a good test.

I’ll try. The one I’m using now is a ‘regular’ one. Of course ssd is quicker. I’ll see if I can fix another regular one, of another brand. That will take some time.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

@Hans_Beuzel Are you still getting slow syncs?
How large are all your Engine m.db files? I’m wondering if maybe it has to do with that

Hi Christian, since I don’t analyze anymore on the MacBook in Engine DJ, but on the SC6000’s, it’s useable. It takes a bit of time for the SC6000’s to analyze, but I can live with that. The Engine m.db files are 955,5 MB. Thanks for coming back to this topic!

Can you upload both your Lexicon database and the m.db once more? I’m going to try to recreate this problem again, it bothers me that this is still not fixed…
This is the upload link: http://upload.rekord.cloud

Done. It could take a while before I react again. Now working on two gigs for this weekend, so my focus lies there… But it’s great to see how involved you are!

1 Like

Could be related, perhaps, the issue/problem reported by @Hans_Beuzel with what I mention in my post?

And to which @Christiaan replied:

By the way, an answer that I still haven’t forgotten to this day.

Something I discovered recently. I did a full Engine-sync to an external drive. That’s something I haven’t done for quite a while. Mostly I just sync playlists. It took all night to sync. And now comes the strange part. At night a had another screen open on my MacBook, because I was simultaneously doing a RekordBox-export to another drive and looking at that screen. When I got back to the Lexicon-screen, it was at 50% but then it went fast to 51… 52… 53%. Like the syncing had been stopped because I got to another screen. Is that even possible? By the way, this was happening on a HDD-drive, when I sync to an SSD, it’s (of course) a lot faster.

I think that is a Windows thing, I notice the same thing here when I switch virtual desktops. Seems like it gives it less performance or pauses it or something when you’re not actively doing anything with it.

1 Like

There was a different user this week who had huge performance problems when trying to import from their Serato library. Turns out they had a 2TB exFAT drive that was either not defragmented or just exFAT being slow. But after a format and change to macOS journaled file system, the problem was gone and performance was way higher.

Maybe that is what is going on here too? I suspect for Windows NTFS would also be a lot faster than (ex)FAT

But NTFS won’t work with Engine DJ, it has to be either FAT32 or exFAT

Right… Maybe the FAT drive is so fragmented that causes this huge performance drop?

I don’t think that could be the case, Christiaan. At least, not in my case. Then the drive should be this defragmented directly after formatting it. For me the ‘solution’ has been a: not analyzing tracks in Engine DJ (so I let the SC6000 make the preview, which takes more time loading, a bit annoying) b: be very patient when syncing c: don’t plan syncing right before a gig.