Moode Audio Player for Raspberry Pi

I have actually got pihole and moode running together on a raspberry pi B. I'm not at that house now, so I may have forgotten something, but the difficulties I remember were that pihole wants to run a different web server (lighttpd) to Moode (nginx) and that the fixed IP address is most easily set on the router. So what I did (from memory) was to set the router to give the pi a fixed IP address -- in any case a good idea -- and then start with a working moode installation. I ran the install script for pihole from the command line. I did not install lighttpd from that.

Moode writes its index file for the web front end into the web server's html directory. Pihole writes its index file into html/admin. So to get at the pihole front end you need to point your browser at http://moode.local/html/admin/

The setup now runs perfectly well. The pihole web front end is very slow, but the command line scripts to add domains to the blacklist work very well. The cpu runs at about 50 degrees, which is hot but not panic inducing.

Thanks Andrew! I will give this a shot again this weekend. When you say you did not install lighttpd from that - I didnt realize you could setup the pi hole script to ignore that portion of the install. Did you have to do anything special to make sure the lighttpd and dnsmasq services were up and running correctly? That was the issue I faced when running with volumio.

I assume you didnt play around with iptables either right?
 
I am running moode 2.7 and experiencing the usual difficulties with getting a local media store (a 120gb ssd) to index or play. It did index once but after I plated something over the dnla streamer it refused to play anything on the local media and now it won't reindex it either.

But I have also found a new, and interesting glitch. I have a hifiberry Amp+ on my pi.

When I stream music over airplay after a break it is completely silent until I move the volume control on the playback screen. This need only be a twitch, from 59 to 58 or something like that. Then the music works fine and continues to work, at least until the mac goes to sleep or otherwise loses the connection. After that there is the same silence until I nudge the software volume

If I move the volume control on my mac, it is utterly silent until it reaches full volume, at which point there is a burst of deafening sound. It seems then to have no setting between 0 and 100%. The controls on the moode front end work fine, as I say, as soon as I nudge them.

Hi,

Are u experiencing these issues on a clean Moode 2.7 image or on an image where the pihole software is installed?

-Tim
 
Tim,
One request and one question for you.
- Is it possible to add some sort of fade in/fade out on the alarm feature? I like waking to the radio but waking up to a fixed volume is very sudden. Is it possible to add in something to fade the volume up or down (so that the alarm can be used to wake up and sleep?)

- Randomly while playing audio via airplay there are gaps in the audio - about a second or so. Any ideas as to what could be going on? I am on Rpi1-b if that helps. Theres also a IQAudio-PI DAC on the pi board.
 
Hi,

Touch "iPhone" at the bottom of the popup and it will expand into a list that will have "Moode Airplay" as one of the items.

-Tim

Moode airplay does not appear, only 'apple tv' appears under 'iphone'.
I moved the pi running mode 2.7 to the same switch as the apple tv, rebooted, no go.
I turned off the embedded wifi and bt in the system setting of moode. rebooted. still no mode on airplay.
Interestingly in the mac finder under 'shared', mode does appear. I guess it's running smb? I can brows 4 shares-NAS, Radio, SDCARD, USB
Although I can reload the original mode image on the micro SD card, I would rather learn to try and trouble shoot this. Any suggestions?
 
Tim,
One request and one question for you.
- Is it possible to add some sort of fade in/fade out on the alarm feature? I like waking to the radio but waking up to a fixed volume is very sudden. Is it possible to add in something to fade the volume up or down (so that the alarm can be used to wake up and sleep?)

- Randomly while playing audio via airplay there are gaps in the audio - about a second or so. Any ideas as to what could be going on? I am on Rpi1-b if that helps. Theres also a IQAudio-PI DAC on the pi board.

Hi,

Try a 30 sec ping test from Pi to client thats sending Airplay and examine the ping statistics for dropped packets, high %packet loss, excessively long round trip (RTT) times, etc.

Clock radio volume fade not so easy so unless a lot of requests for this it won't happen.

-Tim
 
I have actually got pihole and moode running together on a raspberry pi B. I'm not at that house now, so I may have forgotten something, but the difficulties I remember were that pihole wants to run a different web server (lighttpd) to Moode (nginx) and that the fixed IP address is most easily set on the router. So what I did (from memory) was to set the router to give the pi a fixed IP address -- in any case a good idea -- and then start with a working moode installation. I ran the install script for pihole from the command line. I did not install lighttpd from that.

Moode writes its index file for the web front end into the web server's html directory. Pihole writes its index file into html/admin. So to get at the pihole front end you need to point your browser at http://moode.local/html/admin/

The setup now runs perfectly well. The pihole web front end is very slow, but the command line scripts to add domains to the blacklist work very well. The cpu runs at about 50 degrees, which is hot but not panic inducing.

Thanks, Andrew. I obviously gave up too soon.

I still think I'll run these applications on separate RPi's for the reason I stated, but others will make their own determination now that they know it can be done.

Regards,
Kent
 
Hi,

Try a 30 sec ping test from Pi to client thats sending Airplay and examine the ping statistics for dropped packets, high %packet loss, excessively long round trip (RTT) times, etc.



-Tim
Did this test:
The mode player is not playing anything.
ping the pi from the iPhone (using FING)
64 bytes from 192.168.9.39: icmp_seq=0 ttl=64 time=2.607 ms
64 bytes from 192.168.9.39: icmp_seq=1 ttl=64 time=2.235 ms
64 bytes from 192.168.9.39: icmp_seq=2 ttl=64 time=1.657 ms
64 bytes from 192.168.9.39: icmp_seq=3 ttl=64 time=1.420 ms
64 bytes from 192.168.9.39: icmp_seq=4 ttl=64 time=3.039 ms
64 bytes from 192.168.9.39: icmp_seq=5 ttl=64 time=2.602 ms

ssh into the pi and ping the iPhone
pi@moode:~ $ ping 192.168.9.47
PING 192.168.9.47 (192.168.9.47) 56(84) bytes of data.
64 bytes from 192.168.9.47: icmp_seq=1 ttl=64 time=106 ms
64 bytes from 192.168.9.47: icmp_seq=2 ttl=64 time=48.2 ms
64 bytes from 192.168.9.47: icmp_seq=3 ttl=64 time=71.2 ms
64 bytes from 192.168.9.47: icmp_seq=4 ttl=64 time=94.9 ms

no packet loss but 50x longer time. If i had a lot of traffic on my LAN, I would see symmetric congestion in both directions, no?
 
Did this test:
The mode player is not playing anything.
ping the pi from the iPhone (using FING)
64 bytes from 192.168.9.39: icmp_seq=0 ttl=64 time=2.607 ms
64 bytes from 192.168.9.39: icmp_seq=1 ttl=64 time=2.235 ms
64 bytes from 192.168.9.39: icmp_seq=2 ttl=64 time=1.657 ms
64 bytes from 192.168.9.39: icmp_seq=3 ttl=64 time=1.420 ms
64 bytes from 192.168.9.39: icmp_seq=4 ttl=64 time=3.039 ms
64 bytes from 192.168.9.39: icmp_seq=5 ttl=64 time=2.602 ms

ssh into the pi and ping the iPhone
pi@moode:~ $ ping 192.168.9.47
PING 192.168.9.47 (192.168.9.47) 56(84) bytes of data.
64 bytes from 192.168.9.47: icmp_seq=1 ttl=64 time=106 ms
64 bytes from 192.168.9.47: icmp_seq=2 ttl=64 time=48.2 ms
64 bytes from 192.168.9.47: icmp_seq=3 ttl=64 time=71.2 ms
64 bytes from 192.168.9.47: icmp_seq=4 ttl=64 time=94.9 ms

no packet loss but 50x longer time. If i had a lot of traffic on my LAN, I would see symmetric congestion in both directions, no?

Examine and interpret on your own or post the ctrl-c ping stats after a 30 sec run.
 
I let the pi run ping for 2 minutes and saw this pattern:
64 bytes from 192.168.9.47: icmp_seq=101 ttl=64 time=109 ms
64 bytes from 192.168.9.47: icmp_seq=102 ttl=64 time=29.9 ms
64 bytes from 192.168.9.47: icmp_seq=103 ttl=64 time=52.7 ms
64 bytes from 192.168.9.47: icmp_seq=104 ttl=64 time=74.7 ms
64 bytes from 192.168.9.47: icmp_seq=105 ttl=64 time=97.1 ms
64 bytes from 192.168.9.47: icmp_seq=106 ttl=64 time=17.8 ms
64 bytes from 192.168.9.47: icmp_seq=107 ttl=64 time=40.6 ms
64 bytes from 192.168.9.47: icmp_seq=108 ttl=64 time=62.8 ms
64 bytes from 192.168.9.47: icmp_seq=109 ttl=64 time=85.9 ms
64 bytes from 192.168.9.47: icmp_seq=110 ttl=64 time=108 ms
64 bytes from 192.168.9.47: icmp_seq=111 ttl=64 time=29.6 ms
64 bytes from 192.168.9.47: icmp_seq=112 ttl=64 time=51.7 ms
64 bytes from 192.168.9.47: icmp_seq=113 ttl=64 time=74.6 ms
64 bytes from 192.168.9.47: icmp_seq=114 ttl=64 time=95.9 ms
64 bytes from 192.168.9.47: icmp_seq=115 ttl=64 time=16.4 ms


every ninth ping is ~100ms

I also pinged my phone from a mac for 2 minutes and the pattern is similar
64 bytes from 192.168.9.47: icmp_seq=38 ttl=64 time=113.538 ms
64 bytes from 192.168.9.47: icmp_seq=39 ttl=64 time=34.115 ms
64 bytes from 192.168.9.47: icmp_seq=40 ttl=64 time=56.200 ms
64 bytes from 192.168.9.47: icmp_seq=41 ttl=64 time=79.249 ms
64 bytes from 192.168.9.47: icmp_seq=42 ttl=64 time=101.652 ms
64 bytes from 192.168.9.47: icmp_seq=43 ttl=64 time=21.472 ms
64 bytes from 192.168.9.47: icmp_seq=44 ttl=64 time=44.632 ms
64 bytes from 192.168.9.47: icmp_seq=45 ttl=64 time=67.474 ms
64 bytes from 192.168.9.47: icmp_seq=46 ttl=64 time=89.229 ms
64 bytes from 192.168.9.47: icmp_seq=47 ttl=64 time=112.034 ms
64 bytes from 192.168.9.47: icmp_seq=48 ttl=64 time=32.699 ms
64 bytes from 192.168.9.47: icmp_seq=49 ttl=64 time=54.944 ms


pinging the pi for 2 min reveals
64 bytes from 192.168.9.39: icmp_seq=72 ttl=64 time=2.984 ms
64 bytes from 192.168.9.39: icmp_seq=73 ttl=64 time=3.235 ms
64 bytes from 192.168.9.39: icmp_seq=74 ttl=64 time=3.084 ms
64 bytes from 192.168.9.39: icmp_seq=75 ttl=64 time=2.925 ms
64 bytes from 192.168.9.39: icmp_seq=76 ttl=64 time=3.496 ms
64 bytes from 192.168.9.39: icmp_seq=77 ttl=64 time=4.053 ms
64 bytes from 192.168.9.39: icmp_seq=78 ttl=64 time=2.552 ms
64 bytes from 192.168.9.39: icmp_seq=79 ttl=64 time=3.703 ms
64 bytes from 192.168.9.39: icmp_seq=80 ttl=64 time=3.126 ms

So I don't think it's the network since the mac sees the Apple TV on airplay.

I guess people don't use airplay anyway since it only sends audio data at 16/44.(From Apple I read this:

Airplay will stream the 24/96 content to receiving devices like the Marantz NA7004, but only from your computer, not from one of the portable Apple devices. Those portable devices, like the iPhone and iPad are internally limited to 16/44. You can use your iPhone or iPad to control the content streaming from the computer to the receiver.
From here I read

AirPlay streams at 16-bit, 44,100 kHz. However, what you don’t see is that AirPlay streams music in Apple Lossless format. What this means is that no matter what format your music is in, it gets converted by OS X – not by iTunes – to Apple Lossless, to ensure the highest quality. So lossless files will be streamed as lossless, as will AAC or MP3 files.

However, high-resolution files will be downsampled to 16/44.1. Interestingly, the Apple TV outputs audio in 48 kHZ, most likely because this is 48 kHz is the standard for movie and TV audio[1]. Movies sold by the iTunes Store contain audio at 48 kHz, but only at 160 kbps.

So the whole idea of getting airplay to send tidal music (16/44 lossless) is good unless shairport resamples it to 48 kHz like the apple tv. Too bad because i REALLY like moode and TIDAL.
 
Hi,

Try a 30 sec ping test from Pi to client thats sending Airplay and examine the ping statistics for dropped packets, high %packet loss, excessively long round trip (RTT) times, etc.

Clock radio volume fade not so easy so unless a lot of requests for this it won't happen.

-Tim

Cool. will try that. Somehow the pi isnt turning on now.. so may have to check that out first... it was streaming airplay for a while then just stopped. Since then, I cant login to the pi remotely or access moode.local. So maybe something went on with the sd card or something. Will check that first and then try this out.
 
and here is the log:
debug log and airplay metadata are turned on in moode.
pi@moode:~ $ cat /var/log/moode.log
20161007 233219 worker: Startup
20161007 233223 worker: Host (moode)
20161007 233223 worker: Hdwr (Pi-3B 1GB)
20161007 233223 worker: Arch (armv7l)
20161007 233223 worker: Krnl (4.4.19-v7+)
20161007 233223 worker: OS (moodeOS 1.0)
20161007 233223 worker: Rel (Moode 2.7 2016-08-28)
20161007 233223 worker: Upd (None)
20161007 233223 worker: MPD (0.19.19)
20161007 233223 worker: Session loaded
20161007 233223 worker: Debug logging (on)
20161007 233223 worker: File check...
20161007 233223 worker: File check ok
20161007 233224 worker: Auto-shuffle deactivated
20161007 233224 worker: USB sources (none attached)
20161007 233224 worker: MPD started
20161007 233224 worker: wlan0 does not exist (off)
20161007 233224 worker: Audio (USB audio device)
20161007 233224 worker: ALSA outputs unmuted
20161007 233224 worker: ALSA mixer name (PCM)
20161007 233224 worker: MPD volume control (software)
20161007 233225 worker: MPD output 1 ALSA default (enabled)
20161007 233225 worker: MPD output 2 ALSA crossfeed (disabled)
20161007 233225 worker: Hdwr volume controller exists
20161007 233225 worker: Volume level (39) restored
20161007 233225 worker: wlan0 address not assigned
20161007 233225 worker: eth0 exists
20161007 233225 worker: eth0 wait 1 for address
20161007 233228 worker: eth0 (192.168.9.39)
20161007 233228 worker: Airplay metadata on
20161007 233228 worker: (/usr/local/bin/shairport-sync -a "Moodey Airplay" -S soxr -w -B /var/www/command/spspre.sh -E /var/www/command/spspost.sh --metadata-pipename=/tmp/shairport-sync-metadata --get-coverart -- -d hw:1 -c "PCM" > /dev/null 2>&1 &)
20161007 233228 worker: Airplay receiver started
20161007 233229 worker: NAS sources (mountall initiated)
20161007 233229 worker: MPD consume reset to off
20161007 233229 worker: Watchdog started
20161007 233229 worker: End startup
20161007 233229 worker: Ready
20161007 233232 waitWorker(): Start (sys-config, w_active=0)
20161007 233232 waitWorker(): End (sys-config, w_active=0)


It says the airplay receiver started so I don't know why I am not seeing it from an iPhone or a mac. Another user had a similar problem but he said he actually connected.

This is what i see on the iPhone. As you see there are four lines on that dialog - the first is the active device, then there is the iPhone, then there is the apple tv, and then there is a blank space. I assume mode airplay should appear there. I cannot scroll that dialog up and there is nothing else to click there.

I also tried on a windows machine. I installed airfoil and it did see the appleTV as well as the iPhone but not the pi running moode.
 
Hi Etienne,

Try editing /etc/udisks-glue.conf and change sync to async

-Tim

Hi Tim and thanks a lot for your answer.

Tried it to no avail.

I finally decided to have a look at permissions on my drive and found out that common user doesn't have writing rights ... what's odd is that it never was an issue before with the other software of the same type.

Tried to chmod to give rights to anybody but didn't succeed (not such a specialist at linux commands ...)

So back to step 1 : unplug disk, connect to laptop, copy, replug ... quite tedious, but works as long as I don't find a better solution.

Thanks again for great work and prompt answer.

Etienne
 
Thanks Andrew! I will give this a shot again this weekend. When you say you did not install lighttpd from that - I didnt realize you could setup the pi hole script to ignore that portion of the install. Did you have to do anything special to make sure the lighttpd and dnsmasq services were up and running correctly? That was the issue I faced when running with volumio.

I assume you didnt play around with iptables either right?
I didn't mess around with iptables at all. So far as I remember, I let the install script run, and it may even have installed lighttpd, but it couldn't start it, because nginx was already running.

I had another look at my setup last night, and saw two things I had had to change.

1) Moode places a dnsmasq.conf into /etc and this takes precedence over the one which pihole expects, which is in /etc/dbus-1/system.d/ so I renamed the moode one. This was necessary because the moode config file makes dnsmasq look for wlan0 which does not exist on my pi because it's on an ethernet connection directly to the router.

2) my nginx.conf looks like this

Code:
acb@moode:/etc$ cat nginx/nginx.conf
##
# AG moode 3 conf file
# TC set fastcgi_read_timeout to 600000 to prevent 504 timeouts
# TC switch to unix socket for fastcgi_pass
#

user root users;
worker_processes  4;

events {
	worker_connections 512;
	multi_accept on;
}

http {
	sendfile on;
	tcp_nodelay on;
	tcp_nopush on;

	client_body_timeout 10;
	client_header_timeout 10;
	keepalive_timeout 15;
	send_timeout 10;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	# access_log /var/log/nginx/access.log;
	access_log off;
	error_log /var/log/nginx/error.log;

	gzip on;
	gzip_disable "MSIE [1-6]\.";
	# include /etc/nginx/conf.d/*.conf;
	# include /etc/nginx/sites-enabled/*;

	# Moode UI server
	server {
		listen 80;

		location / {
			root /var/www;
			index index.html index.php;
			try_files $uri $uri/ /coverart.php;
		}

		# redirect server error pages to the static page /50x.html
		error_page 500 502 503 504 /50x.html;
		location = /50x.html {
			root html;

		}

		# php5-fpm
		location ~ \.php$ {
			root /var/www;
			fastcgi_pass unix:/var/run/php5-fpm.sock;
			fastcgi_index index.php;
			fastcgi_param SCRIPT_FILENAME $request_filename;
			fastcgi_read_timeout 600000;
			#fastcgi_read_timeout 60;
			include fastcgi_params;
		}
	}
}


and, for completeness, my dnsmasq.conf is

Code:
acb@moode:/etc$ cat dnsmasq.d/01-pihole.conf
# Pi-hole: A black hole for Internet advertisements
# (c) 2015, 2016 by Jacob Salmela
# Network-wide ad blocking via your Raspberry Pi
# [url]http://pi-hole.net[/url]
# dnsmasq config for Pi-hole
#
# Pi-hole is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 2 of the License, or
# (at your option) any later version.

# If you want dnsmasq to read another file, as well as /etc/hosts, use
# this.
addn-hosts=/etc/pihole/gravity.list

# The following two options make you a better netizen, since they
# tell dnsmasq to filter out queries which the public DNS cannot
# answer, and which load the servers (especially the root servers)
# unnecessarily. If you have a dial-on-demand link they also stop
# these requests from bringing up the link unnecessarily.

# Never forward plain names (without a dot or domain part)
domain-needed
# Never forward addresses in the non-routed address spaces.
bogus-priv

# If you don't want dnsmasq to read /etc/resolv.conf or any other
# file, getting its servers from this file instead (see below), then
# uncomment this.
no-resolv

# Add other name servers here, with domain specs if they are for
# non-public domains.
server=8.8.8.8
server=8.8.4.4

# If you want dnsmasq to listen for DHCP and DNS requests only on
# specified interfaces (and the loopback) give the name of the
# interface (eg eth0) here.
interface=eth0
except-interface=wlan0
# Or which to listen on by address (remember to include 127.0.0.1 if
# you use this.)
# listen-address=127.0.0.1

# Set the cachesize here.
cache-size=10000

# For debugging purposes, log each DNS query as it passes through
# dnsmasq.
log-queries
log-facility=/var/log/pihole.log

# Normally responses which come from /etc/hosts and the DHCP lease
# file have Time-To-Live set as zero, which conventionally means
# do not cache further. If you are happy to trade lower load on the
# server for potentially stale date, you can set a time-to-live (in
# seconds) here.
local-ttl=300

# This allows it to continue functioning without being blocked by syslog, and allows syslog to use dnsmasq for DNS queries without risking deadlock
log-async
 
Hi,

Are u experiencing these issues on a clean Moode 2.7 image or on an image where the pihole software is installed?

-Tim
those problems come on a clean image. I have two pis with moode on; the one at my gfs has pihole installed as well. I get dropouts in shairport (not dlna) on both, but the volume problem comes only on the clean install at home. I could I suppose try making a whole new image there.
 
and here is the log:
debug log and airplay metadata are turned on in moode.
pi@moode:~ $ cat /var/log/moode.log
20161007 233219 worker: Startup
20161007 233223 worker: Host (moode)
20161007 233223 worker: Hdwr (Pi-3B 1GB)
20161007 233223 worker: Arch (armv7l)
20161007 233223 worker: Krnl (4.4.19-v7+)
20161007 233223 worker: OS (moodeOS 1.0)
20161007 233223 worker: Rel (Moode 2.7 2016-08-28)
20161007 233223 worker: Upd (None)
20161007 233223 worker: MPD (0.19.19)
20161007 233223 worker: Session loaded
20161007 233223 worker: Debug logging (on)
20161007 233223 worker: File check...
20161007 233223 worker: File check ok
20161007 233224 worker: Auto-shuffle deactivated
20161007 233224 worker: USB sources (none attached)
20161007 233224 worker: MPD started
20161007 233224 worker: wlan0 does not exist (off)
20161007 233224 worker: Audio (USB audio device)
20161007 233224 worker: ALSA outputs unmuted
20161007 233224 worker: ALSA mixer name (PCM)
20161007 233224 worker: MPD volume control (software)
20161007 233225 worker: MPD output 1 ALSA default (enabled)
20161007 233225 worker: MPD output 2 ALSA crossfeed (disabled)
20161007 233225 worker: Hdwr volume controller exists
20161007 233225 worker: Volume level (39) restored
20161007 233225 worker: wlan0 address not assigned
20161007 233225 worker: eth0 exists
20161007 233225 worker: eth0 wait 1 for address
20161007 233228 worker: eth0 (192.168.9.39)
20161007 233228 worker: Airplay metadata on
20161007 233228 worker: (/usr/local/bin/shairport-sync -a "Moodey Airplay" -S soxr -w -B /var/www/command/spspre.sh -E /var/www/command/spspost.sh --metadata-pipename=/tmp/shairport-sync-metadata --get-coverart -- -d hw:1 -c "PCM" > /dev/null 2>&1 &)
20161007 233228 worker: Airplay receiver started
20161007 233229 worker: NAS sources (mountall initiated)
20161007 233229 worker: MPD consume reset to off
20161007 233229 worker: Watchdog started
20161007 233229 worker: End startup
20161007 233229 worker: Ready
20161007 233232 waitWorker(): Start (sys-config, w_active=0)
20161007 233232 waitWorker(): End (sys-config, w_active=0)


It says the airplay receiver started so I don't know why I am not seeing it from an iPhone or a mac. Another user had a similar problem but he said he actually connected.

This is what i see on the iPhone. As you see there are four lines on that dialog - the first is the active device, then there is the iPhone, then there is the apple tv, and then there is a blank space. I assume mode airplay should appear there. I cannot scroll that dialog up and there is nothing else to click there.

I also tried on a windows machine. I installed airfoil and it did see the appleTV as well as the iPhone but not the pi running moode.

Hi,

Blank space at bottom of list is normal. I see it on my iPhone.

You can try running shairport-sync from command line with -vv arg. This will print debug information which may contain error lines.

1) killall shairport-sync

2) run the command below
/usr/local/bin/shairport-sync -vv -a "Moodey Airplay" -S soxr -w -B /var/www/command/spspre.sh -E /var/www/command/spspost.sh --metadata-pipename=/tmp/shairport-sync-metadata --get-coverart -- -d hw:1 -c "PCM"

-Tim
 
For debugging purposes, I renamed airplay to 'Moodey Airplay' so I can see if mode is reading the settings.
I then executed the commands you suggested).

Code:
pi@moode:~ $ killall shairport-sync
shairport-sync: no process found

Code:
pi@moode:~ $ /usr/local/bin/shairport-sync -vv -a "Moodey Airplay" -S soxr -w -B /var/www/command/spspre.sh -E /var/www/command/spspost.sh --metadata-pipename=/tmp/shairport-sync-metadata --get-coverart -- -d hw:1 -c "PCM"

Looking for the configuration file "/etc/shairport-sync.conf".
Looking for configuration file at full path "/etc/shairport-sync.conf"
Output device name is "hw:1".
Open Mixer
Failed to attach mixer
Request to shut down all rtsp conversation threads
asking playing threads to stop
^Cshutdown requested...

Code:
pi@moode:~ $ pgrep shairport*

So it seems shairport is not starting.
What is this error 'failed to attach mixer'?

and even if I start shairport like so

Code:
pi@moode:/etc/init.d $ /usr/local/bin/shairport-sync
Successful Startup

The mode still does not appear on the list of airplay devices.
 
Last edited:
I didn't mess around with iptables at all. So far as I remember, I let the install script run, and it may even have installed lighttpd, but it couldn't start it, because nginx was already running.

I had another look at my setup last night, and saw two things I had had to change.

1) Moode places a dnsmasq.conf into /etc and this takes precedence over the one which pihole expects, which is in /etc/dbus-1/system.d/ so I renamed the moode one. This was necessary because the moode config file makes dnsmasq look for wlan0 which does not exist on my pi because it's on an ethernet connection directly to the router.
Thanks! This worked out for me!!