apopsisdj
In Greece we say: "a picture worth as thousands words"
http://img1.imageuploader.net/535/VDJtools.jpg
But let me explain the "Compact database" function, and why i believe this is really important:
Every loaded track in virtualdj is automatically recorded
in "VirtualDJ Database.xml", right ?
For tracks that loaded only once, and then deleted/renamed,
or TAG edited (this changes the filesize), their "ghost" entries remain in the database forever...
ending with a database full of chunk and garbage...
This can be a real (performance) problem for users :
1. That uses "temp" files and then rename (outside vdj)
2. Edit tags often (using mp3 utilities)
In the other hand, the Search database is so flexible, so easy
and quick to built from scratch, and represents a "real" image
of the tracks that are availaible, and tracks that the dj really
needs to keep.
So what i found as the best solution is a "one button" -use with care- command that can "trim" the xml database from
unused entries by keeping only files that are present in the
current search database.
I believe that it is possible by comparing the two databases
(filenames and filesizes)
Now, about filesizes, a good idea is -maybe- to allow a small
(a few bytes/kbytes) offset for files that tags are edited external.
This will "speed up" and improve the performance of the program for users with thousands of files, i think.
Please let me know if you found it a good idea.
http://img1.imageuploader.net/535/VDJtools.jpg
But let me explain the "Compact database" function, and why i believe this is really important:
Every loaded track in virtualdj is automatically recorded
in "VirtualDJ Database.xml", right ?
For tracks that loaded only once, and then deleted/renamed,
or TAG edited (this changes the filesize), their "ghost" entries remain in the database forever...
ending with a database full of chunk and garbage...
This can be a real (performance) problem for users :
1. That uses "temp" files and then rename (outside vdj)
2. Edit tags often (using mp3 utilities)
In the other hand, the Search database is so flexible, so easy
and quick to built from scratch, and represents a "real" image
of the tracks that are availaible, and tracks that the dj really
needs to keep.
So what i found as the best solution is a "one button" -use with care- command that can "trim" the xml database from
unused entries by keeping only files that are present in the
current search database.
I believe that it is possible by comparing the two databases
(filenames and filesizes)
Now, about filesizes, a good idea is -maybe- to allow a small
(a few bytes/kbytes) offset for files that tags are edited external.
This will "speed up" and improve the performance of the program for users with thousands of files, i think.
Please let me know if you found it a good idea.
Posté Sat 08 Jan 05 @ 10:59 am
clax
Question launched a long time ago.
You're right it could be interresting.
Your link seems to be dead.
You're right it could be interresting.
Your link seems to be dead.
Posté Sat 08 Jan 05 @ 1:26 pm
DJ Andre Landry
Apopsis ....You got my vote on that one This would be the best back up tool ever..Clax i think you having problems with your explorer ..(Mozilla Firefox)is fine for this link!
Andre
Andre
Posté Sat 08 Jan 05 @ 2:13 pm
djzero
maby even a tool so we can edit tags from within VDJ so it can keep track of all of the changes, it works wonders for rename now why not tags aswell
Posté Sun 09 Jan 05 @ 2:33 am
idj4u
Great idea!
The "autosave" option may be best to be "save on exit". Depending on the sze of the file, autosave may suck some resource power away from VDJ.
The "autosave" option may be best to be "save on exit". Depending on the sze of the file, autosave may suck some resource power away from VDJ.
Posté Sun 09 Jan 05 @ 4:02 am
clax
OK now I've seen.
It would be totally useful.
It would be totally useful.
Posté Sun 09 Jan 05 @ 7:36 am
apopsisdj
I've just forwarded this request/idea to the Team, as i have advised
by the technical support page.
by the technical support page.
Posté Tue 18 Jan 05 @ 1:48 pm