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: The (painfully slow) making of foo_dynfil (Read 59681 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

The (painfully slow) making of foo_dynfil

Reply #75
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.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

The (painfully slow) making of foo_dynfil

Reply #76
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.
Full-quoting makes you scroll past the same junk over and over.

The (painfully slow) making of foo_dynfil

Reply #77
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].
Full-quoting makes you scroll past the same junk over and over.

The (painfully slow) making of foo_dynfil

Reply #78
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.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

The (painfully slow) making of foo_dynfil

Reply #79
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.

The (painfully slow) making of foo_dynfil

Reply #80
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....)

The (painfully slow) making of foo_dynfil

Reply #81
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.

So we have 2 dynamic fields (DF):
DF1: DAR code: %_dynamic_rating%
DF2: Hotness: %_hotness% (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 - 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
PC = TAK + LossyWAV  ::  Portable = Opus (130)

The (painfully slow) making of foo_dynfil

Reply #82
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.
Full-quoting makes you scroll past the same junk over and over.

The (painfully slow) making of foo_dynfil

Reply #83
How does that explain the data above? i.e. Hotness (given the data supplied to it) simply cannot be 62.

C.

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

The (painfully slow) making of foo_dynfil

Reply #84
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.
Full-quoting makes you scroll past the same junk over and over.

 

The (painfully slow) making of foo_dynfil

Reply #85
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.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

The (painfully slow) making of foo_dynfil

Reply #86
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?
The very act of observing, influences what happens.

The (painfully slow) making of foo_dynfil

Reply #87
I just noticed that it works correctly with the EsPlaylist.

Sorry for double post, but I couldn't edit.
The very act of observing, influences what happens.

The (painfully slow) making of foo_dynfil

Reply #88
• 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')?

The (painfully slow) making of foo_dynfil

Reply #89
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

The (painfully slow) making of foo_dynfil

Reply #90
^i don't think you'll have much joy. Yirkha hasn't posted here for a very long time.

The (painfully slow) making of foo_dynfil

Reply #91
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.



Re: The (painfully slow) making of foo_dynfil

Reply #93
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)
Code: [Select]
$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.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

Re: The (painfully slow) making of foo_dynfil

Reply #94
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.

Re: The (painfully slow) making of foo_dynfil

Reply #95
I doubt Yirkha is going to respond to you anytime soon.

Re: The (painfully slow) making of foo_dynfil

Reply #96
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.

Re: The (painfully slow) making of foo_dynfil

Reply #97
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.
Think millionaire, but with cannons.