Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_DAR: auto rating (Read 125419 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foo_DAR: auto rating

Reply #125
Still, there is no single person in the huge amount of people desperately waiting for such features who cares enough to create such a component, what a shame!
Absolutely; that's really the crux of the issue.

I wish you a restful hiatus.
Thank you.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

foo_DAR: auto rating

Reply #126
+1. I would love if DAR worked with 0.9.5.2+
\"I never said I would stay to the end...\"

foo_DAR: auto rating

Reply #127
+1. I would love if foo_dar worked with 0.9.5.2+

(knowing admins don't like those kind of post..but what else can I do?)

foo_DAR: auto rating

Reply #128
This is a duplicate of a post to Kitahei's / Thuan's "Some Playcounter mods, For foobar 0.9" thread, in case Kitahei chooses to respond, but does not want to take that thread off-topic.

*******

Hi kitahei

I've been using your excellent component and it's great you've updated it for the latest version of fb2k.

I'll make this as brief as possible, but it may be better to continue any discussion here (I've posted a duplicate of this post on my foo_DAR thread) as I don't want to hijack this thread.

A while back I wrote foo_DAR ratings formula which relied on your Playback Statistics Custom component as well as cwb_hooks. As you probably know cwb_hooks was banned and one of the reasons for this was that its system time function caused "repaint glitches".

As Frank stated in a recent thread re. Custom Database - foo_customdb.dll's implimentation of %now%

Quote
The current time is an information that cannot be reliably provided through title formatting.
It is not properly refreshed and may cause display glitches, for example when scrolling

It is very disappointing that, even though compatibility has been broken and the documentation has
been updated to make these things very clear, developers keep repeating the same mistakes.


The reply from tedgo was:
   
Quote
@Frank Bicking
That's true and i'm not really glad about the %now% "solution", but unfortunately there is no other way to catch the system date (which would be easy possible with a field that only updates on startup)


This is correct and I suggested such a solution back in February:

Quote
i.e. foobar would have its own "foobar instance date" as a reference which would remain static for that instance of foobar (regardless of time passing) and would thus be able to calculate these fields in conjunction with data provided by the playback statistics database.


What I would like to know is would it be possible to impliment the following fields which would solve many problems:

1) Create a static NOW field that is based on a when foobar2k was started, but which doesn't change while that instance of foobar2k is open (i.e. a static snapshot of the time/date foobar was started). This would prevent problems with repaint glitches.

2) Impliment the following fields based on this static NOW:

%Days Since Added%
%Days Since First Played%
%Days Since Last Played%

These would be static fields yeilding integer values.

This would enable auto ratings formulas such as topdownjimmy's hotness auto-rating formula and my foo_DAR auto-rating formula to function in the latest versions of fb2k without annoying the developers by creating the kinds of glitches associated with the ever-changing "dynamic variables" such as system date time.

Thank you very much for your consideration and as I say probably best to reply to this in the foo_DAR thread. 

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

foo_DAR: auto rating

Reply #129
Yes, it would be great to have fields like %foobar_instance_date% (or %foobar_startup_time%), %days_since_added% etc.

For the moment i use the semi-optimal solution %played_per_day% (from which i re-calculate the days between first played and last played) from the official playback statistics plugin in my own auto-rating system.
But i know, this auto-rating says nearly nothing because it only takes into account how often it was played until "last played", not until "today". A track that has been played 10 times in the first week i added it to the library would still have a good auto-rating after one year not played anymore...

I still hope that the official playback statistics plugin will get an improvement and offers these fields one day.
But if a 3rd party plugin will offer it, i would switch to it only for that purpose immediately

foo_DAR: auto rating

Reply #130
I agree. The most welcome solution would be for such fields to be provided by the official stats component, but I think it's more likely that a 3rd party developer will provide the solution. Hopefully Kitahei can come up with the goods. We'll see.

I've made a number of improvements to foo_DAR and have been conducting a long-term test with my full library and the results are very good. But I don't really want to provide the code because doing so encourages the use of the component that cannot be named and older versions of fb2k.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

 

foo_DAR: auto rating

Reply #131
It's been a while since I've studied the background for these algorithms, but AFAIR it involved the record of a track being skipped without full play, right? If that's the case (and a component is to be written anyway), wouldn't it be more appropriate to also record how much a track eventually have been played (maybe an average over time?).
Can't wait for a HD-AAC encoder :P

foo_DAR: auto rating

Reply #132
It's been a while since I've studied the background for these algorithms, but AFAIR it involved the record of a track being skipped without full play, right? If that's the case (and a component is to be written anyway) ...

a) The latest version doesn't bother with %skip% any more (after testing it became clear that penalising a track for being skipped was not a good solution)

b) A seperate component does not need to be written - foo_DAR (and hotness) are more like parasites that rely on a good host.

wouldn't it be more appropriate to also record how much a track eventually have been played (maybe an average over time?).

c) That's precisely what foo_DAR does (as well as other things).

Very simply foo_DAR attempts to (and IMO succeeds at) solving a number of problems:

1) THE PLAY PER PERIOD PROBLEM
"Total Playcount" / "No. Days in Library" will give unfair advantage to new tracks.

2) THE TOTAL PLAYCOUNT PROBLEM
Total playcount will give unfair advantage to old tracks.

3) THE TRACK DURATION & PLAYCOUNT PROBLEM
Song A = 30 mins, Song B = 3 mins, the opportunity cost of listening to Song A is listening to Song B 10 times. If playcount is at the root of the rating (and it has to be), somehow duration has to be factored in, because we are physically limited by time (lifetime/listening time). No matter how much one likes Song A you simply cannot fit as many plays of that track into a lifetime as you can with Song B. So all other things being equal, Song B has an advantage (due to its duration) and this has to be adjusted for.

There are other factors, but they are the principle ones that foo_DAR is based on solving.
So foo_DAR attempts to equalise all these issues so that regardless of the above, all tracks are rated on a level playing field.

I hope that answers your question.

C.

ps. foo_DAR should really be called foo_DDAR (Date and Duration Adjusted Rating)

[EDIT: Typos]
PC = TAK + LossyWAV  ::  Portable = Opus (130)

foo_DAR: auto rating

Reply #133
I'd love to use this component; I didn't know about its existence 'til some days ago, but now I'd really appreciate the opportunity to give it a try!

Let's wait for kitahei's answer, then

foo_DAR: auto rating

Reply #134
ps. foo_DAR should really be called foo_DDAR (Date and Duration Adjusted Rating)
Maybe this formula/methodology shouldn't really be called foo_anything to avoid confusion with real components.
Full-quoting makes you scroll past the same junk over and over.

foo_DAR: auto rating

Reply #135
Yirkha, I agree.

Feel free to rename the post title to Date and Duration Adjusted Auto Rating Forumula.

As you know, nothing's happening to DDAR until certain fields are allowed (whether by official or 3rd party components).
If and when this happens, I'll request this post be closed and start a new thread - this time making sure foo_ is missing.

I was pretty new to foobar2000 when i wrote it and actually thought that any add-ons / submission were called foo_something - my mistake.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

foo_DAR: auto rating

Reply #136
I was pretty new to foobar2000 when i wrote it and actually thought that any add-ons / submission were called foo_something - my mistake.


Actually I also thought this was the way components should be called  For example, all my components seem to begin with foo_something - could someone explain me which criterion is used to distinguish among components? (it's just a curiosity - no hurry  )

foo_DAR: auto rating

Reply #137
carpman: Thanks for consideration. I think I'll leave it as it is for now though, people know it by that name and you'll do it yourself for that next/latest-fb2k-compatible version.

Dallaz: Components are usually named foo_something, because foobar2000 searches them under names foo_*.dll in the "components" folder. But foo_DAR is only a set of formulas to calculate and display smart, automatically computed rating of the tracks. You don't have to install it, it's no file, you just set some values in the configuration.
Full-quoting makes you scroll past the same junk over and over.

foo_DAR: auto rating

Reply #138
Dallaz: Components are usually named foo_something, because foobar2000 searches them under names foo_*.dll in the "components" folder. But foo_DAR is only a set of formulas to calculate and display smart, automatically computed rating of the tracks. You don't have to install it, it's no file, you just set some values in the configuration.


Ok, thank you for your exaustive explanation. Having never used it, I didn't know it wasn't a real component 

foo_DAR: auto rating

Reply #139
carpman san

I'm sorry for the reply's slowing.

I have a question.
Is it that foo_DAR runs when the field below is implemented?

%Days Since Added%
%Days Since First Played%
%Days Since Last Played%

I am interested in foo_DAR, too and I want to cooperate as much as possible.

Thanks.

foo_DAR: auto rating

Reply #140
Hi Kitahei

I'm really glad you're interested! 

The simple answer to your question is YES. Those fields would make the foo_DAR formula work in the current fb2k.
Are these fields possible to impliment without bumping into the "dynamic system time problem" I mentioned?

Quote
Create a static NOW field that is based on a when foobar2k was started, but which doesn't change while that instance of foobar2k is open (i.e. a static snapshot of the time/date foobar was started). This would prevent problems with repaint glitches.

What would be ideal, is to have some way for the component to calculate the result of the auto-rating formula and provide that result as its own titleformatting field i.e. %auto_rating%. This way the user could use it in Facets (and auto playlists such as %auto_rating% IS GREATER 10000, and have an auto playlist sorted by %auto-rating%).

It seems to me, that the whole auto-rating component thing can be as simple or as ambitious and complex as one desires. If you'd like to discuss how a full auto-rating "hosting" component could work I'd be glad to by PM.

Cheers Kitahei

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

foo_DAR: auto rating

Reply #141
If you'd like to discuss how a full auto-rating "hosting" component could work I'd be glad to by PM.


That's great reading this kind of news, but let us know something if you start working in pair

Do not let us unaware of what's going on "behind the scenes"

foo_DAR: auto rating

Reply #142
@ Dallaz
Well to be honest, my thoughts on this aren't exactly top secret, if you're interested in a rough outline have a look at these 2 posts:

http://www.hydrogenaudio.org/forums/index....st&p=567166
http://www.hydrogenaudio.org/forums/index....st&p=566241

ps. the formula post is a little out of date (there's been a number of refinements).

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

foo_DAR: auto rating

Reply #143
@ Dallaz
Well to be honest, my thoughts on this aren't exactly top secret, if you're interested in a rough outline have a look at these 2 posts:

[CUT]


No, you're absolutely right, your posts are very self-explanatory  What I actually meant to say is that I'd love to see the features you need implemented, so it would be great if you warned us wherever there's something new  In the meantime, thanks for the effort you put in DAR

foo_DAR: auto rating

Reply #144
Hi, carpman san

I understand (1).
But, I don't understand (2).

Quote
2) Impliment the following fields based on this static NOW:

%Days Since Added%
%Days Since First Played%
%Days Since Last Played%

These would be static fields yeilding integer values.


Are these fields exist in each track?
And, when do update the track information?

foo_DAR: auto rating

Reply #145
Hi Kitahei

As you know both the official and unofficial playback statistics components store the following date related information:
  • First Played
  • Last Played
  • Added
And these values are PER TRACK.

The problem for me is that they store that data as a DATE string i.e. a TIMESTAMP. I need a way to turn that TIMESTAMP into an integer value. Furthermore, I need that integer to be related to NOW.

What I need is literally what cwb_hooks used to provide with:
  • $cwb_datediff(%added%,%cwb_systemdatetime%)    =    %Days Since Added%
  • $cwb_datediff(%added%,%first_played%)    =    %Days Since Added% minus %Days Since First Played%
  • $cwb_datediff(%added%,%last_played%)    =    %Days Since Added% minus %Days Since Last Played%

So, yes, these fields would be per track fields.

The problem, as I'm sure you know was with %cwb_systemdatetime%. This was always changing.
However, if the component used SYSTEM DAY THAT FOOBAR WAS LAUNCHED it would be a STATIC TIMESTAMP refreshed on fb2k initialisation.

From that the component would calculate:
  • %Days Since Added%  (NOW TIMESTAMP minus ADDED TIMESTAMP)
  • %Days Since First Played%  (NOW TIMESTAMP minus FIRST PLAYED TIMESTAMP)
  • %Days Since Last Played%  (NOW TIMESTAMP minus LAST PLAYED TIMESTAMP)

Quote
And, when do update the track information?

I'm not sure I understand the question. In a sense these fields are reading data from track information that is currently provided by both official and unoffical play statistics components (just as %_length_seconds% reads from the TRACK).

i.e. %Days Since Added% is simply a calculation based on the %added% timestamp and the (currently non-existent) NOW timestamp. So, since we have to make the NOW timestamp static the %Days Since Added% field is updated once per fb2k session (probably as some background process).

I'm not sure if that answers your question, if not, let me know and I'll try again.

C.

EDIT: Kitahei -- perhaps the problem you are having is related to my clumsy use of the word FIELDS. Perhaps FUNCTION would be a better word. i.e.  %Days Since Added% is a FUNCTION that produces an integer value based on existing FIELDS.
Does that help?
PC = TAK + LossyWAV  ::  Portable = Opus (130)

foo_DAR: auto rating

Reply #146
Hi carpman san

Thank you for a detailed explanation.
Maybe, I understand what you said.

However, I have the problem.
I do not understand how to implement "FUNCTION".

Do I have to use "metadb_display_field_provider"?
However, there seem to be the following limitations in "metadb_display_field_provider".

Quote
/*!
   Implementing this service lets you provide your own title-formatting fields that are parsed globally with each call to metadb_handle::format_title methods. \n
   This should be implemented only where absolutely necessary, for safety and performance reasons. Any expensive operations inside the process_field() method may severely damage performance of affected title-formatting calls. \n
   You must NEVER make any other foobar2000 API calls from inside process_field, other than possibly querying information from the passed metadb_handle pointer; you should read your own implementation-specific private data and return as soon as possible. You must not make any assumptions about calling context (threading etc). \n
   It is guaranteed that process_field() is called only inside a metadb lock scope so you can safely call "locked" metadb_handle methods on the metadb_handle pointer you get. You must not lock metadb by yourself inside process_field() - while it is always called from inside a metadb lock scope, it may be called from another thread than the one maintaining the lock because of multi-CPU optimizations active. \n
   If there are multiple metadb_display_field_provider services registered providing fields of the same name, which one gets called is undefined. \n
   IMPORTANT: Any components implementing metadb_display_field_provider MUST call metadb_io::dispatch_refresh() with affected metadb_handles whenever info that they present changes. Otherwise, anything rendering title-formatting strings that reference your data will not update properly, resulting in unreliable/broken output, repaint glitches, etc. \n
   Do not expect a process_field() call each time somebody uses title formatting, calling code might perform its own caching of strings that you return, getting new ones only after metadb_io::dispatch_refresh() with relevant items. \n
   If you can't reliably notify other components about changes of content of fields that you provide (such as when your fields provide some kind of global information and not information specific to item identified by passed metadb_handle), you should not be providing those fields in first place. You must not change returned values of your fields without dispatching appropriate notifications. \n
   Use static service_factory_single_t<myclass> to register your metadb_display_field_provider implementations. Do not call other people's metadb_display_field_provider services directly, they're meant to be called by backend only. \n
   List of fields that you provide is expected to be fixed at run-time. The backend will enumerate your fields only once and refer to them by indexes later. \n
*/

How to use metadb_display_field_provider

foo_DAR: auto rating

Reply #147
You should do the calculation when asked by user or perhaps on startup, then cache the result data. The metadb_display_field_provider implementation should simply return the cached value.
Full-quoting makes you scroll past the same junk over and over.

foo_DAR: auto rating

Reply #148
You should do the calculation when asked by user or perhaps on startup, then cache the result data. [SNIP]
It would be nice if there was an option to do one or the other either:
  • Auto: Calculate on Startup  [yes / no ]
  • Manual: On User Request (to have this option always available)
C.

ps. Kitahei, I'm not a programmer, any expressions I use are entirely descriptive and non-technical. I can explain how I think something should work, but I can't help in regard to how this can actually be implimented / programmed  (unlike Yirkha who can).

Quote
I do not understand how to implement "FUNCTION".

Do I have to use "metadb_display_field_provider"?
However, there seem to be the following limitations in "metadb_display_field_provider".
This kind of question scares me! 

EDITED: Auto / Manual part of post.
PC = TAK + LossyWAV  ::  Portable = Opus (130)