From Amarok Wiki

(Redirected from AFT)

Contents

What is it?

Most people do not have static music collections; songs are always being renamed and moved. With most other media players, renaming a file or moving it from folder to folder causes the player to lose track of the file, forcing you to re-add the file to your playlist and possibly to lose any statistics about that song that you may have accumulated. This is time-consuming and annoying. Amarok has implemented file tracking features to cope with this common use-case, allowing Amarok to track your songs as you rename and move your files (referred to as AFT for the rest of this page). Parts of Amarok that can take advantage of this file-tracking behavior are AFT-enabled.

Currently, Amarok's Playlist, Statistics, and cached lyrics are AFT-enabled. Playlist functionality includes AFT support for in-line tag editing, the Tag Dialog, and playback. In addition, Playlist items that are disabled (for instance, if you tried to play a file immediately after a move and before the incremental scanner runs) will be automatically re-enabled as soon as a scan finds the new location of the file. Statistics will track files as they are moved around; you can even move a file out of a collection folder, and put it back in somewhere else and have the stats update to the new location!

How does it work?

Amarok's collection scanner, with incremental updates enabled, already detects additions and deletions of files in your colleciton folders and updates the collection automatically. With AFT, when files are scanned by Amarok's collection scanner, a small portion of the file's data, in addition to the file's size, is used to generate a unique hash. Using this hash, Amarok can check if a file that is being added to the collection is really a file that has simply been renamed or moved. Amarok's Playlist and its statistics table are then updated with the new file name information, allowing you to manage your files without having to manage Amarok, or worry about losing years of statistics information!

There are a few cases in which this tracking can fail:

  1. Both editing a file (i.e. its tags) and renaming it outside of Amarok. AFT can handle either of these cases singularly, but not both at once.
  2. Two identical copies of a file. Only one (the first one the scanner sees) will be tracked.

Note: Because the incremental scanner uses mtimes (modify times) of the selected directories to determine what to rescan, and not of the individual files, if you modify the tags of a file outside of Amarok, the incremental scanner will not re-scan that directory. If you then move one of these files, the tracking will fail. Therefore, if you want tracking to work after you've modified files outside of Amarok you should either: manually run a full rescan of your files, touch the directory that the file resides in (works on most filesystems), or "trick" the incremental scanner into scanning the directory those files were in by creating a new file (i.e. with touch) so that the directory's mtime is updated (you can delete the file after the scan).

How do I turn it on?

You don't -- it's already enabled for every single file in your collection. Enjoy.

Amarok File Tracking -- What Happened to Advanced Tag Features (ATF)?

If you don't know what ATF is or don't care, you don't need to read this.

Amarok File Tracking is the result of a change in the way ATF gathers its unique identifiers (UIDs). When file tracking features in Amarok were conceived, we considered various ways we could track files:

  1. Hash on the entire file. This is slow, as every bit of every file must be read, every time the file changes in some way.
  2. Hash on only the song data, which is nearly as slow, and requires a way to know when the song data starts and stops -- something that was not provided by our tagging library.
  3. Hash on a fixed-length portion of the file. This has the advantage over the previous options in that it requires only a small amount of the file to be read, which generally is long enough and changes enough from song to song to guarantee unique-ness.
  4. Use tags inserted into the file metadata.

When implemented, ATF used UIDs randomly generated and inserted into the metadata of a file. Unlike hash-based methods, a file could be renamed and retagged at the same time and still be successfully tracked. In addition, if a file was copied, a new UID could be assigned to the copy, letting each copy be tracked individually. This effectively solved the two problems listed in the section above, creating a very robust tracking solution. In addition, it was conceived that other useful things could be done with the files by inserting such metadata.

Unfortunately, this method had disadvantages as well, including being unavailable to users with music stored on read-only media, requiring a long initial tagging scan (which for some users with extremely large collections or slow links to them could take upwards of a day), and supporting only the formats that our tagging library can handle. These disadvantages ended up being cumbersome, and the need to insert metadata into files meant we could not make it an option that was on by default, which for a useful feature makes no sense.

Due to these disadvantages, the UID generation has changed to use a hash based on a fixed-length portion of the file and the file's size in bytes. If the tagging library supports it for a particular format, a rendering of the file's tags is also hashed. This method of getting UIDs works over all formats that you can put in your collection, and works for read-only pools of music as well. When this change was made, the Advanced Tag Features/ATF moniker was dropped; after all, since metadata tags are no longer being used with the file-tracking system, it didn't make much sense to have a name that indicated tags played a role. The new system is simply referred to as file tracking, or, for short, feel free to switch two letters from ATF and call it Amarok File Tracking (AFT)  :-)

It's not working for me / It works great and I want to give kudos

No problem. Send email to kde-dev @t emailgoeshere d.t com, and please put AFT somewhere in the subject line. You can also file a bug at bugs.kde.org. Thanks!