Mopidy not playing anything (mopidy-tunein, mopidy-spotify)

Hey guys!

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/ ( 16.99ms
2019-06-28 22:14:32,219 INFO [1168:HttpServer] tornado.access: 200 GET /moped/ ( 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/", line 1141, in run
    yielded = self.gen.throw(*exc_info)
  File "/usr/lib/python2.7/dist-packages/tornado/", line 876, in wrapper
    raise 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).

Any thoughts?

Thank you!

Bumpty bump.

Hoping someone can provide some insight :slightly_smiling_face:

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?

FWIW, I built up a new Raspbian disk yesterday. If time permits I’ll get audio and the like going on it today and test. I use TuneIn, but not Spotify.

Please run through

@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.

Mopidy config

cache_dir = /var/cache/mopidy
config_dir = /etc/mopidy
data_dir = /var/lib/mopidy
max_tracklist_length = 10000
restore_state = false

color = true
console_format = %(levelname)-8s %(message)s
debug_format = %(levelname)-8s %(asctime)s [%(process)d:%(threadName)s] %(name)s\n  %(message)s
debug_file = /var/log/mopidy/mopidy-debug.log
config_file = /etc/mopidy/logging.conf

mixer = software
mixer_volume = 
output = autoaudiosink
buffer_time = 

scheme = 
hostname = 
port = 
username = 
password = 

enabled = true
username =
password = ********
client_id = xxxxxxxx-d308-43ae-9b71-xxxxxxxxxxxx
client_secret = ********
bitrate = 160
volume_normalization = true
private_session = false
timeout = 10
allow_cache = true
allow_network = true
allow_playlists = true
search_album_count = 20
search_artist_count = 10
search_track_count = 50
toplist_countries = 

enabled = true

enabled = true
hostname =
port = 6600
password = 
max_connections = 20
connection_timeout = 60
zeroconf = Mopidy MPD server on $hostname
command_blacklist = 
default_playlist_scheme = m3u

enabled = true
hostname =
port = 6680
static_dir =
zeroconf = Mopidy bureau
allowed_origins = 
csrf_protection = true

enabled = true
protocols = 
metadata_blacklist = 
timeout = 5000

enabled = true
base_dir =
default_encoding = latin-1
default_extension = .m3u8
playlists_dir = /var/lib/mopidy/playlists

enabled = true

enabled = true
media_dirs = 
excluded_file_extensions = 
show_dotfiles = false
follow_symlinks = false
metadata_timeout = 1000

enabled = true
library = json
media_dir = /var/lib/mopidy/media
scan_timeout = 1000
scan_flush_threshold = 100
scan_follow_symlinks = false
excluded_file_extensions = 

enabled = true
timeout = 5000

Mopidy deps (mopidy-spotify is from the PR linked in the first post)

Executable: /usr/bin/mopidy
Platform: Linux-4.19.50-v7+-armv7l-with-debian-10.0
Python: CPython 2.7.16 from /usr/lib/python2.7
Mopidy: 2.2.2 from /usr/lib/python2.7/dist-packages
Mopidy-Moped: 0.7.1 from /usr/local/lib/python2.7/dist-packages
  setuptools: 40.8.0 from /usr/lib/python2.7/dist-packages
  Mopidy>=1.0.0: 2.2.2 from /usr/lib/python2.7/dist-packages
Mopidy-TuneIn: 0.4.1 from /usr/lib/python2.7/dist-packages
Mopidy-Spotify: 3.1.0 from /usr/local/lib/python2.7/dist-packages
  setuptools: 40.8.0 from /usr/lib/python2.7/dist-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
  pyspotify>=2.0.5: 2.0.5 from /usr/lib/python2.7/dist-packages
    cffi>=1.0.0: 1.12.2 from /usr/lib/python2.7/dist-packages
  Mopidy>=2.0: 2.2.2 from /usr/lib/python2.7/dist-packages
  requests>=2.0: 2.21.0 from /usr/lib/python2.7/dist-packages
GStreamer: from /usr/lib/python2.7/dist-packages/gi
  Detailed information: 
    Python wrapper: python-gi 3.30.4
    Relevant elements:
      Not found:

GST_DEBUG=3 Mopidy -v output

/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?


Could you try
and also run:

gst-launch-1.0 audiotestsrc ! audioresample ! autoaudiosink

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?

This looks similar to No sound from spotify.

Can you try the instructions for PulseAudio? Is this a Raspbian Desktop or Raspbian Lite installation?

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:

# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_amp], device 0: HifiBerry AMP HiFi tas5713.1-001b-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

/etc/asound.conf may be redundant at this point:

pcm.!default  {
  type hw card 0
ctl.!default {
  type hw card 0

@KraigoMpls Thanks for your help trying to reproduce.

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.

The gst-launch command should play a tone. Does it?

The reason I suggested pulseaudio is due to:

0:04:42.504401055 5277 0x7282ba60 WARN pulse pulsesink.c:615:gst_pulseringbuffer_open_device: error: Failed to connect: Connection refused

In your GST_DEBUG log. Could you try specifying alsasink in your Mopidy output config section:

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.