Event System overehauled, not yet released

[K1ngjulien]

Hi!

I'm working on automatically turn on my sound system when a device connects to my raspotify (wrapper of librespot) instance using the following script.

https://gitlab.com/k1ngjulien/raspotify-handler

While writing docs for all the different parameters being passed from the rust source code, i noticed that the event names did not match those found in the source code...

(I would be happy to clean up the docs and add them here in the upstream wiki)

Describe the bug It looks to me like the event system was overhauled months ago, yet the released packages all still contain the old api.

https://github.com/librespot-org/librespot/commit/8545f361c47b764739ebc4925c4bd33416baa91b#diff-fc7864922f0436a665441a6e16f5294eefdb830ccdc3f8affd1bc9fc1795b49c

When can I expect these 6month old changes to land on a release tag?

I am running the latest 0.4.2 release but even this seems out of date.

To reproduce Steps to reproduce the behavior:

1. Launch librespot -v --onevent something.py
2. See "PLAYER_EVENT" environment variable being passed when an event fires

Log

May 02 16:03:54 page librespot[25606]: [2023-05-02T14:03:54Z INFO  librespot::player_event_handler] Running ["/usr/bin/raspotify-handler.py"] with environment variables {"OLD_TRACK_ID": "538IL5DHWHdD0vRUFIfMoM", "PLAYER_EVENT": "changed", "
TRACK_ID": "6S5BiqsDSpwfnjbcQpmjhI"}

when looking at the current source code, it should be "track_changed" and not "changed"

https://github.com/librespot-org/librespot/blob/dev/src/player_event_handler.rs#L30

Host (what you are running librespot on):

[page /etc]: librespot --version
librespot 0.4.2 70997e9 (Built on 2023-03-16, Build ID: flowgGlc, Profile: release)

Linux page 6.1.19-v7+ #1637 SMP Tue Mar 14 11:04:52 GMT 2023 armv7l GNU/Linux

Raspberry Pi 3 Model B Rev 1.2 PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)" NAME="Raspbian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)"

[K1ngjulien]

@JasonLG1979 Is this something you can bundle with raspotify or has your fork diverged too much?

I will try building librespot from HEAD of dev and see if i can get all the event details that way.

[JasonLG1979]

No.

[JasonLG1979]

Here is an example event handler script written in python with all of the events listed for the dev branch.

https://github.com/librespot-org/librespot/blob/dev/contrib/event_handler_example.py

[K1ngjulien]

so im guessing the raspotify librespot has diverged too much from upstream? any particular reason why?

[JasonLG1979]

No. The use of the new API in the dev branch facilitated the event revamp. Backporting makes no sense because what you would end up with would be the dev branch.

[JasonLG1979]

If you want to use those events you'll need to use the dev branch and roll your solution. Events don't really work at all with Raspotify with how locked down the service is and I really don't plan on changing that or supporting events or inevitably whatever they're triggering.

[K1ngjulien]

hmm events seem to work just fine with raspotify. i just added the following to /etc/raspotify/conf and it called my script right away, even tho its still sending the old events.

...
LIBRESPOT_ONEVENT="/usr/bin/raspotify-handler.py"
...

to me it seems like raspotify is not doing much besides passing the config value as a parameter when running librespot.

currently trying to build librespot for/on my raspberry pi 3, we'll see how that works :D

[JasonLG1979]

The event script will have the same restrictions as the librespot binary.

Building on a Pi takes forever. You can build an ARM binary using docker in less than 5 min.

[JasonLG1979]

The easiest way to work around any restrictions is to UDP multicast the events with something like this:

https://gist.github.com/JasonLG1979/934a5bd969180141a970e2e8197c1f09

With that the receiver of the event only needs to be on the same network.

[K1ngjulien]

Huh I didn't even know you could listen to the events over the network :D

anyway, i was able to do what i wanted (which was automatically turn on my sound system when a client connects) with the following script:

https://gitlab.com/k1ngjulien/raspotify-handler/-/blob/main/soundsystem-on.sh

The event script will have the same restrictions as the librespot binary.

idk what restrictions you're talking about, but the --onevent parameter works just fine for my use :) I was just confused as to why the event names were all weird until i noticed that this was changed about 6months ago.

would be neat if at least the new src/player_event_handler.rs could land in raspotify, even if I can do everything i needed with the old "api"

[K1ngjulien]

anyways, my sound system now automatically turns on when i connect to raspotify with my phone 🎉 I'll consider my issue to be solved 😊

[JasonLG1979]

If that works for you with stock Raspotify please consider adding a wiki howto page.

[K1ngjulien]

sure! but only if you can upstream the api changes :P /s

[JasonLG1979]

You don't need the new API if all your doing is turning an amp on and off. When whatever dev becomes is released Raspotify will switch to that version.

[K1ngjulien]

I've added a Wiki entry. I'm surprised I'm just allowed to edit all those pages 😅

https://github.com/dtcooper/raspotify/wiki/How-To:-Listen-To-Librespot-Events

[JasonLG1979]

Thanks. Yep wikis by default are writeable to everyone.