GNOME Bugzilla – Bug 153286
'in/not in playlist x' playlist criteria
Last modified: 2018-05-24 10:37:02 UTC
I'd like to be able to see which of my songs aren't in any playlists (including automatic playlists). Have a "not in any playlists" query in the automatic playlists would fix this. (Couldn't figure out rhythmdb, so I'm filing)
Hm, couldn't implement it just in rhythmdb because rhythmdb isn't aware of what songs are in playlists. What you want is a bit tricky because it cuts across a lot of the internal objects and layers :) I'll try to think about how to implement it.
The reason this is tricky is because we want to preserve the "automatic" part of automatic playlists, and there's a lot of ways in which "not in any playlists" could change. For example when you delete a playlist, or add a new one. Also there are ordering issues - let's say you have two automatic playlists, one which is "not in any playlist" and another which just picks up all songs. If you just iterate through the playlists trying to do changes, then the first playlist won't update when the second automatic playlist picks up the song. Also it's weird because you need to exclude "not in any playlist" from the updates - because obviously the "not in any playlist" playlist includes those songs! :)
Maybe it should rather be "not in any non-automatic playlist" rather than "not in *any* playlist"
*** Bug 374332 has been marked as a duplicate of this bug. ***
Created attachment 85247 [details] [review] proof-of-concept This is a proof-on-concept on how to support "is/isn't in playlist X" criteria, it works by adding a keyword to each entry in a playlist "!rb:playlist:present:ID", where ID is an identifier for the playlist. The prefixed exclamation mark indicates to the backend that these keywords don't need to be saved on disk. Something like the following can be added to ~/.gnome2/rhythmbox/playlists.xml to test (it will match tracks in the "third" playlist created) <playlist name="woo!" type="automatic" sort-key="Artist" sort-direction="0"> <conjunction> <equals prop="type">song</equals> <subquery> <conjunction> <like prop="keyword">!rb:playlist:present:2</like> </conjunction> </subquery> </conjunction> </playlist> There is a fair bit of work yet to do: * give playlists a persistent identifer, so we can use that instead of the number I checked in there currently * improve the auto playlist editor so that it lists in/not in playlist X * if the playlist in the criteria is another auto playlist, we could probably just get the query and insert it into our own * when doing the above, keep a list of playlists we've used and detect loops
*** Bug 522573 has been marked as a duplicate of this bug. ***
Created attachment 131781 [details] [review] An Alternative proof-of-concept Whoops. I didn't see this patch on this bug, and I accidentally wrote the same proof-of-concept, but did it slightly differently. I'm posting it here in case it's interesting to some people later, but I'm going to continue working, using the other patch.
Created attachment 131783 [details] [review] Jonathan Matthew's patch, updated to apply to r6255 The proof-of-concept patch needed some slight work to be able to apply. One thing I noticed was that row-deleted has become row_deleted. I tried to figure out what was the proper convention to use. Unfortunately, both seem to be in use. In fact, I mean that both row-deleted and row_deleted appear in the source code. Hopefully in different contexts! But it seems like it would be a good idea to standardize on one. Meanwhile, I'll try to update the auto-playlist queries to make use of these keywords.
In gobject signal names, '-' and '_' are equivalent. I don't really like the idea of using keywords for this because it's duplicating information that we already have, so the feature is going to cost you memory whether you use it or not. I'm thinking about a more complicated scheme where query models would be registered (by name) with rhythmdb, which would allow them to be used in criteria in other query models.
The current patch could work as something to support investigation of the UI aspects of this and how to go about storing playlists using 'in/not in playlist x' criteria. I don't think we can just use the keyword as it is, as the playlist IDs assigned won't be stable. If a playlist is renamed such that the order changes, or if a new playlist is created somewhere in the playlist order, the IDs will change on next startup.
Are you thinking of a UI like is currently employed for the "Title" field, where you pick "contains", "does not contain", "equals", etc.. then enter text. (i.e. a text-PlaylistName-matching scheme) Or, a UI with a drop-down list of playlists. If parentheses are drop-down lists, it would be more like: (Playlist) (is in/isn't in) (other playlists) Which, would facilitate a (behind-the-scenes) PlaylistID matching scheme. Or, am I way off base?
I'm thinking of the second option. It'd be pretty silly to make the user type out the name of their own playlist. We'd also want "is in/isn't in any playlist" options, for which there wouldn't be a drop down menu, but these would probably be harder to implement.
Created attachment 132580 [details] [review] Proposed Patch r6291 Incorporates Jonathan Matthews proposed patch, and adds Playlist option to the rb-query-creator-properties.c. Proposed interface style. Still needs to fetch the list of playlists for the option menu, and create the query.
I should point out that this wasn't originally my patch. See comment 5.
So you are proposing to register queries into the database as RHYTHMDB_ENTRY_CONTAINER types, then?
I hadn't really thought about the exact mechanism used to register query models with rhythmdb itself, but I don't think creating database entries for them would help much. We don't need the set of registered query models to be persistant, as the playlist manager would take care of that, we don't need to use the rhythmdb query functions to find them, and I can't see it being helpful to treat a query model the same as a normal db entry anywhere. I think all we'd need would be a name:query-model map in rhythmdb, with a few get/set functions. Then, we'd add new RhythmDBQueryType values, RHYTHMDB_QUERY_ENTRY_IN_QUERY and RHYTHMDB_QUERY_ENTRY_NOT_IN_QUERY.. and some other stuff I haven't thought through.
*** Bug 496303 has been marked as a duplicate of this bug. ***
*** Bug 583946 has been marked as a duplicate of this bug. ***
*** Bug 655376 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/46.