After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 341249 - Generate a playlist with a random set of tracks of fixed size based on criteria
Generate a playlist with a random set of tracks of fixed size based on criteria
Status: RESOLVED OBSOLETE
Product: rhythmbox
Classification: Other
Component: User Interface
HEAD
Other Linux
: Normal enhancement
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 377825 440506 566256 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-05-10 13:01 UTC by Alex Lancaster
Modified: 2018-05-24 11:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
this sort of works (47.71 KB, patch)
2008-05-14 07:44 UTC, Jonathan Matthew
needs-work Details | Review

Description Alex Lancaster 2006-05-10 13:01:56 UTC
I'd like to add to add a new autoplaylist type with the ability of generating a playlist of N Megabytes/ of random tracks based on a criteria.

Idea discussed on IRC, will attach log excerpts.
Comment 1 Alex Lancaster 2006-05-10 13:05:58 UTC
Initial discussion and doctau's suggestions:

(19:28:36) doctau: alexl: the best way would be to do it in RhythmDBQueryModel
(19:29:08) doctau: a) when a new entry is inserted into the query model, give it a random number between 0 and 1
(19:29:21) doctau: b) add a new sorting method, that sorts on those numbers
(19:29:26) doctau: c) add it to the query editor
(19:30:03) alexl: wouldn't that mean that everytime you created a new "random" query, you'd get the same order though?
(19:30:31) alexl: as a user I'd expect that a new query would "reseed" the random number generator
(19:32:43) doctau: the entry->number mapping would only be stored in the query model, and never saved
(19:33:06) doctau: so it would get new random number when you made a new playlist/restarted rb
(19:33:39) alexl: ok, so that sounds good
(19:34:18) alexl: so it would require adding a new query type like RHYTHMDB_QUERY_RANDOM to RhythmDBQueryModel (haven't looked at that class yet)
(19:34:20) alexl: ?
(19:34:51) alexl: that would do (a), (b) & (c) I think I already know how to do
(19:35:46) doctau: no, it wouldn't need a new query type
(19:36:09) doctau: sorting is done a level above queries
(19:36:48) doctau: rhythmdb-query-model.c has things like rhythmdb_query_model_date_sort_func()
(19:37:15) alexl: ok
(19:37:41) doctau: you would write a new one that sorts on the numbers assigned to the entries
(19:40:26) doctau: to store the numbers, I would do this: the first time rhythmdb_query_model_random_sort_func is called, create the entry->number hash table and fill it with the entries already in the query model
(19:41:20) doctau: in rhythmdb_query_model_do_insert, check if the hash table exists, and add a new entry->number if it does
(19:41:29) doctau: destroy the hash table in the finalise method
Comment 2 Alex Lancaster 2006-05-10 13:08:52 UTC
An issue that arose in initial implementation was needing to add a new RB_ENTRY_VIEW_COL_RANDOM for each entry in query model:

IRC log:

(20:58:20) alexl: I'm trying to add the random feature to sort_options in rb-query-creator-properties.c: { N_("Random"), "FirstSeen", N_("W_ith a no-op here") },
(20:58:31) alexl: but it says: "All entries MUST have column keys column keys listed in rb-entry-view.c"

[...]

(21:36:29) alexl: adding a new RB_ENTRY_VIEW_COL_RANDOM seems kind of messy, wouldn't we need a value for each entry, whether we were creating a random playlist or not?
(21:36:58) doctau: yeah :(
(21:37:32) alexl: then we have to create a RHYTHMDB_PROP_RANDOM, I thought the idea was to localise it inside the query model and create a new rhythmdb_query_model_random_sort_func ?
(21:37:33) doctau: I'm just looking at it now
(21:37:48) doctau: you won't need a new prop type
(21:38:08) doctau: we just need to make it so you can sort on things that aren't columns
Comment 3 James "Doc" Livingston 2006-07-11 11:18:26 UTC
Looking at it again, we don't actually have to do that.

rb_auto_playlist_source_set_query currently calls rb_entry_view_set_sorting_order. What would happen is that instead we check whether we are sorting randomly; if so we call rhythmdb_query_model_set_sort_order with our random sorting function, if not we call rb_entry_view_set_sorting_order like before.

Alternately the source could add a (invisible) custom entry view column for the random number.
Comment 4 Alex Lancaster 2006-11-21 21:20:27 UTC
*** Bug 377825 has been marked as a duplicate of this bug. ***
Comment 5 Alex Lancaster 2007-02-01 02:41:40 UTC
More suggestions from Doc here:

http://mail.gnome.org/archives/rhythmbox-devel/2007-January/msg00121.html

> If anyone in interesting in working on this, this is how I'd do it:

> 1) add a new instance variable to RhythmDBQueryModel, which is a
> GHashTable which maps from RhythmDBEntry to int.

> 2) add a new sorting function to rhythmdb-query-model.{c,h}
> "rhythmdb_query_model_random_sort_func". This function should look the
> two entries up in the hash table to find their int value, if they aren't
> in the table pick a random int and put that in the hash table. Make the
> compare function say the later entry is the one with the largest int
> value, and go by the LOCATION property if equal.

> 3) Fix the likely few bugs, and think about dealing with things like
> removing entries from the table when they get removed form the model.

> 4) Enjoy.
Comment 6 Jonathan Matthew 2007-05-22 22:27:57 UTC
*** Bug 440506 has been marked as a duplicate of this bug. ***
Comment 7 Dan Mihai Ile 2008-01-02 00:25:08 UTC
So what is the status of this?

It's because this feature is really useful when filling iPod with some X GB of songs from the library.
As a workaround for this I still keep Banshee installed for this. But would like to be able to do everything iPod related in Rhythmbox.
Comment 8 Jonathan Matthew 2008-05-14 07:44:24 UTC
Created attachment 110890 [details] [review]
this sort of works

I ignored all of the above commentary and instead added the concept of an ordering type to the query model.  Query models are manually ordered, sorted, or randomised.  The main difference is the behaviour of the entry insertion methods.  What I've implemented for random ordering is mostly guesswork at this stage.

A few UI things: the 'remove' action on a random playlist reshuffles (or, as I seem to have called it, 'percolates') the selected entries, and when the playing entry changes, the previous playing entry is also moved.  Entries can also be manually moved around in random playlists.

It's fairly easy to make it crash, and the additions to the playlist file are not backwards compatible (it'll crash if you attempt to edit random playlists with a version that doesn't understand them), but this should be good enough for people to try out, at least.
Comment 9 Alex Lancaster 2008-05-15 11:20:25 UTC
(In reply to comment #8)
> Created an attachment (id=110890) [edit]
> this sort of works

Great!  Thanks for this, I had meant to get around to implementing this myself at some stage but never got time.

> I ignored all of the above commentary and instead added the concept of an
> ordering type to the query model.  Query models are manually ordered, sorted,
> or randomised.  The main difference is the behaviour of the entry insertion
> methods.  What I've implemented for random ordering is mostly guesswork at this stage.

> A few UI things: the 'remove' action on a random playlist reshuffles (or, as I
> seem to have called it, 'percolates') the selected entries, and when the
> playing entry changes, the previous playing entry is also moved.  Entries can
> also be manually moved around in random playlists.
 
> It's fairly easy to make it crash, and the additions to the playlist file are
> not backwards compatible (it'll crash if you attempt to edit random playlists
> with a version that doesn't understand them), but this should be good enough
> for people to try out, at least.

It seems to work for me: it chooses random tracks using the criteria.  One thing I noticed is that it doesn't seem possible to sort via clicking the columns headers like other autoplaylists.

I did manage to make it crash via progressively removing tracks.  Otherwise it seems to work fine.

Comment 10 Jonathan Matthew 2008-05-16 01:23:41 UTC
(In reply to comment #9)
> It seems to work for me: it chooses random tracks using the criteria.  One
> thing I noticed is that it doesn't seem possible to sort via clicking the
> columns headers like other autoplaylists.

That's a good point.  I hadn't really thought about it, but it does make sense to be able to sort the random selection.  It might be a bit tricky to combine this with manual reordering and use of the 'shuffle playlist' action, but it does seem to be the right thing to do.
Comment 11 Jonathan Matthew 2009-01-02 04:19:12 UTC
*** Bug 566256 has been marked as a duplicate of this bug. ***
Comment 12 GNOME Infrastructure Team 2018-05-24 11:34:18 UTC
-- 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/184.