Dynamic Collections + AFT issues

[Jeff Mitchell]

On Sunday 03 December 2006 13:36, Maximilian Kossick wrote:
> 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.

The file wasn't moved -- it stayed in the same place.  What changed is that 
the DynCol mount point changed from (nothing) to /mnt/shared (and the 
deviceid changed as well).  As a result when the uniqueid database is checked 
for the file, the query fails, but then when the stat is done on it, the stat 
works.  Without dynamic collections (one workaround I was told on IRC is to 
disable DynCol in amarokrc), this is correct behavior -- if a file is 
scanned, and is not in the same place as the old file with the same ID, and 
the old file is still in existence, the new one is a copy.  With DynCol, when 
the deviceid/mountpoint changes, the "is not in the same place as the old 
file with the same ID" step is true, when it should be false.

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

Sure, look at it when you have time.  I'm going to do the fix on the AFT 
side -- I think it should be there as a sanity check anyways.

--Jeff