The (painfully slow) making of foo_dynfil

Topic: The (painfully slow) making of foo_dynfil (Read 60091 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

The (painfully slow) making of foo_dynfil

Reply #25 – 2010-11-09 21:12:24

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.

The (painfully slow) making of foo_dynfil

Reply #26 – 2010-11-10 15:46:24

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

The (painfully slow) making of foo_dynfil

Reply #27 – 2010-11-10 17:19:02

Awesome! I haven't managed to break it yet.

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.

The (painfully slow) making of foo_dynfil

Reply #28 – 2010-11-10 17:19:42

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.

The (painfully slow) making of foo_dynfil

Reply #29 – 2010-11-10 18:54:24

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

The (painfully slow) making of foo_dynfil

Reply #30 – 2010-11-10 19:48:48

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

The (painfully slow) making of foo_dynfil

Reply #31 – 2010-11-10 22:43:11

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.

The (painfully slow) making of foo_dynfil

Reply #32 – 2010-11-11 00:39:38

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

The (painfully slow) making of foo_dynfil

Reply #33 – 2010-11-11 01:28:30

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)

_______________________________________________________________________________________________

Quote from: carpman on 2010-11-10 18:54:24

It would be nice if there was a way to export/import your various scripts.

Export to/import from what format?

Quote from: carpman on 2010-11-10 18:54:24

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

Quote from: Purple Monkey on 2010-11-10 17:19:02

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.

The (painfully slow) making of foo_dynfil

Reply #34 – 2010-11-11 01:43:52

Wow, you've been busy!
Will try out the new version.

Quote from: Yirkha on 2010-11-11 01:28:30

Quote from: carpman on 2010-11-10 18:54:24
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.

The (painfully slow) making of foo_dynfil

Reply #35 – 2010-11-11 02:34:10

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.

The (painfully slow) making of foo_dynfil

Reply #36 – 2010-11-11 02:51:03

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)

The (painfully slow) making of foo_dynfil

Reply #37 – 2010-11-11 02:52:36

Quote from: carpman on 2010-11-11 02:34:10

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!

Quote from: carpman on 2010-11-11 02:34:10

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.

The (painfully slow) making of foo_dynfil

Reply #38 – 2010-11-11 02:58:42

Changelog:
• Fixed: One track missing in metadata change notification (autoplaylist and display update problems).

Download:
foo_dynfil v1 beta 2 (outdated link removed)

The (painfully slow) making of foo_dynfil

Reply #39 – 2010-11-11 05:16:00

Superb! Looks fixed on cursory test. Will give it a proper look over tomorrow.

C.

The (painfully slow) making of foo_dynfil

Reply #40 – 2010-11-11 16:48:59

Quote from: Yirkha on 2010-11-11 02:52:36

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?

The (painfully slow) making of foo_dynfil

Reply #41 – 2010-11-11 16:53:27

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

The (painfully slow) making of foo_dynfil

Reply #42 – 2010-11-11 17:09:28

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.

The (painfully slow) making of foo_dynfil

Reply #43 – 2010-11-11 17:23:49

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.

The (painfully slow) making of foo_dynfil

Reply #44 – 2010-11-12 06:03:56

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:

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

The (painfully slow) making of foo_dynfil

Reply #45 – 2010-11-12 12:51:15

Quote from: gurubhai on 2010-11-11 16:48:59

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.

Quote from: carpman on 2010-11-11 16:53:27

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:

Quote from: Purple Monkey on 2010-11-11 17:09:28

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

Quote from: q-stankovic on 2010-11-11 17:23:49

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.

Quote from: ???? on 2010-11-12 06:03:56

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.

The (painfully slow) making of foo_dynfil

Reply #46 – 2010-11-12 13:57:33

Quote from: Yirkha on 2010-11-12 12:51:15

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.

The (painfully slow) making of foo_dynfil

Reply #47 – 2010-11-12 23:52:00

I don't know if they're supposed to, but the dynamic fields aren't included when you export a DUI theme.

The (painfully slow) making of foo_dynfil

Reply #48 – 2010-11-13 04:41:35

Quote from: Yirkha on 2010-11-12 12:51:15

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.

The (painfully slow) making of foo_dynfil

Reply #49 – 2010-11-13 10:49:31

Quote from: Yirkha on 2010-11-12 12:51:15

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?

Notice