Except that every new way to do playlists makes the code more complex. Part of the attraction of moving to a sql backend and sql-based playlists is that somewhere around 40% of the code just disappeared. That’s attractive.
Simple is more bug free. So I like that aspect of it.
The other thing is that I want to move all this stuff into the database. So I think it will end up being something of a compromise — something like the old .playlist file, but the spec stored in the database, rather than in a file, that way it can get re-parsed every time it gets requested, and things like “most recently played” get updated in realtime, rather than whenever mt-daapd starts.
By putting it in the database, it eliminates a whole series of misfeatures that plagued the .playlist implementation.
There will always be a way to do smart playlists, as that’s all I use. So I need to have it for me, if nothing else.
Anyway, I guess that’s how I see it going.