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!

I wish you a restful hiatus.

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.

@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)

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.

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?).

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

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

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.

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.

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

@ 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]

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.

• First Played
• Last Played
• Added

• $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%

• %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)

And, when do update the track information?

/*!
   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
*/

You should do the calculation when asked by user or perhaps on startup, then cache the result data. [SNIP]

• Auto: Calculate on Startup  [yes / no ]
• Manual: On User Request (to have this option always available)

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".