Issue with Plex scrobble

[mannp]

I cannot seem to get Plex to scrobble...

2022-04-02T14:58:31+01:00 info : [Source - Plex - myplex ] Initializing with the following filters => Users: N/A | Libraries: N/A | Servers: http://192.168.40.65:32400

I have a webhook setup in Plex, well two and neither work;

http://192.168.10.41:9078/plex &

http://localhost:9078/plex

Nothing appears in the log except timeouts for deezer occasionally :-/

[mrstrayer]

Hello! I don't have anything helpful to add here yet, but I just wanted to let you know that I may be having the same issue. I just got everything set up finally this morning. Spotify is working fine, but it is slow, so I'm kinda waiting to see if there's just a significant lag in Between me clicking "play" on a song and it eventually getting to the scrobbler. I'll report back.

EDIT - The documentation says to list users with email addresses. I just tried adding my actual username as listed on my Plex account, instead of just my email, and it started working! So it looks like that's the solution!

[mannp]

Yes, the documentation uses different terminology than my Plex account does, but it clearly states that neither are needed, so it should work without the email or username.

Did you use the full ip address of your MS instance, with /plex appended in the Plex webhook?

[mrstrayer]

I have the full IP address in there, yes, with /plex appended. Working just fine.

On Thu, Apr 21, 2022 at 4:52 PM mannp @.***> wrote:

Yes, the documentation uses different terminology than my Plex account does, but it clearly states that neither are needed, so it should work without the email or username.

Did you use the full ip address of your MS instance, with /plex appended in the Plex webhook?

— Reply to this email directly, view it on GitHub https://github.com/FoxxMD/multi-scrobbler/issues/40#issuecomment-1105796883, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFTLPE66U5WS5VE2HMBDMETVGHE3BANCNFSM5SLCMXEQ . You are receiving this because you commented.Message ID: @.***>

[northys]

[OFF TOPIC]

Spotify is working fine, but it is slow, so I'm kinda waiting to see if there's just a significant lag in Between me clicking "play" on a song and it eventually getting to the scrobbler. I'll report back.

After you click on See recently played tracks returned by API there is a warning :) This list was returned from the Spotify Api now. Sometimes Spotify "backlogs" user activity so your recent tracks may not show up for minutes (or hours). ¯_(ツ)_/¯

It scrobbles only played songs. I don't think that multi-scrobbler has "now playing" feature as last.fm.

[FoxxMD]

Sorry for the severely long delay on this @mannp . Most of the free time these days is put into another project I am working on. On top of that, I've had to pin the version of plex I use (1.24.5.5173 oct 2021) because of a transcode issue that made it unusable, for me, in later versions. I mention that because trying to reproduce your issue would require me spinning up another plex instance with a new DB and I just haven't had the time to devote to doing that.

Since it still seems to be working for @mrstrayer I would suggest you first rule out any basic connectivity issues. Webhook issues should be logged and you should be able to see them from the downloadable logs (from desktop)

You can also try pointing your webhooks URL at a simple HTTP server on the same host as MS and echo out the response to verify that its sending/receiving them at all.

@northys

It scrobbles only played songs. I don't think that multi-scrobbler has "now playing" feature as last.fm.

That is correct. MS uses spotify's recently played api endpoint which only returns tracks after a user has stopped playing them -- either through pausing for a long enough time, stopping the player, or starting a new track. This is because recently played returns a timestamp of when the track was played which makes it easier for MS to compare to recently scrobbled info from the client (maloja, last.fm) in order to avoid creating duplicate scrobbles.

[k-boyle]

I'm having the same issue and from the logs it looks like he webhook gets sent successfully;

Jun 13, 2022 23:54:03.660 [0x146eb5bbab38] DEBUG - Webhook: Delivering media.scrobble event by user kieranthebest (1) to 1 hooks.
Jun 13, 2022 23:54:03.661 [0x146eb5acbb38] DEBUG - HTTP requesting POST http://...:9078/plex
Jun 13, 2022 23:54:03.667 [0x146eb6441b38] DEBUG - [HttpClient] HTTP/1.1 (0.0s) 200 response from POST http://...:9078/plex

[k-boyle]

I've debugged locally and it looks like the issue is here, I don't know why you wouldn't just use req.body directly however

image

[k-boyle]

Nevermind looks like the example payload in Plex docs is wrong. I did need to set the PLEX_USER env var to get the app to recognise Plex as a source otherwise, it looks like Plex just isn't sending the scrobble event for whatever reason. I get the start play events just not the scrobble

[FoxxMD]

Thanks for looking into this!

I did need to set the PLEX_USER env var to get the app to recognise Plex as a source

So using plex.json did not work or is there any issue with default config for plex?

it looks like Plex just isn't sending the scrobble event for whatever reason. I get the start play events just not the scrobble

I'm guessing this is a regression introduced in a recent version of plex? They do hooks in such a weird way (multi-part POST) it could also be that Plex is sending some of the data (since your logs say it is) but not data signifying the end of the multi-part POST call.

[k-boyle]

So using plex.json did not work or is there any issue with default config for plex?

That might be my bad, the docs read to me as if the configs were optional 😵

I'm guessing this is a regression introduced in a recent version of plex? They do hooks in such a weird way (multi-part POST) it could also be that Plex is sending some of the data (https://github.com/FoxxMD/multi-scrobbler/issues/40#issuecomment-1154531200) but not data signifying the end of the multi-part POST call.

So I was seeing a weird request without a body which was occurring about 80% of the way through songs (Plex docs say it sends scrobble at the 90% mark) but with no data attached, I couldn't tell what it was exactly. Also I think this weirdness might apply to the start stop too since I'm only getting some of them in my fork that uses the start event instead of scrobble.

[FoxxMD]

@k-boyle you could try debugging before multer gets ahold of the request(s) to see if plex is doing things differently now. I would think multer would transparently pass along a normal json POST (not multi-part) but I'm not so sure now.

        const testMiddle = (req, res, next) => {
            const f = 1; // put your breakpoint here and inspect req
            next();
        }

      app.postAsync('/plex', testMiddle, upload.any(), async function (req, res) {
      ...

[k-boyle]

Yeah so I have a 1:40 audio file, and then at 1minute in I get

In the testMiddle and then in the handler

[k-boyle]

Although funnily somehow I got a scrobble on my running fork that uses the play event which is the first I've seen in a couple hours of testing

Ignore the log saying the wrong thing

[FoxxMD]

Ok, so Plex is definitely still sending a multi-part POST, which you can tell from the headers in both screenshots with multipart/form-data. The "empty" body was also the behavior i was seeing before i added multer...

Do you notice a difference in testMiddle between the two types of events? For example, do you see testMiddle hit multiple times -- prior to the request coming through to the main function (after multer) -- when the media.play event is sent?

[FoxxMD]

@k-boyle @mannp @mrstrayer I have refactored how requests from plex are handled by using a different library with more control over the request lifecycle. Changes include much more debug logging, aggressive checking for valid data in the request (with errors thrown if not), and some potential fixes for the issues @k-boyle was specifically seeing.

Can you all try MS on the develop branch/image and see if this fixes anything for you.

[FoxxMD]

@k-boyle @mannp @mrstrayer any updates or had a chance to test this out?

[k-boyle]

Oh yes sorry I've been away for the past couple weeks. I should be able to do some testing this weekend though

[mannp]

I tested the changes a few days ago and didn't see any immediate change, but it was rather brief test and I haven't got around to trying it again.

Thank you for the further investigation and changes, I will give them another try and report back.

[FoxxMD]

Any updates @k-boyle @mannp ?

[mannp]

Sorry not had chance to retest, will do over this weekend, if that works.

Edit: Not had the chance to test and unlikely for a while. Thanks for peoples work and happy for this to be closed if others have it working 👍🏻

[HStep20]

I think Im having issues related to this as well. Im currently on the develop tag (tried on latest as well), but I cannot get it to pick up Plex or Tautulli webhooks being sent to the proper URL endpoints.

I see the webhooks being sent in the Tautulli notification logs, but noting is coming through on the MultiScrobbler end. Debug logs reveal nothing when configured (what I assume is) properly, but if I send a Tautulli webhook to the /plex endpoint, I get a debug log saying that it failed. It just doesn't seem to be accepting them at the proper endpoint from Plex or Tautulli

[FoxxMD]

@HStep20 are you using a reverse proxy by any chance?

In the latest develop tag I have added logging for when MS receives an invalid request or request to an unknown route. Please update and then make sure debug logging is turned on by using the LOG_LEVEL=debug environmental variable.

[HStep20]

I am not using a reverse proxy - All internal traffic. Still experiencing similar behavior where the webhook is called, but never 'read' by multiscrobbler.

Tautulli gives me this, which is odd because its a 500 error when trying to reach MultiScrobbler:

Tautulli NotificationHandler :: Notification thread exception: decoding str is not supported
Traceback (most recent call last):
    File "/app/plexpy/request.py", line 178, in request_response2
        response.raise_for_status()
    File "/app/lib/requests/models.py", line 1021, in raise_for_status
        raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: http://10.0.0.101:9078/tautulli

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
    File "/app/plexpy/notification_handler.py", line 78, in process_queue
        notify(**params)
    File "/app/plexpy/notification_handler.py", line 430, in notify
        success = notifiers.send_notification(notifier_id=notifier_config['id'],
    File "/app/plexpy/notifiers.py", line 713, in send_notification
        return agent.notify(subject=subject,
    File "/app/plexpy/notifiers.py", line 970, in notify
        return self.agent_notify(subject=subject, body=body, action=action, **kwargs)
    File "/app/plexpy/notifiers.py", line 4228, in agent_notify
        return self.make_request(self.config['hook'], method=self.config['method'], headers=headers, **data)
    File "/app/plexpy/notifiers.py", line 977, in make_request
        response, err_msg, req_msg = request.request_response2(url, method, **kwargs)
    File "/app/plexpy/request.py", line 207, in request_response2
        req_msg = server_message(e.response, return_msg=True)
    File "/app/plexpy/request.py", line 318, in server_message
        message = str(message, 'utf-8', 'replace')
TypeError: decoding str is not supported 

Plex has similar issues. I ended up connecting LastFM as a source, and Majola as a client so my scrobbles flow Plex > LastFM > MultiScrobbler > Majola, however Id love to find out why its acting so odd when trying to use webhooks scrobbling within the network

[FoxxMD]

@HStep20

With the updates I mentioned on develop MS should record any communication it gets from Plex or Tautulli. Even if the request is invalid. This is a good way to determine if there is a connectivity issue between Plex and MS (so not an issue with MS). You should see something like this in the MS logs when (more info when LOG_LEVEL=debug is enabled):

2023-05-24T11:56:21-04:00 info    : [Ingress] [Plex] Received request from a new remote address: ::ffff:192.168.0.XXX (UA: PlexMediaServer/1.24.5.5173-8dcc73a59)
2023-05-24T11:56:21-04:00 debug   : [Plex Request] Receiving request from Plex...
2023-05-24T11:56:21-04:00 debug   : [Plex Request] Received 0 bytes of expected 5360
2023-05-24T11:56:21-04:00 debug   : [Plex Request] Received 5360 bytes of expected 5360
2023-05-24T11:56:21-04:00 debug   : [Plex Request] File Begin: payload
2023-05-24T11:56:21-04:00 debug   : [Plex Request] File Begin: thumb
2023-05-24T11:56:21-04:00 debug   : [Plex Request] File Recieved: payload
2023-05-24T11:56:21-04:00 debug   : [Plex Request] File Recieved: thumb
2023-05-24T11:56:21-04:00 debug   : [Plex Request] Received end of form data from Plex
2023-05-24T11:56:21-04:00 info    : [Ingress] [Plex] ::ffff:192.168.0.XXX (UA: PlexMediaServer/1.24.5.5173-8dcc73a59) Received valid data from server MYSERVER for the first time.

Similar logging would occur for Tautuilli.

If you don't see anything like this in your logs at all then it means Plex/Tautulli are unable to reach the MS instance and you have a networking issue (firewall? port forwarding?) Check the FAQ for more info and some steps you can check to take to try and troubleshoot.

Tautulli gives me this

So tautulli can access MS which is good. This error is most likely fixed in the develop branch/image #77