Testing the Kodi 18 1013 build. I found a problem, probably extends back to Krypton. I had a bad composer name (misspelling) in a specific song file. I corrected the spelling and did a music library update, followed by clean. Looking at my database, the bad artist name is still in the artist table and is still linked back to the song (in song_artist) from which it was removed. This is the only song that ever was tagged with this composer. The corrected artist name string is also in the database as a separate artist and in song_artist, both with idRole of composer and linked to the idSong.
I should note that the correctly spelled artist name also has a role of artist (same song) and has the correct artist MBID in the artist table. The misspelled artist name has no other data associated with it.
scott s.
.
Thanks Scott, I'll investigate.
Hum... I don't seem to be able to reproduce this, nor imagine why the tag rescan didn't clean out that entry. Rescanning calls CMusicDatabase::RemoveSongsFromPath() that deletes the from the song table, and a trigger then clears song_artist, song_grenre and art tables.
Perhaps check that the tgrDeleteSong trigger exists on that db? No idea why it wouldn't be there.
Can you also confirm that the mis-named artist has role of composer in the song_artist table, or something else.
(BTW please check for a PM from me. New forum is not making them as obvious as the old one)
I have another composer problem. Not sure if it is related. My mp3 file has ID3v2.3 TCOM "Joe Darion/Larry Coleman". Forward slash is the spec required separator for TCOM. The file also has APEv2 tags COMPOSER "Joe Darion" and COMPOSER "Larry Coleman". Prioritiseapetags is true in advancedsettings. After scanning I get 3 new artists with composer roles: Joe Darion, Joe Darion/Larry Coleman, and Larry Coleman.
So it seems like 2 problems:
1. The tag parsing isn't properly applying the spec separator of forward slash in ID3v2.3 TCOM.
2. As I read the logic, first the ID3v2 tags are read and parsed. Then if prioritiseapetags is true, the APE tags are read and parsed. If COMPOSER exists in the APE tags it should replace whatever was found in the ID3 TCOM, so even with the incorrect parsing of the TCOM the ID3v2 tag shouldn't be saved to the db.
I converted the ID3 tags to v2.4 and that allowed the composers to scan properly, so there does seem to be an issue with the forward slash separator on ID3 v2.3 TCOM.
scott s.
.
Some nice thorough testing Scottt, I'll follow it up.
Meanwhile have I offended you in some way? No replies to my PM and I don't understand it.