Registered Member
|
Hi
Using the GIT version. Just pulled and re-compiled. This is something that left me wondering for a few days but running amarok -d gave me the answer. The problem is, when Amarok is building the collection if a song has say the artist tag set to "A B C" and after that other songs have the artist tag set to "A B c" (different case, slightly mistaken tagging) then only the first song is imported as the artist "A B C" and the other songs with the different case are put into "Various Artists" and, this is the worst, in these songs' case the Artist field is not displayed (not in the collection, neither in the playlist, nor in the "Now Playing" block) Example: I had 2 SOAD albums. One tagged as "System Of A Down", the other tagged as "System of a Down". The first album gets imported as "System Of A Down". When the scanner reaches the second album it outputs: amarok: [ERROR!] GREPME MySQL query failed! Duplicate entry 'System of a Down' for key 2 on "INSERT INTO artists_temp( name ) VALUES ('System of a Down');" (x n times the number of songs) IMHO amarok should either display some warning at the end of the import process or import case-sensitively and then let the user see that his collection's tags are messed up. Not sure if this is a bug or deliberate behavior but in any case the blank artist field is a problem. PS: I created an account to report on KDE's bugzilla but what made me post here instead is that I couldn't find any "mask email address" option. I'd like to report things on Bugzilla as instructed but I don't feel like leaving my email address in the wild... anyone knows how to achieve that?? |
Registered Member
|
btw, re-tagging these 2 albums as "System of a Down" and doing a full rescan imports them correctly as the same artist but in Amarok they still display as "System Of A Down"...
Do I really need to wipe out the whole collection every time I'm fixing few tags? |
Registered Member
|
GIT is work in progress and reporting bugs is senseless, because they could be fixed in the meantime.
Using it, is risky and can havoc your database. And differentiating the cases is correct behaviour of an adult OS. m0nk
If men could get pregnant, abortion would be a sacrament.
|
Registered Member
|
I understand the nature of GIT, I'm perfectly aware there are rough edges to expect.
But I'm not talking about a brand new feature here, more like a regression don't you think? btw, the sole reason I'm using the GIT version is that I've seen too many times around here "fixed in SVN" answers to reported bugs... Oh and as for the "differentiating the cases is correct behaviour of an adult OS", yeah sure, great, whatever. How's swallowing errors and silently blanking fields then? And if you had read my post before jumping on the reply button you'd have noticed I was ADVOCATING for case-sensitivity... Thought I'd help, sorry man. |
Manager
|
Actually I'd advocate for case insensitivity (at least as an option) as well as an option for "&" and "And" and "and" to be considered as the same string.
|
Registered users: Baidu [Spider], Bing [Bot], Google [Bot], Yahoo [Bot]