New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scanner: Changing large and lower case in FILE name results in double entries (on Windows) #705
Comments
I could imagine that this would be Windows (and probably some macOS) only issue: internally we sometimes compare the hashes of the path, sometimes check the real path name. On a case insensitive file system the latter would succeed, while the hash comparison would fail. |
@mherger , yes, I'm sure it's a problem of case(in)senstivity / windows, but it works in a wired way (I'll do some testes and look into the db afterwards). If I change ABC.mp3 => abc.mp3 (filename) ABC.mp3 (#1) and abc.mp3 (#2) But when "removing" scanner should "normally" see (for they are different tracks to the database), that abc.mp3 (#1) is still there, while ABC.mp3 (#2) is gone and remove it from the db? So it looks to me the adding part of the scanner is casesensitive, while the removing part isn't? |
Never mind: you seem to be right. I changed one character in a filename from lower to uppercase:
|
Argh... we must have been dealing with this very issue 10 years ago already... without really fixing it? See the comment on the following line, which describes the URL field for the tracks table: It's made case insensitive. The same does not apply to the https://github.com/Logitech/slimserver/blob/public/8.3/SQL/SQLite/schema_11_up.sql So when we look for tracks which are in Fixing this in code will require a bump to the database schema. Which will require a rescan on an update. I try to prevent this, as it's uncomfortable in some situations. But you could try to modify the schema in your own library.db using something like SQLite Studio (https://sqlitestudio.pl): add the If you don't care about running a full rescan you can update to the next 8.3 nightly, delete |
@mherger I just had a look into the tracks table. Timestamp, filesize are identically. Next thing is I will dig the logfile before I will try to modify my db ( I'm btw using DB Browser for SQLite Version ) - I'm not sure if I do have to modify it after every nightly...?! |
Ah, just saw the r1643665089 already, will install it and do a full rescan tomorrow - and will report. |
@mherger , so, I took 1 day for re-scanning my "monster" and another day for some testing, as far as I can see, all 3 issues are gone:
So many MANY thanks for caring! |
One more long standing issue down 😁. |
I know this is known - but with growing databases it becomes more and more important in my eyes:
If I change the large and lower case in a filename or foldername it results in double entries.
e.g.:
C:\A\ABBA\albumname\titlename.mp3
is a different track than
C:\A\ABBA\albumname\Titlename.mp3
obviously for windows is case sensitive at this point, scanner is not, I guess.
So if I change this, it results in "titlename.mp3" AND "Titlename.mp3" resting in the database with the same tags.
For a while I tried to avoid this by only changing the tags when I do some changes on large and lower case and NOT renaming the file.
But for I use mp3tag for tagging and the feature "tag - filename" that creates filenames automatically from my tags, I can't really avoid it.
MANY thanks again for caring.
REM:
I thought this would be an "classic", too, but couldn't find any bug report either.
The text was updated successfully, but these errors were encountered: