Where does the reporting happen?

[michaelherger]

I've had a report of a user who happens to be an artist, too. He claims that when he's listening to his own music using my implementation of librespot, the tracks would not be reported. This is definitely not what I want to happen, therefore I'm a bit concerned.

And I must admit I've been wondering why my kids' listening habits hadn't polluted my profile yet... (but I was less concerned about that :-D).

Is there code in librespot which actively does report when a track has been listened to? I was assuming that telling librespot to play a track would do all the magic for me.

I'm using a slightly modified fork of librespot (https://github.com/michaelherger/librespot), and I'm not sure whether one of my modifications is causing this mis-behavior or not.

[michaelherger]

Anyone?

[devgianlu]

How can we test whether the playback history is being recorded or not? I am willing to fix this issue for librespot-java, but I need a way to test it properly.

[michaelherger]

That's a good point and something I'll try to do: you can get the recently played tracks using the web API (the call is still beta... hopefully that won't confuse even more...).

https://developer.spotify.com/documentation/web-api/reference/player/get-recently-played/

[devgianlu]

@michaelherger I've checked and it seems that tracks played from librespot aren't reported by that endpoint. I will investigate this further.

[michaelherger]

Thanks for the confirmation!

[devgianlu]

Unluckily I don't see any specific call to report that a track is playing. I am afraid that it is done via the event-service endpoint which hasn't been reversed engineered at all. The only (mercury) packet that has the track uri in it is the following:

0078  # Changes every time, not incremental

5549496e746572616374696f6e # "UIInteraction"

0935  # Padding + "5"

0909  # Double padding
706c61796c697374  # "playlist"

09  # Padding
73706f746966793a6170703a706c61796c697374  # "spotify:app:playlist"

0909  # Double padding
32  # "2", could be track index in playlist

09  # Padding
73706f746966793a747261636b3a3367696379666945564d474f4e677a796770576a4e54  # Track uri

0909  # Double padding
6c6973742d6974656d2d73656c6563746564  # "list-item-selected"

09  # Padding
31353637303834303738323536  # Timestamp in millis

There's no reporting in the HTTP API either. Android doesn't seem to have any of this either.

I've also noticed that the Recently played API updates quite slowly, so maybe librespot-java works with reporting? Don't know.

[ashthespy]

@devgianlu There is also an activity-manager endpoint that I recall seeing, but didn't investigate further.

[devgianlu]

@devgianlu There is also an activity-manager endpoint that I recall seeing, but didn't investigate further.

I did not see any of that. Maybe it has been deprecated when they upgraded the protocol.

[ashthespy]

This was from an older version indeed. I need to find my notes.
Also might be of interest:

hm://played-state/v1/items
hm://played-state/v1/updates
hm://played-state/v1/unsubscribe
hm://played-state/v1/items?fromTimestamp=%Lu

[devgianlu]

I think that's for episodes only.

[ashthespy]

You are probably right again, its been a while I looked at this!

[caba8685]

Any updates on this?

[devgianlu]

We are stuck on trying to find a way to check if the changes on the client work.

[sashahilton00]

It’s probably handled via the events service. I’d be surprised if Spotify does the play reporting client side, would make it too easy to abuse. Then again, I can’t see how they track it server side unless they’re doing some sort of calculation based on the number of chunks sent to a client

[ashthespy]

I was thinking about this some time back, and I guess they probably have metrics based on client type, and since we report librespot they could just not be propagating those metrics?