The issue, as far as I can discern, is that the function that describes the rating would change every time the date/time changes, which is a continuous process.

The reason that date/time stuff is so resisted is simply because it is hard to do right. It would require a massive overhaul of the underlying APIs, and the cost isn't worth the gain.

Extending title formatting is not a bad idea, but one of the underlying assumptions made in places is that the contents of these variables is constant until the file being referred to is modified. If that's true, perhaps your idea could be implemented as some kind of tagging extension. Click on an entry in the main menu, and the rater iterates through the entire media library, changing the tags to be most up-to-date based on your rating scheme.

But clearly fb2k has no problem reading from a DB and everytime you play a track the playcount changes and fb2k can deal with such changes.

What I'm suggesting is pretty much the same, except that the component would offer up a %calculation% for fb2k to read, and the frequency of updates from the database is something that could be negotiated to avoid the core problem. [...] Wouldn't this bypass the re-paint problems that Peter was talking about?

An alternative way around this is to include a form of system time which = %system day%. Date-based autoratings schemes like "hotness" and foo_DAR only need system day. Would that solve the constant update problem?

Partialy, but it's a bad design anyway. Because you couldn't link %system day% to a particular track(s), the refresh command would need to be send about all 10000+ tracks each midnight, even for people who don't care at all.

Might a solution be a %startup time/day%? It would be constant through the foobar instance solving the non-repeatability problem, but you would have to restart foobar to update the field. A cross of this and the "recalculate" idea could become a full solution.

Such a solution would work - it could be either a manual "Recalculate" command, it could happen automatically "when computer is idle" in the background, ...

a) record "Total Played Time per Track", or
b) allow an option whereby Playback Statistics offers an additional (alternative) playcount based on:
Total Played Time per Track / Track Length

Currently, if I play the first 1 min of a 10 min song 10 times, foo_playcount says I've played it 10 times, whereas "total played time" / "track length" would say I've played it once. Though this is not entirely accurate, it's far, far closer to the truth.

Benefits:
a) Eliminates the need for skip counts.
b) It would not affect those users who always play their files all the way through, but it would beneficially affect those users who skip from track to track and still require an accurate reading of how often they've listened to each track.
c) Eliminates the need for any "count if played when played x %" or "count if played when played > 2 mins" kind of options.

The most accurate play-count is: "totalseconds played" / "track length in seconds".

Quote from: carpman on 2008-05-25 21:09:54

The most accurate play-count is: "totalseconds played" / "track length in seconds".

I suggest "totalseconds played" (e.g. some Playback statistics database field) would update on song change. When you seek, it'll save seconds played so far and position after seek. When you seek again or song changes, you would do "current position"-"saved position" and add this to seconds played so far and update field in database. It shouldn't be hard to implement (I'm not C++ developer so I leave this to devs or somebody else).