Notice: Comments you submit will be routed for moderation. If you have an account, please log in first.

Ticket #4 (closed Bug: Fixed)

Opened 8 years ago

Last modified 2 years ago

Collection corruption

Reported by: bflorat Owned by: bflorat
Priority: 9, highest Milestone:
Component: Core Version: Init dev
Keywords: Cc:

Description

In some cases on big collection volume, several tracks
can get the same track id.

Attachments

Change History

Changed 8 years ago by bflorat

  • status changed from assigned to closed

Changed 8 years ago by bflorat

Logged In: YES 
user_id=363565

Fixed : we now take album into account when computing track
MD5. 

Note however that event with this fix, a design problem
could accur if two tracks with no name, no album, no author
have the same length and type. It can occur if option 'use
directory as album name' is unchecked and collection has
very few id3 tags. This will not be fixed because it is
design. Note that in the case of a very poorely tagged
collection, logical perspective will probably not be used at
all because it is useless.

Possible problem : low : 2 physical files totally different
could be asociated to the same track. Then stats could
erronus and a property set on a track could be seen for a
wrong file.

Changed 8 years ago by bflorat

Logged In: YES 
user_id=363565

Followup:

Added a fix to definitively prevent from the very unlikely
bug described before ( track confusion for two files having
none id3 tag , same name, same length and same size ) :
Added a low level checksum on files by reading 10 bytes
inside the file itself. This sub-checksum is token into
account in the file checksum. ( see Util.getFileChecksum )

Conclusion : This phantom bug is definively fixed

Add/Change #4 (Collection corruption)

Author



Action
as closed
Next status will be 'reopened'
 
Note: See TracTickets for help on using tickets.