Latest release: foo_dynfil v1 beta 4 (http://yirkha.fud.cz/progs/foobar2000/foo_dynfil-v1-beta-4.zip)
This version was released in post #71 (http://hydrogenaudio.org/forums/?showtopic=86853&st=50#entry744320). Various things were added or changed since the version originally posted below, so check that post and the preceding discussion for the full details.
[original post follows]
Try this and let me know if it works satisfactorily enough: foo_dynra (outdated link removed)
Provides %_dynamic_rating% calculated according to a formula entered under Preferences > Media Library/Dynamic Rating.
While evaluation, an additional field %now% and two functions, $time_diff() for seconds and $date_diff() for days, are supported.
[ETA: Function called with only one argument, like $time_diff(%added%), is a shorthand for difference to %now% (with better performance too).]
Refreshes asynchronously at startup, when you press a button and using bindable main menu command Library > Recalculate dynamic rating.
Prints how much time did a recalculation take to the console, so we can see how silly this idea is.
[ETA: Sample formula to try: http://fb2k.pastebin.com/XrcDzA1j (http://fb2k.pastebin.com/XrcDzA1j)]
Some Data:
Library size: 13740 items
%length_seconds% : 0.0426459 s
$muldiv(%play_count%,10000,$date_diff(%added%)) : 0.3555903 s
Above with $if(%play_count%) : 0.1595538 s
FooDAR link : 3.0252005 s
Plays per year (below) : 0.2179175 s
Those numbers are a lot faster than I had expected, although I've only a relativity small library with about 1700 items with a play count. The following code probably isn't very efficient, but the $if(%play_count%) made a big difference (down from about 0.7s.) I wouldn't probably use the fooDAR code but I'm going to see how useful I find Plays per Year.
Good work, the only thing that needs doing is improving "Blah Blah Blah..."
$if(%play_count%,
$puts(_dr,$mul($muldiv(%play_count%,10000,$date_diff(%added%)),7,52))
$puts(_s,'0000')
$puts(_sl,$len($get(_s)))
$puts(_m,1$get(_s))
$puts(_l,$len($get(_dr)))
$cut($if($greater($get(_l),$get(_sl)),$substr($get(_dr),0,$sub($get(_l),$get(_sl))).
$substr($get(_dr),$sub($add($get(_l),1),$get(_sl)),$get(_l)),$substr(0.$get(_s),0,
$sub($add($get(_sl),2),$get(_l)))$get(_dr)),$add($get(_sl),2))
)
Refreshes asynchronously at startup, when you press a button and using bindable main menu command Library > Recalculate dynamic rating.
As long as the dynamic rating changes only on a daily basis an option to calculate rating automatically at 0:00 (midnight) would redudantize any need for manual calculation. Even if the rating changes more frequent
(since $time_diff retreives seconds) we could have then a sensible rythm of automatic calculations. However, i can't estimate if that is technically feasible.
Wow! Most unexpected and thanks a lot Yirkha.
Firstly, I suggest we stop referring to foo_DAR and call it DAR, short for DADA (Date and Duration adjusted) Auto-Rating (for the moment at least).
Secondly, I'm going to play around with this when I get a chance to. In the meantime I've posted below the latest DAR Code (which is much improved and solves pretty much all the issues that were raised earlier in this thread).
Because anyone messing with this is a sophisticated fb2k user, I'll let you change whatever needs to be changed to work with the latest playback stats and Yirkha's foo_dynra (the code below uses foo_customdb):
Also the © is actual a c enclosed in brackets --- ( c ) but the forum software changes it to ©.
$puts(c,%play_counter%)
$puts(x,$add($cwb_datediff(%added%,%cwb_systemdatetime%),2))
$puts(y,$cwb_datediff(%added%,%last_played%))
$puts(z,$sub($get(x),$get(y),2))
$puts(l,%length_seconds%)
$puts(d1,$muldiv($add($get(l),540),1,4))
$puts(d2,$muldiv($get(l),$get(l),9000))
$puts(d3,$add($get(d1),$get(d2)))
$puts(r0,$mul($add(1000,$muldiv($get(d3),$get©,100)),10))
$puts(dd,$div($add($get(y),50),10))
$puts(pp,$muldiv($get©,10000,$get(x)))
$puts(2,$muldiv($get(dd),$get(pp),100))
$puts(3,$muldiv($get(x),135,100))
$puts(4,$div($get(pp),50))
$puts(5,$div($muldiv($add($cwb_datediff(%added%,%first_played%),2000),500,$add($div($get(d3),6),70)),$add($mul($get©,$get©),1)))
$puts(6,$muldiv($get©,625,$get(x)))
$puts(7,$add($get(3),$get(5),$get(6)))
$puts(r1,$add($get(2),$get(r0)))
$puts(r2,$add($get(4),$sub($get(r1),$get(7))))
$puts(r3,$sub($get(r2),$div($mul($get(r2),$get(l),$get(z),$get©),500000000)))
$puts(r4,$ifgreater($get(r3),0,$get(r3),1))
$ifgreater($get©,0,$num($get(r4),5),-----)
Thanks again Yirkha, will report back when I can.
C.
Good work, the only thing that needs doing is improving "Blah Blah Blah..."
OK, thanks.
Naturally the dialog text will provide some more useful information in the final release.
I had the component sitting abandoned on my harddisk for more than a year and was reminded of it only now when carpman linked to this topic in another thread. So this is just a quick beta release, published only because I've been in a publicization mood recently.
As long as the dynamic rating changes only on a daily basis an option to calculate rating automatically at 0:00 (midnight) would redudantize any need for manual calculation. Even if the rating changes more frequent (since $time_diff retreives seconds) we could have then a sensible rythm of automatic calculations. However, i can't estimate if that is technically feasible.
Anything is possible.™
I'm just not sure about the midnight part - somebody might get used to it being synchronized at 0:00 and then bitch after refreshing manually or at startup, suddenly with a non-aligned timestamp.
But yes, some automatic refresh while fb2k is running is definitely needed - then the component will "just work" for most people and that's always a good thing.
I guess I'll simply add two options, "
- Recalculate at startup" and "
- Recalculate each [day____]" (with a list of various periods).
Wow! Most unexpected and thanks a lot Yirkha.
You are welcome. (And please don't kill me for the delay described above...)
I suggest we stop referring to foo_DAR and call it DAR, short for DADA (Date and Duration adjusted) Auto-Rating (for the moment at least).
OK, well it's your formula. My part is only providing a generic framework to accomplish things like this - so the component will probably get its own thread later too. Maybe you could create a new, up-to-date topic for DADAAR too after everything settles down.
Maybe you could create a new, up-to-date topic for DADAAR too after everything settles down.
Yes, precisely - I will do. I'll come up with something that isn't so fooDADADADAAAAAAAAAAAR.
C.
Yirkha, a couple of technical questions just out of curiosity :
- where is %_dynamic_rating% stored ? I guess not in tags
- how did you (which SDK function) manage to make this info available to the rest of foobar (playlist renderer, search engine, ...). I thought this capability was removed (http://www.hydrogenaudio.org/forums/index.php?showtopic=62286) some time ago
Thanks
1. where is %_dynamic_rating% stored ? I guess not in tags
It's naturally not stored anywhere, it's calculated. And cached in memory till the next recalculation.
2. how did you (which SDK function) manage to make this info available to the rest of foobar (playlist renderer, search engine, ...).
metadb_display_field_provider. Nothing new, all playback statistics, custom DB, foo_exvar and other components have been using it for a long time.
Okay, well this DAR Code works with the official Playback Statistics component and Yirka's foo_dynra:
$puts(pc,%play_count%)
$puts(x,$add($date_diff(%added%),2))
$puts(y,$date_diff(%added%,%last_played%))
$puts(z,$sub($get(x),$get(y),2))
$puts(l,%length_seconds%)
$puts(d1,$muldiv($add($get(l),540),1,4))
$puts(d2,$muldiv($get(l),$get(l),9000))
$puts(d3,$add($get(d1),$get(d2)))
$puts(r0,$mul($add(1000,$muldiv($get(d3),$get(pc),100)),10))
$puts(dd,$div($add($get(y),50),10))
$puts(pp,$muldiv($get(pc),10000,$get(x)))
$puts(2,$muldiv($get(dd),$get(pp),100))
$puts(3,$muldiv($get(x),135,100))
$puts(4,$div($get(pp),50))
$puts(5,$div($muldiv($add($date_diff(%added%,%first_played%),2000),500,$add($div($get(d3),6),70)),$add($mul($get(pc),$get(pc)),1)))
$puts(6,$muldiv($get(pc),625,$get(x)))
$puts(7,$add($get(3),$get(5),$get(6)))
$puts(r1,$add($get(2),$get(r0)))
$puts(r2,$add($get(4),$sub($get(r1),$get(7))))
$puts(r3,$sub($get(r2),$div($mul($get(r2),$get(l),$get(z),$get(pc)),500000000)))
$puts(r4,$ifgreater($get(r3),0,$get(r3),1))
$ifgreater($get(pc),0,$num($get(r4),5),-----)
By the way, Yirkha, am I right in thinking that your component doesn't allow fields such as $date_diff(%added%) outside of the component, i.e. you can't use fields such as %now% as a stand-alone bit of script in a column?
[EDIT]
I've got some code (which basically uses the DAR as an index, for those who prefer dots instead of numbers). I'll post that up when I start a new thread.
C.
But yes, some automatic refresh while fb2k is running is definitely needed - then the component will "just work" for most people and that's always a good thing.
While experimenting with carpmans script i noticed that another type of automatic updating would be senseful. When a currently playing track increases its playcount and therefore changes its first played time then its and only its dynamic rating could be updated to reflect immediately the change of the value.
I agree, that would be ideal.
By the way Yikha, great job!
C.
It is possible now to have a field for autorating or hotness or average daily playcount or ... But you have to decide for one of them.
Yes, so what you're suggesting to Yirkha is something like having, the same interface but with 3 or so tabs to enter code, and having 3 or so fields for outputting:
%_dynamic_rating1%
%_dynamic_rating2%
%_dynamic_rating3%
Then of course you could see side by side how the different ratings formulas stack up against oneanother.
DAR and Hotness (AFAIK) are doing two different things, DAR is an attempt to level the playing field and give you an idea of your favourite tracks (new and old, long and short, right now) and Hotness is telling you your latest craze (I think).
C.
EDIT: Personally, after setting up fb2k 1.1 with the official Playback Stats and Yirkha's dynra component, what I'd like is:
1) The ability to see simple things like Age (in no. of days since added) and (no. days since last played) (i.e. $date_diff(%added%)) -- that's very handy for testing and a 2 or 3 digit number takes up much less space than a long date and time stamp/string.
2) I've had to install foo_customdb.dll (and remove all fields except Playcount) just for the "count as played after x%" (but that's an official playback stats issue).
3) The ability to transfer stats from unofficial stats components (foo_custominfo.dll) to the official one. It would be nice if someone could work on an SQL export to XML (?) or whatever the official format is for importing stats. EDIT2 -- I've got stats for DAR testing that are more than 2 years old - thus I'm still with 0.9.4.3 when it comes to checking how the DAR formula performs. Ultimately you want everyone using the official stats plugin (I'd like to personally - and in my test setup I'm using most of it - but that count as played after 1 min bugs me).
%_dynamic_rating1%
%_dynamic_rating2%
%_dynamic_rating3%
Hmm, that would be better:
%_hotness%
%_auto_rating%
%_daily _playcount%
%_days_since_added%
Own names!
Yeah, but each time someone comes up with a new thing Yirkha would have to add a field for it - not so good. This way there's no worry of redundancy.
C.
I thought of creating own name s for field as you can do for columns in CUI - have you ever waited for musicmusic ...
have you ever waited for musicmusic ...
What do you mean?
C.
Am I right in thinking that your component doesn't allow fields such as $date_diff(%added%) outside of the component, i.e. you can't use fields such as %now% as a stand-alone bit of script in a column?
Yes, those are supported in the local context only. It hasn't been possible to add custom global $functions() since [a href='index.php?showtopic=62286']0.9.5.2[/a]. As for the %now% field, the local availability is obviously the only way to avoid the well known problems (repaint glitches and other unreliability).
While experimenting with carpmans script i noticed that another type of automatic updating would be senseful. When a currently playing track increases its playcount and therefore changes its first played time then its and only its dynamic rating could be updated to reflect immediately the change of the value.
Indeed, seems reasonable. I'll add that to the component, so that when any metadata changes, the dynamic values of the relevant track(s) will be also recalculated.
And I'll make it do the same for any newly added tracks too. Currently the only action taken was to remove information for tracks removed from the Media Library.
I had been pondering for a while whether the data should be updated using %now% of the last recalculation or the new, current time in such cases - because people might not want some random play count increase or whatever change the time reference point. But then I strongly decided for the latter, because 1) the recalculation time is not predictable anyway, 2) nobody can expect people's script working properly with negative date/time differences, 3) it will be the right thing to do to return correct values in almost all usages anyway.
It is possible now to have a field for autorating or hotness or average daily playcount or ... But you have to decide for one of them.
Yeah, yeah. Of course I
knew that someone will suggest that, it's not in the current release only because it needs additional UI, restarting fb2k upon change and so on. (If anybody is wondering about why a restart is necessary, it's a price we pay for the performance to not [a href='index.php?act=findpost&pid=564566']suck[/a] anymore.)
So, for a likely tiny decrease in performance, support for multiple fields will come in the next version too. And naturally this way:
%_hotness%
%_auto_rating%
%_daily _playcount%
%_days_since_added%
Own names!
But another question is then raised by extending the functionality - can it still be called foo_dynra for Dynamic Rating if people use it to show things like "Added: 123 days ago" in their playlists?
I say no, therefore the component will be called "Dynamic Fields" from now on. I guess.
In contrast with the new Playback Statistics 3.0, foo_dynra observes only tracks from the Media Library.
Yes, and it will always stay like that. For the best performance during drawing, sorting and so on, the component needs to remember the calculated value for all tracks it will be used with. Limiting that to the Media Library, which is always fully loaded and clearly constrained seemed like a decent solution to me.
I'd appreciate it, if a moderator would close this thread.
If you don't mind, I'd leave it alive for a few more days to continue our discussion about foo_dynra, as I don't like complicated topic splitting. After release of the component, I'd create a proper stand-alone topic for it and finally close this.
Yirkha, no problem, of course I don't mind. Keep it open for as long as is needed.
By the way, I'm very pro all the decisions for foo_dynra. Very good news.
Now if Peter allows count as played only after x% in his foo_playcount, I do believe a choir of angels will descend and lift me to the nirvana of my choosing.
Cheers,
C.
I wouldn't count on that, though. I'm pretty sure it uses the playback_statistics_collector API, which has a well defined constant behaviour - "at least 60s of the track has been played, or the track has reached its end after at least 1/3 of it has been played through". The core does the monitoring and calls registered components when the condition is hit. Extending this so that each client could change the parameters would need a new version of the API as well as making the inner implementation more complex. And Peter is not usually keen on messing with stuff which works well enough.
"at least 60s of the track has been played, or the track has reached its end after at least 1/3 of it has been played through"
I see. So Peter could actually make it even more simple, by simply fixing it at 50% or 67%. So a) still, no one gets to "change the parameters", and b) that's more simple than the current "60 secs or ...".
And it would get rid of the strange part where 39 mins of a 40 min track (97.5%) are skipped, yet it's still counted as played.
Anyway, this is OT for this old thread.
Thanks again, and I'm looking forward to the next episode of Dynamic Fields starring Yirkha.
C.
EDIT: Spelling.
@carpman
A total play length for a track would solve that. You already explained somewhere that total play length diveded by track length then would be the "real" playcount. The relation between that playcount and the official one would also offer some information about skipping behaviour. I liked the idea when i read it the first time.
@yirkha
Is that possible in the context of your component at all? It seems to me that it would work a bit different than the dynamic fields: %total_play_length% has to be available in scripts which define a dynamic field.
Recording how many seconds a particular track has been playing in total needs persistent storage, track pinning scheme and all the other stuff Playback Statistics do. I'm not going to create yet another foo_playcount_mod_mod from this component.
I see! I anyway had the feeling it would be an other thing than a dynamic field - just: such feelings doesn't help an average user to recognize which features are feasible and which not.
Recording how many seconds a particular track has been playing in total needs persistent storage, track pinning scheme and all the other stuff Playback Statistics do. I'm not going to create yet another foo_playcount_mod_mod from this component.
Yes, indeed, it's ideal in some ways, but
not really, precisely because it's also a big deal (as Yirkha points out) and also it becomes unnecessary when playcount is counted after a fixed % (e.g. 67%).
If you eat a few peas you can't say you've had dinner, half the meal? - maybe, but two thirds? - I think you can politely excuse yourself as being satisfied; you've made a decent effort.
romor's case is an ideal example, he chose the mother of all feasts (155 min song) (http://www.hydrogenaudio.org/forums/index.php?showtopic=83954&view=findpost&p=724828), took a bite and foo_playcount excused him from the table.
C.
Hi Yirkha,
Quick question. Is there any way to get the number of days between a static (i.e. non %field%) date and %now%.
So for example the approx timestamp for 1/1/2000 is 125910720000000000, but foo_dynra doesn't allow:
$datediff(125910720000000000)
So is there a way to generate this from the existing component, and if not I'd like propose some date syntax for this, such as:
$datediff(YYYY-MM-DD).
Cheers,
C.
I thought this had already worked, but it didn't. [font= "Courier New"]$date_diff(2010-11-10 00:00:00)[/font] would though.
Anyway, here is foo_dynfil v1 beta (outdated link removed).
(Please save your awesome patterns and uninstall foo_dynra before using this.)
I don't have time to properly test it, so I thought I'd better release it and leave testing to the users.
So please give me any feedback here and if everything goes well, I'll post a final version to its own new pretty topic later.
And by feedback, I mean anything you don't like. Not just the obvious crashes, but also all the interesting nitpicking stuff you usually keep to yourself. Yes, really. Even the moments you think "oh, right, I can't do this, I have to do this first, computers work that way". Or bad looking off-by-one pixel offsets in your arbitrary DPI mode - I'll do what I can. There is no excuse for a program to not "just work right" and look nice.
Well, and I also want to release this once and forget about it for years
Some patterns to try:
%_simple_popularity%:
[font= "Courier New"]$muldiv(%play_count%,1000,$date_diff(%added%))[/font]
%_simple_popularity%: (without Playback Statistics)
[font= "Courier New"]$muldiv(%last_modified%,1000,$date_diff(%added%))[/font]
%_added_days%:
[font= "Courier New"]$puts(x,$date_diff(%added%))$ifequal($get(x),0,today,$get(x) day$ifgreater($get(x),1,s,) ago)[/font]
%_recalc_count%: (my favourite)
[font= "Courier New"]$add(%_recalc_count%,1)[/font][/indent]
Edit reason: %_simple_popularity% w/o PS should use %last_modified%.
Awesome! I haven't managed to break it yet.
Niggles:
[/li]- Can't Crtl+A in the script box.
- The orange circle button wasn't obvious on first look, tool-tips or maybe a pencil?
- When opening the preferences page (after closing it), the shown script is the first that was added not the first sorted. eg:
First added: plays_per_year
Second added: added_ago
When you open the preferences page afresh it shows the script from plays_per_year but the drop down has added_ago.
Ideas/wishes:
- Preview box, I find these useful with complex scripts but I wouldn't consider it a "must have" feature.
Thanks Yirkha!
Okay here we go ....
The rating only updates the bit of the playlist in view. So DAR column, seemed to update, then another instance of that column would be completely blank when I viewed it in another playlist. So I hit recalculate, and it would, but then I'd scroll down and see that the rest of that playlist that wasn't in view when recalculating was blank as far as the DAR column.
That's all so far with my limited beta testing. Easy to see that this is a genius component in the making.
Thanks again!
C.
EDIT -- put this on hold. Seems okay now. Perhaps the background processing is very easy on resources and initial calc takes a while? I'll keep using, and if there's anything to the above I'll report in more detail.
EDIT2: No, there is an issue. It seems to be a display / refresh issue. I've an autoplaylist which is basically DAR > 0, and that is still populated and in DAR order. So at some level the system seems to calculate / know the correct values. However, the DAR column, let's say %dar%, seems to lose it's values when the individual track updates its.
So for example. I'll do recalculate dynamic fields, and the DAR column is full of values. However, as soon as the playing song updates its values, all the rest of the values go missing.
EDIT 3: The values all go missing on track change (if that helps) - i.e. the song has finished playing moves on to the next one and then all other tracks lose their values (display-wise at least).
Hope that helps.
Using latest fb2k (1.1.1) latest CUI, Win XP SP2.
+1 for Purple Monkey's niggles.
It would be nice if there was a way to export/import your various scripts.
Does this get backed up by foo_jesus, by default?
C.
Also, re. the above, I have a column with the Replay Gain values, if I remove RG values from file, the values calculated by foo_dynfil are all lost. So it's a display / refresh issue.
Nitpicking on preferences page: I use Win 7 with 125 % scaling of fonts. The explaining text for $date_diff is truncated after ".. for calculating difference to".
Thanks for dynamic fields.
Similar to carpman I am experiencing loss of values calculated by foo_dynfil. So far this has occurred upon changing playlists, importing a new dui theme and following a restart of foobar2000. It does not always occur, but seems to occur about 50% of the time. I did not notice such problems with the previous version (foo_dynra). I am using foobar2000 v1.1.1 with EsPlaylist to display the values and XP SP3.
I am also having the same problem as carpman has, the dynamic field values just go missing when I:
1. Change track, or
2. Change playlist
Other than that, it works brilliantly. Thanks for this great plugin
Great, thank you very much for your feedback - Purple Monkey, carpman and ojdo.
Changelog:• Fixed: Partial recalculation (adding tracks to ML, metadata changes) clears values for the rest of the items.
• Fixed: When opening the preferences page (after closing it), the shown script is the first that was added, not the first sorted.
• Fixed: Ctrl+A doesn't select all text in the script edit box.
• Fixed: Preferences page layout in high DPI mode (truncated text).
• Added title formatting preview.
• Changed image for the rename button.
• "Recalculation took..." messages for less than 0.1 second are not logged (less spam in the Console for casual updates like single track %play_count% increment).
• The worker thread runs at lowered priority.
Download:foo_dynfil v1 beta 1 (obsolete link removed)_______________________________________________________________________________________________
It would be nice if there was a way to export/import your various scripts.
Export to/import from what format?
Does this get backed up by foo_jesus, by default?
Yes, everything is in the standard "configuration\foo_dynfil.cfg". (And everything means the update period, custom field names and their respective title formatting scripts.)
The orange circle button wasn't obvious on first look, tool-tips or maybe a pencil?
Well, the button icons are parametrically generated, so I did my best (see the new version), but don't expect miracles.
Wow, you've been busy!
Will try out the new version.
It would be nice if there was a way to export/import your various scripts.
Export to/import from what format?
Forget it, as you said, foo_dynfil.dll.cfg takes care of it. It's good to have individual configs for each component.
C.
Big improvement. Preferences is all good (for me at least), and the updating issue is mainly sorted out, except for one minor ...
Bug:
foo_dynfil doesn't update data (after playcount change - using offical playstats 3.0 plugin) in one autoplaylist, but does in another and does update in normal playlists and elsewhere, such as Main Window (CUI). The autoplaylist that didn't update is actually based on a foo_dynfil field (the DAR script), see below.
).
Great work Yirkha, and many thanks.
C.
EDIT1: Weird. It's gone all quantum on me. Observing seems to effect the testing, this time I didn't observe the autoplaylist in question, and then looked to see if the track data in the autoplaylist had changed, it had, but its position in the autoplaylist hadn't, so something's going on with foo_dynfil and autoplaylists based on foo_dynfil fields. Not sure what though.
Nice update, great component.
There's probably a cleaner way to do this but here's a "last played days ago" field:
$if(%last_played%,$puts(x,$date_diff(%last_played%)), Never Played)
$ifequal($get(x),0,$if(%last_played%,Today,),$get(x) day$ifgreater($get(x),1,s,) ago)
foo_dynfil doesn't update data (after playcount change - using offical playstats 3.0 plugin) in one autoplaylist, but does in another and does update in normal playlists and elsewhere, such as Main Window (CUI).
Ah, yeah, I know what happens, one track is accidentally left out from the metadata change notification being broadcasted, which means nothing changes after updating just one item. I'll roll out a new version shortly. Thanks for finding out!
Would it be possible to have an option for foo_dynfil to not update / recalc at fb2k start. For example, only update on first track change or update x secs after fb2k has already started.
How much of a problem is it, do you have any measurements at hand? The calculation is already done in a thread with lowered priority, it shouldn't affect startup of other components. Also, you need to calculate it as soon as possible, otherwise people's nice autoplaylists will be useless.
Well, I can imagine one reason for slowness - foo_dynfil does its job properly in a separate thread, but then fires a notification that all tracks in the ML have changed (their %_yourfields% have) and various ML viewers hold the UI as they are updating.
Changelog:
• Fixed: One track missing in metadata change notification (autoplaylist and display update problems).
Download:
foo_dynfil v1 beta 2 (outdated link removed)
Superb! Looks fixed on cursory test. Will give it a proper look over tomorrow.
C.
How much of a problem is it, do you have any measurements at hand? The calculation is already done in a thread with lowered priority, it shouldn't affect startup of other components. Also, you need to calculate it as soon as possible, otherwise people's nice autoplaylists will be useless.
Its taking about 1.2 s on my system. Wouldn't it be better if recalculation was done at closing the foobar instead of startup?
Hi Yirkha,
The only thing I'd like, in addition to what your wonderful component already provides, is the ability to switch off the "re-calculation element" if that's possible. Forget my earlier request re. startup delays etc... , I had a think about that and agree with you. But after sitting with it, what I'm really after is to be able to simply switch it on and off (a simple tick box perhaps? - active / de-activate), without having to remove and re-add the component.
Why? Sometimes I'll be doing some pretty heavy processing, while also listening to music. During those times I'll often close "unnecessary processes" and I'd like to be able to include foo_dynfil in that camp. I don't know if that's tricky, but it would be ideal if all the values remained in their previous state, so later you could simply switch it back on and then it would recalculate.
No worries if that's a real pain. It's not essential - foo_dynfil already does the essentials really well - but a nice additional feature.
C.
EDIT: spelling
I haven't found anything else wrong with beta2, thanks for the component!
@carpman: There is an option to set the interval for recalculation on the preferences page, the first option in the drop down is never. I wouldn't have thought that a single track recalculation would take that much power so it should do that I think you are after.
Hello yirkha,
i am playing around with creation of some fields that transforms dates into natural language (yesterday, this month, ...). In that context i would need two functions that would help to avoid large title formatting. $weekday() that gives back "Monday, ..., Friday, Saturday, ..." and $calendar_week() that returns number in range of 1 to 52.
I know that these fields are not dynamical and could be implemented globally, but somehow they would fit in your component.
Seems to work very well so far, it's really cool! I'll ask something dumb as usual! I may have missed it, but it'd be nice if I could see the values under the Properties of a song. I mean like here:
(http://snobwall.com/upload/stored/clip_2010-11-12_070307.png)
Since I'm using %_dynamic_rating%... The value of it, I have to find it out by using an Item Details panel, which isn't in my normal layout. I know it's nitpicking, but you did ask for anything...
Its taking about 1.2 s on my system. Wouldn't it be better if recalculation was done at closing the foobar instead of startup?
It's taking about 1.2 s because I made it print the number out. Would you notice if it was not shown in the console as well? The point I'm making is I'm all for having options to tweak this and that, but only if there is some
real benefit. If there isn't, why bother? It only confuses people and creates superstitious beliefs about its effects.
Also calculation cannot be done at shutdown instead of startup because the precalculated values are never saved to disk, and the closing procedure is slow enough even now so that people reportedly lose their configuration on Windows shutdown, no need to push it further.
I'd like (...) ability to switch off the "re-calculation element" (...) on and off (a simple tick box perhaps? - active / de-activate), without having to remove and re-add the component. Why? Sometimes I'll be doing some pretty heavy processing, while also listening to music. During those times I'll often close "unnecessary processes" and I'd like to be able to include foo_dynfil in that camp. I don't know if that's tricky, but it would be ideal if all the values remained in their previous state, so later you could simply switch it back on and then it would recalculate.
I have a hard time imagining what kind of heavy processing needs such precautions in this day and age. Nevertheless, this is correct:
There is an option to set the interval for recalculation on the preferences page, the first option in the drop down is never. I wouldn't have thought that a single track recalculation would take that much power so it should do that I think you are after.
Impact of the recalculation for a single track, like after its play count increases, should be quite neglible - at least compared with opening the next track for playback or redrawing an album list.
One more thing, the recalculation times are nicely predictable. If you have set update period as, for example, once per day, you know that if it's 10:20 p.m., you have exactly 1 hour 40 minutes till the next full recalculation at midnight.
Also,
carpman, re: the new DADADAR thread - I did not make it very clear back then, but the short forms of dates work fine in Dynfil, so [font= "Courier New"]$date_diff(2000-01-01 00:00:00) == $date_diff(2000-01-01 00:00) == $date_diff(2000-01-01 00) == $date_diff(2000-01-01) == $date_diff(2000-01) == $date_diff(2000)[/font].
i would need two functions that would help to avoid large title formatting. $weekday() that gives back "Monday, ..., Friday, Saturday, ..." and $calendar_week() that returns number in range of 1 to 52.
OK, I'll see about that. Also I take your point about these being rather candidates for global functions, but this component deals with date/time a lot, they wouldn't too out of place here.
it'd be nice if I could see the values under the Properties of a song.
Yes, indeed. I'll add that in the next version.
Impact of the recalculation for a single track, like after its play count increases, should be quite neglible - at least compared with opening the next track for playback or redrawing an album list.
Yeah, makes sense, scrap that request. I keep forgetting that it's just calculating one track until the interval update. In that way it's far better than the old cwb hooks method.
re. date_diff(year). So just for confirmation $date_diff(2000) defaults to 1st Jan 2000?
Thanks,
C.
I don't know if they're supposed to, but the dynamic fields aren't included when you export a DUI theme.
Also, carpman, re: the new DADADAR thread - I did not make it very clear back then, but the short forms of dates work fine in Dynfil, so $date_diff(2000-01-01 00:00:00) == $date_diff(2000-01-01 00:00) == $date_diff(2000-01-01 00) == $date_diff(2000-01-01) == $date_diff(2000-01) == $date_diff(2000).
Thanks. Have altered code to $date_diff(2000). Handy feature.
C.
One more thing, the recalculation times are nicely predictable. If you have set update period as, for example, once per day, you know that if it's 10:20 p.m., you have exactly 1 hour 40 minutes till the next full recalculation at midnight.
I thought that a new intervall begins from the point of last updatel. Update each day means "at midnight" in every case? How does the other intervalls (f.e. each 8 hours) work? Do they have also fix timepoints?
foo_dynfil v1 beta 2 crashes on media library initialization in foobar2000 v1.1.1 (happens when some folders are moved to different location inside media library).
Illegal operation:
Code: C0000005h, flags: 00000000h, address: 71892758h
Access violation, operation: read, address: 00000000h
Call path:
entry=>app_mainloop=>main_thread_callback::callback_run=>library_callback::on_items_removed
Code bytes (71892758h):
71892718h: FC 01 E8 03 FD FF FF E8 5E 6E 00 00 F6 45 08 01
71892728h: 8B 75 F0 B8 24 9B 8A 71 89 03 89 06 74 07 56 E8
71892738h: 7F 8B 00 00 59 8B 4D F4 5F 8B C6 5E 5B 64 89 0D
71892748h: 00 00 00 00 C9 C2 04 00 55 8B EC 56 8B 75 08 57
71892758h: 8B 3E 85 FF 75 04 32 C0 EB 50 53 8B 5D 0C FF 33
71892768h: 8D 47 08 50 E8 D9 08 00 00 59 59 85 C0 75 13 8B
71892778h: CE E8 62 00 00 00 83 3E 00 0F 95 C0 84 C0 74 23
71892788h: EB 15 8D 47 28 7F 03 8D 47 2C 53 50 E8 B7 FF FF
Stack (003FF928h):
003FF908h: 00000000 FFFFFD34 000002E4 FFFFFD34
003FF918h: 000002CC 00000019 00000000 003FF958
003FF928h: 003FF9C0 718AF640 003FF964 71891D44
003FF938h: 00000000 003FF96C 00000000 00000002
003FF948h: 00000000 718AF650 00002DCA 02405D80
003FF958h: 003FF990 718A6890 00000001 003FF99C
003FF968h: 00B15EB7 003FF954 00002DCA 0691EDDC
003FF978h: 00000000 003FF9A0 02400948 00000037
003FF988h: 03BD7840 00000000 003FF9D4 00BF8A59
003FF998h: 00000000 003FF9E0 00B10E8A 003FF9C0
003FF9A8h: 0691EDDC 00002DCA 02402DBC 02402DBC
003FF9B8h: 06907260 06907260 00C1DBD8 06982308
003FF9C8h: 00002DCA 00004000 00C5697C 003FF9F4
003FF9D8h: 00C022A0 00000000 003FFA00 00B1217E
003FF9E8h: 0691EDDC 0691EDC0 0691DBBC 003FFA34
003FF9F8h: 00BF8BA8 FFFFFFFF 003FFA40 00AFEBA9
003FFA08h: 06907260 0691EDC0 0691DBB8 00B207D2
003FFA18h: 00000000 000004B1 00000000 00000013
003FFA28h: 0691EDC0 0691DBB8 00000004 003FFA60
003FFA38h: 00BF90E1 00000001 003FFA70 00B20961
Registers:
EAX: 003FF96C, EBX: 00000000, ECX: 00000000, EDX: 00C22FA8
ESI: 00000000, EDI: 003FF9C0, EBP: 003FF930, ESP: 003FF928
Crash location:
Module: foo_dynfil
Offset: 2758h
re. date_diff(year). So just for confirmation $date_diff(2000) defaults to 1st Jan 2000?
Yeah, exactly (as you've found out already...). Any omitted values from the right have default values as shown in my post above.
I don't know if they're supposed to, but the dynamic fields aren't included when you export a DUI theme.
They are not suposed to, because the theme stores only configuration of the individual shown/used UI elements. You would have to add some kind of a dummy UI element (provided by this component) to have a chance at adding configured Dynamic Fields into the theme.
I thought that a new intervall begins from the point of last updatel. Update each day means "at midnight" in every case? How does the other intervalls (f.e. each 8 hours) work? Do they have also fix timepoints?
I guess. (To explain: I remembered there was a nice API in the SDK for controlled periodic timers and I thought it would be nice, so I used it. I didn't have patience to try e.g. 8 hours interval though.)
Well, each day is simple, that's midnight. Every 5 minutes is also simple, xx:x0 or xx:x5 - I saw that with my own eyes. Between that it's most probably similar, so probably divide 24:00 by specified interval and you have your fixed time points.
foo_dynfil v1 beta 2 crashes on media library initialization in foobar2000 v1.1.1 (happens when some folders are moved to different location inside media library).
Thanks! I saw that in the crash log submission system too, will be fixed in the next version (soon, I hope).
Good news everyone, it's time for another beta!
Changelog:
• Fixed: Crash on startup if ML items were removed while fb2k was not running.
• New: Title formatting functions [font= "Courier New"]$day_of_week()[/font], [font= "Courier New"]$day_of_year()[/font] and [font= "Courier New"]$week_of_year()[/font].
• New: Dynamic fields are shown in Preferences and selection viewers.
• Preferences dialog UI changes (separators, more extensive help, keyboard navigation, ...)
Known issues:
• Button images look shitty in Windows XP classic mode (at least).
• Weird help button image alignment in various theme/DPI/whatever combinations.
Download:
foo_dynfil v1 beta 3 (outdated link removed)
As always, I'd be happy if you could find any outstanding bugs in this release, ugliness, Engrish and typos included.
In particular, I did not have time to test in different DPI settings and on various OS again.
Thanks!
Thanks Yirkha. Everything's fine so far.
Like the extended help.
C.
Thanks for the update and putting the dynamic fields in properties! Is it possible that it's a bit faster with calculating? It took 4s now whereas before it was always more than that.
This is nitpicking, but when I input a field in the configuration, both times I did it so far, I put the %'s around it. Maybe it should detect that and just remove them? Right now it says "you can only use alphanumeric characters". Just for this particular situation where you put "%ducks%" instead of "ducks", I'd think there's no way it could be anything else...
That's a good idea, thanks. I'll provide some more user-friendly solution in the next version.
I made a mistake in my post, it should say %_ducks% instead of "ducks", but you probably get the idea.
Yes. I think both should be possible (maybe with a short note to avoid confusion about it being automatically changed).
On another matter, maybe it's not so intuitive at first, but I'd recommend naming the fields verbosely with capitalization - case doesn't matter in title formatting, but it looks nice in Properties or Selection properties.
Thanks for new version and the new date functions!
It's nice to see the values of selection in selection properties ui-element. However, it does show for a multiple selection all its single values. The playback statistics are more clever: they show the average or highes or lowest value.
If it is feasible it would be useful to have in "add field" the opportunity how the data should be presented: "show all values" (default), "show average value" and "show range of values (lowest till highest)" are enough i think.
Hi Yirkha,
Below is what the dynamic fields look like in the preferences dialog for me. The reason is presumably because the fields have (conditional colour) rgb info as part of their output. So below "lp_display" (last played) Today would be in red, if not Today then x days in grey.
Looks a bit weird in properties, so I wonder if there is a way to strip the colour data for the properties dialog.
Here's what is currently displayed:
age : 71
dar_pc_penalty : AAAAAA270
dynamic_rating : 09804
lp_display : 000096Today
Here's what I'd expect to see:
age : 71
dar_pc_penalty : 270
dynamic_rating : 09804
lp_display : Today
Cheers,
C.
It's nice to see the values of selection in selection properties ui-element. However, it does show for a multiple selection all its single values. The playback statistics are more clever: they show the average or highes or lowest value.
If it is feasible it would be useful to have in "add field" the opportunity how the data should be presented: "show all values" (default), "show average value" and "show range of values (lowest till highest)" are enough i think.
Yeah, I know, I wanted to do something like the Playback Statistics too, but then realized there really is no way to choose the right aggregation function automatically, like (min, avg, max) or (values and its percentage) or whatever. I agree that it would be nicer, but I'm a bit afraid of the additional UI mess needed to manage this additional setting. (I will do it anyway, I just wanted to say who will be responsible for it. )
(...) I wonder if there is a way to strip the colour data for the properties dialog.
Bah, you are abusing them poor dynamic fields! Or do you store silly color codes in your tags too?
Well, I could somehow take care of that, if only because I didn't want to hear similar whining for the upcoming years, but I have one good reason for not doing it:
If I created a foo_selection_properties_mod_mod_mod (or any other components which would use the Track Property Provider interface to get the values to show) and it would understand color codes, there would be no way to show them there, because they would be always stripped.
No, that's fair enough Yirkha. I'd never thought of myself abusing dem poor dynamic fields, but since you put it that way, it's very easy to leave the colour bit out, and instead put it in the intended column where it's appropriate.
But what I would say, is that it's worth mentioning this (when your component has its official place) that superficial look is best left to $applying(...) to the dynamic fields %_output% rather than being included in the actual dynamic fields calculation itself.
Consider this case closed.
C.
> As always, I'd be happy if you could find any outstanding bugs in this release
On 0.9.6.9, in put foo_dynfil.dll and laucnhed FB2K. I got
Failed to load DLL: foo_dynfil.dll
Reason: The specified procedure could not be found.
This on Win XP SP2.
I'm guessing it requires foobar 1.0+ (current is 1.1.1 (http://www.foobar.org/download)), version 0.9.6.9 is quite old.
I got a question, but I really don't know if its a question to carpman or yirkha
I'm using these newest components (only relevant ones)
- foobar2000 core 1.1.2
- Dynamic Fields 1 beta 3
- Playback Statistics 3.0.1
- Columns UI 0.3.8.7 (http://0.3.8.7)
I have a column with carpman's code from the start page of this thread
$puts(maxdar,11000)
$puts(mindar,8000)
$puts(maxsub,$sub($get(maxdar),0))
$puts(r3,$ifgreater(%_dynamic_rating%,$get(maxsub),$get(maxsub),%_dynamic_rating%))
$puts(r4,$ifgreater($get(r3),0,$get(r3),1))
$puts(minmax,$sub($get(maxdar),$get(mindar)))
$puts(darind1,$sub($get(r4),$get(mindar)))
$puts(darind2,$div($mul($get(darind1),10),$get(minmax)))
$puts(darind3,$ifgreater($get(darind2),1,$get(darind2),1))
$puts(display,$rgb(100,100,100)$repeat($char(9679),$get(darind3))$rgb(220,220,220)$repeat($char(9679),$sub(10,$get(darind3))))
$puts(notplayed,$rgb(200,200,200)- n/a -)
$ifgreater(%play_count%,0,$get(display),$get(notplayed))
I got 3 sorts of music
1) mp3 watched by my media library and got a playcount (=working fine with dynamic ratings)
2) mp3 not watched by media library and got a playcount (= not working fine)
3) dynamic URLs (radio streams) not watched by media library and got a playcount (= not working fine)
4) mp3 not watched by media library but got no playcount after playing (thats a problem related only to foo_playcount)
Ok, the second and third type of music are the strange ones.
These mp3 files aren't included to my media library, ok.
And they got growing playcounts from foo_playcount, thats ok too.
Now my question: carpman's column code is showing 1 dot/star even for these files without a calculated dynamic rating.
Can I tweak this code to hide this dot for files which
- has playcount stats
- but aren't included to media library
Thanks
PS: I read yirkhas statement to exclude files from calculation which aren't in ML.
But I wish he would rethink this and add an option to include even those files (e.g. with a big hint "this will slowdown your foobar's start time dramatically! Use at own risk"
Hi Nixdagibts
Yes, you'd need a line of code that said something like:
(Where X is the blank output of DAR (via foo_dynfil) when a non media library file is played.)
IF DAR = X THEN "no dot" OTHERWISE "do what it normally does"
The problem I have is that I don't know what foo_dynfil is outputting/doing when DAR is blank, so I don't know how to query it.
I suggest waiting for Yirkha to weigh in on this.
Cheers,
C.
He seems busy
Coulnt we use something like this?
IF NOT %_dynamic_rating% EQUAL 0 THEN ...
@ Nixdagibts
See this post (http://www.hydrogenaudio.org/forums/index.php?showtopic=83954&view=findpost&p=741040) for solution.
C.
@ Yirkha
Any idea when foo_dynfil gets officially released?
http://www.hydrogenaudio.org/forums/index....st&p=742301 (http://www.hydrogenaudio.org/forums/index.php?showtopic=83954&view=findpost&p=742301)
C.
Hello,
I'm having the problem that one of my tags doesn't update properly, here is the code:
$puts(maxdar,10000)
$puts(mindar,5000)
$puts(maxsub,$sub($get(maxdar),0))
$puts(r3,$ifgreater(%_dynamic_rating%,$get(maxsub),$get(maxsub),%_dynamic_rating%))
$puts(r4,$ifgreater($get(r3),0,$get(r3),1))
$puts(minmax,$sub($get(maxdar),$get(mindar)))
$puts(darind1,$sub($get(r4),$get(mindar)))
$puts(darind2,$div($mul($get(darind1),10),$get(minmax)))
$puts(darind3,$ifgreater($get(darind2),1,$get(darind2),1))
$puts(notplayed,n/a)
$ifgreater(%play_count%,0,$get(darind3),$get(notplayed))
I put it in the tag %_dynamic_rating_10% and made an album list view from it. When I start foobar it is rating all tracks I have with either 1 or n/a, but when I force an update it works properly.
Hi. Well, as you've probably figured out, I'm mostly busy with other things and this project has been stalled for months. But I've made at least some progress tonight and because I don't have time to test the changes properly (or finish everything needed and release a final version), here is another beta.
Changelog:• New: Per-field aggregation functions (none, group, sum, min/avg/max).
• New: Automatically remove %/% or %_/% around the name when adding/renaming a field.
• Fixed: Compare new field name with existing fields case-insensitively.
• Fixed: Plenty of other more or less problematic bugs, UI changes, ...
Known issues:• Button images look shitty in Windows XP classic mode (at least).
• Weird help button image alignment in various theme/DPI/whatever combinations.
Download:foo_dynfil v1 beta 4 (http://yirkha.fud.cz/progs/foobar2000/foo_dynfil-v1-beta-4.zip)
Warning: The config format has changed and it is not compatible with previous versions. Backup your precious patterns before upgrading!
(I love staying in beta, no silly compatibility measures to do. Also whoever downloads this without reading gets what he deserves )
______________________________________________________________________________________
Yes, you'd need a line of code that said something like:
(Where X is the blank output of DAR (via foo_dynfil) when a non media library file is played.)
IF DAR = X THEN "no dot" OTHERWISE "do what it normally does"
The problem I have is that I don't know what foo_dynfil is outputting/doing when DAR is blank, so I don't know how to query it.
Guess what - when DynFil doesn't know any value for the specified track, the [font= "Courier New"]%_field%[/font] is
not defined, as is [font= "Courier New"]%bflmpsvz%[/font]. So [font= "Courier New"][%_field%][/font], [font= "Courier New"]$if(%_field%,YES,no)[/font], everything works as expected.
Also, Carpman, I've finally killed that old DAR thread, hope that makes it easier to keep things in relevant topics now.
I'm having the problem that one of my tags doesn't update properly, here is the code:
I put it in the tag %_dynamic_rating_10% and made an album list view from it. When I start foobar it is rating all tracks I have with either 1 or n/a, but when I force an update it works properly.
I don't know. Yes, fields provided by DynFil are not available until they are (asynchronously) calculated and that takes a while, so it's expected. However when they are ready, proper notifications are dispatched to make the updates show correctly. Or so I believe, it would result in much more breakage otherwise...
@ Yirkha
Any idea when foo_dynfil gets officially released?
When it's done.
What needs to be done? Any outstanding bugs you people will find during the upcoming weeks, then mostly UI glitches and compatibility with various OS/theme/whatever settings.
What might get done extra? I have only one idea, having a checkbox for monitoring items in all playlists too, not only the ML. It would slow down startup and perhaps other playlist operations, but who knows how much really and if someone has use for it, oh well.
• New: Per-field aggregation functions (none, group, sum, min/avg/max).
Very cool! Haven't tried yet, but if it does what I think, that's a very nice addition.
Also, Carpman, I've finally killed that old DAR thread, hope that makes it easier to keep things in relevant topics now.
Thank you, it will do. My concern for an official release was actually due to the fact that (at least I had thought) you'd mentioned that the foo_dynfil wouldn't have its own thread until it was out of beta. Now it has its own thread, I'm unconcerned about foo_dynfil's release status.
EDIT: Yirkha, a favour. Would you mind creating some kind of release section for the first post (as per here (http://www.hydrogenaudio.org/forums/index.php?showtopic=81002&view=findpost&p=705720)). That way people (i.e. me) who link to it don't have to change their links for each release.
EDIT2: Yirkha, can you give an example of how the new per-field aggregation functions can be used. I've tried a few things but everything gives the same result as selecting "None", so I guess I'm not getting something.
By the way, from my brief test, everything is working fine.
Thanks again,
C.
I'm having the problem that one of my tags doesn't update properly, here is the code:
I put it in the tag %_dynamic_rating_10% and made an album list view from it. When I start foobar it is rating all tracks I have with either 1 or n/a, but when I force an update it works properly.
Post your question here (http://www.hydrogenaudio.org/forums/index.php?showtopic=83954) and I'll try to help, but please outline what you are trying to achieve; ps. I'm confused by the purpose of:
tag %_dynamic_rating_10%
C.
Yirkha, I'm intrigued by the (now resolved) issue raised by sollniss. Here's the scenario:
2 fields in foo_dynfil, one references the other, for example:
%_a% = the DAR code
%_b% = a number between 1 and 10 generated by referencing %_a% *
%_b% is then used as a filter in the Library > Album List viewer.
The solution, in this case, is that %_b% doesn't need to be a dynamic field, but if it did then should this cause problems?
The reason I ask is because I can't understand why sollniss' "misuse" of foo_dynfil didn't work, when there was nothing wrong with sollniss' code. Here's the solution that did work, for some context:
http://www.hydrogenaudio.org/forums/index....st&p=744368 (http://www.hydrogenaudio.org/forums/index.php?showtopic=83954&view=findpost&p=744368)
Just thought I'd bring it to your attention should you expect foo_dynfil to work differently in such cases.
C.
*EDIT: minor edit for clarity
I am just wondering if it is possible for foo_dynfil to fork the calculation works on a separate thread.
The reason behide that is that when the track playback hits the 1 minute mark, the new rating reprocessing work would freezes up foobar completely. The GUI stops working and visualization would freezes up aswell. My foobar freezes up for about 10-20 seconds, since I have a pretty huge media library.
Yirkha, can you give an example of how the new per-field aggregation functions can be used. I've tried a few things but everything gives the same result as selecting "None", so I guess I'm not getting something.
It determines how the dynamic fields of a multiple selection of tracks are shown in the selection info viewer (Dui) - don't know if that also works in correspondending panel in Cui.
It determines how the dynamic fields of a multiple selection of tracks are shown in the selection info viewer (Dui) - don't know if that also works in correspondending panel in Cui.
Thanks. That makes sense. Shows up for me in the properties dialog (properties tab) in CUI.
C.
Would you mind creating some kind of release section for the first post? That way people (i.e. me) who link to it don't have to change their links for each release.
Not now during lifetime of this thread and beta cycle.
I'm intrigued by the (now resolved) issue raised by sollniss. (...) Just thought I'd bring it to your attention should you expect foo_dynfil to work differently in such cases.
A
dynamic field used in the title formatting definition of a
dynamic field (the same one or another one) returns the previous value of that field, i.e. the one from the previous recalculation.
I am just wondering if it is possible for foo_dynfil to fork the calculation works on a separate thread.
The reason behide that is that when the track playback hits the 1 minute mark, the new rating reprocessing work would freezes up foobar completely. The GUI stops working and visualization would freezes up aswell. My foobar freezes up for about 10-20 seconds, since I have a pretty huge media library.
The calculation has always been done in a separate, low priority thread. The UI (main) thread is blocked only during dispatch of the "track(s) have changed" notification. But when a single track is updated by Playback Statistics, a notification for only one track is sent as well, so that should not take a long time either. Unless you have some UI library viewer refreshing itself completely even when just one track has changed or something, I don't know.
Do you people think [font= "Courier New"]$date_diff()[/font] should be changed so that time is not compared at all? That would make [font= "Courier New"]$date_diff(%last_played%)[/font] work as some people expect with regard to "yesterday" soon after midnight etc.
I'm a bit inclined to do so, because you can always get the current behavior simply by [font= "Courier New"]$div($time_diff(%last_played%),86400)[/font], but emulating it the other way is more messy, e.g. [font= "Courier New"]$date_diff($cut(%last_played,10),$cut(%now%,10))[/font].
Does this mean, that if %added% is at 11:59pm then after a minute it will have been considered to have been in the collection for 1 day? i.e. $date_diff(%added%) = 1.
If so, I'm against the idea.
C.
EDIT: That said, it's not a big deal for me. In regard to "time" the smallest unit I work with is days.
I am just wondering if it is possible for foo_dynfil to fork the calculation works on a separate thread.
The reason behide that is that when the track playback hits the 1 minute mark, the new rating reprocessing work would freezes up foobar completely. The GUI stops working and visualization would freezes up aswell. My foobar freezes up for about 10-20 seconds, since I have a pretty huge media library.
The calculation has always been done in a separate, low priority thread. The UI (main) thread is blocked only during dispatch of the "track(s) have changed" notification. But when a single track is updated by Playback Statistics, a notification for only one track is sent as well, so that should not take a long time either. Unless you have some UI library viewer refreshing itself completely even when just one track has changed or something, I don't know.
Just did some trial and error tests on what is casuing the problem, it turns out it was the foo_uie_albumlist.dll component that was hanging up the main thread when the metadata changes. My apology for not getting it right the first place.
A crazy idea.
Is it possible to add a playlist column to the individual playlist?
E.G. for the top rated tracks playlist it would be nice to have dynamic rating displayed.
For recently added I would try to hack a social network like date comparison e.g. (about 7 days etc....)
Yirkha, there seems to be a bug.
I'm using the latest version of foo_dynfil on WinXP SP2.
It only happens when the recalculation interval is set (normally i have it at never, i.e. at startup only). It's the scenario that was highlighted in this post (http://www.hydrogenaudio.org/forums/index.php?showtopic=86853&view=findpost&p=744440).
So we have 2 dynamic fields (DF):
DF1: DAR code: %_dynamic_rating% (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=83954&view=findpost&p=724734)
DF2: Hotness: %_hotness% (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=87111&view=findpost&p=747286) (which takes one of its values from the DAR code).
All is well on startup. However when recalculation is set to say 5 mins (or any interval) DF2 is calculated wrongly.
For example, in this picture (http://www.giantpygmy.net/stuff/hotness/last_played_with_hotness.png) - see the track with DAR=10347, it has a hotness value of 0. When recalculated that hotness value went to 62, yet nothing had changed (the track had not been played, and if anything the hotness would have gone down if this was to do with time passing).
I'll run some tests with simpler code to replicate this when I have time. But there's definitely something up.
C.
EDIT: Here's the before and after calculation stats from the properties panel:
AFTER STARTUP CALCULATIONS ARE DONE:
age : 812
dar_pc_penalty : 5
dynamic_rating : 10347
hotness : 0
lp_display : 83
skip_recent : 0
Played : 41 times
First played : 2008-12-17 02:45:35
Last played : 2010-12-14 00:12:08
Added : 2008-12-15 02:45:35
AFTER FIRST RE-CALCULATION
age : 812
dar_pc_penalty : 5
dynamic_rating : 10347
hotness : 62
lp_display : 83
skip_recent : 0
Played : 41 times
First played : 2008-12-17 02:45:35
Last played : 2010-12-14 00:12:08
Added : 2008-12-15 02:45:35
A dynamic field used in the title formatting definition of a dynamic field (the same one or another one) returns the previous value of that field, i.e. the one from the previous recalculation.
How does that explain the data above? i.e. Hotness (given the data supplied to it) simply cannot be 62.
C.
When I took DF2, replaced some values with fixed data from your example like this
$puts(lp,2010-12-14 00:12:08)
$puts(fp,2008-12-17 02:45:35)
$puts(pc,41)
$puts(rating,$get(darind3))
$puts(avgrating,2)
and also replaced %_dynamic_rating% with '' (i.e. as if there was no value), the output was 0.
Then, if I replaced %_dynamic_rating% with 10347 instead, the output was 60.
It seems to correspond with your observations.
Yes, I've just run the details of that track through my hotness spreadsheet and (if the darind3 variable is 4, I get 62). So what that means is, when you have a DF1 to DF2 situation the initial DF2 calculation will be wrong (i.e. not correctly reflect the data) and it will only get corrected on recalculation.
Is this intended?
C.
EDIT: If it is impossible to get around, I'd like to suggest an option / setting whereby foo_dynfil runs a re-calc immediately after the initial startup calc, to correct for such DF1 - DF2 situations, so one can safely set the recalc interval to never (knowing that foo_dynfil readings won't be incorrect for the whole foobar2000 instance), thus avoiding situations where the user has to wait 5 mins, 1 hour or whatever the recalc interval is before foo_dynfil readings are correct.
I got another problem. This time it's regarding the Autoplaylist binding of the track and the problem is quite simple:
My Autoplaylist looks like this:
%_hotness% GREATER 0
$sub(99999,%_hotness%)
When I listen to a track and that track jumps to first position while still listening to it the next song would be the 2nd highest rating, this again jumps to 1st place and the track after that is played.
Now I get to listen the same two songs over and over again.
I think this can be solved by just updating the tags after the songs has finished, can't it?
I just noticed that it works correctly with the EsPlaylist.
Sorry for double post, but I couldn't edit.
• New: Per-field aggregation functions (none, group, sum, min/avg/max).
I've just noticed (hack yeah! after almost a year (-; )
Anyhoo -- would it be possible to add an option to calculate dynamic field within a group for files matching certain patter (yes, this would be for an 'album rating')?
Super ultra bump power! To +1 Wojtek's suggestion of having aggregation function for album rating stuff! Unless I misunderstand how Aggregation fields work, I don't think it works for that. It'd be great for group calculations (make sure it's possible to define the field--I use %directory% for example)
EDIT: Is there maybe another thread for this that I missed? Sorry
^i don't think you'll have much joy. Yirkha hasn't posted here for a very long time.
hi.
good effort.
but would it be possible to add the abitliy to use dynamic variables in file operations in the Destination folder name and File name pattern definitions?
as it is now the variables are not accessible there.
I followed the guide at https://tilde.town/~resir014/etc/fb2k and the %_dynamic_rating% tag seems to be broken, as can be seen at https://files.catbox.moe/ai7o4e.png . Could it be related to me using foobar via wine?
The image you posted looks like the Rating Column has something like:
%play_count% || %_dynamic_rating%
If playcount = 0, then DAR Rating will output "-----".
Did you do the bit where he states:
"Now, click on the Scripts tag, and paste the following into the textfield on the “Display” tab."
https://resir014.github.io/etc/fb2k/
To get the "indexed" rating dots (rather than a number) you need to enter the following code into Columns > Scripts (Tab) > Display (Tab)
$puts(maxdar,10000)
$puts(mindar,5000)
$puts(maxsub,$sub($get(maxdar),0))
$puts(r3,$ifgreater(%_dynamic_rating%,$get(maxsub),$get(maxsub),%_dynamic_rating%))
$puts(r4,$ifgreater($get(r3),0,$get(r3),1))
$puts(minmax,$sub($get(maxdar),$get(mindar)))
$puts(darind1,$sub($get(r4),$get(mindar)))
$puts(darind2,$div($mul($get(darind1),10),$get(minmax)))
$puts(darind3,$ifgreater($get(darind2),1,$get(darind2),1))
$puts(display,$rgb(100,100,100)$repeat($char(9679),$get(darind3))$rgb(220,220,220)$repeat($char(9679),$sub(10,$get(darind3))))
$puts(notplayed,$rgb(200,200,200)- n/a -)
$ifgreater(%_dynamic_rating%,0,$get(display),$get(notplayed))
The official guide for DAR setup is here:
http://www.giantpygmy.net/gpa/data/uploads/files/dada_autorating_dar_latest_version.txt
And the HA thread for DAR is here:
https://hydrogenaud.io/index.php/topic,83954.0.html
C.
Hi everybody. I have a custom %listened on% field, and a $date_diff(%listened on%)) function that gives me a number of days (e.g. 429). That works.
Is there a function or an existing titleformat code that would transform that number of days into a more friendly 00y 00m 00d format ?
e.g. if %listened on% == 2017-10-01, then when compared to today's date (2018-12-04) the output would be
01y 02m 03d ...
Also,
@Yirkha , is foo_dynfil v1 beta 4 still the latest release ? Thanks.
I doubt Yirkha is going to respond to you anytime soon.
Hi everybody. I have a custom %listened on% field, and a $date_diff(%listened on%)) function that gives me a number of days (e.g. 429). That works.
Is there a function or an existing titleformat code that would transform that number of days into a more friendly 00y 00m 00d format ?
e.g. if %listened on% == 2017-10-01, then when compared to today's date (2018-12-04) the output would be 01y 02m 03d ...
Can anybody help me with this part which was of course the essential ? Thanks.
I will need this or something with the same functionality if I am to ever move to 64 bit. Does anyone have the source code?
(I'm not in a hurry, I can be patient— I'm just concerned that 32 bit support might end someday.)
I use it with foo_skip to make a column which uses a formula to tell me if a track will be skipped or not by foo_skip, and at this point it is vital to the way I use foobar2000.