Dynamic Collections + AFT issues

[Jeff Mitchell]

A lot of people have been complaining about seeing errors like this on every 
single file in their collection:

amarok:     [CollectionDB] [WARNING!] Already-scanned file 
at /mnt/shared/Current Media/CDs/Classical/Richard Strauss/London 
Philharmonic Orchestra/Richard Strauss - London Philharmonic Orchestra - 11 - 
Four Last Songs - Fruhling.mp3 has same UID as new file at ./Current 
Media/CDs/Classical/Richard Strauss/London Philharmonic Orchestra/Richard 
Strauss - London Philharmonic Orchestra - 11 - Four Last Songs - Fruhling.mp3
amarok:     [CollectionDB] [WARNING!] Already-scanned file 
at /mnt/shared/Current Media/CDs/Classical/Richard Strauss/London 
Philharmonic Orchestra/Richard Strauss - London Philharmonic Orchestra - 12 - 
Four Last Songs - September.mp3 has same UID as new file at ./Current 
Media/CDs/Classical/Richard Strauss/London Philharmonic Orchestra/Richard 
Strauss - London Philharmonic Orchestra - 12 - Four Last Songs - 
September.mp3


If you'll notice, the difference between the "already-scanned file" and 
the "new file" are that the prefixes are different -- the previous prefix was 
nothing and the new one is /mnt/shared.

What's happening is that AFT finds the UID and does a stat to see if the file 
is still at the other location.  The stat is done on the absolute path, so it 
works, and AFT hits a case where it essentially thinks it sees two copies of 
the same file.

I'm confused as to why this happens, because AFAIK when dynamic collections 
changes a device id, it should update the tables.  I don't know under what 
conditions the device ID changed, either -- the file has stayed in the same 
place.

Anyways, I'm looking for input on solutions.  On the AFT side, if the new 
location and old location have the same absolute path, instead of stat-ing, I 
could just do the update (including with the new url and deviceid), and only 
do the stat if the absolute paths of the new and old locations differ.  But 
before I commit to that, I was hoping to get some input as to why this 
situation can occur -- why the ID would change, and why the database isn't 
being updated if it should be -- to see if maybe the fix should lie in 
dynamic collection code instead, in case this could be affecting other areas 
(I have some weird problem with it saving statistics too, which I think may 
be related).

--Jeff