We are almost ready to integrate a version of tsid into sidplay2(/w). Preferably we would like to add TSID2 support as it's based on the more flexible MD5 key structure and I've been eagerly awaiting a first stab usable version of the code.
I see that TSID2-0.1 but could you provide the following information:
Can this be updated with changes to HVSC?
Can statics be extracted yet via the library even if theres no standalone program?
Is there any upgrade path in tsid2 library (or via an external program) to convert tsid1 user data to tsid2?
Any information on implemented library features or important missing library features would also usefull.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>We are almost ready to integrate a version of tsid into sidplay2(/w). >Preferably we would like to add TSID2 support as it's based on the more >flexible MD5 key structure and I've been eagerly awaiting a first stab >usable version of the code.
Take present that for TSID2 0.1 I have already correct two important bugs that affect the real time lists generation (no, fortunately, the stored data). I would like to release TSID2 0.2 for this soon, but at the moment, I obtains some segmentation fault after some continuate use of the library that I'm not able to detect when debugging with EFence.
>Can this be updated with changes to HVSC?
no at the moment:
The update of the stored data for being in sync with HVSC (or CGSC), is probably the task that require more code to add.
Actually, I'm able to produce an TSID/HVSC upgrade for TSID 1 in about 2/3 hours, but most of the time is only for listening to the tunes that require special adjustment in subtunes order, as the LaLa updatePath script performe most of the required works.
In order to produce a such files based onto MD5, I must provide a Perl script that automate this process (this is why I'm now studying Perl).
On the TSID2 side, the 'tupdate' program of TSID1 must be only adapted to the syntax of the new files.
Fortunately, the use of MD5 do not allow to overwrite already stored data of a different HVSC version (as can be occurred with TSID1 if it is not updated as soon as the HVSC is upgraded). With TSID2 the update can be apply more times and without any particular order. I manage to provide HVSC upgrade for TSID2 from the previous HVSC version, as I have already stored data of TSID2 of that version.
>Can statics be extracted yet via the library even if theres no >standalone program?
At the moment you can obtain the stored information in 2 ways:
1) With the class TBlist you can have the tune info (position/MD5/subtune/listen time/number of listen/last known path and name/last know length) of the most used tunes (the size is a user paramether).
2) with the TSidExeminer2 you can have the tune information as in TBlist, but of all the tunes.
What is actually missing in TSidExaminer2 is the capacity of reading a provided Collection name files of the form:
[HVSC]
MD5_fingerprinter1 /DEMOS/PIPPO.sid
MD5_fingerprinter2 /DEMOS/PLUTO.sid
....
[CGSC]
MD5_fingerprinter9 /VARY/PIPPO.mus
...
Then this information should be used for giving output like in 'examiner' program of TSID 1. So, give total time listen for one Author (so by grouping sids with the same path ...).
Generating such files is quite easy using a little Perl script, then the implementation of the code in TSidExaminer2 can be easy using LibIni and reusing the code of TSidExaminer (of TSID 1).
>Is there any upgrade path in tsid2 library (or via an external >program) to convert tsid1 user data to tsid2?
Conversion from TSID1 data to TSID2 data will be granted as I have about 2 years of stored statistic with TSID1 that I want to transfer to TSID2.
The task is easy as both TSID and TSID2 library can be used together, so a little program will do that. (I think to be able to produce such program in some days)-
>Any information on implemented library features or important missing library features would also usefull.
The only class that need more features is TSidExaminer2 for the reason describe above.
All the other class need only to implement the error handling (now an error is found and comunicated to the caller, but without any error codes)
bye
S.T.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
//find if the MD5 / tune is already in the list
// we go from the top of the list
for (unsigned int i=0; i<list->number; i++) {
if (list->item[i] != NULL) { // be sure that exist (just for security)
if ( (strcmp(list->item[i]->MD5, MD5) ==0) && (list->item[i]->tune == tune)) {
// tune is already in list
<----------------- rec still NULL********************
if (rec->cached==false) readRecord(rec);
Also please change the NULLs in the ini_open calls to the relevant comment strings e.g. ";". Using NULL for later versions of libini causes it to crash.
Lastely the configure.in contains a bad Makefile. You need to remove src/tsid2/include/Makefile.
Simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are almost ready to integrate a version of tsid into sidplay2(/w). Preferably we would like to add TSID2 support as it's based on the more flexible MD5 key structure and I've been eagerly awaiting a first stab usable version of the code.
I see that TSID2-0.1 but could you provide the following information:
Can this be updated with changes to HVSC?
Can statics be extracted yet via the library even if theres no standalone program?
Is there any upgrade path in tsid2 library (or via an external program) to convert tsid1 user data to tsid2?
Any information on implemented library features or important missing library features would also usefull.
>We are almost ready to integrate a version of tsid into sidplay2(/w). >Preferably we would like to add TSID2 support as it's based on the more >flexible MD5 key structure and I've been eagerly awaiting a first stab >usable version of the code.
Take present that for TSID2 0.1 I have already correct two important bugs that affect the real time lists generation (no, fortunately, the stored data). I would like to release TSID2 0.2 for this soon, but at the moment, I obtains some segmentation fault after some continuate use of the library that I'm not able to detect when debugging with EFence.
>Can this be updated with changes to HVSC?
no at the moment:
The update of the stored data for being in sync with HVSC (or CGSC), is probably the task that require more code to add.
Actually, I'm able to produce an TSID/HVSC upgrade for TSID 1 in about 2/3 hours, but most of the time is only for listening to the tunes that require special adjustment in subtunes order, as the LaLa updatePath script performe most of the required works.
In order to produce a such files based onto MD5, I must provide a Perl script that automate this process (this is why I'm now studying Perl).
On the TSID2 side, the 'tupdate' program of TSID1 must be only adapted to the syntax of the new files.
Fortunately, the use of MD5 do not allow to overwrite already stored data of a different HVSC version (as can be occurred with TSID1 if it is not updated as soon as the HVSC is upgraded). With TSID2 the update can be apply more times and without any particular order. I manage to provide HVSC upgrade for TSID2 from the previous HVSC version, as I have already stored data of TSID2 of that version.
>Can statics be extracted yet via the library even if theres no >standalone program?
At the moment you can obtain the stored information in 2 ways:
1) With the class TBlist you can have the tune info (position/MD5/subtune/listen time/number of listen/last known path and name/last know length) of the most used tunes (the size is a user paramether).
2) with the TSidExeminer2 you can have the tune information as in TBlist, but of all the tunes.
What is actually missing in TSidExaminer2 is the capacity of reading a provided Collection name files of the form:
[HVSC]
MD5_fingerprinter1 /DEMOS/PIPPO.sid
MD5_fingerprinter2 /DEMOS/PLUTO.sid
....
[CGSC]
MD5_fingerprinter9 /VARY/PIPPO.mus
...
Then this information should be used for giving output like in 'examiner' program of TSID 1. So, give total time listen for one Author (so by grouping sids with the same path ...).
Generating such files is quite easy using a little Perl script, then the implementation of the code in TSidExaminer2 can be easy using LibIni and reusing the code of TSidExaminer (of TSID 1).
>Is there any upgrade path in tsid2 library (or via an external >program) to convert tsid1 user data to tsid2?
Conversion from TSID1 data to TSID2 data will be granted as I have about 2 years of stored statistic with TSID1 that I want to transfer to TSID2.
The task is easy as both TSID and TSID2 library can be used together, so a little program will do that. (I think to be able to produce such program in some days)-
>Any information on implemented library features or important missing library features would also usefull.
The only class that need more features is TSidExaminer2 for the reason describe above.
All the other class need only to implement the error handling (now an error is found and comunicated to the caller, but without any error codes)
bye
S.T.
The CVS version of tsid2 crashes here:
void TBLIST::addList(tblistList *list, const char *MD5, unsigned int tune,
unsigned long int rate, bool isTime) {
BDEBUG("Add " << rate << " for #" << tune << "-" << MD5 <<" to one list with "
<< list->number <<" elements\n");
tblistRecord *rec=NULL;
//security action
if (list==NULL) {
// error, cannot continue
return;
}
//find if the MD5 / tune is already in the list
// we go from the top of the list
for (unsigned int i=0; i<list->number; i++) {
if (list->item[i] != NULL) { // be sure that exist (just for security)
if ( (strcmp(list->item[i]->MD5, MD5) ==0) && (list->item[i]->tune == tune)) {
// tune is already in list
<----------------- rec still NULL********************
if (rec->cached==false) readRecord(rec);
Also please change the NULLs in the ini_open calls to the relevant comment strings e.g. ";". Using NULL for later versions of libini causes it to crash.
Lastely the configure.in contains a bad Makefile. You need to remove src/tsid2/include/Makefile.
Simon
< <----------------- rec still NULL********************
>if (rec->cached==false) readRecord(rec);
Yes, this line must be below the line that come after otherwine the pointer is not initialize!
All fix will be available for this weekend. Else the program for convert old tsid data to new format is almost done (I've to test extensively)
bye
S.T.