Jellyfin songs listened to via Symfonium while offline are not scrobbled. #87
Labels
Comments
|
Thanks for the detailed response and context links. The webhook plugin does allow sending events on |
|
CC'd on the symfonium support forum Using {
"NotificationType": "UserDataSaved",
"Timestamp": "2023-07-18T14:03:23.6061191Z",
"Played": true,
"SaveReason": "PlaybackFinished",
"LastPlayedDate": "2023-07-18T14:03:23.6061191Z"
}There is an issue specific to symfonium, however. The Timeline:
This scenario isn't tenable for scrobbling. All offline plays would be reported as played at the same time which doesn't make sense. I was able to get Jellyfin to report the correct Based on the code for 1. (most likely) symfonium is sending JSON when
|
|
Symfonium 5.6.0 was released which has "- Fixed Jellyfin/Emby offline playback count sync not sending the proper time of play" in the changelog. |
|
Not yet! I was waiting for symfonium so i could do some real-world testing and am not in the beta channel. I'll get on this shortly. Thanks for the notification. |
FoxxMD
added a commit
that referenced
this issue
Aug 4, 2023
* Refactor candidate/discovered Play maps to use tuple id instead of string so user can be compared later * Add option to check all discovered platform plays (since jellyfin UserDataSaved doesn't include device id in payload) * Check for UserDataSaved notification with correct reason as well as sanity check last played date (since jellyfin will save as played regardless of duration played) * Bypass play tracking
FoxxMD
added a commit
that referenced
this issue
Aug 7, 2023
…rting due to incorrect timestamp #87 * Move UserDataSaved heuristics into scrobble method implementation with more descriptive logging * Add more aggressive UserDataSaved filtering by discarding play if its found in memory tracking, regardless of play date * Attempt to correct bad UTC offset for second UserDataSaved event
|
@HairyOtter please try |
Thanks for all your work, sadly I did have issues. Scrobbles while online work fine with "foxx/multi-scrobbler:jellyin". I've tried 4 songs. First I listened to "The Unthanks - Magpie" online. That was scrobbled just fine. Then I downloaded the album to the offline cache in Symfonium, turned off my wifi and listened to the same song again. Then I listened to "Linkin Park - Heavy" while online, which was scrobbled successfully. I downloaded another album by The Unthanks to the offline cache in symfonium after that, enabled debug logging in the app, turned off the wifi on my phone, listened to "The Unthanks - Starless", turned the wifi back on, waited a minute and then turned debug logging in symfonium off again. Here are the logs from multi-scrobbler. Do I have to change something in the webhook plugin for jellyfin? The symfonium debug log looks like it did send the scrobbles to jellyfin. So far I have only ticked: Edit: |
|
I think the issue may be that you are listening to the same song consecutively. There are a lot of variables at play with offline detection (and
All of these things make it hard to determine when a track is truly being reported from a client that was offline. The Due to the unreliability of detection I had to make MS more aggressive about dropping found One of the things it does is check the recently played memory and drop the event if an identical track is found. MS only keeps the last played track in memory, though. So you shouldn't have any issue with offline recording as long as the last online track isn't the same as one of the offline ones being recorded. So...please try listening to anything (Track X) online, then go offline and listen to Tracks A, B, and C. Then go back online. MS should correctly record A B and C. |
FoxxMD
added a commit
that referenced
this issue
Aug 8, 2023
Check forward and backward offsets and use absolute difference
|
I did make a small fix for timezone issues (first issue on that list). Please update your image to the latest with the same tag. |
I did. First I played "The Cranberries - The Icicle Melts" online. Got scrobbled just fine. Then I deactivated wifi and played 3 tracks from the offline-cached Unthanks Album "Last". Tracks "No One Knows I'm Gone", "My Laddie Sits Ower Late Up" and "Last Reprise". Then I reconnected the wifi. Once again none of the offline scrobbles made it to multi-scrobbler. Jellyfin log: |
|
Have you enabled Also, please turn on debugging for MS logs and jellyfin. MS: Start docker container with the environmental variables to your For jellyfin modify |
I did not. Sorry. I was tired when I read your reply yesterday and failed to realize that you did answer my question:
I have added "UserDataSaved" to the jellyfin webhook plugin, however now even online plays are no longer scrobbled. This is the debug output of multi-scrobbler when I play a track online. The jellyfin debug log of the same time-frame is 381 lines and 305k characters, which is why I won't paste it here. Edit: I tried an offline-played song as well and multi-scrobbler debug log shows: |
|
You need to have both event types enables in the webhook plugin:
Your logs looks right. MS only uses |
|
Forget all that, I am an idiot. I somehow managed to accidentally rename the jellyfin server when I was in the config. After reverting the name-change, scrobbling online works again. Sorry for wasting your time. I still had no luck with offline scrobbles tho. |
|
I did another test today with 5 tracks offline. The negative 7200ish seconds offset looks like the difference from my timezone (UTC+2 summer time in Germany) to UTC. |
FoxxMD
added a commit
that referenced
this issue
Aug 10, 2023
|
@HairyOtter please try updating to the latest For MS you can set the timezone with the environment variable For jellyfin its the same variable if you are using linuxserver/jellfin |
|
I already had the TZ in my compose (stack in portainer) for MS, which looks like this:
I'm using jellyfin in a FreeBSD jail in TrueNAS Core. I don't know how to force jellyfin to use my timezone but it appears to already be using it. If I use the "date" command within the FreeBSD jail for jellyfin I get: And the logs which jellyfin creates also use my timezone: However the timezone error seems to persist on my end: To ensure that I have the latest version of foxxmd/multi-scrobbler:jellyfin I deleted the container, deleted the image and then recreated it which pulled the latest image. |
|
Hmmm...I set up my whole stack to use Europe/Berlin and was able to reproduce this error yesterday but the last changes i made fixed it. Sorry this has been such a pain. Can you get a little more debugging information for me: I imagine you are already using [
{
"name": "JellyUser1",
"clients": [],
"data": {
"users": ["JellyUser1"],
},
"options": {
"logPayload": true
}
}
]This will make it so MS logs the raw payload received from jellyfin for every event. It will look like this: It'll make your logs noisy 😅 ...what I need is a log excerpt that includes the payload output before one of these occurs: Please also report the exact local time (to the second if possible) that:
I believe we are very close to getting this to work. Timezones are the bane of my existence. |
|
There you go. I might have had my config wrong. I had "options" at the same level as "users" and "servers" in jellyfin.json. However I think "logFilterFailure": false still worked like that. Edit: I pressed play at 17:16:35 and the song ended at 17:17:12.
I prefer a bit of productive pain to what I experienced in the jellyfin forum so far. I asked how to import my local playlists into jellyfin while restricting their scope to my user instead of having every user being able to see them. No one even bothered to reply. They do tend to complicate things, I agree. |
FoxxMD
added a commit
that referenced
this issue
Aug 11, 2023
The If you want to see a cool preview add Please pull the latest |
|
My first 2 tests failed because I reenabled the wifi too quickly. First song: I reenabled the wifi seconds after the offline play was done: Second song: I waited ~ a minute before reenabling the wifi: And for the last test I played 3 tracks offline, then waited 3 minutes and THEN enabled the wifi again. Maybe a stupid question: How do you handle offline scrobbles that happened further in the past? If I wait more than 2 hours before reenabling the wifi that won't be the case anymore tho. Will those scrobbles end up shifted 2 hours into the future (for my timezone) or will they be caught and corrected as well? Edit: "LastPlayedDate":"2023-08-11T19:02:25.0000000Z" is local time falsely written as UTC if I'm not mistaken. Could you simply take the "+02:00" part of "Timestamp", invert it and apply it as an hour offset to "LastPlayedDate" if "Timestamp" and "UtcTimestamp" aren't equal? In my case -2 hours? Then you'd have a correct "LastPlayedDate" in UTC "2023-08-11T17:02:25.0000000Z", no matter when the payload was delivered. |
If it was consistent, yes. Unfortunately I have seen Jellyfin send
Not stupid! This is the main pain point. I am trying to cover as many scenarios as possible for what I would consider to be a "typical" offline use-case while being aggressive about not letting jellyfin scrobble "online" plays. The likely scenario:
It's easier to explain all it is doing than just when play is in the past:
This covers most cases where Jellyfin sends It cannot do anything about plays in the past. If those timestamps are wrong, they will be wrong. But at least they will actually be in the past, likely offline, and not duplicate scrobbles from the present. |
That's very frustrating. Have you asked about that in the jellyfin forum?
I don't think I've seen that happen on my end yet, but I've only looked at a few offline payloads. How common would you guess the double occurrences to be on your end?
Thanks for the explanation, that's very thoughtful and should work for the majority of cases.
Very true. Personally I don't care if I listened to a song at 2pm or 4pm. However this behaviour could mess up the play order if I'm correct: If I were to listen to music offline for a little over 4 hours in my utc+2 timezone, the first 2 hours would seem valid even with an offset of +2 hours (they would still be in the past), while the most recent 2 hours would be corrected since they would appear to be from the future. As a result, the plays of 4 hours could end up being mixed and compressed into a 2 hour time frame as far as the scrobbles are concerned. Anyways, I've pestered you enough about this topic. |
|
I've done a longer test today. Rode my bicycle for almost 2 hours and listened to an entire album offline that has 29 tracks and a duration of 1:22:02. Of these 29 plays only the most recent 15 got scrobbled. Here are the MS logs. |
FoxxMD
added a commit
that referenced
this issue
Aug 15, 2023
…bsolute diff #87 May allow more UserDataSaved scrobbles to occur but gives up any form of disallowing future scrobbles from bad timestamps
|
I'm sorry but I've run out of ideas. I started a completely clean Jellyfin server, played tracks from symphonium, and still receive bad timestamps. I played 4 offline songs, 2 of them had correct dates and 2 of them did not. I also had occurrences of this happen while just using the jellyfin web player. I've added a final fix that will prevent I will file a bug report with jellyfin soon since this is reproducible but I don't expect much help from them. Finally, I've added a big, fat warning in logs about using |
Thanks! I'm not overly optimistic either, but it might at least tell others encountering the same problem that it's not their fault.
I understand. Thank you for all your effort. It's a pity that such a "simple" error caused so much trouble and turned out not to be resolvable without jellyfin fixing their side. This is what my sisters boyfriend (who works with databases and statistics as his job) sent me when I told him about the scrobble problem. It might amuse you if you don't already know it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Please check the FAQ before submitting a bug report.
Describe the bug
I listened to 2 albums which I had added to the offline-cache in Symfonium without internet connection. When I reconnected to the internet those plays were reported to jellyfin and did show up in the jellyfin activity log. However multi-scrobbler took no notice of them and thus they did not end up in lastfm or maloja.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expected the scrobbles to end up on lastfm and maloja as soon as the internet connection was reestablished.
Versions (please complete the following information):
Additional context
I've described the entire problem in greater detail on the Symfonium forum:
Here's the link
The developer Tolriq asked me to relay this as a solution to a similar problem:
Problem with listenbrainz
The text was updated successfully, but these errors were encountered: