When I install musicbox I can access musicbox.local, but as soon as I changes the settings (I have to, because I have to switch on AirPlay, etc) and reboot the device (RasPI zero) musicbox.local wont load (no error such as “cant access musicbox.local” does accur).
Anybody has an idea what to do?
Thanks in advance 
Exactly what settings are you changing? How are you making the changes? Can you try changing fewer/one thing at a time? Do you have a mini hdmi to plug in and see the boot error? Or put the SD card back into a computer and view the contents of /var/log/musicbox_startup.log (don’t think you can do this with a Windows PC).
I am seeing something similar using a Pi 3 - After the first boot - which works fine with the inbuilt WiFi connecting OK, after that the boot tries 4 times to access wlan0 but fails - wlan0: link is not ready (on IPv6)
RTNETLINK answers: Network is unreachable.
So while the Pi is running, the web service can not be accessed -
I would have thought that the WiFi would use IPv4?
Thanks
I have the same issue.
On initial installation everything works smoothly. Once Airplay is enabled via web interface and Pi3 reboots, web interface no longer works.
Browser reports:
"This site can’t be reached
192.168.1.xx refused to connect."
I can ping the IP, Airplay from an iPad works. I have disabled everything that I can with the exception of Airplay and get the same results.
Is this some configuration issue from the Web configurator? If I re-load the disk image to SD card, Web interface works again - until reboot.
I’m currently downloading a live linux distro to check the startup log. Will post it soonest.
edit: Forgot to mention that iTunes on Windows won’t connect through Airplay.
Have you tried the latest release at https://github.com/pimusicbox/pimusicbox/releases/tag/v0.7.0RC4 ?
Yup, That’s my current version.
This is the startup log. I can’t see anything that could impact web browser access.
Initializing MusicBox…
Setting sound configuration…
Listening on LPF/eth0/b8:27:eb:3b:f5:ec
Sending on LPF/eth0/b8:27:eb:3b:f5:ec
Sending on Socket/fallback
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/wlan0/b8:27:eb:6e:a0:b9
Sending on LPF/wlan0/b8:27:eb:6e:a0:b9
Sending on Socket/fallback
DHCPRELEASE on wlan0 to 192.168.1.1 port 67
Reloading /etc/samba/smb.conf: smbd only.
done.
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.
Starting daemon monitor: monit.
Scanning music-files, please wait…
INFO Starting Mopidy 1.1.2
INFO Loading config from builtin defaults
INFO Loading config from /etc/mopidy/mopidy.conf
INFO Loading config from command line options
WARNING Found alsamixer configuration errors, the extension has been automatically disabled:
WARNING alsamixer/control must be set.
WARNING alsamixer/card must be set.
WARNING Please fix the extension configuration errors or disable the extensions to silence these messages.
My IP address is 192.168.1.44
Connect to me in your browser at MusicBox.local or //192.168.1.44
UPDATE: I reinstalled musicbox and manually enabled Airplay via the config file. All working perfectly. Rebooted from the Web interface and all still worked.
I then enabled DLNA/UPnP from web interface, saved, and rebooted - Web access still working.
Disabled Airplay from web interface, saved, rebooted - Web access still working
Re-enabled Airplay from web interface, saved, rebooted - Web access still working but Airplay not possible from iPad (MusicBox not visible as client)
Can you post the output of /var/log/mopidy/mopidy.log? It should hopefully report stuff about the web frontend e.g.
INFO Starting Mopidy frontends: MpdFrontend, HttpFrontend, QueueManagerFrontend
Sure. Please see my update above. I’ll post the latest logs (Need to boot up linux again )
I’m going to start the process again with a clean install.
And after duplicating all my steps - it is now working without a hitch.
If it falls over, I’ll post the logs to this thread. Thanks for the help.
If you are still having any airplay issues there are a couple of known bugs in RC4 I can point you to fixes.
Airplay from iOS seems stable. From iTunes on Windows it stalls on ‘connecting’, but for my usage that isn’t a problem.
On iOS, after a device disconnects, the client isn’t visible to any other devices until after a reboot. A bug, but one that is easily managed.
There should be a timeout after disconnection, I think it’s 2 minutes (don’t hold me to that). But you should be able to fix that one by running
sed -i 's/udp_port_range = 3/udp_port_range = 100/' /etc/shairport-sync.conf
The workaround for windows connections is to disable the firewall, that may or may not be a concern for you depending on your network.
If you want to disable it you can stick the following lines at the bottom of /etc/rc.local
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -F
iptables -X
Thanks. I’ll check the 2 minute thing first.
Solved the issue by changing
´"/etc/wpa.conf"
in /etc/network/interfaces to:
“/etc/wpa_supplicant/wpa_supplicant.conf”
(Maybe you’ll need to execute:
“wpa_passphrase “your_ssid” “your_password” > /etc/wpa_supplicant/wpa_supplicant.conf”
to get your wifi settings stored.
Hope this helps anyone.
(EDIT: This was related to an interface error for me. The pi wasn’t connected to the wifi at all. Check you routers interface if it shows the “musicbox”)