Hello, I have a P4+ running OS v4.0 and the search using the internal SSD (150,000 files) takes forever, I have made a video comparing it with a regular P4 running v3.4 and there is almost no delay on the older P4 running v3.4
I have also downgraded the P4+ to v3.4 and it has improved the search speeds a bit, any ideas?
The P4 had the stems beta, then i went to v4 then I downgraded back to 3.4
The same internal SSD was use for both videos…
Video Links Below:
I’m sorry but who the heck needs 150,000 songs to choose from? There’s no way you’ve listened to even half of them.
about the search time is super slow on the v4.0 i have experience that also compare with the v3.4 is more faster i hope on the next update they fix it plz
It’s a huge amount of tracks, it looks like you have a lot with non English metadata, as in not even the standard alphanumeric values. You also don’t seem to have any sort of organisation to it, like playlists.
I posted on a separate thread about searching huge databases with no filters. Tracks can have info stored in several parts of the metadata (at least 6 places), so if you just type ‘rolling’ into your search and it’s got to trawl through 6x150000 records to find them with no other criteria to narrow it down, it’s going to take a lot of time.
If I wrote an SQL query that just loosely had a LIKE ‘%rolling%’ across 6 different DB columns with no other restrictions it would take an age.
This is why there is now the ability to search playlists and various other filters to help narrow down what you’re looking for.
Sorry, but 150k songs is just too much. Anyway, there is one trick to get better search time. When the P4 is connected to the Engine program on the computer by USB cable do a library optimization.
That’s nothing. I saw a post on another forum recently from a guy claiming to have 500,000 tracks - all recorded to 320K MP3 from vinyl he’d purchased. 
At 6 minutes per track, so 10 an hour, that’s 50000 solid hours of recording, or 2083 continual days, 5.7 years.
My guess is a 100meg fibre connection and soulseek.
Yeah, I was doing the maths too.
Nobody’s going to be ripping 24/7 so accounting for all the “in between” time it takes to get the record out, cue it, set levels, play it, stop the recording, tag it, name and save the file, then the likely amount of hours per day doing it, it would take decades - and MP3 has only been around for 30 years. The earliest encoders didn’t even go up as high as 320K from what I remember.
It took me just over 2 years (very casually) to record all my d&b records (about a 1000ish including the b-sides.
I set everything on the mixer in unity & ran every record through the the pc recording software twice, once to check for any jumpy needles in the record & to set the auto gain level input so it wasn’t distorted upon recording.
Then once I was happy with the test recording I’d run it through again, record and tag it on the software.
I’ve deleted a few really crap b-sides over the years that’s why I’m left with just under 900ish on file but even that many is enough for me let alone people talking about multiple thousands.
thx for the help
Hi STU,
I live in Mexico so of course I have a lot of tracks in spanish.
So yes I understand the 6 search filters you mention in v4, however even if I choose to search in “artist” or “title” or both, or more, it is much slower in v4 than in 3.4 for some reason, sometimes it could take half a track or more to find a tune (v4).
My P4+ downgraded to 3.4 is working similarly to the older P4 in searching speeds.
I do have playlists on my drive, (video to follow and searching speed with 3.4)
As of why i want all my music on it, its just for my personal setup.
try the library optimization ,i try it my p4+ search faster now
I was talking about 0:11 on the v4 video, it looks like mandarin or something? Definitely not Spanish. Those characters might be seen as basically invalid.
As far as the speed goes, it could be the added features of 4.0 that have increased the time, or as others have said, run a disk cleanup.
Those of you saying 500,000 records to search is a lot - sorry guys you’re talking rubbish.
I can install a database on a raspberry pi with a couple of million records on it which are indexed and find stuff in under 2 seconds. And a raspberry pi doesn’t have anything like the power of a P4.
500k is a tiny amount of records to search if it’s indexed properly.
@andrew_nicoire How do you do the library optimization please?
Yes I have Asian tracks also in my library, I have tried the library optimization in engine desktop and it’s still the same in v4. Something is making the search definitely slower on this version as with 3.4 is working as expected.
Video Link:
Can you guys please take a look in the future updates.
in Engine DJ (computer) click the gear icon (settings) then click the library tab, then scroll down and under library optimization click “run cleanup”
That’s it.
Nobody said that. I mentioned someone on another forum who claimed to have recorded 500,000 MP3s from vinyl, but nothing was said about searching that quantity.
I agree though, that Denon’s database system is not particularly speedy. They actually suggest in the manual to deselect any tags you’re not searching, to make it faster.
You need to be more clear with your claim here. Are your raspberry pi searches referencing multiple columns when they search? Or just a single one? What does your original query look like?
A music file will have file name, artist, track name, remixer, year, comments, bpm, album, composer, album artist, genre.
So take 150000 records, multiply it by say 9, so 1.35m records to trawl through, your SQL query as an example would be.
SELECT * FROM t_engine_db WHERE (file_name LIKE ‘%Rolling Stones%’ OR artist LIKE ‘%Rolling Stones%’ OR track_name LIKE ‘%Rolling Stones%’ OR remixer LIKE ‘%Rolling Stones%’ OR comments LIKE ‘%Rolling Stones%’ OR album LIKE ‘%Rolling Stones%’ OR composer LIKE ‘%Rolling Stones%’ OR album_artist LIKE ‘%Rolling Stones%’ OR genre LIKE ‘%Rolling Stones%’)
This is where it gets messy, suddenly the query has to do wildcard search against 9 different columns, each with 150000 records.
Adding an AND playlist = ‘Rock Music’ drastically reduces the query.
Unless of course you think differently?
To give some clarity on @PKtheDJ suggestion from the manual.
