• %played_times% - Date formatted list: ["2012-08-04 15:58:37", "2012-12-10 14:40:46", "2018-01-02 23:38:13"]
• %played_times_js% - JS timestamp list: [1344117517000, 1355172047000, 1514957893431]
• %played_times_raw% - raw foobar timestamps: [129885911170000000, 129996456470000000, 131594314934316754]
• %lastfm_played_times% - Date formatted list of scrobbles: ["2012-08-04 15:58:37", "2012-12-10 14:40:46", "2018-01-02 23:38:13"]
• %lastfm_played_times_js% - JS timestamp list: [1344117517000, 1355172047000, 1514957893000]
• %lastfm_play_count% - Count of last.fm plays, a la %play_count%: 5
• %lastfm_added% - Single date: "2012-08-04 15:58:37"
• %lastfm_first_played% - Always exactly the same as %lastfm_added%. Use whichever one makes most sense logically
• %lastfm_last_played% - Single date: "2018-04-04 15:58:37"
• %added_enhanced% - Single date, earliest value of either %added% or %lastfm_added%
• %first_played_enhanced% - Single date, earliest value of either %first_played% or %lastfm_first_played%
• %last_played_enhanced% - Single date, latest value of either %last_played% or %lastfm_last_played%

var raw = fb.TitleFormat('[%played_times_js%]').Eval();
var playedTimes = [];
try {
	playedTimes = JSON.parse(raw);	// this is required because the value is a string
} catch (e) {
	fb.trace('<<< ERROR parsing JSON >>>');  // you probably don't need this try/catch, but it was helpful in my debugging
}
for (i=0; i < playedTimes.length; i++) {
	var p = new Date(playedTimes[i]);
	// do something with this value
}

$max(%play_count%,%lastfm_play_count%)

var added = fb.TitleFormat('%added%').Eval().replace(' ','T');

• x64 support
• Dark mode
• Historical scrobble dates now accurate and resetting them now displays current date
• When going through your recent plays to pull scrobbles now deduping those calls before querying Last.fm to avoid duplicated (and confusing) console spam
• Component is now referred to everywhere in the UI as "Playback Statistics Enhanced", instead of confusingly sometimes calling itself "Playcount Enhanced"
• Updated SDK
• Cleaned up and refactored a bunch of code to make things easier to maintain

• No longer escaping usernames.
• Reporting last.fm errors in the console.

• Rebuilt component with released 1.4 SDK which cut file size by 50%

• Fixed a bug where if last.fm scrobbling is disabled, or a track has first/last_played values but no scrobbles were found for it in last.fm, then foobar's first and last played times were not being saved to the database.

• Relaxed last.fm string matching. Before "Test: This", "Test - This", "Test/This" all would be seen as different, now they'd all be considered matches.
• last.fm string matching still ignores all punctuation other than &,(, and ), but if the song title only contains spaces and punctuation, then an exact match is done. This fixed a problem I had with an album which only contained songs with punctuation for song titles.
• If retrieving last.fm scrobbles is unchecked in the config, or the username has not been set, the right-click option to retrieve scrobbles is disabled.

• When no lastfm plays recorded by the component, [%lastfm_playcount%] now shows a blank value instead of 0 meaning it operates identical to [%playcount%] - Thanks to @annalise for reporting
• Fixed a bad regression where changing file tags would cause all plays and scrobbles of that song to be lost. This allowed me to clean up some code and ensure this can't happen again as there's now a single code path for generating hash strings

• Added three new properties: %added_enhanced%, %first_played_enhanced%, and %last_played_enhanced%. These will return the earlist/latest value between the values foo_playcount stores and what this component stores. I.e. %last_played_enhanced% will equal the latest value between %last_played% and %lastfm_last_played%. If you haven't pulled scobbles for a song (or it had no scrobbles) %last_played% will be returned.
• All last.fm calls made in separate thread
• Scrobbles retrieved when a song starts playing
• Matching song/album titles to last.fm scrobbles is now case-insensitive even with special characters (i.e. É and é are considered the same). All punctuation is also ignored except for "&", "(", and ")"
• Files now pinned to the following hash string, lowercased: "%artist% - $year($if2(%date%,%original release date%)) - %album% $if2(%discnumber%,1)-%tracknumber% %title%". This means you can change capitalization with foobar closed, and your hashes won't get lost. This exactly mirrors the hash string that foo_playcount uses, except Peter doesn't toss in a $year() around %date%
• Due to new hash string, old database will be migrated to new format so no plays get lost or need to be repulled.

• Retrieving scrobbles by right click now happens in a separate thread so the UI is not blocked.
• Removed restrictions on the number of songs you can retrieve scrobbles from at once
• Max scrobbles that will be retrieved for an artist changed from 1000 to 200 * (cache_size - 1). Cache_size can be set to a max of 50 meaning all scrobbles will be retrieved for every song if it's artist has less than 9800 scrobbles.

• No longer escaping usernames with underscores in them

• Added three new properties:
  %lastfm_added%
  %lastfm_first_played%
  %lastfm_last_played%
• All return a date/time string like "2018-03-04 12:34:56" exactly the same as their counterparts from foo_playcount. If the time doesn't exist, "N/A" is returned, but $if2, or the bracket format ([%lastfm_added%]) will not display the N/A.
• %lastfm_added% and %lastfm_first_played% both return the exact same value, but I created both for convenience. If you'd like to use the most recent date between your foobar library and last.fm you can use this TF code:

Is this a limitation people are willing to live with?

Is this a limitation people are willing to live with? Does a system that works perfectly 98% of the time, but drastically overcounts plays the other 2% of the time okay? Should last.fm plays be mixed in with the standard calls, or separated from the other plays (i.e. adding a %played_times_lastfm_js% field)?

I'd say no. This would be a reason for me to avoid it completely. Most scrobbles on last.fm that are not from the user itself come from either youtube or spotify and spotify in particular is a complete mess with its tagging. The more someone uses other sources to scrobble which they didn't tag themselves the more there will be a disconnection between the "real" plays and the ones reported. What loz is saying about lastfm revamping their api in the coming months should be taken with a serious grain of salt as the site has been in beta since september 2015 and new implementations are moving on with a snail pace (and getting slower).

• %lastfm_played_times% - Date formatted list: ["2012-08-04 15:58:37", "2012-12-10 14:40:46", "2018-01-02 23:38:13"]
• %lastfm_played_times_js% - JS timestamp list: [1344117517000, 1355172047000, 1514957893431]
• %lastfm_play_count% - Count of last.fm plays, a la %play_count%: 5

• Caching currently only works at most when the song has never been scrobbled, and then again after first scrobble. Subsequent calls restrict the API call to after the last known recorded last.fm play. This means these API calls aren't cached. I need to be smarter about this. Done
• Thinking about allowing the component to use user-settable fields to match against. Something like LASTFM_ALBUM_NAME and then you could tag affected files with that field, e.g. set the value "My Album" and it would fallback to that if a match could not be made for %album%.
• Ignoring files with a LASTFM_NO_SCROBBLES meta tag because pulling scrobbles incorrectly matches other songs
• Last.fm calls ought to be done in a separate thread. This is hard and I'll probably save it for last because I'm not a C++ developer and I hate this shit.

• Updated caching system so that ALL calls to last.fm are cached, regardless of whether a song already has recorded last.fm plays
• Cached responses now expire if the cache is full and the response was the least recently used page OR this song has already read the current response page from the cache once. In the second case I immediately re-query the API, and clear the list of songs that have read from the cached response page (since it's new).
• Improved console logging. Will reduce the amount for actual release.

Hi, if I install foo_enhanced_playcount, should I remove foo_playcount, or do they coexist?

I'm a bit puzzled as to the use of %lastfm_play_count%, is this supposed to display the scrobble count of the song retrieved from last.fm? If yes, under what circumstances would that be the case because I don't seem to notice much consistency in what is shown. At what point is lastfm queried? At the start? When the song gets scrobbled?  I would expect a song that has been played and scrobbled, then restarted to display %lastfm_play_count% as 1 but it doesn't, then again if I replay a song I played and scrobbled from the day before %lastfm_play_count% shows the correct amount of plays.
I also have noticed for example a song which has 1 playcount and one scrobble starts out as 1 displayed local play count and 0 displayed %lastfm_play_count%. It gets scrobbled at the halfway point, local play count increments to 2 and then suddenly %lastfm_play_count% turns from 0 to 2.

One other question, is it retrieving the scrobble count of artist-title or artist-album-title?

Thanks for the explanation. The artist-album-title makes sense and clarifies the play count -vs scrobble discrepancies I was seeing. I was working under the assumption artist-title. It's too bad really it's not artist-title based because spotify with its louzy album naming throws a wrench into making my foobar plays and scrobbles be more in sync.

Disable album title checking would be great. The con is a non issue to me since I already lump them together anyway.