Spotify web player in moOde local display

[Master_Plo]

@TheOldPresbyope Do you think it is possible to do something like the web UI of MoOde, but with the Chromium page that I am visiting? I have successfully modified the .xinitrc and I can visit the Spotify and Tidal web applications, but It would be far better if I could connect from my PC, like in the web UI, and control the chromium tab from there.

[TheOldPresbyope]

Hello there, regarding just replacing chrome I ran into issues which I seem to be unable to resolve:



Anyone more knowledgeable who could help me?
(uninstalling chromium is not possible)

Ah, looks like some apt packages have been marked "hold".

If that's not enough of a hint, I'll need to spin up a copy of 8.2.2 (all my players are running pre-release versions of 8.2.3 at the moment) to make sure I suggest the correct work-around for that release.

Regards,
Kent

[TheOldPresbyope]

@TheOldPresbyope Do you think it is possible to do something like the web UI of MoOde, but with the Chromium page that I am visiting? I have successfully modified the .xinitrc and I can visit the Spotify and Tidal web applications, but It would be far better if I could connect from my PC, like in the web UI, and control the chromium tab from there.

Perhaps I don't understand what you are asking. Right now you can open the Spotify Web Player in your PC's web browser and choose your moOde  player's Spotify Connect renderer as the output device. Seems like that's what you are describing.

Tidal is somewhat similar but (to the best of my knowledge) there's no acceptable open-source implementation of the Tidal Connect protocol so you'd have to use Bluetooth or AirPlay to connect to the appropriate renderer on your moOde player.

Regards,
Kent

[TheOldPresbyope]

Hello there, regarding just replacing chrome I ran into issues which I seem to be unable to resolve:



Anyone more knowledgeable who could help me?
(uninstalling chromium is not possible)

Ah, looks like some apt packages have been marked "hold".

If that's not enough of a hint, I'll need to spin up a copy of 8.2.2 (all my players are running pre-release versions of 8.2.3 at the moment) to make sure I suggest the correct work-around for that release.

Regards,
Kent

OK, so on an 8.2.2 player I ran apt-mark to see what packages are marked

Code:

pi@mmoode:~ $ apt-mark showhold
alsa-cdsp
alsacap
bluez-alsa-utils
camilladsp
camillagui
caps
chromium-browser
chromium-browser-l10n
chromium-codecs-ffmpeg-extra
libasound2-plugin-bluez
librespot
mediainfo
minidlna
moode-player
mpd
python3-libupnpp
raspberrypi-kernel
shairport-sync
squeezelite
trx
udisks
udisks-glue
upmpdcli

You'll notice that three chromium-related packages are marked hold.

This could also be determined using the dpkg command

Code:

pi@moode:~ $ dpkg --get-selections chromium*
chromium-browser                hold
chromium-browser-l10n                hold
chromium-codecs-ffmpeg-extra            hold

You can unhold these packages one at a time or go-for-broke and do all chromium-related packages at once

Code:

pi@moode:~ $ sudo apt-mark unhold chromium-browser
...repeat for the other two packages...

# or

pi@moode:~ $ sudo apt-mark unhold chromium-*

Note that in the latter case you'll get a lot of lines about packages which are "already not hold" in addition to the three "cancelled hold" packages. 

Now you're on your own.

Regards,
Kent

[Tim Curtis]

Hello there, regarding just replacing chrome I ran into issues which I seem to be unable to resolve:



Anyone more knowledgeable who could help me?
(uninstalling chromium is not possible)

Ah, looks like some apt packages have been marked "hold".

If that's not enough of a hint, I'll need to spin up a copy of 8.2.2 (all my players are running pre-release versions of 8.2.3 at the moment) to make sure I suggest the correct work-around for that release.

Regards,
Kent

There is a set of packages marked as held to prevent breakage if something like apt upgrade were attempted.

The commands to control the hold status are below.

Code:

sudo moode-apt-mark unhold
sudo moode-apt-mark hold

[Ale2.0]

Can confirm that the workaround indeed works.
Just use these three commands in order and you will be able to use the Spotify Webplayer on your system.

Code:

sudo moode-apt-mark unhold
sudo apt install chromium-browser:armhf libwidevinecdm0
sudo moode-apt-mark hold

[Tim Curtis]

Can confirm that the workaround indeed works.
Just use these three commands in order and you will be able to use the Spotify Webplayer on your system.

Code:

sudo moode-apt-mark unhold
sudo apt install chromium-browser:armhf libwidevinecdm0
sudo moode-apt-mark hold

Interesting and couple of questions.

1. Do you think this could be used to provide a generalized feature for accessing and playing music from streaming services?

2. Can chromium-browser be configured to route audio to locally attached USB or I2S ]audio devices?

[TheOldPresbyope]

Can confirm that the workaround indeed works.
Just use these three commands in order and you will be able to use the Spotify Webplayer on your system.

Code:

sudo moode-apt-mark unhold
sudo apt install chromium-browser:armhf
sudo moode-apt-mark hold

Interesting and couple of questions.

1. Do you think this could be used to provide a generalized feature for accessing and playing music from streaming services?

2. Can chromium-browser be configured to route audio to locally attached USB or I2S ]audio devices?

As I said earlier, this isn't really a use-case I'm interested in, but I haven't seen a reply from the OP yet, so here's my 2-cents worth.

I'd expect this would work for any streaming service which provides an in-browser player experience. 

To test, I flashed the 32-bit moOde 8.2.4 image to another uSD card and fired it up on an RPi3B+ with an Official 7-in touch screen and a USB DAC (actually, my Creative Tech USB-BT adapter, which enumerates as a USB audio device). I chose the 32-bit image to minimize the hackery; of course I added the requisite libwidevinecdm0 library.

I configured moOde to output to my Creative Tech adapter and tested everything was working by listening via Bluetooth earphones to several radio stations.

I tried starting the local display om three different streaming services: Spotify (open.spotify.com), Qobuz (play.qobuz.com), and Youtube Music (music.youtube.com). I didn't try Tidal or Amazon Music.

1) Qobuz advises it needs a screen at least 1024 wide and won't go further.

2) Spotify comes up and after signing in, I can browse and play tracks. However, the Chromium browser is playing to the first alsa card which is the RPi3B+ headphone jack, confirmed by looking at /proc/asound/card0/pcm0p/sub0/status and later by plugging in some earbuds.

3) Youtube Music, same behavior as with Spotify.

Observations:

1. I have no idea how you'd blend this with the existing moOdeUI.


2. Signing into these web apps is annoying. The popup keyboard doesn't work in the browser so I had to plug in a USB keyboard. I haven't figured out a way to preserve the credentials between sessions. (In any case, some folks might feel squiggy about saving credentials on a relatively insecure system. I know I do for some.)

3. In general, the sign-in processes are tuned to modern Internet Security practices. For example, my trial Youtube Music account is tied to my Google account which entails 2FA. Things get messy.

4. I thought the Youtube Music layout looked good and worked well with the touch-screen size and aspect ratio. Spotify seemed, well, a bit more fiddly.

5. I haven't found Google documentation which clearly states the variables involved with alsa device selection. Some search hits (StackOverflow, for example) suggest using an environmental variable ALSA_CONFIG_PATH to redirect to a different alsa.conf file. That's an alsa-project variable and I don't know how to use it in the moOde context. Other hits suggest using an undocumented Chromium-Browser startup switch --alsa-output-device.[1] The syntax seemed to be (to use second alsa card for example):

Code:

chromium-browser ... --alsa-output-device=hw:1,0

That's not working for me; I'm still getting output from card 0, the headphone jack, even when I try enclosing the value in quotes --alsa-output-device="hw:1,0" Indeed, I can use the local browser to play YouTube Music to card 0 while using the moOdeUI on a remote browser to play a radio station to my preset selection: card 1.

I've also seen a different syntax suggested for this option but I believe it was based on using PulseAudio.

Perhaps I'm missing something simple but I've confessed before that the whole ALSA subsystem is a mystery to me.

Regards,
Kent

[1] This switch shows up in Peter Beverloo's wonderful list, of course, but with no syntax suggested.

[Tim Curtis]

Given that result I imagine that the current casting approach is the only truly generalized solution that uses a Music Service's native Web Player. Another option would be to integrate a Music Service via one of the wrapper API's.

[guitz]

Hello everyone,
I am a happy moode user, but also with the same usecase as the OP, which brought me eventually to this thread.
On top of this I do not have a screen attached to my pi so I would enjoy a fully remote connection.

While I do not have a solution to the problem, I wanted to report on another approach I took and which allowed me to come one step closer. Using a standard 64bit install of moode I added to it docker compose and installed the following image:
https://docs.linuxserver.io/images/docker-webtop
It worked straight out of the box and provided me with a destkop interface running linux with all standard applications installed, including firefox. I believe guacamole is used to serve the desktop interface via xrdp + some web wrapper.
You access the desktop from your web browser by going to the address
http://host:3000
where host is moode in my standard installation of the system. Effectively this is the moode server address but using the port 3000 rather than the standard 80 one.

I could log in to play.qobuz.com and open.spotify.com just like usual (using my standard computer keyboard).
An added benefice is one can also mount using standard docker options any folder, which I did to add an audio file tag editor software and tweak a few tags in my music library.
This works with both a raspberry pi 3 and 4, though the experience is much smoother with the pi 4 system.

Where things break currently is on the audio side: by default the sound is propagated together with the image to my web client, and does not exit the docker image to reach the underlying system. I tried to find some documentation on how to route the sound where we would like it but could not find anything. I wonder if this is actually possible without using some sort of broadcasting technology which would efectively allow docker image and hosting system to communicate.

So still pretty useless for our purpose, but there might be someone more knowledgeable than I here in this forum.
I have kept the image running as way to install extra stuff if I need (example the audio file editor) without messing too much with moode's standard installation (do not mess with a running system!)
Also I don't think this approach will work using a small screen (like a smartphone).

Hope this brings us a tiny bit further.