Spotify playing now

[m_g_s_g]

Sorry if I'm hijacking this thread, but from its title, it looks like the right one to me.

I've further investigated this possible feature and I got some promising results. This is what I've done so far:

0. Open a SSH session to your moode raspberry pi IP.
1. Stop librespot (included with moOde and started if you activate a Spotify renderer). F.i.: using htop.
2. Install vollibrespot. This is a small wrapper around the librespot core library that broadcasts Spotify song metadata through udp:
wget https://github.com/ashthespy/Vollibrespo...v7l.tar.xz
tar -xf vollibrespot-armv7l.tar.xz
3. The parameters that moOde uses for librespot can be seen in /www/inc/playerlib.php (line 2633). Some of them are gathered from the moOde configuration parameters you complete from the web UI. The exact parameters used to launch last session could be seen in htop (before killing librespot), for instance.
4. Vollibrespot doesn't use the same command line args as librespot. You need to create and edit a toml file (config.toml). Most of the parameters are the same; only the onevent argument doesn't exist. More on that later.
5. You can start now vollibrespot, and you will see your "moOde Spotify connect renderer" from a Spotify app on another device, and you can play some music through moOde:
sudo ./vollibrespot -c ./config.toml --verbose
6. I've created a small simple php script (udpclient.php) that reads Spotify song metadata from UDP port 5030 and sends commands (play, stop,...) to UDP port 5031. When I launch it, I can see the song metadata in the terminal.
7. Since librespot no longer starts this shell script: /var/local/www/commandw/spotevent.sh (no onevent command line parameter, as seen in 4), moOde does not show the usual "dark gray cover modal" (in header.php: inpsrc-msg "INPUT SOURCE INDICATOR").

I would say that the proof of concept was successful.

Of course, many other things would be needed to fully support this feature. At least:

1. Wanting to swap the librespot daemon for vollibrespot. (:-)) = introducing a new piece in the puzzle = risking reliability. I perfectly understand that.
2. Modifying the startSpotify function in /www/inc/playerlib.php to launch vollibrespot instead of librespot.
3. Creating a config.toml template for vollibrespot, and updating some parameters with $cfg_spotify variables (coming from moOde UI Spotify configuration). 
4. Starting a thread that reads from UDP 5030 and writes to UDP 5031 (like my sample udpclient.php does), and stores the song metadata in some global variables/sqlite3/whatever.
5. Update spotevent.sh to the new way of getting metadata and Spotify events.
6. Modifying header.php / INPUT SOURCE INDICATOR to autorefresh (every couple of seconds) and show song/artist/... from the aforementioned global variables/sqlite3/...
7. Modifying the install procedure to additionally download and untar vollibrespot.
8. Testing, testing and testing to see if there are reliability issues.

I'd be happy to help here, but as a moOde newcomer (and not a pro php prog.) there are many things I don't now how to do.

[Alaini93]

@m_g_s_g,  Thanks for looking into it.

[m_g_s_g]

I have a preliminary ("beta") working version of the Spotify Now Playing feature. I've forked the moode repo and created a new branch (nowplaying) here.

When a song is launched from a Spotify app (PC, iPad, Android), moOde shows the currently playing song title/album/artist, just as if played from MPD/File system.

Summary of changes made:
- [/var/local/www/db/moode-sqlite3.db.sql] Added a new Table cfg_nowplaying to store the song metadata. Added new parameter 'vollibrespot' to existing Table cfg_spotify (Yes/No values).
- [/var/www//engine-mpd.php] Changes to "simulate" an MPD status info with the Spotify metadata stored in the database.
- [/var/www/spo-config.php] Changes to support the new cfg_spotify param
- [/var/www/command/sysinfo.sh] Changes to support the new cfg_spotify param
- [/var/www/inc/playerlib.php] Changes to optionally start vollibrespot instead of librespot from startSpotify
- [/var/www/command/worker.php] Kill vollibrespot as well for now
- [/var/www/templates/spo-config.html] Template to show new Spotify config option (vollibrespot) called "Show Metadata"
- [build_recipe.txt] TODO: Skipped for now.
- [snd-config.html] TODO: Skipped for now.

- New files:
- [/var/www/inc/udp_metadata.php] NEW FILE: php daemon that reads UDP metadata info and stores it in sqlib3 cfg_nowplaying table. chmod +x needed.
- [/var/local/www/commandw/install-vollibrespot.sh] NEW FILE: Copies changed files, creates cfg_nowplaying table and inserts default values. chmod +x needed.
- [/usr/local/bin/vollibrespot] NEW FILE: daemon that publishes Spotify connect song metadata. chmod +x needed.

NOTES:
- Why a new table? sqlib3 was used for other stuff, and it looked to cleanest way to communicate to moOde the metadata captured by vollibrespot.
- Now when playing a song from Spotify, the moOde web display is not covered with a "Playing from Spotify" message anymore. You just see the usual display with the now playing song, as if it was playing from MPD.
- Only title, album, artist (first one) and cover image are updated for now. The cover image doesn't automatically refresh. You have to refresh manually the page.
- To avoid constant info refreshes in the web browser, a 10seg sleep has been hardcoded in engine-mpd.php. There's for sure a better way to notify the web ui that new data is available for it to refresh, but I didn't find it.

TODO:
- Update additional info that is accesible: current song elapsed time, bitrate,...
- Backup MPD current track info before showing anything from Spotify and restore once Spotify is paused.
- Auto-restart vollibrespot / udp_metadata if they crash.
...


HOW TO INSTALL:
- Download vollibrespot from your Raspberry Pi:
    wget https://github.com/ashthespy/Vollibrespo...v7l.tar.xz
    tar -xf vollibrespot-armv7l.tar.xz

- Download all mentioned files from the nowplaying branch in my forked repo to a directory in your Raspberry Pi.
- chmod the specified files.
- Execute ./install-vollibrespot.sh (will copy the file to the right directories and create the new database table)
- Restart and configure the Spotify renderer to use vollibrespot instead of librespot. Restart again and try.

Finally, some questions: Is there a documented way to contribute to moOde? Are pull requests welcome?

[m_g_s_g]

[...] As always though, the door is open if a dev wants to volunteer their time and effort to contribute to moOde.

(And my previous post was for exactly this reason...    )

[Alaini93]

Great work on this.

It would be nice if a plug-ins system existed.

[TheOldPresbyope]

@m_g_s_g

Finally, some questions: Is there a documented way to contribute to moOde? Are pull requests welcome?

If you look at the github repo for moOde you'll see that there have been 243 PRs to date.

Regards,
Kent

[m_g_s_g]

@m_g_s_g

Finally, some questions: Is there a documented way to contribute to moOde? Are pull requests welcome?

If you look at the github repo for moOde you'll see that there have been 243 PRs to date.

Regards,
Kent

Thanks, I didn't check it before asking, sorry.

I'll test it for some days and launch a PR if all is Ok.

[Tim Curtis]

The approach is somewhat similar to what was done several years ago to support Airplay metadata. It proved to be overly complex, unreliable and impossible to maintain.

Core components like engine-mpd.php and the rest of the MPD idle timeout pipeline are not on the table to be modified since they provide the underlying reliability for moOde. The renderer management framework is designed to be separate from core MPD framework to ensure its own reliability. If the two were to become intertwined the overall system would become unreliable.

Renderer metadata would need an approach that keeps it in its own pipeline, separate from core MPD components and it would need to prevent UI access to any MPD functions.

[m_g_s_g]

The approach is somewhat similar to what was done several years ago to support Airplay metadata. It proved to be overly complex, unreliable and impossible to maintain.

Core components like engine-mpd.php and the rest of the MPD idle timeout pipeline are not on the table to be modified since they provide the underlying reliability for moOde. The renderer management framework is designed to be separate from core MPD framework to ensure its own reliability. If the two were to become intertwined the overall system would become unreliable.

Renderer metadata would need an approach that keeps it in its own pipeline, separate from core MPD components and it would need to prevent UI access to any MPD functions.

Understood. Yes I can imagine many things that can go wrong mixing both... It was a shortcut to get a quick working demo.

Would it be possible to automatically redirect the user to a separate renderer page (separated from MPD core components) once it is identified that Spotify is active, instead of showing a cover over the MPD user interface? In the future this could be reused for Airplay/Sonos or whatever.

This renderer status page would show song title/author/album cover along with some minimal user interaction controls (play/pause) using the same visual style as for MPD (but without sharing any code).

Would one of the configuration pages (like spo-config.php + html template) be a good model from an application architecture point of view to use for a new hypothetical “renderer-status.php + .html”?

[Tim Curtis]

Conceptually what you want to do is replace the "Renderer Active" overlay screen with a screen that shows the metadata and controls for the renderer. I suppose it could be similar in appearance to the CoverView screen. This kind of approach would prolly be minimally invasive. Maybe something like a cfg_system setting thats checked in playerlib.js to control whether to display the "Render Active" screen or some other screen.

Front-end
- HTML/CSS
- JS to manage the metadata display and controls
Back-end
- server that provides metadata and cmd/ctrl

I'm just thinking out loud so this may or may not be a good approach.