I sometimes tend and like to have very long and descriptive dir names. the collection scan always fails on such songs (having such long paths). here the corresponding debug output: amarok: [ERROR__] [MySqlStorage] "GREPME MySQLe query failed! (1062) Duplicate entry '2-./rfr/tmp/amaroktest/Isis/2010 - Mosquito Control - The Red Se' for key 'urls_id_rpath' on INSERT INTO urls (deviceid,rpath,directory,uniqueid) VALUES (2,'./rfr/tmp/amaroktest/Isis/2010 - Mosquito Control - The Red Sea - Celestial - SGNL-05 - Oceanic - Panopticon [Daymare Recordings - Box Set]/2002 - The Mosquito Control EP - The Red Sea [2009-2010 Reissue - Daymare Recordings - Box Set - DYMC-112, TGCS-6013-6014]/Disc One - The Mosquito Control EP [1998, 2001, Japanese Edition 2002, 2009]/02 - Life Under The Swatter.flac',3,'amarok-sqltrackuid://9ea2b29ef3dd33fd057130e840909314'),(2,'./rfr/tmp/amaroktest/Isis/2010 - Mosquito Control - The Red Sea - Celestial - SGNL-05 - Oceanic - Panopticon [Daymare Recordings - Box Set]/2002 - The Mosquito Control EP - The Red Sea [2009-2010 Reissue - Daymare Recordings - Box Set - DYMC-112, TGCS-6013-6014]/Disc One - The Mosquito Control EP [1998, 2001, Japanese Edition 2002, 2009]/01 - Poison Eggs.flac',3,'amarok-sqltrackuid://a8ab835e4589a86dda9156775851e65d');" To figure out whats wrong I set up a mysql database (but the error also occurs with embedded mysql). It seems to be the case that in table urls the field "rpath" can not be longer than around 325 characters. Reproducible: Always Steps to Reproduce: 1.2 songs with same dir-path, where the path is longer than around 325 characters. 2.collection scan (best with a clean amarok config) 3.only 1 of the songs is imported Actual Results: only 1 of the songs is imported
Yes, the database table has a lenght restiction for paths and it's at (I think) 320 characters. Good to know that these limits will actually be hit.
a temporary fix is to just not create the index urls_id_rpath on the table urls. Than it is possible to give the rpath column in table urls the (maximal) length 1000. I do not know what the downside (presumably in speed) of this is. I didn't had any issues so far ...
What is the status of this in Amarok 2.7?
Moving to wishlist, as this is due to a restriction in the database and would need a change there.
This hits *every* file I have stored in git-annex, which gives files names like this: ./anthony/Music/.git/annex/objects/Kw/pm/SHA512E-s27830960--a0e7606a89737a92e1fd83ab59d6d36531de59c481bc4e50f465795e02b575da62995d2285dc6f6bb4b9f165065146e9aff3b0c30249b148edb0979aa24b4567.flac/SHA512E-s27830960--a0e7606a89737a92e1fd83ab59d6d36531de59c481bc4e50f465795e02b575da62995d2285dc6f6bb4b9f165065146e9aff3b0c30249b148edb0979aa24b4567.flac That's 350 characters. (I use SHA-512 because SHA-256 is not only weaker, but *slower* on modern machines). But there is a simple fix: alter table urls modify column rpath varbinary(996); Not sure if that breaks non-ASCII characters (I have a bunch, but only in the symlink names, and Amarok is using the targets instead), but if it does, I'm not sure why Amarok wants to treat file names as text, really it ought to givem them back to the OS exactly the same as the OS gave it to Amarok.