Mopidy Crashes on use of next song

[deisi]

Hello Folks

When I click the next song button in the web interface (I use moped), mopidy crashes with the message:

Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at 
pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting.

I use mopidy 1.1.0 on a Raspberry Pi 2 running Arch Linux.
mopidy.config
mopidy.log

A quick google research of this messages reveals some old problems with pulse audio. However the same raspberry runs a pure mpd installation and a kodi installation both interfacing with pulse audio without any problem. Only mopidy is crashing with this error.

As long as I do not push the next song button everything runs fine. For this test I used music form google music, but I know for sure that this also happens when playing local music.

PS. The Assertion is actually not part of the mopidy.log, but is printed on the stderr. I pasted it into the log.

[kingosticks]

There is an issue at https://github.com/mopidy/mopidy/issues/933

[jodal]

Yes, but that’s in GLib, not in PulseAudio.

Though, I find it peculiar that all segfaults we ever get reported are on Arch Linux and at the same time we have a lot of Arch Linux users not having any problems.

[deisi]

I switched to alsasink and as a result, I can now switch songs without the crash. However, I see the following line in my logs:

WARNING  Element doesn't implement handling of this stream. Please file a bug.

Because it was wanted in another thread here is my mopidy deps
and here is a more complete debug log

My problem with this switch is, I like to use a module-combined audio sink of pulse audio. This allows for simultaneous playback in a multi-room environment. Up to now this setup works with kodi and mpd. When I configure the default sink ( the one alsa uses) to be the default of the raspberry I get the warning above, but it actually works. When I switch the definition of the default audio sink to be the combined tunnel no sound is played at all. Here is a debug.log of such an event:

https://www.dropbox.com/s/il3tztiz0o1c83l/mopidy.log.2?dl=0

[deisi]

Is there anything I can provide to help to takel this issue down?

[kingosticks]

It might be helpful to provide the gstreamer log (https://docs.mopidy.com/en/latest/troubleshooting/#debugging-gstreamer)

[mguentner]

I can confirm the same problem with ArchLinux on a Cubieboard 2.
Both the Cubieboard 2 and the RPi are armv7 dual core platforms.
Apparently there is some kernel/glibc/compiler bug that affects the
priority inheritance of pthread.

With a few searches I found out, that this bug has been around for
quite some time (also it comes and goes, some posts are from 2010).

The easiest solution is to either disable pulseaudio (meh - I also want to
stream the output via RTP)
or to recompile pulseaudio without the priority inheritance support.

Here’s how you do that:

• Download all files from here: https://github.com/archlinuxarm/PKGBUILDs/tree/master/extra/pulseaudio

• Edit the PKGBUILD and modify the script starting from line 31 to

     build() {
    cd $pkgbase-$pkgver
    read
    ./configure --prefix=/usr \
  

The read allows you to edit the code before starting the make process

• Add armv7h to the arch=() in line 16 like this:

    arch=(i686 x86_64 armv7h)
  

• install all build requirements (maybe some packages are missing here, just pay attention to
  the output)

  pacman -S pkg-config m4 gcc make fakeroot avahi bluez bluez-libs intltool jack2-dbus lirc fftw gtk3 check

• start the build process by running makepkg

• you should now see a blank screen (this is the read waiting for something to happen)

• open a second shell and go into /home/foobar/pulseaudio/src/pulseaudio-6.0 where pulseaudio is the directory where you have placed the PKGBUILD

• now open the configure file and go to line 21554-21587 where it starts with

    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for PTHREAD_PRIO_INHERIT" >&5
  

and ends with

$as_echo "#define HAVE_PTHREAD_PRIO_INHERIT 1" >>confdefs.h

fi

Delete these lines and everything in between them.

• Save the configure script and go back to the shell where read is waiting and hit Enter there.

The compilation should now start with PTHREAD_PRIO_INHERIT being disabled \o/
After a long while (took about 30min on the Cubieboard 2) you can install the package by running

pacman -U pulseaudio-6.0-2-armv7h.pkg.tar.xz

Restart your system so that all cached libraries are reloaded and start mopidy to confirm that it is working.

After this fix, the error message changes to a warning for me:

WARNING Element doesn’t implement handling of this stream. Please file a bug.

Let me know whether this helps. If it does maybe we can push this fix upstream to ArchLinux ARM!

[deisi]

Its a bit off topic, but I now install mopidy via pip and it works. the drawback is, you have to be carefull not installing the same package with pip and pacman, because you will run into some (solveable) trouble then.

@mguentner

The easiest solution is to either disable pulseaudio (meh - I also want tostream the output via RTP

Be careful with the RTP. It killed my WIFI due to UDP flooding of the network. By now i recommend not using it. Instead have a look at GitHub - badaix/snapcast: Synchronous multiroom audio player. It works very reliable and can even be used via Wifi.

[Marian-Silviu]

When listening to music on Audacious, I get a core dump when I want to change song time position.
I did what mguentner proposed on a Raspberry Pi 2 on ArchLinuxArm. Compiled Pulseaudio without HAVE_PTHREAD_PRIO_INHERIT by deleting from line 22598 to 22631 in configure (including the fi).
Problem solved - will (try to) make a comment on the pulseaudio package page.
Thank you mguentner !
Very happy indeed.