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 339975 - Play count based on statistics not raw number
Play count based on statistics not raw number
Status: RESOLVED OBSOLETE
Product: rhythmbox
Classification: Other
Component: general
0.9.x
Other other
: Normal enhancement
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-04-27 23:16 UTC by Trever Adams
Modified: 2018-05-24 11:33 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
make limits saner (29.09 KB, patch)
2006-05-05 12:59 UTC, James "Doc" Livingston
committed Details | Review

Description Trever Adams 2006-04-27 23:16:20 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 -------

Comment 1 Trever Adams 2006-04-27 23:23:34 UTC
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.
Comment 2 Sergej Kotliar 2006-04-29 14:52:55 UTC
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...
Comment 3 Jonathan Matthew 2006-04-29 22:10:39 UTC
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.
Comment 4 Trever Adams 2006-04-30 22:49:32 UTC
This is not fine grained enough. Also, it no longer seems to work on my system.
Comment 5 James "Doc" Livingston 2006-05-03 02:23:11 UTC
(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.

Comment 6 Trever Adams 2006-05-03 17:18:41 UTC
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.
Comment 7 James "Doc" Livingston 2006-05-05 12:59:21 UTC
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.
Comment 8 Jonathan Matthew 2006-05-07 21:21:21 UTC
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.
Comment 9 James "Doc" Livingston 2006-05-08 13:08:28 UTC
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
Comment 10 Trever Adams 2006-09-20 10:36:48 UTC
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.
Comment 11 GNOME Infrastructure Team 2018-05-24 11:33:52 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/183.