Version: 1.12 (using KDE 3.3.2, (3.1)) Compiler: gcc version 3.3.5 (Debian 1:3.3.5-6) OS: Linux (alpha) release 2.4.28 When I provide disc information for a CD not in freedb, a local file is generated in a subfolder of the configured local cddb cache, but it has ffffffff prepended to its proper disc id, giving a 16 hex digits name instead of 8 hex digits. Therefore, the entry will not be found by subsequent requests. I don't know which ID would be sent to a freedb server.
Changed to libkcddb which does the saving of that file.
I wasn't able to reproduce this with either 3.3.2 release or with HEAD. Are you able to reproduce this? If you are, could you give some more detailed instructions on how to reproduce it.
I tried quite a few CDs with this effect. But I found one, where a different effect occured. There, no ffffffff was prepended, but the filename obviously was one character too short (70fea11) and the entry equally was not found by KAudioCreator when I re-inserted the disc. Renaming this file to 070fea11 fixed the problem. It may be that the discs producing the ffffffff problem all have the MSB set (i.e. ID >= 80000000) - this is the case as far as I can recall. So it may be that disks with 10000000 <= ID < 80000000 would work OK, but I could not find an example for this yet. Given the fact that (in the first case), a filename representing a negative 32bit number expands to a filename representing a negative 64bit number, I would suggest to check for explicit assumptions about bit lengths of integers or pointers in conjunction with signed/unsigned errors. Mind that pointers, int's and long int's are all 64bit on Alpha.
CVS commit by larkang: Make sure the disc-id is never shorter than 8 characters CCBUG: 101790 M +1 -1 tracksimp.cpp 1.57 --- kdemultimedia/kaudiocreator/tracksimp.cpp #1.56:1.57 @@ -170,5 +170,5 @@ void TracksImp::lookupDevice() { } - QString currentDistID = QString::number(cddb_discid(), 16); + QString currentDistID = QString::number(cddb_discid(), 16).rightJustify(8, '0'); if (currentDistID == cddbInfo.id) { return;
Ah, if cddb_discid() returns either a (signed) (long) int, or the result of a signed calculation assigned to unsigned int, it would explain the ffffffff problem.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
I have not been able to reproduce this bug. None of the few CDs that went into the machine in the last year triggered it.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!