First Gig With SC6000 Findings

I took My SC6000’s out to their first gig this weekend… Previous to these I was using Traktor with the Kontrol S8. So quite the difference in how these two platforms work.

I find the search times of the SC6000’s to be slooooow! I am using the 2.0 update, I carry an internal 2TB SSD hard drive in one player, with them networked together. For a mobile DJ, this isn’t a huge collection. But, throughout my first gig, I found the Engine DJ software running the players took almost as long as a radio edit to find the next track. I nearly ran out of time on more than one occasion. Cue points or loop points were out the window for the whole night, I just gave up trying to play the way I am used to.

I am used to doing a lot of chopping and changing, using cue points (get on to that in a minute) but I found myself really struggling to just punch in an artist name or track title and have it pop up on the screen in the time I need.

Before taking them out for their first gig I did read the manual and each time I had only the search field I was using selected to reduce the processing power required. But it still took far too much time to find the track I was looking for.

After about an hour I realized I have to navigate to the parent folder and then search for the track and it works much faster. But for me, this takes equally as much time.

In Traktor I just typed in the artist name and song title, less than half a second later it was up, loaded in a deck, and ready to go. My old mac book was the minimum spec for Traktor too, so it’s pretty old. I would really expect the SC6000, flagship model players to at least be a bit snappier on finding the track I am looking for.


I agree, search times on the SC6000 are barely acceptable when coming from Traktor.

1 Like

In my humble opinion, search speed is good enough, and plenty acceptable. A standalone player will never have the search speed of a laptop - this is normal and expected. For a player, 2tb is a huge collection (I believe it is the maximum recommended size for 5000’s players). Stick a 2Tb USB driver to a CDJ3000 and you’ll have some bad surprises :joy::rofl: in searching too.

That’s related to collection size, I’m more of a ‘club dj’ and searching on my sticks is almost instant, my (playing) collection is much smaller and divided between sticks/ssds.

I played with Traktor for a few years but went back to players, as I hated the “checking email” laptop dj attitude. Every platform have limitations and bonuses…searching is a limitation on standalone players, leaving the laptop at home is a bonus.

1 Like

Do mind however that you are not talking about 2TB of metadata when you insert a 2TB drive. My 300GB collection has a m.db of 250MB, and a collection.nml of 54MB. PS: a lot of that 250MB m.db is album art:

sqlite> SELECT SUM("pgsize") FROM "dbstat" WHERE name='Track';
sqlite> SELECT SUM("pgsize") FROM "dbstat" WHERE name='AlbumArt';
sqlite> SELECT SUM("pgsize") FROM "dbstat" WHERE name='Playlist';

So only 124MB is Track information in which I want to search.

Now, admittedly, there are big differences between a Traktor style XML file and a Denon style SQL database: Traktor loads it’s XML file into memory at startup (hence the slow loading time) and from that point has blazingly fast search results, as they come from memory. Denon (and Pioneer) don’t load anything at startup, so startup is quicker, but search times are then much much slower, as they are on disk.

So, essentially when you would load the Track table into memory, it would drasticly speed up search. Or even just a part of it, because I don’t need info like track size and length, or even file location to be searchable. Only artist, album, title, bpm, and such field. Essentially less than 50MB of data. A search would then spit out a few results, have the trackId’s in the background and then look up Metadata like albumart, file location and such. That would only take around 100MB of RAM from the SC6000, and I suspect they have RAM to spare, as the same platform is running a complete MPC Live…

Regarding loading time, I did the test:

time sqlite3 m.db 'SELECT * FROM Track;'
real	0m0.727s
user	0m0.351s
sys	    0m0.108s

I would happily wait 0,727 seconds + some time to arrange the data in memory longer to be able to search instantaniously… Traktor does a lot longer to parse an XML file…

But yes, when you compare with CDJ’s, a SC6000 is faster…

@Outdoordaft PS: you do realise that searching on “title” only is faster than search “title”, “album”, “artist” and a lot more at once? That again has to do with some SQL logic: when you search all fields together, a series of OR operators is involved, when you search one field only, they are not


I totally agree with you :+1::+1::+1::+1:

1 Like

Same here.

What does help tremendously, as I tend to swap and chip and change my ideas on what to play and when to play it, a lot…. Is the prepare list. A simple swipe and it puts a limitless number of found tunes into a list that’s -instantly - accessible. That’s perfect for the rapid choppers and changers

1 Like

True, just too bad that tracks get erased from the prep-list once you load them. Traktor doesn’t delete them from the prepare list, which allows for last minute changing your mind :wink:

1 Like

Still better specs than what is in the standalone devices. As Johan here explained, it’s apples and oranges if you compare DJ software and standalone gear.

It search speed is what is essential to your type of DJing - you choose the wrong gear with Denon standalone. A good DJ can adapt though (optimise their library - reduce the number of analyzed tracks and keep others just imported into the library)

That’s not really what I explained. I explained that loading merely 50-100MB of data into memory potentially speeds up searches tremendously… I think the speed advantage of Traktor lies into loading a XML into memory…

PS: The CPU of a MPC Live (and thus a SC6000) should be something like a Quad core ARM cortex A17 @ 1.8GHz according to the internet. That’s not really slow. The darn thing can even run a light show! EDIT: OK, according to passmark it compares to a Intel Core 2 Duo. White Macbook era. That might look old, but I can assure you that my old white macbook has served me very well back in the Traktor Scratch era. It had faster search speeds. And the SC6000 doesn’t run a full computer OS but a slimmed down Linux…


Now the hard (and some good) facts: We are on the first “baby steps” in ‘OS’ based stand-alone gear. Comparing Denon and Pio (that’s inevitable), we are miles ahead of PIO in terms of firmware/OS. SC’s players have a LOT more features than Pio, with a ‘decent’ FW. 3000’s FWs are a mess, compared to Denon. The features are very limited, and the firmwares are unstable and bugged (1.20 3000’s FW was released and removed a day after, as players became unusable due to pitch flutuactions and screens freezing ) . The future is very bright, as the options for improvement are ‘endless’, but we are still far from a "almost perfect’ FW on both Pio and Denon realms.


That’s true. But that doesn’t mean we can’t speak up about the flaws that are still here. There are more than a few things that make me look back to Traktor. Right now I’m feeling I’m making a compromise using the SC6000’s. And there are a lot of things that would make me and some others happier then Engine Lighting that require a lot less work…


I would much prefer a longer startup time and faster searches any day of the week


It’s quicker to search for a streaming copy of the track than a local copy on a large ssd.

How I gig - say a 4 hour bar gig (top40 and the likes)

I do the first 1.5 or 2 hours in standalone - Crates, playlists arranged to the best of my ability. I usually experiment or try new tracks during this period.

Peak time - when the liquor starts to hit them in the face - I switch over to serato and do like 90 mins of quick mixing. Here I’m searching like 4 tracks ahead. No time to waste waiting for nothing. This period I’m playing from the dome.

Then last half hour or so- it will be mostly requests handling - back to standalone and pulling tracks from Tidal or Beatsource.

I have noticed something else eg say I search 50 cent play candy shop and I run another 50 cent search it returns the results quicker on the next search. Or I’m imagining things

1 Like

Thats because sqlite caches your search results: python - is sqlite caching the results of the query for optimization? - Stack Overflow


I clicked on that link…and i ran back here …lol

Way above my cognitive ability.

I will take your word for it :rofl:

If you have two SC6000’s you can plug in two SD drives and split your collection, that might help with search times.

2Tb is just a massive collection of music and I struggle to see why anyone needs to carry that much music at once. Perhaps consider cutting your collection size down to something more reasonable, it will likely make you a better DJ.

1 Like

I carry 2 tb because I need to carry a collection that caters for everything and everyone. I also do a lot of theme nights.

if I didn’t need it I wouldn’t have it, I have also used the same collection for the past 25 years and know it inside out

1 Like

Radio Edit length search time? That would be 3 minutes. That’s really long indeed.

The old 1.6 database had a unofficial search time of about 1 second every 10000 tracks. Version 2.0 should be faster than that. This means the collection would be 1,800,000 tracks minimum?

There must be something wrong in the database. Certainly something to look into.

1 Like

Hence the reason that having a laptop be a music source over the network would be cool, as it’d let the laptop be strictly for music storage & searching and let the players do all the rest. Having the laptop do everything or the players do everything is not the best use of computing resources.


Im trying to fathom if I used my 2TB drive to play out with…

Assuming if it was full and the average track was 7mb and I catered to 200 different occasions or themes thats still like 1400 tracks per theme.