GNOME Bugzilla – Bug 339975
Play count based on statistics not raw number
Last modified: 2018-05-24 11:33:52 UTC
Distribution: Fedora Core release 5 (Bordeaux) Package: rhythmbox Severity: enhancement Version: GNOME2.14.1 0.9.x Gnome-Distributor: Red Hat, Inc Synopsis: Play count based on statistics not raw number Bugzilla-Product: rhythmbox Bugzilla-Component: Programmatic interfaces Bugzilla-Version: 0.9.x Description: Description of Problem: I would like to set up a filter that I call popular on my system. The reason for this is I don't always like some of my music, so it gets played a lot less. So for normal play back I would like to be able to do it based on statistics. These play count statistics would be percentage above and below average. Sigma (standard deviation) above and below average play count ranging from .10 sigma to 6 sigma in increments of .10. I am not sure this would be too difficult to add for someone who understand RB's internals. This statistics should be based ONLY on those in the source selected. ------- Bug created by bug-buddy at 2006-04-27 23:16 -------
It might be nice to hace the edit dialog to setup such a statistical filter actually show what the selected sigma or percent would be (in songs count and play count) at the time of the edit dialog opening.
I think rhythmbox already does this... At least it used to before, don't know if that changed... The star rating system gets set by the frequency a song is played, combined with other factors (if you CHOSE to play it, if you skipped away from it), and can of course be set manually. This rating system then weighs the songs playing... Devs: correct me if I'm wrong on this...
Auto rating was removed some time ago, mostly because it's not really possible to determine the user's intent when they perform actions such as skipping a song. I don't think it would help solve this problem anyway.
This is not fine grained enough. Also, it no longer seems to work on my system.
(In reply to comment #0) > These play count statistics would be percentage above and below average. > Sigma (standard deviation) above and below average play count ranging > from .10 sigma to 6 sigma in increments of .10. One similar suggestion that has been made is adding a "percentage limit", so you could have a "top 5%" playlist instead of just "top 50". Both the above and the original suggestion shouldn't be too hard to do. The biggest issue is that adding new limit types current sucks. I don't think RhythmDBQueryModel's ability to have multiple limit types actually gets used anywhere, so we could probably replace it with a limit type-value pair. If something did need multiple limits, they could use chained query models anyway, and that is more flexible.
I was thinking as I slept last night, I think it would be a good idea if it wasn't just above and below average. It should be relative (percentage and sigma/partial sigma) to highest count, lowest, and average. This should just be a few more lines of code.
Created attachment 64855 [details] [review] make limits saner This patch changes the way limits are set on query models, and by extension auto playlists. It will make it much easier to add new limit types, although it doesn't yet support dynamically adding them with plugins. Using this removes the ability to have multiple limits of different types, but nothing used that. The reason I've used a GValueArray is that limit may want to use non-numeric data. The usual method of passing gpointers for user data wouldn't work since the data needs to be copied around, which makes data-destroy semantics an issue.
Looks like a good idea to me. Perhaps the file size limit should be treated as a uint64 everywhere, rather than just in rhythmdb_query_model_within_limit.
Committed to cvs with the size-limit type change. I'm not sure how many people have collections over 4Pb (2^32 Mb), but why not? It would probably be better and more consistant to store the filesize in bytes, except that existing playlist.xml files have it in Mb. If someone wanted to work on adding a new limit type (such as suggested in this bug), here is what needs doing: 1) add a new enum constant in rhythmdb/rhythmdb.h 2) add a limit-check case in rhythmdb_query_model_within_limit() in rhythmdb/rhythmdb.h 3) add limit serialisation/deserialisation to sources/rb-auto-playlist-source.c 4) add it to the auto playlist editor in widgets/rb-query-creator.c
This still doesn't seem to be possible (my bug) to do in 0.9.4. I have come to the shocking realization that automatic rating is no longer done. Therefore, without this functionality, it seems things are pretty broken.
-- 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/183.