[PROBLEM] Newbie questions: web interface login, Spotify and radio stations

[cogitech]

I should note that the above librespot log entry is from my Debian workstation, running librespot from the command line.

For the life of me, I cannot find where the heck librespot is logging to on moOde.

Update: I found this https://moodeaudio.org/forum/showthread....34#pid6234

So it is possible to turn logging on. Going to play with that and see what I can come up with. I think verbose logging is too much, so I will not use "-v".

Update #2: Nope. That link above is too old. "/var/www/inc/playerlib.php" doesn't exist. Could not find playerlib.php anywhere in my file system.

[Nutul]

So, parse the librespot log file for the latest "<spotify:track:XXXXXXXXXXXXXXXXXX>" entry, grab the track ID, inject it into the spotify-url-info tool, grab metadata and cover art, display in overlay.

I would love to be able to write the code to make this work. It would be fun!

So, I haven't a Spotify premium account, so cannot use librespot and therefore do not have many track-IDs; just tested with the above.

You can grab the bash script and test it on the Pi command line.
I can retrieve the following information (it takes a couple of seconds, but this depends on the connection and servers availability / speed):

artist, album, cover art, track number, track title, track duration

the script is just a POC

see if it is "enough"

ETA

This is what I can get on my Pi4 (the output is html-encoded, hence the &... thing) 

Code:

pi@moode-lounge:~ $ /home/pi/bin/getSpotifyNowPlayingInfo.sh 5nTtCOCds6I0PHMNtqelas
Artist: SOPHIE
Album : OIL OF EVERY PEARL'S UN-INSIDES
Track : 8 - Immaterial   (3:53)
Cover : https://i.scdn.co/image/ab67616d0000b2736b03d8c63599cc94263d7d60
pi@moode-lounge:~ $

[TheOldPresbyope]

I should note that the above librespot log entry is from my Debian workstation, running librespot from the command line.

For the life of me, I cannot find where the heck librespot is logging to on moOde.

Update: I found this https://moodeaudio.org/forum/showthread....34#pid6234

So it is possible to turn logging on. Going to play with that and see what I can come up with. I think verbose logging is too much, so I will not use "-v".

Update #2: Nope. That link above is too old. "/var/www/inc/playerlib.php" doesn't exist. Could not find playerlib.php anywhere in my file system.

grep is as good as find in cases like this. A quick grep on librespot found your missing bit (it moved when Tim refactored his code).

Have a look at /var/www/inc/renderer.php

Regards,
Kent

[cogitech]

Awesome, guys! I'll do some tinkering.

[cogitech]

Okay, so tweaking the renderer.php works as expected and the log file always shows track ID when a new track is loaded:

Code:

2024-01-24 20:44:48.414941 INFO [src/bin.rs:420] Capture finished
2024-01-24 20:44:48.420066 INFO [src/bin.rs:410] Playback finished
[2024-01-24T20:44:48Z INFO  librespot_playback::player] Loading <夜にダンス> with Spotify URI <spotify:track:0RffFIV29Yb7vjGokb0e6q>
[2024-01-24T20:44:48Z INFO  librespot_playback::player] <夜にダンス> (256875 ms) loaded
[2024-01-24T20:44:48Z INFO  librespot::player_event_handler] Running ["/var/local/www/commandw/spotevent.sh"] with environment variables {"TRACK_ID": "0RffFIV29Yb7vjGokb0e6q", "PLAYER_EVENT": "playing", "POSITION_MS": "0", "DURATION_MS": "256875"}
2024-01-24 20:44:48.931375 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2024-01-24 20:44:48.931499 INFO [src/bin.rs:712] Running on linux, aarch64
2024-01-24 20:44:48.975094 INFO [src/alsadevice.rs:161] Starting playback from Prepared state
[2024-01-24T20:45:07Z INFO  librespot::player_event_handler] Running ["/var/local/www/commandw/spotevent.sh"] with environment variables {"OLD_TRACK_ID": "0RffFIV29Yb7vjGokb0e6q", "TRACK_ID": "14f6jZAEm43fqsrrZpYVeT", "PLAYER_EVENT": "changed"}
no pid file present!
ALSA lib libasound_module_pcm_cdsp.c:869:(cdsp_hw_free) Error executing camilla_exit_cmd /usr/local/bin/cdspstorevolume

2024-01-24 20:45:08.554882 INFO [src/bin.rs:420] Capture finished
2024-01-24 20:45:10.642460 INFO [src/bin.rs:410] Playback finished
[2024-01-24T20:45:10Z INFO  librespot_playback::player] Loading <Ones And Zeros> with Spotify URI <spotify:track:14f6jZAEm43fqsrrZpYVeT>
[2024-01-24T20:45:11Z INFO  librespot_playback::player] <Ones And Zeros> (267360 ms) loaded
[2024-01-24T20:45:11Z INFO  librespot::player_event_handler] Running ["/var/local/www/commandw/spotevent.sh"] with environment variables {"DURATION_MS": "267360", "PLAYER_EVENT": "playing", "TRACK_ID": "14f6jZAEm43fqsrrZpYVeT", "POSITION_MS": "0"}
2024-01-24 20:45:11.091851 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2024-01-24 20:45:11.092328 INFO [src/bin.rs:712] Running on linux, aarch64
2024-01-24 20:45:11.175354 INFO [src/alsadevice.rs:161] Starting playback from Prepared state

And Al's script works as expected:

Code:

moode@moode:~ $ ./metaspot.sh 5qhGBRamxnwW6peITFjCPo
Artist: Barney Bentall
Album : Gift Horse
Track : 4 - Too Good To Be True   (3:33)
Cover : https://i.scdn.co/image/ab67616d0000b273033f8bf880436443b7cc3074

Theoretically, that's all the "data" that we need, just need to figure out how to tie it all together and display it in the overlay.

There is the problem of the log file to deal with, of course. Even though verbose logging is not necessary, eventually the log file will become a problem. That's a lot of wasted cycles and space when all we need, literally, is the most recent occurence of "Spotify URI <spotify:track:xxxxxxxxxxxxxxxxxxx>" in the log. Maybe there is a way to "watch" the log file for "Spotify URI <spotify:track:", parse the track ID, dump it to a state file, and route the rest of the log file to /dev/null ?? Then, Al's script could be written to watch the state file and grab new metadata any time the trackID in the state file changes.

I bet there is a way better approach to this. I have been looking at "spotifyd", which appears to be a daemonized branch of librespot written in rust, with more "extras". From discussion I read, metadata was on the radar (and playback controls). I haven't had time to install it and play with it yet.

[Nutul]

[2024-01-24T20:44:48Z INFO  librespot::player_event_handler] Running ["/var/local/www/commandw/spotevent.sh"] with environment variables {"TRACK_ID": "0RffFIV29Yb7vjGokb0e6q", "PLAYER_EVENT": "playing", "POSITION_MS": "0", "DURATION_MS": "256875"}

[2024-01-24T20:45:07Z INFO  librespot::player_event_handler] Running ["/var/local/www/commandw/spotevent.sh"] with environment variables {"OLD_TRACK_ID": "0RffFIV29Yb7vjGokb0e6q", "TRACK_ID": "14f6jZAEm43fqsrrZpYVeT", "PLAYER_EVENT": "changed"}

[2024-01-24T20:45:11Z INFO  librespot::player_event_handler] Running ["/var/local/www/commandw/spotevent.sh"] with environment variables {"DURATION_MS": "267360", "PLAYER_EVENT": "playing", "TRACK_ID": "14f6jZAEm43fqsrrZpYVeT", "POSITION_MS": "0"}

These messages cought my attention... I have no knowledge about librespot, but I see that a script is being called when the track changes, so that in that script we could add my commands to retrieve the relevant information.

Then what remains to do is find a way to pass the relevant metadata to moOde, IDK, by invoking some php... existing or to-be-created... maybe @Tim Curtis can share a word here.

Happy to see it works... as far as Spotify does not change the header of the pages it will continue to work for centuries to come...
Maybe there is a way to download only the html head with curl, and this will possibly speed up the thing a little bit.

[cogitech]

[2024-01-24T20:44:48Z INFO  librespot::player_event_handler] Running ["/var/local/www/commandw/spotevent.sh"] with environment variables {"TRACK_ID": "0RffFIV29Yb7vjGokb0e6q", "PLAYER_EVENT": "playing", "POSITION_MS": "0", "DURATION_MS": "256875"}

[2024-01-24T20:45:07Z INFO  librespot::player_event_handler] Running ["/var/local/www/commandw/spotevent.sh"] with environment variables {"OLD_TRACK_ID": "0RffFIV29Yb7vjGokb0e6q", "TRACK_ID": "14f6jZAEm43fqsrrZpYVeT", "PLAYER_EVENT": "changed"}

[2024-01-24T20:45:11Z INFO  librespot::player_event_handler] Running ["/var/local/www/commandw/spotevent.sh"] with environment variables {"DURATION_MS": "267360", "PLAYER_EVENT": "playing", "TRACK_ID": "14f6jZAEm43fqsrrZpYVeT", "POSITION_MS": "0"}

These messages cought my attention... I have no knowledge about librespot, but I see that a script is being called when the track changes, so that in that script we could add my commands to retrieve the relevant information.

Then what remains to do is find a way to pass the relevant metadata to moOde, IDK, by invoking some php... existing or to-be-created... maybe @Tim Curtis can share a word here.

Happy to see it works... as far as Spotify does not change the header of the pages it will continue to work for centuries to come...
Maybe there is a way to download only the html head with curl, and this will possibly speed up the thing a little bit.

Nice catch! It is even passing the "TRACK_ID" variable to the script.

Interestingly, spotevent.sh does not reference that variable at all. Perhaps Tim had some plans for this in the future?

I agree, it really looks like your script code could be integrated into spotevent.sh. Something like:

if [[ $PLAYER_EVENT == "playing" ]]; then run Al's code with "$TRACK_ID" and dump the metadata [/to/some/file]

Then the overlay php can grab what it needs from [/to/some/file].

[Nutul]

Interestingly, spotevent.sh does not reference that variable at all. Perhaps Tim had some plans for this in the future?

This script, for what I see, is used to a) stop mpd when Spotify takes over, and b) eventually resume mpd playback when Spotify ends, and the behavior is set so in the configuration. Good it is there, so we can use it.

I agree, it really looks like your script code could be integrated into spotevent.sh. Something like:
if [[ $PLAYER_EVENT == "playing" ]]; then run Al's code with "$TRACK_ID" and dump the metadata [/to/some/file]
Then the overlay php can grab what it needs from [/to/some/file].

We need also to check if the track ID is different from the last one.
It could either write a file and some service at intervals could check it; or it may invoke the php, a more reactive solution IMO, if it is viable, of course.

My script also needs to be tested during playback, to see what is the impact against the caller - that is: librespot, aka the player... if the call is blocking and the operation takes long, it could affect playback...

ETA
There are variables being set, at least this is what the log has to say... there is PLAYER_EVENT, OLD_TRACK_ID and TRACK_ID...
so a if [ PLAYER_EVENT == changed && OLD_TRACK_ID != TRACK_ID ] should keep us on the safe side...
There is also the DURATION and POSITION_MS, both in ms

I am a bit rusty about shell variables... and can't use librespot, but I may think of giving you a small change to the spotevent.sh script just to check if we can detect the correct moment to interrogate spotify...

[Nutul]

Code:

2024-01-24 20:44:48.414941 INFO [src/bin.rs:420] Capture finished
2024-01-24 20:44:48.420066 INFO [src/bin.rs:410] Playback finished
[2024-01-24T20:44:48Z INFO  librespot_playback::player] Loading <夜にダンス> with Spotify URI <spotify:track:0RffFIV29Yb7vjGokb0e6q>
[2024-01-24T20:44:48Z INFO  librespot_playback::player] <夜にダンス> (256875 ms) loaded
[2024-01-24T20:44:48Z INFO  librespot::player_event_handler] Running ["/var/local/www/commandw/spotevent.sh"] with environment variables {"TRACK_ID": "0RffFIV29Yb7vjGokb0e6q", "PLAYER_EVENT": "playing", "POSITION_MS": "0", "DURATION_MS": "256875"}
2024-01-24 20:44:48.931375 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2024-01-24 20:44:48.931499 INFO [src/bin.rs:712] Running on linux, aarch64
2024-01-24 20:44:48.975094 INFO [src/alsadevice.rs:161] Starting playback from Prepared state
[2024-01-24T20:45:07Z INFO  librespot::player_event_handler] Running ["/var/local/www/commandw/spotevent.sh"] with environment variables {"OLD_TRACK_ID": "0RffFIV29Yb7vjGokb0e6q", "TRACK_ID": "14f6jZAEm43fqsrrZpYVeT", "PLAYER_EVENT": "changed"}
no pid file present!
ALSA lib libasound_module_pcm_cdsp.c:869:(cdsp_hw_free) Error executing camilla_exit_cmd /usr/local/bin/cdspstorevolume

2024-01-24 20:45:08.554882 INFO [src/bin.rs:420] Capture finished
2024-01-24 20:45:10.642460 INFO [src/bin.rs:410] Playback finished
[2024-01-24T20:45:10Z INFO  librespot_playback::player] Loading <Ones And Zeros> with Spotify URI <spotify:track:14f6jZAEm43fqsrrZpYVeT>
[2024-01-24T20:45:11Z INFO  librespot_playback::player] <Ones And Zeros> (267360 ms) loaded
[2024-01-24T20:45:11Z INFO  librespot::player_event_handler] Running ["/var/local/www/commandw/spotevent.sh"] with environment variables {"DURATION_MS": "267360", "PLAYER_EVENT": "playing", "TRACK_ID": "14f6jZAEm43fqsrrZpYVeT", "POSITION_MS": "0"}
2024-01-24 20:45:11.091851 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2024-01-24 20:45:11.092328 INFO [src/bin.rs:712] Running on linux, aarch64
2024-01-24 20:45:11.175354 INFO [src/alsadevice.rs:161] Starting playback from Prepared state

And Al's script works as expected:

Code:

moode@moode:~ $ ./metaspot.sh 5qhGBRamxnwW6peITFjCPo
Artist: Barney Bentall
Album : Gift Horse
Track : 4 - Too Good To Be True   (3:33)
Cover : https://i.scdn.co/image/ab67616d0000b273033f8bf880436443b7cc3074

Theoretically, that's all the "data" that we need, just need to figure out how to tie it all together and display it in the overlay.

There is the problem of the log file to deal with, of course. Even though verbose logging is not necessary, eventually the log file will become a problem. That's a lot of wasted cycles and space when all we need, literally, is the most recent occurence of "Spotify URI <spotify:track:xxxxxxxxxxxxxxxxxxx>" in the log. Maybe there is a way to "watch" the log file for "Spotify URI <spotify:track:", parse the track ID, dump it to a state file, and route the rest of the log file to /dev/null ?? Then, Al's script could be written to watch the state file and grab new metadata any time the trackID in the state file changes.

I bet there is a way better approach to this. I have been looking at "spotifyd", which appears to be a daemonized branch of librespot written in rust, with more "extras". From discussion I read, metadata was on the radar (and playback controls). I haven't had time to install it and play with it yet.

Hi,

can you modify the /var/local/www/commandw/spotevent.sh and add the following lines, always, that is, before the very first IF
(then we need to change that script, because ATM for any event other than "started" or "stopped" it just exits... adding these lines before the test at least gets us how-and-when it gets called...)

echo "`date +%Y-%m-%dT%T.%N` - PLAYER_EVENT = ${PLAYER_EVENT}" >> /var/log/moode_spotevent.log
echo "`date +%Y-%m-%dT%T.%N` - OLD_TRACK_ID = ${OLD_TRACK_ID}" >> /var/log/moode_spotevent.log
echo "`date +%Y-%m-%dT%T.%N` -     TRACK_ID = ${TRACK_ID}" >> /var/log/moode_spotevent.log
echo "`date +%Y-%m-%dT%T.%N` -  DURATION_MS = ${DURATION_MS}" >> /var/log/moode_spotevent.log
echo "`date +%Y-%m-%dT%T.%N` -  POSITION_MS = ${POSITION_MS}" >> /var/log/moode_spotevent.log

Then, cast some songs in Spotify, and also do the following:

1. play a song, wait for it to finish, and play the next song. After some time you can stop it.
2. play a song, halfway through select another one to play
3. play a playlist, at least two songs (or do as at point 1)

This to see how many times the script gets called; hopefully only one time per event (STOP / PLAYING / CHANGED)

[cogitech]

Hi @Nutul

Thanks for that, I will try it later today if I have time.

I also noticed that the script is executing sql commands, such as:

Code:

if [[ $PLAYER_EVENT == "started" ]]; then
       $(sqlite3 $SQLDB "UPDATE cfg_system SET value='1' WHERE param='spotactive'")

It seems to me that it might make more sense to do the same with the metadata. The db would need to be modified accordingly. Then the php code could pull the metadata and image url from the db (as I am sure it does for other parameters/settings, etc.).

The only issue I see with this idea is that it requires quite a lot of work and the result is "eye candy". This is fun to work through, for sure, but at some point you have to ask "is it worth the effort"? I don't know. Is it?

(after all, if someone wants to know what song is playing, simply look at the Spotify app on your phone/tablet)