HydrogenAudio

It's been awhile since I've churned out some nonsense so here we go...

This is a cheap clone of foo_playcount with some differences but lets get the common stuff out of the way first...

Plays are tracked in exactly the same way as foo_playcount does it. One minute of playback or when the track ends if less a minute long. Records are remembered for 4 weeks if a track is not part of the media library/loaded playlist.

Now for the differences....

First of all, database records are bound to %path%|%subsong%

But that is not fixed. You can edit it to anything you like in the advanced preferences. Changing this value demands an immediate restart and any previously saved data is gone forever. You have been warned!!

What else is different?

While first played/last played/added are done automatically, you can modify the value(s) for any selection from the context menu in YYYY-MM-DD HH:MM:SS format. You can fake playcounts as well. I don't care. Ratings go up to 10 and there is a field for loved tracks.

These title format fields can be used in any panel/playlist/search

%2003_added%
%2003_first_played%
%2003_last_played%
%2003_playcount%
%2003_loved% (1 or blank)
%2003_rating% (up to 10 via the context menu)

There are no warnings/errors for entering gibberish values via the context menu. It just ignores you.

If you want to import foo_playcount data, do that from the Library menu>Playcount 2003>Import foo_playcount.

Known issue: statistics do not survive copies/moves when using the default %path%|%subsong% pattern. I'm not really sure how to handle that. If using tags, it should survive tag updates.

Would it be possible to also add a %2003_time% variable that contains current system time in a format like "2024-02-13 14:29:59" ?
Precision in seconds would be good enough.

0.1-Beta.2

Fixes an issue where no feedback was provided after a foo_playcount import.

The supported field list has been updated:

Full date/time strings

%2003_now%
%2003_added%
%2003_first_played%
%2003_last_played%

Unix time stamps (number of seconds since 1st January 1970)

%2003_now_ts%
%2003_added_ts%
%2003_first_played_ts%
%2003_last_played_ts%

Numbers

%2003_playcount%
%2003_loved%
%2003_rating%

Great!

Found some time to test and the real-time variables work perfectly and the variables are both availalble in PSS and ELP. As a side note I would have been able to use these realtime variables to fix the remaining de-minimize issue I had with foo_vis_spectrum_analyzer, since %2003_now% / %2003_now_ts% would allow me to detect that fooBar returned from having been minimized and issue a screen repaint from PSS.

One of the main issues I have is the fact there is no way (as far as I know of) to communicate between CUI PSS splitters and ELP (or the other way around). Globals from PSS are not accessible in ELP, and globals (field definitions) in ELP are not accessible in PSS.

Would it be possible to add a function in this or a derivative plugin that allows me to send a name and value (from PSS or ELP) that are published/updated and thus available in both PSS and ELP in a similar way that %2003_now% is available in both PSS/ELP ?

Nope to the above.

0.1-Beta.3 adds file import/export options to the Library menu>Playcount 2003.

Any possibility to add the %played_times% counterparts, like foo_enhanced_playcount? Having all in a single plugin would be great (also the possibility to fake listens, thus being able to import them from Spotify or ListenBrainz)

It's something to think about. I was trying to keep this simple.

I think an array of timestamps isn't really compatible with the free form editing currently provided so I'm thinking a simple/advanced checkbox. Switching modes would cause immediate data loss like changing the title format pattern does now.

The current way of doing things would be the "simple" mode. No data loss for existing users.

Switching to "advanced" would mean no editing via the context menu. The playcount would be the timestamp array length and the first played/last played would be extracted from the highest/lowest values. With the loss of context menu editing does come the possibility of importing JSON arrays via file. I'll give it some thought.

edit: one other thing: I know foo_enhanced_playcount provides an array of full date/time strings. I fail to see the point of that. It's useless to title formatters within fb2k so i'd keep it minimal and provide timestamps only. Only javascripters can make use of it.

It think only timestamps is good enough, since the dates can be easily converted in JS anyway, so I don't see it as a loss.
Having the possibility to get all timestamps for JS and single first/last value for TF is perfect.

Btw, some services, like ListenBrainz, allow to also "hate" a track. In my case I use a %FEEDBACK% tag which can be -1 (hate), 0|null (unset) or 1 (loved). Maybe you also want to consider that, instead of a single loved tag or multiple tags

$select($add(%FEEDBACK%,2),X,,❤)

In CUI:

$puts(t,$select($add(%FEEDBACK%,2),$rgb(0,0,0),,$rgb(255,34,34)))
$set_style(text,$get(t),$get(t))

I appreciate having the time since last playback and current time stuff in Title Formatting, but you knew that already. Thanks again!

It think only timestamps is good enough, since the dates can be easily converted in JS anyway, so I don't see it as a loss.
Having the possibility to get all timestamps for JS and single first/last value for TF is perfect.

I don't have a release ready just yet but the changelog details it some more.

https://jscript-panel.github.io/other/playcount2003/

Also, a command line JSON file importer has been added.

Any plan to add the title formatting similar to the $jsp3_since function?

$jsp3_since is exclusive to the title format functions in that component. It's not possible to make them globally available.

I suppose another %2003_something% field could yield the same result if I hardcoded the input to just last played. I'll think about it.

$jsp3_since is exclusive to the title format functions in that component. It's not possible to make them globally available.

I suppose another %2003_something% field could yield the same result if I hardcoded the input to just last played. I'll think about it.

About this, I was thinking of another thing currently only available scripting. Since a global TF is not allowed, would a %2003_plays_year% be possible?
i.e. total num of plays only this year (not as a period, but just the current year). Or the previous one.

Obviously it would be interesting to be able to do that via TF for any year, but just for the current or previous year would be interesting. Since that allows to easily create an autoplaylist of your most played tracks this year without requiring JS (I know I already coded scripts for that but sure some people would prefer to use plain TF).

Something like this, which would output the top tracks from 2023:

%2003_plays_prev_year% GREATER 10 AND %2003_rating% GREATER 5 SORTED DESCENDING BY %2003_plays_prev_year%

I think this and the other things you have already added complete the most basic stats for foobar2000 compared to other players regarding playback history.

Obviously it would be interesting to be able to do that via TF for any year

That bit is impossible. You'd need a $function that takes parameters and I can't make those global as mentioned above.

%2003_playcount_this_year% and %2003_playcount_last_year% are absolutely doable but I do wonder about the performance implications of iterating over the array on every track. My collection is too small and I have no dummy data to test so if I implement it, you'll have to suck it and see. But if you're already doing it in JS with enhanced playcount data, I guess this can't be any slower.

Retrieving all playcounts within an specific year for 80k tracks takes 7 secs. (1 less if I discard the last.fm plays, which you don't have)
Filtering that handleList first with a query like '%LAST_PLAYED% SINCE 2023', reduces time to 600 ms.

EDIT: not claiming anyway that's the fastest implementation, sure it can be optimized more.

I've got it working but no docs yet. That's the bit I hate the most.

0.1-Beta.4

If the readme is too much, just avoid.  :D

https://jscript-panel.github.io/other/playcount2003/

So I had a quick play with foo_enhanced_playcount earlier and used it to download some plays from my last.fm account. Scripters can parse that data and dump it a JSON file so it can imported in to this component.

I knocked this up for JSP3...

var tfo_id = fb.TitleFormat("%path%|%subsong%");
var tfo_lastfm = fb.TitleFormat("%lastfm_played_times_js%");

var items = plman.GetPlaylistItems(plman.ActivePlaylist);

var dump = [];
for (var i = 0; i < items.Count; i++) {
	var item = items.GetItem(i); // GetItem is JSP3 only, SMP uses items[i]
	
	var arr = JSON.parse(tfo_lastfm.EvalWithMetadb(item)).map(function (item) {
		// foo_enhanced_playcount uses JS timestamps with millisecond accuracy, we don't want that
		return item / 1000;
	});
	
	var obj = {
		"id" : tfo_id.EvalWithMetadb(item),
		"2003_plays" : arr,
	};

	dump.push(obj);
}

var str = JSON.stringify(dump);
// can't remember if SMP writes BOM by default or not?????? It has to be disabled. JSP3 does not write BOM at all
utils.WriteTextFile("z:\\dump.json", str); 

0.1-Beta.5

https://jscript-panel.github.io/other/playcount2003/

This enforces some stricter validation on user imported values. Shouldn't be an issue with genuine data as described in the readme. But supplying timestamps that exceeded the max allowed value may have ended up as garbage dates. Now they should be silently ignored.

0.1-Beta.6

Statistics can now survive moves/copies using the default %path%|%subsong% pattern.

Caveats:
- files must be moved/copied with file operations. Doing it manually or via any other means will not be tracked

- cuesheets/other tracks with multiple chapters are not supported. I only get a path from the SDK file operation callback and I'm assuming a subsong index of zero for every one. I'm not capable of the sort of hacks that would be necessary to determine how many subsongs a given path has.

As I keep mentioning, tag based patterns should be fine if you want to change it in the Preferences.

https://jscript-panel.github.io/other/playcount2003/

0.1-Beta.7 fixes the stupidest bug with the foo_playcount importer. Apologies for being a buffoon.

https://jscript-panel.github.io/other/playcount2003/

Thanks for the update. I was about to report why the foo_playcount import part doesn't work on my end. With the latest update update, it's working as expected.

Request, can the HH:MM:SS section of the %..._ago% fields be truncated/removed?

Another request, how can I make the exported JSON from Last.fm Playcount Sync compatible with this playcount2003?
Since, in my case, the lfm has more completed entries than foo_playcount. Perhaps I could just sync it with masstagger.
I understand that this question may appear unusual considering that the component is no longer supported, thus it is understandable if it is not possible.

Use title formatting to display up to d - that strips away the HH:MM:SS

$substr(%2003_added_ago%,0,$strstr(%2003_added_ago%,d))

As for the last.fm JSON, you can't do anything with it. I'll knock up a bit javascript that can do it later on.

Thanks for the response and the code snippets!

So rather than mess around with scripting nonsense, I'm adding a custom edit dialog/importer from other tags/components. You'll be able use %lfm_playcount% etc here...

(https://i.imgur.com/DTn4QcY.png)

0.1-Beta.8 implements the new edit dialog with title format support.

https://jscript-panel.github.io/other/playcount2003/

I'm calling this 0.1 final.

https://jscript-panel.github.io/other/playcount2003/

- Remove `foo_playcount` importer from main `Library` menu.
- The `Edit` dialog for context menu selections now has built in `Presets`.

(https://jscript-panel.github.io/other/images/playcount-2003-presets.gif)

- Implement drop down history on the `Edit` dialog text boxes. Only title format patterns are remembered. Other plain text entry is not.
- Add support for importing `JSON` files with `UTF8-BOM`.

General incompetence strikes again. 0.1.1 fixes a bug where the context menu items for marking selections as loved/unloved didn't work. This happened during the edit dialog rewrite and I wasn't paying enough attention. :/

https://jscript-panel.github.io/other/playcount2003/

0.1.2 is just very minor file import tweaks for people modifying their own values which I doubt many are.

New download location: https://github.com/marc2k3/foo_playcount_2003/releases
New readme page: https://marc2k3.github.io/foo_playcount_2003/

Hi there again Marc, regarding the %2003_last_played_ago% is there any plan to introduce month(m) and year(y) value instead of overly used week(wk)? just like in $jsp3_since.

Also another title formatting help question, with the last update the code "$substr(%2003_added_ago%,0,$strstr(%2003_added_ago%,d))" will return empty since there is no days(d) in string, since it will return just HH:MM:SS, is it possible to just make it return as "Today" string? Thanks.

Btw, there is small typo in the docs %2003_last_played_ago%`

---
Regarding the import feature, thanks for adding the presets for foo_lastfm_playcount_sync. However, it seems it had to be done manually. Can it be done in batch just like the previously import from foo_playcount in Library menu? Also a console log for the process would be nice.

Thank you.

For display in JSP3, you can use $jsp3_since with these fields. Instead of using %2003_last_played_ago%, use

$replace($jsp3_since(%2003_last_played%),0d,Today)

I'll look at providing more feedback on edits.

0.1.3 now reports how edits were handled in the Console. Also, the file importer stats are more accurate now.

Docs:
https://marc2k3.github.io/foo_playcount_2003/

Download:
https://github.com/marc2k3/foo_playcount_2003/releases

Thanks for the update.
Regarding the last_played title formatting, I think i got it, here's my noob attempt.

$puts(lp,%2003_last_played_ago%)$puts(week,$replace($substr($get(lp),0,$strstr($get(lp), )),wk,))
$if($get(lp),$ifgreater($get(week),52,$div($get(week),52) years ago,$iflonger($get(lp),8,$substr($get(lp),0,$strstr($get(lp),d)),Today)),)

(https://i.imgur.com/Df7Ja9e.jpeg)

I might consider a %2003_last_played_ago2% which does the year/month thing. The current week/days/time code comes from me being really lazy using a one-liner from the fb2k SDK.

https://marc2k3.github.io/foo_playcount_2003/
https://github.com/marc2k3/foo_playcount_2003/releases

So 0.1.4 adds these new fields...

%2003_added_ago2%
%2003_first_played_ago2%
%2003_last_played_ago2%

Demo:
(https://marc2k3.github.io/foo_playcount_2003/images/playcount-2003-text-display.png)

Full code:

$font(Cascadia Mono,24,700)
Added: %2003_added%
$crlf()
Added ago: %2003_added_ago%
$crlf()
Added ago2: %2003_added_ago2%
$crlf()
$crlf()
First: %2003_first_played%
$crlf()
First ago: %2003_first_played_ago%
$crlf()
First ago2: %2003_first_played_ago2% 
$crlf()
$crlf()
Last: %2003_last_played%
$crlf()
Last ago: %2003_last_played_ago%
$crlf()
Last ago2: %2003_last_played_ago2%
$crlf()
$crlf()
Plays: %2003_playcount%
$crlf()
Loved: %2003_loved%
$crlf()
Rating: %2003_rating%

That font function is only supported in JSP3 Text Display. It can be removed for displaying in ye olde foo_textdisplay / CUI item details.

Thank you very much for the update, it looks wonderful!

Since it's just gone midnight where I am, I forgot to mention is has accurate today/yesterday handling for times just before/after like this...

(https://i.imgur.com/ZHRRVtW.png)

0.1.5

Docs:
https://marc2k3.github.io/foo_playcount_2003/

Changes:
https://marc2k3.github.io/foo_playcount_2003/#015

Download:
https://github.com/marc2k3/foo_playcount_2003/releases

0.1.6
Update Edit dialog with Rating field. Although setting the Rating via the context menu was always possible, it wasn't possible to import ratings from foo_playcount. This change allows that.

Docs:
https://marc2k3.github.io/foo_playcount_2003/

Download:
https://github.com/marc2k3/foo_playcount_2003/releases

0.1.7
This works around a horrible bug that prevented library viewers from updating themselves on startup. Apologies to anyone affected.

Docs:
https://marc2k3.github.io/foo_playcount_2003/

Download:
https://github.com/marc2k3/foo_playcount_2003/releases

That was quick! Thank you. Everything is working properly with the Album List Panel again.

0.18

The Edit dialog now supports dates in YYYY-MM-DD format. The time will be set to 00:00:00 automatically. Probably more useful for editing the added time and not first played/last played. :P

Docs:
https://marc2k3.github.io/foo_playcount_2003/

Download:
https://github.com/marc2k3/foo_playcount_2003/releases

It's mentioned that immediate data loss will occur both in the readme and here. Can you expand a bit on that? I'm not installing anything that has the potential to wipe out all my playback statistics; it's bad enough when fb2k crashes and takes the current session's with it.

Does this continue to update both the built-in stats and its own? (As far as I can tell, it has its own database too.) How does it work with regular existing tag names? Is it possible to make changes less ruinous by attempting to map old entries to the new pattern?

The readme says it all really..

It's important that settings are decided on before starting as any change causes immediate data loss. foobar2000 will prompt you to restart when changing any setting.

Title format pattern

This is how database records are bound to your tracks. The default of %path%|%subsong% does mean every track will have unique data.

Note

As of 0.1-Beta.6, statistics can survive files being moved or copied when using file operations. Cuesheets/other tracks with multiple chapters are not supported. If that is not acceptable, you should change it to a pattern that makes use of tags instead. You might consider a pattern like

%album artist%|%album%|%date%|%discnumber%|%tracknumber%|%title%

When you pick a pattern, you need to stick with it. That is all.

And data loss occurs when you change from the default simple mode to advanced mode. Pretty much no one needs advanced mode. This logs the date/time of each individual play and the only way you can make use of this info is by extracting it with scripting components like JScript Panel/Spider Monkey Panel. This is going to be beyond most people so most should ignore it and stick with simple mode.

And it obviously only manages its own data. It can't modify the data of anything else. Data can be imported from foo_playcount via the Edit dialog.

Other than a description here...

https://wiki.hydrogenaud.io/index.php?title=Foobar2000:Components/Playback_Statistics_v3.x_(foo_playcount)

Playback statistics are now pinned to a combination of artist + album + disc number + track number + track title information, contrary to pre-3.0 versions which would pin data to file paths.

...no one knows the exact pattern foo_playcount used internally but the example I posted as an alternative to using the path/subsong should be close enough.

This logs the date/time of each individual play and the only way you can make use of this info is by extracting it with scripting components like JScript Panel/Spider Monkey Panel. This is going to be beyond most people...

To add more details about this, in fact anyone could make use of it if timestamps were also provided as dates (since the tag is a string and can be used via TF). Or if TF support was extended with a date<->Unix timestamp function (but that's a foobar2000 native thing).

Then:

"$strstr(%2003_timestamps_date%,YYYY-MM-DD)" GREATER 0

It could also be tweaked to find tracks played on an specific year, month, etc.

I suppose exposing it as a multivalue tag would also work.

2003_timestamps_date HAS YYYY-MM-DD

Note the first example works fine on the original enhanced playcount:
Spoiler (click to show/hide)So JSP/SMP is not an strict requisite to use it (if dates are exposed too).

I suppose exposing it as a multivalue tag would also work.

Nope, this is technically impossible. It's a single string per field per track.

(if dates are exposed too).

They are not. Converting potentially dozens/hundreds of timestamps->strings on the fly per track does not sit right with me. If foo_enhanced_playcount does it without slowing down, great. But I'm not going anywhere near that functionality.

No idea how it's done, works perfectly fine on real time and pretty fast. For 90K tracks:

[15:57:43] Search took 0:00.279563
[15:57:43] Search sorting took 0:00.022913

But it's fine if you are not interested, was just adding my experience because it has an utility on queries.