I’m trying to figure out why sometimes I am getting duplicate scrobbles when utilizing a different music player than plexamp. Would like to be able to see logs containing scrobble information / know of potential key-words to search on.
Best regards,
mcom12
Are you using LastFm scrobbling? https://plex.tv/users/other-services
Server log has something like this:
Jul 25, 2022 10:30:10.953 [0x7000088e8000] DEBUG - MyPlex: Sending scrobble for account 1 for item 4550330.
Thanks for the help. I appreciate it.
Issue I’m having is duplicate scrobbles to both ListenBrainz and Last.fm when listening via Symfonium app.
Possibly because Symfonium is scrobbling and the media server is scrobbling? I don’t know how that app works, but that’s a possibility. Either that or it’s misusing the Plex API and causing the double-scrobble.
Alternatively, you could check out Plexamp for Android 
API is not really that documented 
Symfonium does not scrobble on it’s side, but properly reports the playing status during playback then manually update the playcount at the end since the app is offline first and handle playcounts when offline.
The question is why does Plex auto scrobble at 50% then again when updating playcount? Can this be avoided when reporting playback via some parameters?
See logs, after 50% when sending the playback state plex answers
“playbackState”:“complete”
“viewOffset”:-1
Those values are wrong since we are only at half of the media.
2022-07-25 11:16:26.306 Verbose/PlexLogger: <-- [616] 200 OK https://xxxx.plex.direct:20123/:/timeline?ratingKey=166504&key=%2Flibrary%2Fmetadata%2F166504&state=playing&time=62000&duration=130000 (12ms, unknown-length body)
2022-07-25 11:16:26.311 Verbose/PlexLogger: <-- [616] {"MediaContainer":{"size":0,"playbackState":"progress","skipCount":0,"viewCount":20,"viewOffset":62000}}
2022-07-25 11:16:27.814 Verbose/PlexLogger: --> [391] GET https://xxxx.plex.direct:20123/:/timeline?ratingKey=166504&key=%2Flibrary%2Fmetadata%2F166504&state=playing&time=63000&duration=130000
2022-07-25 11:16:27.829 Verbose/PlexLogger: <-- [391] 200 OK https://xxxx.plex.direct:20123/:/timeline?ratingKey=166504&key=%2Flibrary%2Fmetadata%2F166504&state=playing&time=63000&duration=130000 (15ms, unknown-length body)
2022-07-25 11:16:27.833 Verbose/PlexLogger: <-- [391] {"MediaContainer":{"size":0,"playbackState":"progress","skipCount":0,"viewCount":20,"viewOffset":63000}}
2022-07-25 11:16:28.573 Verbose/PlexLogger: --> [814] GET https://xxxx.plex.direct:20123/:/timeline?ratingKey=166504&key=%2Flibrary%2Fmetadata%2F166504&state=playing&time=64000&duration=130000
2022-07-25 11:16:28.610 Verbose/PlexLogger: <-- [814] 200 OK https://xxxx.plex.direct:20123/:/timeline?ratingKey=166504&key=%2Flibrary%2Fmetadata%2F166504&state=playing&time=64000&duration=130000 (38ms, unknown-length body)
2022-07-25 11:16:28.611 Verbose/PlexLogger: <-- [814] {"MediaContainer":{"size":0,"playbackState":"progress","skipCount":0,"viewCount":20,"viewOffset":64000}}
2022-07-25 11:16:29.324 Verbose/PlexLogger: --> [584] GET https://xxxx.plex.direct:20123/:/timeline?ratingKey=166504&key=%2Flibrary%2Fmetadata%2F166504&state=playing&time=65000&duration=130000
2022-07-25 11:16:29.796 Verbose/PlexLogger: <-- [584] 200 OK https://xxxx.plex.direct:20123/:/timeline?ratingKey=166504&key=%2Flibrary%2Fmetadata%2F166504&state=playing&time=65000&duration=130000 (473ms, unknown-length body)
2022-07-25 11:16:29.797 Verbose/PlexLogger: <-- [584] {"MediaContainer":{"size":0,"playbackState":"complete","skipCount":0,"viewCount":21,"viewOffset":-1}}
2022-07-25 11:16:30.821 Verbose/PlexLogger: --> [131] GET https://xxxx.plex.direct:20123/:/timeline?ratingKey=166504&key=%2Flibrary%2Fmetadata%2F166504&state=playing&time=66000&duration=130000
2022-07-25 11:16:30.842 Verbose/PlexLogger: <-- [131] 200 OK https://xxxx.plex.direct:20123/:/timeline?ratingKey=166504&key=%2Flibrary%2Fmetadata%2F166504&state=playing&time=66000&duration=130000 (22ms, unknown-length body)
2022-07-25 11:16:30.844 Verbose/PlexLogger: <-- [131] {"MediaContainer":{"size":0,"playbackState":"complete","skipCount":0,"viewCount":21,"viewOffset":-1}}
Users like to see the playback sessions on plex console, but I can easily add an option to remove the reporting and only deal with the playcount / lastplayed.
There’s a special offline=1 parameter which bulk sending when you’re online again and sending offline plays, also updatedAt=X for timestamping the play. If you watch the server logs when bringing Plexamp online you’ll see those variants.
Ok so for offline play I should still use the /:/timeline with those and not the /:/scrobble ? If I send the stopped with a position = duration it will increase playcount? From some previous tests there was some issues if I did not at least send a few queries and have at least like 10 or 30 seconds differences in the positions. (Without those params)
Anyway thanks for the info on those new params never saw them before will test more.
I assume you’re the Symfonium guy? If so, congratulations on a lovely app, well done.
I believe that’s correct, yes. I haven’t been in that code for a while, but when I look I don’t see any references to /:/scrobble, that’s more for marking things (un)watched.
Yes I’m the Symfonium / Yatse guy 
Thanks.
About scrobble I use it to update the playcount, my main problem is that I also handle the resume points from offline mode.
For the resume point I send the timeline with stopped and it works, but does not always touch the playcounts even if past the 50% for music for example, that’s why I also scrobble to mark played. (Yatse works the same but also handles video)
So I guess I’ll have to go the road I wanted to avoid for offline state I’ll need to send multiple fake timelines to have a start, at least 30 seconds then a stop at the resume point to update both properly, and handle online / offline states differently by checking the timeline viewCount increase even if it’s at 50% and not 90% like I do for all other providers.
I’ve just tested the offline param it does the same thing as without, it’s just hidden from the dashboard.
I suppose there’s no other easy param to the timeline to avoid autoscrobble/playcount update and let the clients send the scrobble when wanted (Typically to have a 90% mark for played and not 50%?) that would simplify things a lot.
Actually found an hack, if I send fake durations that are position *3 to the timeline call it does not autoscrobble or update playcount, but the dashboard still shows proper positions as I assume it ignore that param and use the real media duration.
Let’s hope it’s the wanted way for Plex to behave and it won’t be fixed.
I just checked the logic and on the server it has this:
if (offline && playTime == 0 && viewCount > 0)
So if you send offline=1&time=0&viewCount=1 that should make it add to the play count.
Thanks for the check, really appreciated. I’ll try this variation
I’ve currently doing tests and it seems scrobbling use a different logic than playcount hence why most of my tests where wrongs 
Specially when calling scrobble and with webhook handling things differently than last.fm.
For now the way to get control is to report all current playback to timeline with duration=-1 to not have the auto playcount and scrobbling.
Then when wanted I send a a timeline playing then a stopped with proper position/duration and offline=1 to scrobble and update the playcount.
I’ll check if your last update also sends the scrobble or not and can avoid the fake playing timeline event.
Appreciate your patience with an undocumented API…
@aubrey.wodonga - does https://eavesdrop.fm need some specific events for scrobbling tracks? The ‘Playing now’ is working fine, but tracks that are scrobbling fine to Last.fm aren’t making it to ListenBrainz via webhook. Webhook works with Plexamp.
@elan So yes your variation works no need to send the fake playing state and the tweaked positions. And properly handle playcount and scrobbling to last.fm. Thanks a lot, not sure I would have found that one.
Will see with @mcom12 if this variation also send what is needed for eavesdrop else I’ll follow up with the eavesdrop dev to see if he can adapt.
Not sure what’s going on at your end. Also, I think we might be conflating a few separate problems here: Eavesdrop.fm uses webhooks, last.fm doesn’t, and at least for the Eavesdrop.fm case, it shouldn’t matter at all which Plex player you’re using (third party or otherwise), as it’s handled by the server. As long as the player is telling the server about the listens, that is 
Last.fm scrobbles can happen even when webhooks aren’t firing (e.g. if the player is offline, the server has a brief moment of connectivity issues etc). Webhooks, by design MUST happen in real-time. Plex players will resync their listen state with the server after they’ve reconnected, which allows last.fm to receive scrobbles after the event. Eavesdrop.fm can’t do that.
If you’re confident the webhooks should have fired, then server logs will probably tell the tale. I’ve not been able to reproduce the same problem. I even tried your Tidal add-to-library issue from Github, without luck. Any chance you could share your server logs with me next time you see this happening?
The problem here is what events you expect as listens.
Here the app send the playing / paused / stopped timeline events but does not trigger Plex auto playcount increase as it want to have the control about when it happen.
To do that I now use Elan solution by sending one offline event that increase the playcount and scrobble correctly.
If this can’t work what solution do we have to still have control and have the webhook working?
Thanks @Tolriq, I think I understand what’s happening now.
As above, I’m using the media.scrobble event to push a listen to the ListenBrainz API. If it’s not a scrobble (i.e. just a play event), it simply updates the “currently listening to” value, as expected. If your changes make PMS send a scrobble webhook, the Eavesdrop.fm service should work as expected
As you can imagine I don’t control what the server send and when it’s all a black box and trial and errors
I’m currently using @elan trick but it seems it’s not fully WAI as the tracks also are not visible in Plex Dash app play history.
I guess the only solution is to send fake play/stop events with proper fake values to trigger all the things correctly.
