Dynamic Collections + AFT issues

[Maximilian Kossick]

On Sunday, 3. December 2006 10:47, Jeff Mitchell wrote:
> 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.

I'm not convinced that the file was actually moved. The debug output only 
shows an absolute path and a relative path. Without the deviceid ( and mount 
point ) of that file it is impossible to tell if it was moved.

> 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.

I don't have time to test it now but I think the cause for this problem is 
CollectionDB::removeDirFromCollection( QString path )
The method should drop all files in the directory from the tags table too.

> 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

Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/amarok/attachments/20061203/4cac0aa2/attachment.sig>