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: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles (Read 173862 times) previous topic - next topic
0 Members and 6 Guests are viewing this topic.

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #425 –
Quote from: MordredKLB on
Quote from: regor on
That's not what I'm asking. Foo_playcount allows to copy stats between tracks (for ex. if you renamed files using external programs, you can transfer the stats from old to new files). Problem is only rating and basic stats are copied. All that is done via context menu.
Files renamed or retagged (maybe not both at the same time though?) by external programs no longer lose their stats post FB2.0 release. That should also apply to stats from this plugin.
I know this mechanic works, but I'm a little fuzzy on Peter's implementation.
Quote
Like transferring stats between different versions of albums, libraries, etc.
Because the tags are metadata based you can transfer stats from an existing album to a different version of the same album by ensuring that %artist% %album% $year(%date%) %title% %tracknumber% are all identical. Once FB detects the change, the playcount stats will transfer over, and then you can freely rename/retag and they will stick. Not quite as convenient as copy/paste, but I use this all the time.
I know that trick, but then you are bound to tag everything within foobar, which may be totally inconvenient when you start integrating your workflow with other software and/or export your library to other devices. It's also a problem tagging singles or compilations, because you then have to tag multiple times a lot of files one by one.

Another question, would it be possible to integrate listenbrainz listens here? Like last.fm.

I'm currently facing a problem regarding playcount since there are other plugins sending listens to ListenBrainz, the same than last.fm works. But if you listen to things on other devices, then they are not synced back to foobar. Therefore the only listens available on foobar come from your component or marc's one using foobar itself.

I know I can do it via js with their API but I think it would be much more convenient to have them the same than last.fm listens. Like last.fm only a username is needed. The mapping works the same.

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #426 –
Please see this:
https://github.com/phw/foo_listenbrainz2/issues/23

Not sure which one of the 2 plugins is doing something wrong, or both (?)

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #427 –
Reply:
Quote
Interesting. foo_listenbrainz2 stores the time of playback start and uses this for submitting the listened_at time. So this should be fine.

I don't know much about enhanced play count, but looks like this is storing a later time. The 1 minute delay might indicate that it considers 1 minute time before counting it as a play.

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #428 –
@MordredKLB  have you looked at it? Can you confirm is a bug on your component?

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #429 –
Quote
The 1 minute delay might indicate that it considers 1 minute time before counting it as a play.

It is exactly like the other dev pointed out, it counts one track play after 60 sec, so it is the original behavior and not a bug.
I think the logic behind it is to prevent spamming last.fm scrobbles and also it makes sense,
because it would count track playcount right away when always starting a new track playback, i.e on double click.

-TT

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #430 –
The other dev didn't say it's not a bug, just that the problem was not on their component. I think you have misunderstood the problem completely TT.

It's a bug, since the timestamp MUST be the initial time of playback (not that time +1 min). That's has nothing to do with scrobbling or not. It's fine if the listen is only recorded if you listen to the song at least 1 min, but the listen timestamp must be the original time, not shifted by that minute (or whatever minimum you use).

Right now no timestamp from this component matches anything from Listenbrainz, even if both point to the same listen, due to this bug. i.e.

This component listen:
Code: [Select]
["2024-12-16 19:32:18"]
ListenBrainz:
Code: [Select]
["2024-12-16 19:31:18"]

The track was listened at 2024-12-16 19:31:18 (start of playback).

I'm fine deduplicating listens in some cases from different sources, but if there is a systematic error I would say it should be fixed. Also I did not bother to check if it's a 1 min shift or it's also dependent on track length (which would be a lot worse).

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #431 –
I was trying to illustrate Mordred's thought process that the foo_enhanced_playcount component registers
the track playcount only after one minute has passed by design to prevent last.fm scrobble spamming or double click on new track
playcount register.

What I was trying to say is that Mordred just designed it when playcount has been registered, which I do not count as a bug per se.
So from your standpoint the playcount should record the timestamp and subtract the -60 seconds, i.e when playback has actually
started, which of course makes perfectly sense.

But Mordred of course can give you his take as it is his component after all.

-TT

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #432 –
Well not arguing about calling it "bug" or not, but for sure it breaks compatibility with anything else, doesn't follow what other scrobble apps do or what's expected. I get your point, but as the dev of the ListennBrainz component also said, one thing is the reporting logic another the actual playback timestamp.

Adding a component-related shift to the timestamp introduces your own design decisions into the timestamp itself. If every app does that, then it's totally impossible to de-duplicate listens in a sane way. There is no way to know if a listen needs a 1 min shift, 2 mins, 50% track length (which is not necessarily known), etc.

We can all agree that the listen starts at X time or ends at X time. Anything in between is totally arbitrary and should not be used since it depends on unknown variables or the particular implementation used.

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #433 –
As suspected here lies the error:
https://github.com/kbuffington/foo_enhanced_playcount/blob/master/src/PlayedTimes.cpp#L396

Since that callback fires when at least one minute of the track has been played or the track has reached its end after at least 1/3 of it has been played through, the results are totally random. There is no way to differentiate any of the 2 cases to deduplicate things and best guess is supposing you just have to subtract 1 minute.

Time should be saved like here:
https://github.com/phw/foo_listenbrainz2/blob/main/src/play.cpp#L42

@MordredKLB Do you have a plan to fix this? Should I create a pull request?

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #434 –
Quote from: regor on
As suspected here lies the error:
https://github.com/kbuffington/foo_enhanced_playcount/blob/master/src/PlayedTimes.cpp#L396

Since that callback fires when at least one minute of the track has been played or the track has reached its end after at least 1/3 of it has been played through, the results are totally random. There is no way to differentiate any of the 2 cases to deduplicate things and best guess is supposing you just have to subtract 1 minute.

Time should be saved like here:
https://github.com/phw/foo_listenbrainz2/blob/main/src/play.cpp#L42

@MordredKLB Do you have a plan to fix this? Should I create a pull request?
I think you're misunderstanding a few things. The purpose of this component is to keep a record of all playtimes from foobar's internal records along with playtimes from last.fm (which was added later) so that you could have a combined record of all playtimes.

Since that's the goal, I wanted to try and ensure that the timestamp we record from last.fm is the same timestamp (or very close to) what we record when foobar makes a song played (i.e. the count ticks) and so it matches foo_playcount's %first_played%/%last_played% data. The code you're pointing to is the original pre-lastfm code for saving every foo_playcount time stamp. This component doesn't scrobble so changing something in the code you posted wouldn't do anything. I'm getting play times from foobar or from last.fm, not marking them myself.

When last.fm support was added, there was now a problem since last.fm timestamp's were almost always 1 minute earlier than foobar's. So to make deduping "easy" I take the value stored in last.fm and add 1 minute to it when I save the record. That code is here. The times still aren't always perfectly exact but you end up with this normally:

At one point this was spot on if you started the song and played through the first minute, but something has drifted in the intervening years (FB 2.0 maybe?). Just picking a few test files it always seems to be about 1 second difference. Oh well.

As you pointed out, this is not a perfect system. If your song is less than a minute long, the component doesn't care and still shifts the playtime by one minute so you can have the scrobble after the time FB records. Everything completely breaks down if you pause the song inside the first minute, walk away for an hour and then come back and continue it. Now FB's timestamp is from when you resumed and last.fm's is from 1 minute after the song was started. You don't even want to know the BS that ensues if you start a song before daylight savings ends, and it gets marked as played afterwards. Basically it's impossible to get perfect sync in all cases, and you're more than happy to disagree with the stopgap measure I took.

I'm not entirely sure what you're trying to do with the data regor, but it doesn't seem like a heavy lift to dedupe. For some reason you don't have a single source of truth, so the only option is to dedupe. This is not really as big a problem as you seem to think. You already can't scrobble a song with a length <30s, (therefore 5s songs on repeat aren't an issue) so stretching that to a 60s window doesn't seem like huge data loss in the multiple repeat corner case. Just convert all your timestamps to JS (this component conveniently does that for you). Sort your multiple arrays into one combined array, and then filter out anything closer than 60000ms and now you've got one single source of truth.

If I'm misunderstanding something about your situation please let me know. As it is, I don't currently have any intention to change it.

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #435 –
Quote
I think you're misunderstanding a few things. The purpose of this component is to keep a record of all playtimes from foobar's internal records along with playtimes from last.fm (which was added later) so that you could have a combined record of all playtimes.
That's ok, but the actual playtime of a song is when it starts, not shift by 1 minute or a random offset due to track length.

Quote
I'm getting play times from foobar or from last.fm, not marking them myself.
So.. the timestamp you get from foobar is wrong because the ones offered by playcount are also wrong (and you wanted to match them)? If that's the case, I would say it should be reported and asked to change.

Quote
When last.fm support was added, there was now a problem since last.fm timestamp's were almost always 1 minute earlier than foobar's. So to make deduping "easy" I take the value stored in last.fm and add 1 minute to it when I save the record. That code is here. The times still aren't always perfectly exact but you end up with this normally:
Well "the problem" is the timestamp from this component (or foobar), last.fm timestamps are not "wrong" by 1 min.

I understand how it was originated, but that "solution" has just been a patch to an inherent problem in the way timestamps were recorded to match bugged timestamps by foo_playcount. They don't match last.fm, listenbrainz nor anything out there, even if the timestamp comes from other components within foobar2000.

Quote
If I'm misunderstanding something about your situation please let me know. As it is, I don't currently have any intention to change it.
Well it has surprised me you were already aware of the problem... and just keep going with a bad design inherited by the parent software.

Quote
Basically it's impossible to get perfect sync in all cases, and you're more than happy to disagree with the stopgap measure I took.
I am not claiming there is a perfect solution to all cases, but for sure the current one is flawed from the beginning. I now get that's what foo_playcount does, but that doesn't mean it's ok.

Quote
I'm not entirely sure what you're trying to do with the data regor, but it doesn't seem like a heavy lift to dedupe. For some reason you don't have a single source of truth, so the only option is to dedupe. This is not really as big a problem as you seem to think. You already can't scrobble a song with a length <30s, (therefore 5s songs on repeat aren't an issue) so stretching that to a 60s window doesn't seem like huge data loss in the multiple repeat corner case. Just convert all your timestamps to JS (this component conveniently does that for you). Sort your multiple arrays into one combined array, and then filter out anything closer than 60000ms and now you've got one single source of truth.
I know I can do that, already did it weeks ago. But that doesn't change it's far from optimal, and having the real timestamp following a standard like everything out there would make de-duplication 90% faster.

Also, as stated, the offset is not always 1 minute, since there are random situations where track length plays a role. It may not be the more relevant thing in the world (I agree the worst case is losing 0.01% listens, ok xd), but just having wrong timestamps (when the current callbacks allow to record the real timestamps) because the parent software does it wrong too... I don't get it. May just be my personal opinion, I just don't agree with doing things wrong on purpose instead of asking for changes or just a set of alternative tags with right values (*).

(*) Even if we accept your reasons, the only excuse to match foo_playcount timestamps is to be sure that tags like %first_played_enhanced% match tags like %first_played%, because the actual JS arrays are only used in JS and therefore value matching is irrelevant.

But then... if you are already offering your own tag (with internal remapping), one could also argue that tags like %first_played_enhanced% could return the real value too (if it exists and has been recorded by your component, otherwise use the foo_playcount value as fallback), which would work the same as it does now, but returning right values whenever it's possible. The arrays could then just return the real timestamps and not the ones recorded by foo_playcount.

Since the "need to match timestamps" comes from having foo_playcount installed too, people desiring wrong timestamps could still use %first_played%. That's said, If peter insists on not chaning the way it's done right now.

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #436 –
When I wrote foo_listenbrainz2 there was no spec on when a timestamp should be generated. I did it at the moment of submission. Undesirable for some but never wrong.

The metabrainz guys only formalised it just over a year ago...

metabrainz community discussion
https://community.metabrainz.org/t/listened-at-parameter-for-submissions-specification-unclear/659142

Listenbrainz docs PR
https://github.com/metabrainz/listenbrainz-server/pull/2607

phw being a metabrainz guy obviously updated listenbrainz2 to follow this but it doesn't change anything for all timestamps submitted before that

And the notion that any offline play logger like foo_playcount/components that use the fb2k SDK should all play ball with this is utterly laughable.

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #437 –
Quote
And the notion that any offline play logger like foo_playcount/components that use the fb2k SDK should all play ball with this is utterly laughable.
Yeah pretty strong argument to say a timestamp should be shifted by 1 min or randomly by a percentage of track length, yep. Makes so much sense. xd

Like if you just want to say "I designed something this way and years later I am so much into this design that I can not accept a bad design", fine. But don't think other people will agree with you. It has nothing to do with people from musicbrainz doing this or that. If phw's component does it right due to they being related to musicbrainz, great. That doesn't invalidate that way is the right one xd

Also mentioning the past... ok. Since it has been done wrong all this years, we should keep doing it wrong.  So wise ::)

Re: foo_enhanced_playcount - Record all song plays and Last.fm scrobbles

Reply #438 –
Quote from: regor on
I understand how it was originated, but that "solution" has just been a patch to an inherent problem in the way timestamps were recorded to match bugged timestamps by foo_playcount. They don't match last.fm, listenbrainz nor anything out there, even if the timestamp comes from other components within foobar2000.
foo_playcount's timestamps aren't "bugged" though. They're different than what you're getting from listenbrainz/last.fm is all you can say. You're happy to think my adjustment is bugged if you like. For better or worse, this is a foobar component though, and one designed to get timestamps from foobar, and so I feel I'm beholden to follow Peter's design and not anybody else's.

No reason to get testy in here.