Mobile DJ Services
Some of the virtual dj search registry files we're missing a long with other files. When I installed virtual dj on my new laptop the registry files we're not the same as my old laptop. All I did was copy/ export my old virtual dj registry files from my old laptop to my new laptop and that did the trick. As stated above, I'm no computer tech but it worked for me.
Posted Thu 23 Oct 14 @ 11:59 pm
marguello
antdoggy123 wrote :
Ok fixed the problem with slow searches on my laptop. Was comparing my old laptop virtual dj registry files to my new laptop and it wasn't the same and was missing parts. So I just copied/exported my virtual dj register files from my old laptop; and put those on my new laptop and it worked. Back to super fast searhes. I'm a happy camper. ...
Thats great antdoggy, glad u figured it out but it doesnt help situation with having filedate on browser
Still wish vdj team look into that and why no issues on 7. I have used exact laptop and external no new variables same file structure.
Posted Fri 24 Oct 14 @ 12:35 am
PachN
antdoggy123 wrote :
Ok fixed the problem with slow searches on my laptop. Was comparing my old laptop virtual dj registry files to my new laptop and it wasn't the same and was missing parts. So I just copied/exported my virtual dj register files from my old laptop; and put those on my new laptop and it worked. Back to super fast searhes. I'm a happy camper. I'm no computer tech but it worked. Hope this helps someone.
I'm really curious how that could fix your problems because V8 doesn't use the registry anymore :|
Posted Wed 29 Oct 14 @ 11:48 am
groovindj
I have a sneaky feeling that antdog means database files, not registry files...
Posted Wed 29 Oct 14 @ 12:04 pm
NrgPlyr
The file search is slow. Somehow the algorithm is different from VDJ 7. Sorry, with all file folder sizes the exact same, it is the program. Also, the database should store ALL info, period. I dont care if it makes the size large. Whatever column header is available in the program to display and sort by, the database MUST contain that information, otherwise there will be issues of course!
Posted Sat 01 Nov 14 @ 9:25 pm
groovindj
NrgPlyr wrote :
The file search is slow.
Please provide more info.
What columns do you have in the browser? What search options are selected? What view options are you using? How many files are in your database?
Is your data on an internal or external drive? What media is it (video/audio/karaoke)? What data are you searching for? What's the spec of your computer? Mac or PC? What operating system?
The vast majority of VDJ 8 users don't have any issues with search speed. Therefore it's more likely that something about your particular system or usage is causing it. In order to diagnose, it's necessary to gather all relevant information.
NrgPlyr wrote :
the database should store ALL info, period
So you expect the database to keep track of the dates on every single file in your system, constantly rechecking to see if any dates have changed?
Or maybe you'll just remember to rescan every file you modify every time you do it?
Posted Sun 02 Nov 14 @ 6:22 am
marguello
Vdj team
As i put simply why does vdj7 handle the file date just fine and now after years of djs having file date on our vdj7 browser we cant use it on vdj8 because it cant handle it and its searches are extremly slooooww.
Why cant vdj8 be addressed to handle this option in the browser???
As i put simply why does vdj7 handle the file date just fine and now after years of djs having file date on our vdj7 browser we cant use it on vdj8 because it cant handle it and its searches are extremly slooooww.
Why cant vdj8 be addressed to handle this option in the browser???
Posted Mon 03 Nov 14 @ 4:28 pm
Mobile DJ Services
No I meant registry files. Before I copied my virtual dj registry files from my old laptop I only had 1 or 2 of these search files. Now these are the search registry files I have and it works fine now. 
Posted Sun 09 Nov 14 @ 11:31 pm
Adion
Actually, file dates are handled the same in vdj 8 as in vdj 7, meaning that since they are not in the database for either, sorting by file date will be slow, however unsorted results should still show up fast. There might be a small delay showing the file date for the currently visible items, but since this are only 20 items or so it should still be quite fast.
The only exception may be if you have a network drive mapped and some possibly non-existent files in your database.
In this case browser options -> Database -> remove missing files from search db should help.
If it is still slow even with the file date column not shown, please let me know which search fields are enabled in the search options. (Although all search fields come straight from the database, so should be fast)
The only exception may be if you have a network drive mapped and some possibly non-existent files in your database.
In this case browser options -> Database -> remove missing files from search db should help.
If it is still slow even with the file date column not shown, please let me know which search fields are enabled in the search options. (Although all search fields come straight from the database, so should be fast)
Posted Mon 10 Nov 14 @ 1:38 am
homeworld
Now, lets go back to my last post and answer the questions! That's how we will figure out the problems!
We know it's slow. We were actually getting somewhere!
Continue.......
We know it's slow. We were actually getting somewhere!
Continue.......
Posted Tue 18 Nov 14 @ 10:30 pm
Adion
v7 did not keep the file date either.
8 scans the folders you browse to, and the files you manually tell it to scan (right->click recurse, or right->click add to search db)
First seen is the date vdj first saw that file. So the time you browsed to it, or re-scanned the folder that the track is in. It doesn't change when the file is modified.
8 scans the folders you browse to, and the files you manually tell it to scan (right->click recurse, or right->click add to search db)
First seen is the date vdj first saw that file. So the time you browsed to it, or re-scanned the folder that the track is in. It doesn't change when the file is modified.
Posted Tue 18 Nov 14 @ 11:25 pm
EpicBeats
Since I know this topic has garnered a lot of attention, I will try not to re-hash the details provided in any of the previous posts. Long story short, on occasion, the search feature does take quite awhile. I'm hoping the development team can find a way to solve this one, since it can be quite devastating if it happens at the wrong time (e.g. middle of a party, etc.). Thanks in advance for your hard work guys.
Now, here are the facts.
Reproduction Steps:
1. Type a broad query string in the search box
2. If the condition is triggered, VDJ should say 'Searching' or 'Browsing' to the right of the search box
3. VDJ decks continue to function as normal, but the browser is unusable (e.g. cannot abort search operation, cannot select new tracks, etc.). This may persist for several minutes (3 minutes, 4 minutes, and 4 minutes were the wait times for the previous 3 incidents)
Columns that are active in the browser window:
-File Name
-BPM
-Title
-Artist
-Album
-File Date (Yes, the problem child)
To be clear (and as many have mentioned), First Seen is not a substitute for File Date. As per the user guide, First Seen "stores the date of when the track was first added to the database." File Date, which as someone mentioned comes from the file properties, seems to reflect when the track was first downloaded, created by the user, etc. The latter may have happened at a much earlier point in time when compared to the date when VDJ first sees it.
High-Level Computer Specs:
i7 - 3.07 GHz
24 GB RAM
4 TB HDD (Internal 2 - 2 TB Drives w/ RAID 0 Striping)
Impact:
-Although the VDJ decks are still operational, since the browser is unusable, DJs may be unable to select new tracks and cue them up before the song on the current deck ends
Comparison to VDJ 7:
-While the search feature may have been slow, I don't recall it freezing the file browser interface completely.
Suggested Possible Workarounds:
@Adion: Introduce an abort operation button in the UI that when clicked will terminate the search immediately. This will allow DJs to regain control over the UI if they choose not to wait for the search to complete. (The little 'X' button next to the search bar does not currently do this)
Possible Long-Term Fix:
@Adion: Upon reading the file for the first time, can the file date information be extracted and cached in the DB to prevent having to repeatedly search the file properties? Since I'm sure this has been considered, I'm curious to know the technical details on why that can't be done. Is there an initial performance hit here? Or are there certain circumstances where the file date for a particular file is expected to change, thus concern over storing possibly outdated info? From a dev perspective, just curious to hear the specific design/implementation concerns the team is facing; would like to help you guys get over the hump on this one.
Cheers...
Now, here are the facts.
Reproduction Steps:
1. Type a broad query string in the search box
2. If the condition is triggered, VDJ should say 'Searching' or 'Browsing' to the right of the search box
3. VDJ decks continue to function as normal, but the browser is unusable (e.g. cannot abort search operation, cannot select new tracks, etc.). This may persist for several minutes (3 minutes, 4 minutes, and 4 minutes were the wait times for the previous 3 incidents)
Columns that are active in the browser window:
-File Name
-BPM
-Title
-Artist
-Album
-File Date (Yes, the problem child)
To be clear (and as many have mentioned), First Seen is not a substitute for File Date. As per the user guide, First Seen "stores the date of when the track was first added to the database." File Date, which as someone mentioned comes from the file properties, seems to reflect when the track was first downloaded, created by the user, etc. The latter may have happened at a much earlier point in time when compared to the date when VDJ first sees it.
High-Level Computer Specs:
i7 - 3.07 GHz
24 GB RAM
4 TB HDD (Internal 2 - 2 TB Drives w/ RAID 0 Striping)
Impact:
-Although the VDJ decks are still operational, since the browser is unusable, DJs may be unable to select new tracks and cue them up before the song on the current deck ends
Comparison to VDJ 7:
-While the search feature may have been slow, I don't recall it freezing the file browser interface completely.
Suggested Possible Workarounds:
@Adion: Introduce an abort operation button in the UI that when clicked will terminate the search immediately. This will allow DJs to regain control over the UI if they choose not to wait for the search to complete. (The little 'X' button next to the search bar does not currently do this)
Possible Long-Term Fix:
@Adion: Upon reading the file for the first time, can the file date information be extracted and cached in the DB to prevent having to repeatedly search the file properties? Since I'm sure this has been considered, I'm curious to know the technical details on why that can't be done. Is there an initial performance hit here? Or are there certain circumstances where the file date for a particular file is expected to change, thus concern over storing possibly outdated info? From a dev perspective, just curious to hear the specific design/implementation concerns the team is facing; would like to help you guys get over the hump on this one.
Cheers...
Posted Sat 20 Dec 14 @ 5:50 pm
Adion
There are 3 messages related to the browser that might come up in the status text: "Browsing", "Searching" and "Sorting"
All of them can be canceled by entering a new search string, clearing the search string or selecting a different folder.
If it does not cancel, I think it is stuck on a single file for some reason. Did you see it lock up on either 'Browsing' or 'Searching', or only one of the two?
If you can reproduce it relatively easy, could you try if not showing the File Date changes this.
The file date does not have to be accessed while Searching, only when you sort by File Date, or when the files are shown.
If File Date is the problem, I would expect it to be either stuck on 'Sorting', or when it shows the files, but then you would get these lockups when scrolling through the list as well.
All of them can be canceled by entering a new search string, clearing the search string or selecting a different folder.
If it does not cancel, I think it is stuck on a single file for some reason. Did you see it lock up on either 'Browsing' or 'Searching', or only one of the two?
If you can reproduce it relatively easy, could you try if not showing the File Date changes this.
The file date does not have to be accessed while Searching, only when you sort by File Date, or when the files are shown.
If File Date is the problem, I would expect it to be either stuck on 'Sorting', or when it shows the files, but then you would get these lockups when scrolling through the list as well.
Posted Sun 21 Dec 14 @ 12:14 am
EpicBeats
I reproduced it today, and whether 'File Date' is an active column or not I've seen it lock up on 'Searching' and 'Browsing', not 'Sorting'. To give you some more details here, if I leave my search query in the box and don't attempt to navigate to any other folders, we'll see 'Searching' throughout the duration until the results are returned. On the other hand, if you attempt to cancel the search or navigate to a different folder (which is likely what most DJs do when they feel they have waited too long), you'll see 'Browsing' displayed next to the search box. After the 'Browsing' lock-up is over, you'll see the tracks in the folder that is currently active. This should explain the lock-up case with respect to the differences in messages (e.g. 'Searching' and 'Browsing'), and is likely consistent with the VDJ definition of these terms.
In the past and even today, I have tried clearing the search string box, entering a new search string, and selecting a different folder during the 'Searching' and 'Browsing' messages, but none of them work. As mentioned the decks are still active during this time. Whatever tracks are currently displayed in the browser can still be selected and loaded into a deck, but again the view does not change if you navigate to a different folder.
I didn't really experience any issues with 'Sorting' whether File Date was an active column or not. At most there was a brief pause (e.g. 5-10 secs), but the 'Browsing' and 'Searching' pauses were magnitudes of order longer (e.g. 3-5 minutes).
Since the problem occurs whether the 'File Date' column is active or inactive, and 'Sorting' is not an issue I ran into, perhaps 'File Date' is not the culprit?
In the past and even today, I have tried clearing the search string box, entering a new search string, and selecting a different folder during the 'Searching' and 'Browsing' messages, but none of them work. As mentioned the decks are still active during this time. Whatever tracks are currently displayed in the browser can still be selected and loaded into a deck, but again the view does not change if you navigate to a different folder.
I didn't really experience any issues with 'Sorting' whether File Date was an active column or not. At most there was a brief pause (e.g. 5-10 secs), but the 'Browsing' and 'Searching' pauses were magnitudes of order longer (e.g. 3-5 minutes).
Since the problem occurs whether the 'File Date' column is active or inactive, and 'Sorting' is not an issue I ran into, perhaps 'File Date' is not the culprit?
Posted Sun 21 Dec 14 @ 10:08 am
markdeejay75
i see a lot of the same being mentioned as what im getting with v8..
This screenshot was taken back on Halloween night and has re-occurred RANDOMLY ever since.
When i say randomly, there is no set sequence of events before the skin locks me out and fills the browser area with gradient colors. could occur 5 mins into gig, 1h or not at all.. irrespective of the skin im using too.
Is there anyway of sending a crash report or memory dump when this happens??
The music continues to play, just locks me out of the skin... so cant continue until restarting v8.
This screenshot was taken back on Halloween night and has re-occurred RANDOMLY ever since.
When i say randomly, there is no set sequence of events before the skin locks me out and fills the browser area with gradient colors. could occur 5 mins into gig, 1h or not at all.. irrespective of the skin im using too.
Is there anyway of sending a crash report or memory dump when this happens??
The music continues to play, just locks me out of the skin... so cant continue until restarting v8.
Posted Mon 22 Dec 14 @ 2:37 pm
EpicBeats
@Adion: Any updates since my last post?
Posted Sat 17 Jan 15 @ 4:18 pm
homeworld
Bump...
Posted Tue 17 Feb 15 @ 9:45 pm
Adion
Which search columns are activated? (When clicking the dot next to the search box)
Also, how many files are we talking about (search for "*", is this slow too btw?)
Also, how many files are we talking about (search for "*", is this slow too btw?)
Posted Wed 18 Feb 15 @ 12:45 am
homeworld
God, REALLY?????
READ...
READ...
Posted Wed 18 Feb 15 @ 1:11 pm
homeworld
I don't mean to be an a**, but really. This problem is not imaginary! I have newer laptop with a newer external WD hard drive. USB 3. Windows 8.1, latest drivers, 12 gigs of ram, i5 2.3ghz 1080 display, and using for test purposes, a Herk RMX 2. Latest build .2139
I also have VDJ 7.42 loaded on it.
7 works on all aspects, search with the same criteria is instantaneous! Which is, by the way, TITLE, ARTIST, BPM, FILE DATE.
VDJ 8. Type in an artist, it says "searching" and now you wait, and wait, and wait..... We're talking 2-4 minutes of activity you can't escape from!
I looked at the task manager and the only thing that is using any resources is VDJ8. And not a whole lot of them either (39% proc) and about 200mb memory.
Even doing a search with windows explorer is faster, like 10 seconds, and that's saying a lot!
I have about 50k tracks including music and videos. No karaoke.
I also have VDJ 7.42 loaded on it.
7 works on all aspects, search with the same criteria is instantaneous! Which is, by the way, TITLE, ARTIST, BPM, FILE DATE.
VDJ 8. Type in an artist, it says "searching" and now you wait, and wait, and wait..... We're talking 2-4 minutes of activity you can't escape from!
I looked at the task manager and the only thing that is using any resources is VDJ8. And not a whole lot of them either (39% proc) and about 200mb memory.
Even doing a search with windows explorer is faster, like 10 seconds, and that's saying a lot!
I have about 50k tracks including music and videos. No karaoke.
Posted Wed 18 Feb 15 @ 1:32 pm
