Raspberry Pi with mpd/mpc: Time change stops snapserver playback

[Mugridge]

From the beginning, when I started with snapcast, I was wondering why the snapserver sometimes stops a few seconds after boot and sometimes not. I changed the shortly released snapserver.service what has no affect. Now I recognized, that the time update, caused by the ntp daemon, is the reason. Because the raspberry has no realtimeclock he updates the time from a ntp server after start. This takes a few seconds. During this time the snapserver is running. After getting the time the playback stops. You can check this by continuously checking the time:

pi@raspberrypi:~ $ date Di 31. Jan 16:04:34 CET 2017 pi@raspberrypi:~ $ date Di 31. Jan 16:04:35 CET 2017 pi@raspberrypi:~ $ date Di 31. Jan 16:04:35 CET 2017 pi@raspberrypi:~ $ date Di 31. Jan 16:06:33 CET 2017 -> playback stops

If the raspberry has no connection to a ntp server, the problem does not exist. It doesn't matter if the time change is done by the ntp daemon or manual by the 'date' command, the playback stops. To reactivate the playback it is necessary to restart mpd and the snapserver service. I built a workaround by restarting the services a few seconds after boot with a short script. The snapclient doesn't have this problem, after changing the local time he only makes a short break. Is there a better way to fix this behavior or ist it maybe a bug?

[realglotzi]

Do not use NTP. Use systemd-timesyncd in a systemd environment. This works fine on my RPi's

[Mugridge]

How did you do that? I removed the timeserveraddress from /etc/ntp.conf and added it to /etc/systemd/timesyncd.conf. The result is the same, the playback starts and is running until the time is updated.

[realglotzi]

I'm using a distribution with systemd-timesyncd per default.

[stuwil]

I'm using a snapcast client on a Raspberry Pi with Arch, using system-timesyncd as the default, and running into a similar problem - once timedatectl indicates NTP synchronized: yes, the audio drops out for about ~30 seconds before suddenly coming back. I've only observed this on boot for now - starting snapclient via systemd.

[Mugridge]

I am using Raspbian Jessie Lite and the audio doesn't come back. My workaround is now to check the /var/log/syslog after boot against the appearance of the string "Time has been changed" and then restart the mpd. This causes a short break but after this the audio is running continuously. Maybe not the best way, but it works.

[badaix]

The clients are syncing their time every second with the server (getting a delta between server and local time) and using the median delta of 60 sync samples to get the server's time (server time = client time + delta). If the server changes the time, it will take ~30 seconds to get in sync again (median of 60s buffer).

It might help to change the time bases to something that is not influenced by NTP, e.g. time at boot + uptime. But for the moment a hard NTP can cause 30s silence (but should not cause more). Once synchronized, the NTP time changes should be small enough to not have an impact on the audio signal.

[aludwiko]

the same in my case, after restart the music is playing, after 20 seconds it stops. I can observe this in system log:

Nov  3 17:56:42 raspberrypi_1 systemd[1]: Started User Manager for UID 1000.
Nov  3 17:56:45 raspberrypi_1 dhcpcd[486]: eth0: no IPv6 Routers available
Nov  3 17:57:05 raspberrypi_1 systemd[1]: Time has been changed
Nov  3 17:57:05 raspberrypi_1 systemd[523]: Time has been changed
Nov  3 17:57:05 raspberrypi_1 systemd-timesyncd[298]: Synchronized to time server 193.238.191.249:123 (2.debian.pool.ntp.org).
Nov  3 17:57:05 raspberrypi_1 systemd[1]: apt-daily-upgrade.timer: Adding 9min 25.020978s random time.
Nov  3 17:57:05 raspberrypi_1 systemd[1]: apt-daily.timer: Adding 9h 2min 45.475033s random time.

and after additional ~60 seconds everything return to normal.

In my case, the workaround was to disable systemd-timesyncd

[aludwiko]

@Mugridge do you have some script for that?

[Mugridge]

I have tried some workarounds with different scripts und different success. Tired of this I finally solved the problem by installing a DS3231 RTC on the server and the client. Now it works well (until the batteries are getting empty).

[FilipLigaarden]

@Mugridge Thank you. This is a great workaround.

[badaix]

this is fixed in master branch and will be part of 0.19