My specific case:
NDBM 1.24 and 1.25 (at least, maybe earlier releases also)
Mandrake Linux 9
I had 2 files in one of the HISI directories with mp3
extensions but 0 size. Every time I would connect my
Neuros (20G model) and start up NDBM, if I checked the
database information, the total time would be waaaaaaay
off. I've got approximately 1300 tracks on the device
with a total play time of between 3 and 4 days, but the
DB information was showing total time of over 28
*weeks*. When I deleted the 0-byte files from the HISI
directory (unidentified, I believe), the problem
resolved itself. However, I would venture a guess that
the problem would manifest itself if a user had one of
these 0-byte files (or potentially any kind of
corrupted file with the appropriate file extension) in
any directory that NDBM searches for files.
I do not know if there was any actual database
corruption, since the N worked just fine the whole time.
Logged In: YES
user_id=130375
It probably was a incorrect calculation of the playing time.
Did you notice how much time (reported by NDBM) for each
track that was causing problems?
Logged In: YES
user_id=959787
The more I consider it, the more I believe you're correct
that there was no corruption, just a calculation malfunction.
Unfortunately, I did not notice the reported time of the bad
files...I only knew they were there because I looked in the
log for another reason and saw that it was having difficulty
with a file or files in the HISI directory. Without even
thinking about it (shame on me as a programmer), I removed
the files and discovered that they were causing the problem.
Logged In: YES
user_id=896951
Hmm,
I authored the Time calc stuff. It works fine with
uncorrupted MP3/ogg/wma/wav. But if they are malformed in
some particular way, the time display is indeed incorrect.
I don't think it should be our problem to handle peoples
malformed music files.
As far as I can tell, there isn't any database corruption
with bad times, just wierdness with total times and progress
bar when playing.
just my $0.02
Cheers
Paul Warren
u3292467 at anu dot edu dot au
www.geocities.com/qvack_82
Logged In: YES
user_id=959787
I believe that you're right about the lack of DB corruption.
And I agree that if an audio file is corrupt that there's
not a whole lot to be done about it. However, the files in
question were 0 size files rather than files with corrupted
data in them. Without having inspected the time calc code I
don't know what's going on there, so this may wind up being
a stupid question, but shouldn't we just be able to bypass
files like that since there's nothing there to work with? If
it's a stupid question, feel free to flog me. :)