Phenryll
Hi guys,
VDJ 5 stores new pieces of information in the xml database such as FirstSeen, LastPlay, etc. There are other pieces of information that can be access through VDJ whereas they are not stored in the xml file such as FileDate.
Therefore, it had taken time before that feature was perfecly mastered. This is my personal opinion but many tracks weren't recognised with the new engine whereas they were previously.
As a consequence, 20% of my tracks had to be scanned again causing a loss of information.
The main one was the piece of information related to the FirstSeen's attribute in the xml. The very first time that VDJ 5 checked the database, it stored that piece of information taken from the filedate of the file. That's the way VDJ should have be working but for some reasons tons of tracks were detected as new causing the date of FirstSeen the one you scanned the file.
If a file was written on your HD 2001/09/08 and wasn't recognized correctly, VDJ stored the FirstSeen information as for example 2007/12/23.
You may be retorting that the FileDate can be retrieved from the HD. That's true but this is a workaround that is CPU consuming. Sorting out files by FileDate may be freezing VDJ, depending on the amount of files the HD contains.
Moreover, the FirstSeen attribute is read from the xml file. That make the sorting out very fast.
What I am willing to do is to write a small application that stores the Filedate of a file as the FirstSeen in the xml database in order to keep everything as accurate as possible. This piece of information is perennial: never will you change it.
What I'd like to know guys is: have you ever encountered such problem with VDJ 5 with the FirstSeen attribute? Or am I the poor one who had experienced such bad thing?
If many of you encountered it, I will share that application when it is coded (not tomorrow lol).
VDJ 5 stores new pieces of information in the xml database such as FirstSeen, LastPlay, etc. There are other pieces of information that can be access through VDJ whereas they are not stored in the xml file such as FileDate.
Therefore, it had taken time before that feature was perfecly mastered. This is my personal opinion but many tracks weren't recognised with the new engine whereas they were previously.
As a consequence, 20% of my tracks had to be scanned again causing a loss of information.
The main one was the piece of information related to the FirstSeen's attribute in the xml. The very first time that VDJ 5 checked the database, it stored that piece of information taken from the filedate of the file. That's the way VDJ should have be working but for some reasons tons of tracks were detected as new causing the date of FirstSeen the one you scanned the file.
If a file was written on your HD 2001/09/08 and wasn't recognized correctly, VDJ stored the FirstSeen information as for example 2007/12/23.
You may be retorting that the FileDate can be retrieved from the HD. That's true but this is a workaround that is CPU consuming. Sorting out files by FileDate may be freezing VDJ, depending on the amount of files the HD contains.
Moreover, the FirstSeen attribute is read from the xml file. That make the sorting out very fast.
What I am willing to do is to write a small application that stores the Filedate of a file as the FirstSeen in the xml database in order to keep everything as accurate as possible. This piece of information is perennial: never will you change it.
What I'd like to know guys is: have you ever encountered such problem with VDJ 5 with the FirstSeen attribute? Or am I the poor one who had experienced such bad thing?
If many of you encountered it, I will share that application when it is coded (not tomorrow lol).
发表时间 Sun 14 Sep 08 @ 12:01 am
Rune (DJ-In-Norway)
Sounds interesting that app ;)
and yes... Virtual DJ's first seen, is when its first seen BY virtual DJ, and not by the operation system... For some reason.
It might be logic too, for some users.
First seen, in Virtual DJ, is when its first scanned (seen) by Virtual DJ
But personally, I would want it like you do, first seen by the operation system. So I'm looking forward to test that app ;)
Nice initiative
发表时间 Sun 14 Sep 08 @ 6:22 am
Phenryll
Thanks Norway :)
Actually, I have tracks whose the FirstSeen's Attribute in the xml database is the FileDate taken from the system. I mean tracks from 2000 or 2001 and that job was done by VDJ itself.
That's why I said that the very first time VDJ 5 checked the database to fill in the newly implemented FirstSeen's attribute feature, VDJ read the FileDate from the tracks itself. But for some reasons, some tracks were not recognised and had to be scanned again.
Even though it makes sense to have 2 distinct pieces of information for the FirstSeen's attribute (by VDJ) and the FileDate (the date the file was created by the system), I am in shock when I notice that an old mp3 ripped in 2000 is "FirstSeen" in 2007 by VDJ.
The application will be written in C# with the .NET Framework 3.5.
Actually, I have tracks whose the FirstSeen's Attribute in the xml database is the FileDate taken from the system. I mean tracks from 2000 or 2001 and that job was done by VDJ itself.
That's why I said that the very first time VDJ 5 checked the database to fill in the newly implemented FirstSeen's attribute feature, VDJ read the FileDate from the tracks itself. But for some reasons, some tracks were not recognised and had to be scanned again.
Even though it makes sense to have 2 distinct pieces of information for the FirstSeen's attribute (by VDJ) and the FileDate (the date the file was created by the system), I am in shock when I notice that an old mp3 ripped in 2000 is "FirstSeen" in 2007 by VDJ.
The application will be written in C# with the .NET Framework 3.5.
发表时间 Sun 14 Sep 08 @ 10:04 am
Andrew87
edit: nevermind, worked it out
But to maximize compatibility, how about .NET 2.0?
But to maximize compatibility, how about .NET 2.0?
发表时间 Sun 14 Sep 08 @ 11:05 am
Phenryll
Actually, the W3C API that is provided with .NET 2 freaks me out (the manipulation of the XML I mean).
That's why I propose to use the new .NET Framework, specially the LINQ to SQL feature that is easier to use. Sure thing that an update may be come in handy.
In the worst case, if upgrading the framework freak the users out, they can send me their xml databse and I'll do the job :)
That's why I propose to use the new .NET Framework, specially the LINQ to SQL feature that is easier to use. Sure thing that an update may be come in handy.
In the worst case, if upgrading the framework freak the users out, they can send me their xml databse and I'll do the job :)
发表时间 Sun 14 Sep 08 @ 11:24 am