>This really needs to be fixed or it's going to cause havoc when 7.4 is >released. I'm not sure where the difference lies, but previously these >would be treated as the same. I thought that the way it worked was to >transform the characters with diacritics into their non-diacritic >character counterparts. > I prefer the way it works now in SQLite; I considered the old behaviour a bug. What is in tags should be what is displayed in the app, so if you have entered albums by "Mel Torme" and "Mel Tormé", they should be treated as different artists. It's then easy it identify errors in tags and fix them.
e.g What if I had artist tags containing "Enrique Englesias", "Enriqué Englesias" and "Enriqué Englésias"? In MySQL, it was non-deterministic as to what was displayed for the artist in the app, as it depended what order the files were scanned in. If it picked the wrong one and you wanted to change tags to fix the display name, you had to find the song that needed updating, but as the app wasn't reporting the tags for the song, it meant that fixing tags was harder. Also, a scan for new/changed music wouldn't then pick up tag changes; a full wipe+rescan was necessary. I haven't tried a new/changed scan after having changed one artist tag to be another artist tag (to merge their albums/songs together under one artist), as I can't get sqlite scanning to work now, but this would be a good test. >Searching is also broken with respect to the old behavior. Take the >artist 'Mel Tormé'. In SC7.4 Trunk, if I search with 'mel torme' it >finds the artist. In SC7.4 noweb-sqlite, the search comes back empty. That's a bug though; I'd expect a search for "Torme" or "Tormé" to return both artists "Torme" and "Tormé". i.e. store a search field without any diacritics. Strip search string of diacritics, and find matches. Then display the artist display name for any matches found. _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
