1.4.3

[Joe Rabinoff]

Hi Jeff --

After some more thought, I've decided that AFT needs a bit more functionality 
before the moodbar can really be AFT-enabled.  Namely, I want to be able to 
delete moodbars when music files are deleted -- users would get annoyed if 
they stored their moodbars with music, and deleting music files didn't result 
in mood files being deleted as well.  We talked a bit on #amarok about how 
one might do this -- namely, queueing deletions until the collection scanner 
finishes -- but I don't think this is really the right solution, since 
there's no systematic way of telling which files were added back *in place* 
(as opposed to having been moved).  I could hack something together as it is 
probably, but what seems to me to be the most elegant solution would be as 
follows: AFT should emit signals for both moved *and* deleted files.  When it 
comes down to it, the AFT code is where you would figure out whether a file 
has been deleted anyway.  So I'm envisioning something like what you 
suggested: the incremental collection scanner keeps a list of all the files 
it has deleted from the main tags table (the ones in the dirs it's scanning), 
then every time a track is added, the AFT code checks it off as either having 
been added back in place or moved.  For anything left over, a 
CollectionDB::fileDeleted() signal or something should be emitted.  The point 
is, you don't really know if files have been deleted or not until AFT has 
checked if they've been moved or added back in place.

I'm happy to try to code this up if you don't want to, although I'm sure you'd 
be able to do it faster since you know your way around the AFT code.  Let me 
know what you think.

Joe


On Monday 04 September 2006 08:04, Jeff Mitchell wrote:
> I can definitely help with the AFT part, but if you want to try it yourself
> before you and I chat (and, since I'll be on vacation from next Thursday
> until two Tuesdays after that I won't have much time to talk until 1.4.3 is
> released) have a look at two signals emitted from CollectionDB: fileMoved
> and uniqueIdChanged.  (Note that fileMoved is overloaded; you're concerned
> with the three-argument version).
>
> fileMoved emits (old path, new path, unique id), uniqueIdChanged emits
> (path, old unique id, new unique id).  All paths are absolute -- I guess
> they theoretically could be changed at some point to emit a device ID as
> well as a relative path, but that's down the line.  If you need to be
> Dynamic Collections-friendly, have a look at
> CollectionDB::aftMigrateStatisticsUrl for how to get the device id and
> relative path.
>
> That's it -- just connect two slots to those signals and figure out how to
> use 'em.
>
> --Jeff