Amarok Blog

One of the features that saw quite a bit of pimping in the 1.4 series is the new Collection Scanner. For the new scanner we had the following goals:

• 
  Support for more media formats. This has been achieved by bundling custom TagLib plugins with amaroK. New supported formats include AAC (MP4) and WMA.
  


• 
  Crash proof. This is a really important aspect, which originally led to the redesign of the scanner code. With the old scanner design, a crash in TagLib would automatically mean that amaroK crashed completely. This could be very frustrating for the user, since effectly amaroK could crash right on first startup, and the user would be unable to ever locate or fix the issue by himself.
  
  TagLib is fairly stable, but with ever growing media collections, the probability of hitting a "bad" file rises proportionally. This is especially true for our new custom TagLib plugins, which are not yet well tested.
  


• 
  No compromises with performance. amaroK's scanner has always been exceptionally fast (a lot of credit has to go to TagLib here, the fastest tagging library available), and this performance should not be hampered.
  

Now, we've reached all of these goals "Everything should be made as simple as possible, but not simpler". Well, this problem required quite a bit of complexity, but I think it was worth it. The new scanner has been implemented in two parts: The core of the scanner, "CollectionScanner", has been splitted off into a separate application. This application takes a list of folders, reads the tags of all files (using TagLib), and sends this information in an XML format to the amaroK process. Part two of the scanner, the "ScanController", is a separate thread in amaroK which receives, parses (SAX2 parser) and stores (in the database) this information from the CollectionScanner. The controller also invokes and monitors the CollectionScanner application.

With this design, we can do some very nice tricks behind the scenes. What happens when the CollectionScanner process crashes? The Controller immediately notices the crash, remembers the "bad" file that caused the crash, and silently restarts the scanner process just where it left off before the crash. Except that this time around we skip the "bad" file. All this is completely transparent to the user - you'll never see that the scanner process has had any problems, amaroK just continues scanning!

When the scan has finished, amaroK shows a "Scan Report" dialog, informing the user which files had to be skipped. And all is well - No crash, no cry.