Bugzilla – Bug 17457
Import actions failing on case insensitive filesystems (Windows)
Last modified: 2011-08-19 05:09:57 UTC
Up to 7.5.x Slim::Schema->objectForUrl() wasn't case sensitive, as MySQL's TEXT type isn't case sensitive. This changed in 7.6, as SQLite is case sensitive by default. Thus many import actions seem to be failing, as playlists, iTunes XML or MusicIP do not always use the same case for eg. drive letters or folder names. objectForUrl() wouldn't find them any more. Unfortunately with SQLite we can't change a column's definition. Don't know how to handle this the best. We could change schema_1_up.sql, but this would require users to clean their cache and start from scratch. Or we dump the track table and re-build it with the new additions? The following change fixed eg. bug 17450. Other columns might need to be considered too. Index: schema_1_up.sql ==================================================== --- schema_1_up.sql (revision 33102) +++ schema_1_up.sql (working copy) @@ -34,7 +34,7 @@ DROP TABLE IF EXISTS tracks; CREATE TABLE tracks ( id INTEGER PRIMARY KEY AUTOINCREMENT, - url text NOT NULL, + url text NOT NULL COLLATE NOCASE, title blob, titlesort text, titlesearch text,
Could this be a workaround? The drive letter stored in the DB is 'F'. It does appear to be case sensitive using the = operator, but not the LIKE operator. This returns nothing: SELECT * FROM tracks_persistent WHERE url = 'file:///f:/Flac/McCoy Tyner/The%20Real%20McCoy/01%20Passion%20Dance.flac'; But this works: SELECT * FROM tracks_persistent WHERE url LIKE 'file:///f:/Flac/McCoy Tyner/The%20Real%20McCoy/01%20Passion%20Dance.flac'; I'm not sure how the % characters in the URL are dealt with, but would assume the SQLite handler escapes them properly.
Oh, my checkin notification didn't make it to the bug report... I already changed the schema in trunk. Please svn up and give it a test ride!
Will do. Why isn't the same change needed in tracks_persistent?