"Misspelled" artists remain in the database

[frank1969]

>> What would such a clean up do which the regular scan shouldn't already
>> be doing?...
>
> It was just an idea to keep the "new&changed" quick (and I like it to be
> this quick ) to "outsource" options like looking for orphaned entries
> in a separate routine You only use once a week or once a month... (the
> "n&c" I use daily).

You're one of the multi 100k tracks guys, aren't you? Would you mind
sharing a (compressed) copy of your library.db which is in a "has empty
artists" state?

https://www.dropbox.com/request/T3RctyzGgNg0oFDubq6a

I wonder whether a simple SQL query could cure this particular problem.

> OK, for now I have 3 main issues (I started to look into the sqlite
> myself to get some "idea" where they result from, but I'm really not an
> expert ;-))

Please create tickets on Github for the actual bugs. Thanks!

> 1. Artists without any tracks in the database are still listed and still
> linked to their "old" entries

The problem here being that the artist is listed even though it's only
there as a "secondary" contributor, not to be listed?

> 3. Adding tracks to an existing albums result in two albums of the same
> name
>
> (Happens when You add tracks from a deluxe edition e.g.:
> - Standard edition is in database (one album, 10 tracks) => all fine
> - You add track 11-13 from the deluxe edition: SAME (windows) folder,
> SAME album name, SAME year, SAME album artist, SAME compilation tag
> eg...) => You have TWO albums of the same name and artist in Your db,
> one with track 1-10 , the other one with track 11-13)

This IMHO would only happen if the tracks were stored in different
places, if the titles differed (eg. due to the appended "deluxe
edition"), or if some musicbrainz ID was different. Please double and
triple check that this is not a tagging issue. Would a wipe & rescan
overcome this issue? Here again a copy of a libary.db in this state
could be helpful.

[frank1969]

"Misspelled" artists remain in the database

One bug about cleaning up database, that still exists
(I just did a clear scan a few weeks ago):

If You correct an artists name (e.g. misspelling), the old artist remains in the database although it has NO existing tracks.

e.g.:
- You have misspelled "Beetles" on some tracks in Your database.
- You correct it to "Beatles"
- You do a "new & changed scan"
- You search for "Beatles" (and click on the artist name) - the tracks (before tagged with "Beetles") are found - FINE!
- You search for "Beetles" (and click on the artist name) - the tracks (before tagged with "Beetles") are still found. When You "click" them, it shows "empty" ("leer").

So they are really gone - but there still is a connection between the misspelled artist and the (now corrected) tracks.

One idea:
Maybe we could invent something like a "Database cleanup" routine (in addition to the "new & changed") - I saw something like this in Media Monkey.
There are a few more "bugs" (e.g. the "Windows bug" (I know, it is caused by windows and not by LMS, but it's frustrating) of being not case sensitive (e.g. If You correct a file name from "...beatles..." to "...Beatles..." You have TWO entries in Your database, pointing to the same file (one with small letter, one with capital letter)...

btw: THANKS for Your great work.

Frank

[slartibartfast]

One bug about cleaning up database, that still exists
(I just did a clear scan a few weeks ago):

If You correct an artists name (e.g. misspelling), the old artist remains in the database although it has NO existing tracks.

e.g.:
- You have misspelled "Beetles" on some tracks in Your database.
- You correct it to "Beatles"
- You do a "new & changed scan"
- You search for "Beatles" (and click on the artist name) - the tracks (before tagged with "Beetles") are found - FINE!
- You search for "Beetles" (and click on the artist name) - the tracks (before tagged with "Beetles") are still found. When You "click" them, it shows "empty" ("leer").

So they are really gone - but there still is a connection between the misspelled artist and the (now corrected) tracks.

One idea:
Maybe we could invent something like a "Database cleanup" routine (in addition to the "new & changed") - I saw something like this in Media Monkey.
There are a few more "bugs" (e.g. the "Windows bug" (I know, it is caused by windows and not by LMS, but it's frustrating) of being not case sensitive (e.g. If You correct a file name from "...beatles..." to "...Beatles..." You have TWO entries in Your database, pointing to the same file (one with small letter, one with capital letter)...

btw: THANKS for Your great work.

Frank

I have always found that "new and changed" scan can leave lots of unexpected things behind. The only way to be safe is to do a "Clear and rescan" or remove incorrectly tagged items, do a "new and changed" scan, replace corrected items and do another "new and changed" scan.

Sent from my Pixel 3a using Tapatalk

[frank1969]

I have always found that "new and changed" scan can leave lots of unexpected things behind. The only way to be safe is to do a "Clear and rescan" or remove incorrectly tagged items, do a "new and changed" scan, replace corrected items and do another "new and changed" scan.

Thanks!
Yes, I have the same experience and sometimes I do it that way (moving files to a "quarantine" ordner, do a "new&changed", correct them and move them back, do another "new&changed").

But I guess/hope this forum is a chance to make LMS even (still) better and find a solution without those workarounds...

btw: I just looked into the sqlite-database and "try" something with a new scan...

[slartibartfast]

Thanks!
Yes, I have the same experience and sometimes I do it that way (moving files to a "quarantine" ordner, do a "new&changed", correct them and move them back, do another "new&changed").

But I guess/hope this forum is a chance to make LMS even (still) better and find a solution without those workarounds...

btw: I just looked into the sqlite-database and "try" something with a new scan...

It would be a welcome improvement if "new and changed" worked correctly.

Sent from my Pixel 3a using Tapatalk

[mherger]

"Misspelled" artists remain in the database

> Maybe we could invent something like a "Database cleanup" routine (in
> addition to the "new & changed") - I saw something like this in Media
> Monkey.

What would such a clean up do which the regular scan shouldn't already
be doing?... I think we have to clearly identify the open issues we
have. Some of them already are on Github (eg.
https://github.com/Logitech/slimserver/issues/547). Can we compile a
complete list, with easy descriptions to reproduce the issue?

Once we have a good understanding of what was wrong we can look into how
to fix the issues. I believe if they were easy to fix, this would have
happened long before. But maybe we could indeed simply add a purely
database based cleanup step, eg. figure out orphaned entries etc.

> There are a few more "bugs" (e.g. the "Windows bug" (I know, it is
> caused by windows and not by LMS, but it's frustrating) of being not
> case sensitive (e.g. If You correct a file name from "...beatles..." to
> "...Beatles..." You have TWO entries in Your database, pointing to the
> same file (one with small letter, one with capital letter)...

Could probably be tweaked to behave better, too.

[frank1969]

What would such a clean up do which the regular scan shouldn't already
be doing?...

It was just an idea to keep the "new&changed" quick (and I like it to be this quick ) to "outsource" options like looking for orphaned entries in a separate routine You only use once a week or once a month... (the "n&c" I use daily).

I think we have to clearly identify the open issues we
have. Some of them already are on Github (eg.
https://github.com/Logitech/slimserver/issues/547). Can we compile a
complete list, with easy descriptions to reproduce the issue?

OK, for now I have 3 main issues (I started to look into the sqlite myself to get some "idea" where they result from, but I'm really not an expert ;-))

1. Artists without any tracks in the database are still listed and still linked to their "old" entries

(I just reproduced this by looking in the db and found the reason - the misspelled name ("Beetles") was still in another track tagged with anouther contributor role (composer). So it still had an ID in contributors - and was linked in contributor_track just to this ONE track (after correcting the composers spelling it was gone). But the main problem is, that as long as the contributor id is "active" there seems to be still a connection to "old" entries, where it was mentioned before (couldn't see where it resulted from, now it's gone - will keep an eye when it happens again)

2. Chaning capitalization / lower case in FILENAME leads to double entries

(I can reproduce this issue ONLY if the filename is changed - changing capitalization in another tag (e.g. track, artist) seems to work fine)

3. Adding tracks to an existing albums result in two albums of the same name

(Happens when You add tracks from a deluxe edition e.g.:
- Standard edition is in database (one album, 10 tracks) => all fine
- You add track 11-13 from the deluxe edition: SAME (windows) folder, SAME album name, SAME year, SAME album artist, SAME compilation tag eg...) => You have TWO albums of the same name and artist in Your db, one with track 1-10 , the other one with track 11-13)

Many thanks for caring
Frank


Once we have a good understanding of what was wrong we can look into how
to fix the issues. I believe if they were easy to fix, this would have
happened long before. But maybe we could indeed simply add a purely
database based cleanup step, eg. figure out orphaned entries etc.

> There are a few more "bugs" (e.g. the "Windows bug" (I know, it is
> caused by windows and not by LMS, but it's frustrating) of being not
> case sensitive (e.g. If You correct a file name from "...beatles..." to
> "...Beatles..." You have TWO entries in Your database, pointing to the
> same file (one with small letter, one with capital letter)...

Could probably be tweaked to behave better, too.[/QUOTE]

[slartibartfast]

It was just an idea to keep the "new&changed" quick (and I like it to be this quick ) to "outsource" options like looking for orphaned entries in a separate routine You only use once a week or once a month... (the "n&c" I use daily).




OK, for now I have 3 main issues (I started to look into the sqlite myself to get some "idea" where they result from, but I'm really not an expert ;-))

1. Artists without any tracks in the database are still listed and still linked to their "old" entries

(I just reproduced this by looking in the db and found the reason - the misspelled name ("Beetles") was still in another track tagged with anouther contributor role (composer). So it still had an ID in contributors - and was linked in contributor_track just to this ONE track (after correcting the composers spelling it was gone). But the main problem is, that as long as the contributor id is "active" there seems to be still a connection to "old" entries, where it was mentioned before (couldn't see where it resulted from, now it's gone - will keep an eye when it happens again)

2. Chaning capitalization / lower case in FILENAME leads to double entries

(I can reproduce this issue ONLY if the filename is changed - changing capitalization in another tag (e.g. track, artist) seems to work fine)

3. Adding tracks to an existing albums result in two albums of the same name

(Happens when You add tracks from a deluxe edition e.g.:
- Standard edition is in database (one album, 10 tracks) => all fine
- You add track 11-13 from the deluxe edition: SAME (windows) folder, SAME album name, SAME year, SAME album artist, SAME compilation tag eg...) => You have TWO albums of the same name and artist in Your db, one with track 1-10 , the other one with track 11-13)

Many thanks for caring
Frank


Once we have a good understanding of what was wrong we can look into how
to fix the issues. I believe if they were easy to fix, this would have
happened long before. But maybe we could indeed simply add a purely
database based cleanup step, eg. figure out orphaned entries etc.

> There are a few more "bugs" (e.g. the "Windows bug" (I know, it is
> caused by windows and not by LMS, but it's frustrating) of being not
> case sensitive (e.g. If You correct a file name from "...beatles..." to
> "...Beatles..." You have TWO entries in Your database, pointing to the
> same file (one with small letter, one with capital letter)...

Could probably be tweaked to behave better, too.

[/QUOTE]I seem to remember "new and changed" doesn't pick up a changed folder.jpg.
I don't trust it with anything to do with tag changes either.
The only situation where I am confident it will work is adding or deleting albums.

Sent from my Pixel 3a using Tapatalk