Hi, that's funny. I've investigated the same thing, though without getting so far as to submit a patch. Especially I was interested in lowering the probability of very recent songs being replayed.
In the course I noted, that the "history" of a song isn't updated before the next song is played, but after the next but one (in the SVN-checkout of rhythmbox 0.11.6). Let's give me an example: song A is played and was never played before (rhythmdb_entry_get_ulong (entry, RHYTHMDB_PROP_LAST_PLAYED) returns 0). When the function "rb_random_by_age_and_rating_get_entry_weight" is called in the process to select the next song, the query "rhythmdb_entry_get_ulong (entry, RHYTHMDB_PROP_LAST_PLAYED)" for song A returns 0 again! Only after the next song you get the correct result. A reason might be, that the next (random) song is choosen before the database is updated, but I never checked for this. This behaviour makes it rather pointless to try to avoid a song being played twice in a row in random play. I always wanted to improve on that but couldn't find the time to learn the principles of bookkeeping in rhythmbox. Maybe someone could give a hint? Anyway: I think the patch of Alan is a great idea. I would like to have something like this in rhythmbox. @ Alan: I have a little setup here for testing the "randomness" of songs being played which gives nice little graphs as output (sweet ;) ). If you like I could run it with your patch applied. Please give me a note if this is of any help. Cheers, Alex Dr. David Alan Gilbert schrieb: > Hi, > I've just posted an improved version of my random patch onto > bug 163196: > > http://bugzilla.gnome.org/attachment.cgi?id=122538 > > Unlike the previous version I believe the maths actually now > work well to summarise: > > > 1) It adds a random pane on the preferences dialog > 2) This allows you to select the behaviour when just 'shuffle' is > selected - either random or shuffle (for those who don't like the > odd UI trick of selection based on shuffle+repeat) > 3) It combines the random-by-age, by-rating, by-age-and-rating all > into one chunk of code and selects the behaviour by a series of > sliders - age bias and rating bias. > 4) A further bias is used for 'very recent' plays - and you can > define that; so for example you can set it up for plays within the > last 2 days are heavily penalised. > > The only thing I think could improve is how to set the initial > values of the sliders - I believe I have them in the schema - can > anyone suggest how to improve that? > > I find with the age-bias set to about 25% of the way it works well; > if it's on max then you'll get little other than your very oldest > tracks (or ones never played) - I've tried this out and it seems > to work. > > The patch is against the SVN version of 0.11.6 in Ubuntu Intrepid; > but should go on pretty easily. > > Any chance of this making it to a release? > > All comments welcome. > > Dave _______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
