GNOME Bugzilla – Bug 729311
Use Tracker to save Playlists
Last modified: 2014-06-05 09:12:46 UTC
Using Tracker to save Playlists instead of into files has several advantages: 1. We could take advantage of tracker:id of an nmm:Playlist to easily distinguish each playlist from each other. Currently, the only way to do this is to use the filename of the playlist. Useful for bug 729309. 2. We could take advantage of tracker:id of each nfo:MediaFileListEntry to easily distinguish each entry. Currently, we could only use the uri, but that doesn't work when a playlist has multiple entries of a single file. See bug 728254. 3. We currently use the filename as playlist title. Therefore filename and filesystem restrictions apply on playlist titles. If we use Tracker, we could use any title we want, which fixes bug 728330. 4. We could finally show playlists found by Tracker in any folder it looks up into, see bug 728255. 5. We have to rewrite everything when a playlist changes, which is ugly (and we put dummy entries when the playlist is empty - really ugly fix). If we use tracker, we just add/remove nfo:MediaFileListEntry objects, then adjust their nfo:listPosition predicates. 6. We could remove the playlists reading code in playlists.py. That also means we no longer have to depend on totem-pl-parser (this approach will still work even if totem-pl-parser is not around or if Tracker-extraction of playlists is disabled). 7. Ordering of entries is more predictable. Currently, we just load the items using separate queries then let them race on which one gets fetched up by grilo first. There's a nfo:listPosition predicate in Tracker, and grilo will fetch them one by one in order if they are in a single query. 8. We could easily detect if a playlist changes then automatically reload it if it does. According to Tracker documentation for nmm:Playlist, "This class notifies about changes". 9. Makes searching easier, we could create a query for looking up matches. Currently, we could only load each playlist then load each one with grilo, then check if each one matches. 10. All of gnome-music's data will now be in the Tracker store.
Sample command to look up Playlist entries in Tracker: tracker-sparql -q "SELECT tracker:id(?playlist) AS id nie:title(?playlist) tracker:id(?entry) nfo:listPosition(?entry) nfo:entryUrl(?entry) WHERE { ?playlist a nfo:MediaList ; nfo:hasMediaFileListEntry ?entry }" Sample output: Results: 102539, Bakemonogatari, 102540, 1.0, file:///home/kyoushuu/Music/AnimeOST/Bakemonogatari/Hanazawa%20Kana%20-%20Ren'ai%20Circulation.flac 102539, Bakemonogatari, 102541, 2.0, file:///home/kyoushuu/Music/AnimeOST/Bakemonogatari/Saitou%20Chiwa%20-%20staple%20stable.flac 102539, Bakemonogatari, 102542, 3.0, file:///home/kyoushuu/Music/AnimeOST/Bakemonogatari/Satoru%20Kosaki%20-%20Futakotome.mp3 102539, Bakemonogatari, 102543, 4.0, file:///home/kyoushuu/Music/AnimeOST/Bakemonogatari/supercell%20-%20Kimi%20no%20Shiranai%20Monogatari.mp3 102539, Bakemonogatari, 102544, 5.0, file:///home/kyoushuu/Music/AnimeOST/Bakemonogatari/01%20marshmallow%20justice.flac 102539, Bakemonogatari, 102545, 6.0, file:///home/kyoushuu/Music/AnimeOST/Bakemonogatari/01%20Hakkin%20Disco.flac 102539, Bakemonogatari, 102546, 7.0, file:///home/kyoushuu/Music/AnimeOST/Bakemonogatari/01%20Naisho%20no%20Hanashi.flac But first you should have a playlist extracted by Tracker. If you don't, you could grab one from your Music's playlists: tracker-control -f ~/.local/share/gnome-music/playlists/Bakemonogatari.pls
I started working on this in https://github.com/gnome-prototypes-team/gnome-music/tree/tracker-playlists
Excellent job, Arnel, merged into master since https://git.gnome.org/browse/gnome-music/commit/?id=4462d98cb6ff09a1f039dba287cc9e764645a79a, will be a part of 3.13.3 release