Yet another short update on the development of my still untitled media player for the Zaurus. In the meantime it’s called YAZMP.

Again, I’ve been working on improving performance – this time on the performance when loading playlists.
Before I continue, let me give a brief overview of the structure:

Library -> Playlists < -> Media Cache

YAZMP doesn’t manage a library similar to i*Tunes. Instead it solely relies on playlists. Metadata (title, artist, album, etc.) is kept in the database and will be associated to once the playlist is loaded. The reason for this is pretty simple: Scanning audio files (and media files in general) each and every time a playlist is loaded will definitely take a lot of time. So, for every file the gathered metadata will be saved in the DB. Think of it as a cache.

ZPlayer, which YAZMP is based on, follows a similar approach. However, in my opinion it’s ill-conceived in the current version. It keeps the media cache in memory all the time. With lots of files this can get very expensive. Also, ZPlayer isn’t very efficient at saving the media cache to disk. It does so for the whole cache, not just changed entries. Furthermore, when saving the cache on quitting, ZPlayer sometimes simply truncates the cache file and all metadata is lost. So, next time you open it, it has to scan all files again…
Perhaps I’m nitpicking, perhaps I’m an optimization dork, whatever it is, please forgive my harsh words for the otherwise excellent work atty and Atmark have done in ZPlayer!

Technical ramblings

For YAZMP I rewrote the metadata cache management from scratch and extended it to do a lot more.
As I already mentioned above, YAZMP doesn’t manage any library, it only knows about filenames in playlist files.
For that to work correctly and efficient especially in combination with the media cache, there are four cases that need to be taken care of:

1. A new file has been added to the playlist which doesn’t exist in the media cache.
   This case is very simple: The player has to scan the file no matter what.
2. A file has been physically removed and it’s metadata is still in the cache.
   In this case the player has junk entries in its database, which need to be cleaned once in a while.
3. A file has been renamed, that is, it’s basename changed
4. A file or a whole directory / sub-tree of files have moved to another location.
   In a naive implementation both cases would trigger a lengthy rescan of the file(s) that are about to be added in the playlist, because new location can’t be associated with any data in the cache.
   For YAZMP I’ll use several approaches + fallbacks to try to limit the impact. The following messy pseudo-code illustrates this:

     get attributes filename, directory  from current playlist item to be added
     get attributes filesize, lastmoddate for file (directory + filename)
   
     // NOTE: check via checksum / hash for faster lookup
     if exactly one entry by hash value of (directory + filename) in DB then
       // NOTE: did the file change since the last scan?
       if entry.filesize not equal filesize or entry.lastmoddate not equal lastmoddate in FS then
         rescan file (directory + filename) and update entry in DB
       return entry
     else if exactly one entry by tuple of (filename, filesize, lastmoddate) in DB then
       // Was the file moved to a new directory? (case 4)
       // If so, check for other files in the old directory and change them
       // to the new location...
       // NOTE: this is purely predictive. It might not always yield a benefit.
       if directory by value of entry.location not in FS then
         change every siblingentry in DB where siblingentry.location is entry.location
           set siblingentry.location to directory
           set siblingentry.locationHash to hash value of (directory + siblingentry.filename)
         until no siblingentry is left
       // NOTE: did the file change since the last scan?
       if entry.filesize not equal filesize or entry.lastmoddate not equal lastmoddate in FS then
         rescan file (directory + filename) and update entry in DB
       return entry
     // NOTE: For case 3 one could check for a smaller tuple of (filesize, lastmoddate)
     // which would result in the almost the same code as above
     // The likeness of wrong results is a lot higher though.
     else
       scan file (directory + filename) as newentry and add newentry to DB
       return newentry
   

Conclusion

What that means is pretty simple: You can move your media files to a different location, perhaps a SD-Card, and the player will still be able to associate the new location in the playlist file with the data it has in cache. And that means: No useless scanning of files and fast playlist load times.

Yet another feature…

I tend to copy several albums to my Zaurus for listening on the road. So, once I’ve copied new stuff, it’s always the same mindless and inconvenient procedure in most players: Clear the playlist, add files or directories, play stuff.
And that brings me straight to another new feature: Dynamic Playlists
In general the idea is pretty simple: Instead of just listing every file’s location in a playlist file, one may also list folders that are automatically scanned for audio or video files. Here is an example:

Music.dynplaylist

/hdd3/Music/test1.mp3
/mnt/card/Music/Mozart/
/hdd3/Music/Beethoven/**

This will add a single file “test1.mp3”, all files in “/mnt/card/Music/Mozart/” and all files in “/hdd3/Music/Beethoven/” including all files in its sub-directories.

Conclusion

Instead of adding files, you just define what the layout of the playlist should look like and the player does the rest automatically. It can even rescan for changes. It’s all wrapped up in a nice UI.
Combined with the flexibility of the metadata cache and the fact that one isn’t forced into this library thing, I think this makes for a pretty unique solution. What do you think?