- Sometime in the last few years, the timestamp Last.fm returns from it's API went from being exactly 60s behind the timestamp Foobar uses to mark a play, to 61s behind (I'm not sure if this is a FB or last.fm problem). I've been manually adding 60s to last.fm timestamps so that %LASTFM_PLAYED_TIMES%/%LASTFM_LAST_PLAYED%/etc. matches up with the timestamps foobar reports for %last_played%, etc. Changed this to do +61s and now they match up again.
- A user had some kind of weird metadb corruption where certain plays were missing from foo_playcount and some were missing from foo_playcount_enhanced. We can't completely recover all lost plays, but we can check to see if first_played/last_played are in the list of plays this component has recorded, and if they aren't we add them back in. This likely only affects users on v1.x

• 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

4.3.3
- %added_enhanced% now returns "N/A" when a file is not in the media library, the same as foo_playcount
4.3.2
- In some situations (probably only if foo_playcount was not installed), the various %played_times%/%played_times_js% functions could have a foobar timestamp 0 as the first entry. This would get returned to the caller as a date around the year 65000. No longer saving timestamps with value 0, and no longer returning any 0 values either.