Mopidy Locks up with Filesink (for snapcast)

General
1

Hi, I’m running Mopidy as Musik-Source for my Snapcast multiroom audio with transcoding (to always have the correct sampling rate) and an file-sink.

Playing start immediatly, however if I want to pause or switch tracks (no matter if stream, spotify or local media) mopidy locks up for 15-600 seconds.in this time neither webif nor mpd work (more or less hang waiting for data)

deps
sysadmin@server-musik-wien:~$ mopidy deps
Executable: /usr/bin/mopidy
Platform: Linux-3.16.0-4-amd64-x86_64-with-debian-8.6
Python: CPython 2.7.9 from /usr/lib/python2.7
Mopidy: 2.0.1 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=2.3: 3.2.2 from /usr/lib/python2.7/dist-packages
Mopidy-MusicBox-Webclient: 2.3.0 from /usr/local/lib/python2.7/dist-packages
setuptools: 5.5.1 from /usr/lib/python2.7/dist-packages
Mopidy>=1.1.0: 2.0.1 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=2.3: 3.2.2 from /usr/lib/python2.7/dist-packages
Mopidy-Moped: 0.7.0 from /usr/local/lib/python2.7/dist-packages
setuptools: 5.5.1 from /usr/lib/python2.7/dist-packages
Mopidy>=1.0.0: 2.0.1 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=2.3: 3.2.2 from /usr/lib/python2.7/dist-packages
Mopidy-Local-Images: 1.0.0 from /usr/local/lib/python2.7/dist-packages
uritools>=1.0: 2.0.0 from /usr/local/lib/python2.7/dist-packages
ipaddress: 1.0.17 from /usr/local/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
setuptools: 5.5.1 from /usr/lib/python2.7/dist-packages
Mopidy>=1.1: 2.0.1 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=2.3: 3.2.2 from /usr/lib/python2.7/dist-packages
Mopidy-Podcast: 2.0.1 from /usr/local/lib/python2.7/dist-packages
Mopidy>=1.1.1: 2.0.1 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=2.3: 3.2.2 from /usr/lib/python2.7/dist-packages
uritools>=1.0: 2.0.0 from /usr/local/lib/python2.7/dist-packages
ipaddress: 1.0.17 from /usr/local/lib/python2.7/dist-packages
setuptools: 5.5.1 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
cachetools>=1.0: 2.0.0 from /usr/local/lib/python2.7/dist-packages
Mopidy-Spotify: 3.0.0 from /usr/lib/python2.7/dist-packages
Mopidy>=2.0: 2.0.1 from /usr/lib/python2.7/dist-packages
Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
tornado>=2.3: 3.2.2 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.1.2 from /usr/lib/python2.7/dist-packages
pycparser: 2.10 from /usr/lib/python2.7/dist-packages
requests>=2.0: 2.4.3 from /usr/lib/python2.7/dist-packages
GStreamer: 1.4.4.0 from /usr/lib/python2.7/dist-packages/gi
Detailed information:
Python wrapper: python-gi 3.14.0
Relevant elements:
Found:
uridecodebin
souphttpsrc
appsrc
alsasink
osssink
oss4sink
pulsesink
id3demux
id3v2mux
lamemp3enc
mad
mpegaudioparse
vorbisdec
vorbisenc
vorbisparse
oggdemux
oggmux
oggparse
flacdec
flacparse
shout2send
Not found:
flump3dec
mpg123audiodec

mopdidy conf
[audio]
mixer_volume = 100

output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! filesink location=/tmp/snapfifo_1

[mpd]
hostname = ::
port = 6601
#password =
zeroconf = Musik Wohnzimmer

[http]
hostname = ::
port = 6681
zeroconf = Musik Wohnzimmer

I’m running mopidy as service with an core and zone specific config file.

2

Hi,
I have almost the same problem. From what I’ve found, mopidy hangs while writing to the snapcast fifo. If I delete the fifo (after stopping snapserver) and creating an empty file before starting mopidy, all seems to work ok. The file is written to and the web interface is still responsive.
I’ve also found that if using spotify instead of local media the problem is not as severe. This makes me wonder if it also is
related to disk access.

There must be some one that has some Idea how to solv this. Mopidy(spotify) and Snapcast is a real Sonos killer!

Best regards

Per-Ola

3

What pi are you running it on - it has been running flawlessly, using mainly spotify, for me over the past 3 months.
Standard set up; Pi3 running Mopidy and Snapserver & Snapclient wirelessly
Pi B+ running Mopidy & Snapclient Hard wired
3 x Pi Zero W running Mopidy & Snapclient wirelessly.
I did experience problems with bad wifi connections and this caused a lot of stuttering earlier on.
Have you tried running it with all your Snapclients closer to the router (or wireless source) or hard wiring them in. At one point we had all 5 in the same room, then slowly moved them around the house to get the best signal.

I will try some local media and let you know if I get a problem.

4

Hi Steve and all,
Some back ground info, I’m trying to move away from a LMS server with Pi:s in 4 rooms running squeezlite. All hardwired. This setup has worked great for years playing local media and Spotify. A couple of weeks ago Spotify abandoned Logitech…

Now I’m evaluating an alternative. Test setup as follows:
Server:
Linux Mint on VirtualBox running Mopidy 2.1.0, Moped 0.7.1 and Snapserver 0.11.1 (as user, not daemon)
Client:
Pi:A with Hifi-Berry-DAC running snapclient v0.11.1, Raspbian GNU/Linux 8.0 (jessie)

Mopidy + Moped works great on local soundcard. And when writing to a dummy file instead of fifo. This makes
me wonder if mopidy is using blocking writes to the fifo…

I’m a developer but unfortunatly I’ve never learned Python, It would have been helpful now…

/Per-Ola

5

I’m afraid most of what you said is over my head - however have you tried Snapclient on the Virtualbox, If it plays then you could probably put it down to the Pi A not being fast enough to cope or a connection problem.

6

I’m running a similar system:

(3x) Pi3 + (1x) Pi2 - Standard Jessie (full GUI) with Mopidy and Musicbox installed. They are all set up as both SnapServers and SnapClients, but only one of the Pi3’s has Mopidy, Musicbox and SnapServer daemons enabled. The rest are failovers and staged for the day when I can have multiple servers dynamically assigned to clients.

(4x) PiB - Standard JessieLite with SnapClient installed.

All are running HiFiBerry DACs.

My system has been working pretty well for a year at least.

A few months ago BadAix found and fixed a bug in SnapCast that may be related to your issue. I went through and updated all eight RPI’s, which was a pain. The system is still stable after that. You may want to verify that you’re running the latest SnapCast (v0.11.1 apparently) throughout the network.

I see in Stenborg’s post that he is, which isn’t surprising since it was apparently released last March. I’m running everything as a daemon. Our systems are similar. I mostly play local media and TuneIn. I can’t imagine that the source should matter given the description.

I’m not pointing fingers at either Mopidy or SnapCast as it could be either or an interaction, but have you checked in with SnapCast’s forums (https://github.com/badaix/snapcast) as well?

I know “It works on mine” isn’t that helpful. Sorry.

KO

7

Hi all,
thanks kraigompls69, it’s nice to know that it should work:) I’ll do some more digging in the next days. I’m wondering if somehow the virtualized environment affects performance. I’ll try to find some “real” hardware to test the server side on.
I’m pretty sure that the problem is on the server side, not the pi/client.

/Per-Ola Stenborg