I have had Mopidy and mopidy-spotify running for quite some time on Raspbian. My brother told me it broke a while ago (his playlists weren’t showing he said) so I decided this was the time to reinstall and start from scratch.
This is a Raspberry Pi 3 with the latest Raspbian (based on pre-release Debian Buster). I read here in the forums that the Mopidy apt repos (for Stretch) worked fine with Debian Buster, so that’s what I am running now.
Mopidy is at 2.2.2 (I saw 2.2.3 just got released but it’s not showing up in the repo yet), mopidy-spotify was at 3.1.0 but I replaced it with the code from PR #188 as per kingosticks’ instructions. After a restart, his playlists were showing again; however, hitting play doesn’t do anything. /var/log/mopidy/mopidy.log doesn’t show anything either. A lot of this did show up in the log though, after a bit of delay:
2019-06-28 22:14:32,181 ERROR [1168:HttpServer] mopidy.http.handlers: WebSocket request error:
2019-06-28 22:14:32,183 ERROR [1168:HttpServer] mopidy.http.handlers: WebSocket request error:
2019-06-28 22:14:32,186 ERROR [1168:HttpServer] mopidy.http.handlers: WebSocket request error:
2019-06-28 22:14:32,214 INFO [1168:HttpServer] tornado.access: 200 GET /moped/ (10.0.0.10) 16.99ms
2019-06-28 22:14:32,219 INFO [1168:HttpServer] tornado.access: 200 GET /moped/ (10.0.0.10) 2.77ms
2019-06-28 22:14:40,216 ERROR [1168:HttpServer] tornado.application: Future exception was never retrieved: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/tornado/gen.py", line 1141, in run
yielded = self.gen.throw(*exc_info)
File "/usr/lib/python2.7/dist-packages/tornado/websocket.py", line 876, in wrapper
raise WebSocketClosedError()
WebSocketClosedError
I have browsed through the open bugs and searched the forum but I’m not finding anything about Spotify playback being broken. The Spotify login itself works (log says login is succesful) and the personal playlists are showing so not sure what the issue is here.
Playing saved radio streams (local stations outside Spotify) doesn’t work either (nor does playback through the TuneIn plugin, it seems).
No solid ideas off the top of my head. Does the UI act like it’s playing back or does it immediately stop? Do you have a local library and if so, does it play back? What happens if you eliminate Mopidy from the equation and just try to directly play back a file from gstreamer? https://www.systutorials.com/docs/linux/man/1-gst-play-1.0/
@KraigoMpls Thanks. The UI does nothing. I click the play buttons, nothing happens, dragging the dot on the time progress bar and dropping it somewhere in the middle doesn’t do anything either.
@kingosticks This is what I have as per the debugging instructions.
/var/log/mopidy/mopidy-debug.log seems largely identical to the one I linked to above and it’s too big to paste but I can split it over multiple pastes if needed?
@kingosticks I ran the debug commands a few days ago but Akismet has hidden my post because it suspects it’s spam. Could you (or another admin) have a look at it?
There are quite a few suspicious looking GStreamer ALSA errors in your debug log. What audio device are you trying to use? The onboard audio or something else?
I got my Raspbian Buster (Desktop) to work yesterday morning. No major missteps, but I do find it useful to test everything along the way. First I install the OS, then do my customizations for hostname, static IP, etc., then hook up the audio card (HiFiBerry DACPlus) and automatically mounting the thumb drive the music library is hosted on.
Since I’m using the full GUI I can use VLC to test audio at that point or I can use something lighter weight. I’m not sure if VLC uses GStreamer, so you may want to submit the job straight to GStreamer.
After all of that I can install Mopidy then MusicBox and any extensions.
I make enough mistakes along the way that incremental installations and testing when you can is the best route to success. Sorry if this post is so obvious it’s a waste of everyone’s time. The data point I have to offer is that, as expected, there is nothing about Buster per se that is making your setup not work.
Added: Sort of works anyway. I can start streams from the local library or TuneIn, I can control the volume, but I have limited control (e.g. stop/pause) with the controls. I have not done any troubleshooting of the issue yet and may not get to it tonight as this is a fairly low priority item requiring a rainy day (which we may get over this long weekend) to properly address.
The RPi is at my brother’s, they’re away for the weekend so I won’t be able to test the sound output until following week. Running the gstreamer command gives me this:
# LANG=C gst-launch-1.0 audiotestsrc ! audioresample ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock
The devices has a Hifiberry Amp installed (that worked fine on the previous Raspbian Jessie image, I don’t think Buster is to blame here). It’s a Raspbian Lite, libpulse0 is installed (by default it seems) but Pulseaudio is not. Previous setup was a headless image as well. I have disabled the onboard audio so there’s only the Hifiberry Amp:
Hey guys. Sorry about the delay… So I have access again and ran the test you asked:
# aplay /usr/share/sounds/alsa/Front_Center.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
aplay: set_params:1345: Channels count non available
No sound from that test file.
And the gst-launch command again:
# LANG=C gst-launch-1.0 audiotestsrc ! audioresample ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock
As per the ‘testing sound output’ instructions I checked raspi-config as well but it shows the following:
Choose the audio output
0 Auto
1 Force 3.5mm ('headphone') jack
2 Force HDMI
Picking ‘auto’ errors out with ‘There was an error running option A4 audio’. I have double checked for pulseaudio, it’s not installed and there’s no pulseaudio processes running either. Pulseaudio stuff is stuff that seems to be pulled in by other packages:
# dpkg -l|grep pulse
ii gstreamer1.0-pulseaudio:armhf 1.14.4-1 armhf GStreamer plugin for PulseAudio
ii libpulse0:armhf 12.2-4 armhf PulseAudio client libraries
@kingosticks I checked that other thread you linked to but he apparently did have pulseaudio installed and running, that’s not the case here AFAICT.
I also re-enabled onboard audio but that doesn’t change anything (which I could have guessed myself but one never knows). Commands above have been re-run with onboard audio enabled (and device in /etc/asound.conf set to 1 instead of 0), same outcome.
Are there any stereo .wav files you can try? My HiFiBerry Dac+ also refuses to open as a mono device. On the HiFiBerry site, Daniel has a person try MPlayer (I think) for testing because it will play more formats. My library is all .flac files, so aplay won’t do it. When I put a stereo .wav on a flash drive and redid the test it worked as planned.
I’m saying that in your case, the aplay test is not a valid one.
In your GST_DEBUG log. Could you try specifying alsasink in your Mopidy output config section:
[audio]
output = alsasink
EDIT: I’m not convinced this will do anything. The debug log actually looks OK when you consider it’s all warnings rather than errors. I think we need to concentrate on getting any kind of sound output to work on your setup before bringing Mopidy into the mix. I am extremely surprised to hear that the aplay command didn’t work with the onboard sound - that does not make sense to me.
Thanks for your help so far guys. It looks more and more like this is an issue with Debian Buster. I have also installed raspotify in the meantime and we can interact just fine with that, but no sound either.
I have tried ALSA’ test files in /usr/share/sounds/alsa/ and a normal music WAV file, but the whole system stays mum. So I’ll be trying a Debian Stretch based Raspbian next.
Hey guys. As a follow-up, it turned out that, while volume at 30% was plenty on Raspbian Jessie, it was woefully insufficient on Stretch on Buster. We had to turn it all the way up to get sound. So the sound issues turned out to be just volume issues, unfortunately… Something we were unable to confirm for a long time since my brother could only test when his kids were in bed.
That’s odd. I’ve used Jessie, Stretch and Buster in my system and I have never noticed a change in volume between versions, much less as drastic as you mention.