Hmm well when I looked at your logs, it seemed that the most time was spent in the last step, which is writing playlists and cleaning up unused tracks/playlists in the Engine database. So that is after the file copying, so I think file copying is unrelated.
I don’t know of any Mac setting that might affect this, but I’m no Mac expert by any means.
I suppose you could try carbon copying the drive to a different drive, then export Lexicon to that drive and see how fast that is. If it is faster, then it must be related to that specific drive or USB.
Okay, I made a drastic decission I’m going to use my other MacBook for Lexicon. I thought about that before, but then it didn’t seem to work on that MacBook also. Today I realized then the problem was the name of the external SSD-drive and that was solved. So I tried again and now the syncing-process went well on the other MacBook. The difference between them is the OS. I upgraded the one I was working on to Catalina and the other one was still Mojave. (And I’m going to keep it like that ) So, fingers crossed, I hope this will be the answer.
Well… I’m sorry to say it worked just once like it should on the other MacBook. Now syncing is taking a lot of hours again. I’m starting to think my MacBooks are just to old for the job. I have RekordBox running too, to fill up a drive for playing at places where they have Pioneer. That also takes multiple days. It’s strange, I never had the impression my MacBooks were slow, but now they suddenly seem to be, for some jobs a least. Copying with CCC still goes fast. Maybe there’s still some kind of bug somewhere. Don’t know.
It could definitely be a bug but I don’t really know what it could be… Just wish I could reproduce it here I’m not giving up though but at the moment focused on other tasks, to get the final release ready
Just noticed that syncing just one playlist (even very big ones, containing many folders with playlists) is relatively much faster than a full sync. I have eight main categories of playlists and I think syncing one of them costs minutes, while a full sync takes hours. Maybe that’s a clue?
I guess it must have something to do with the amount of calls it makes to the database. More tracks means more calls. It all happens pretty efficiently though, but maybe there is some kind of buffer problem on certain USB devices.
What drive is it exactly? Do you have a link? If it’s not expensive, I can buy one and test it. Not sure we will see the problem here but it will get us slightly closer.
I may have discovered something. When I sync just a playlist, it goes fast. Also when I sync a folder with playlists in it. But there’s one very big folder with playlists. I call it the Collection Playlist (although it’s actually a folder) and every track should be in there and it’s divided in a lot of folders and playlists. When I try to sync this Collection PLaylist-folder, it takes like forever.
The other folders and playlists are more specified for occasions, like weddings, festivals, luxurous locations, etcetera. Syncing them doesn’t take this much time. That all seems kind of logic, but when I take just one playlist of the ‘Collection playlist’, it also takes like forever, although it’s just a small playlist.
So I synced the ‘Miauw’-folder (with some folders and playlists in it) and it took a minute. After that I took one small playlist called ‘Bizar’ in the Collection Playlist-folder. I aborted syncing after 15 minutes (because I wanted to work in Lexicon), but it obviously took al lot more time. So could it be that being part of a very big folder slows the syncing of a specific playlist?
Weird, I don’t expect that to influence it. And if you move that playlist elsewhere? So it’s no longer part of that big folder. Should not make any difference, but if it does, that would be something
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.