Some confusion: If files are read from a Samba drive, it is possible to access the same file regardless of the character case.
For example, "Nights in white satin.mp3" and "NIGHTS IN WHITE SATIN.mp3" can both be opened and refer to the same file. regardless of the character case of the original file. This is by design, Samba/SMB does not care about that and considers both files equal.
A look into the database with an SQL browser reveals that there are several file entries created with different character case. This is correct. But only one entry is updated (i.e. the finished flag, file size etc. filled in). This causes the file to be transcoded over and over.
Reason:
"SELECT WHERE filename = 'Nights in white satin.mp3'" is case sensitive, while "SELECT WHERE filename LIKE 'Nights in white satin.mp3' is not.
Solution:
SQLite must specifically instructed to handle LIKE statements case sensitive as well. Strange as it seems...
Some confusion: If files are read from a Samba drive, it is possible to access the same file regardless of the character case.
For example, "Nights in white satin.mp3" and "NIGHTS IN WHITE SATIN.mp3" can both be opened and refer to the same file. regardless of the character case of the original file. This is by design, Samba/SMB does not care about that and considers both files equal.
A look into the database with an SQL browser reveals that there are several file entries created with different character case. This is correct. But only one entry is updated (i.e. the finished flag, file size etc. filled in). This causes the file to be transcoded over and over.
Reason:
"SELECT WHERE filename = 'Nights in white satin.mp3'" is case sensitive, while "SELECT WHERE filename LIKE 'Nights in white satin.mp3' is not.
Solution:
SQLite must specifically instructed to handle LIKE statements case sensitive as well. Strange as it seems...