New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Mugridge opened this Issue Feb 3, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@Mugridge

Mugridge commented Feb 3, 2017

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

This comment has been minimized.

Contributor

realglotzi commented Feb 6, 2017

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

@Mugridge

This comment has been minimized.

Mugridge commented Feb 6, 2017

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

This comment has been minimized.

Contributor

realglotzi commented Feb 7, 2017

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

@stuwil

This comment has been minimized.

stuwil commented Feb 16, 2017

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

This comment has been minimized.

Mugridge commented Feb 20, 2017

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

This comment has been minimized.

Owner

badaix commented Mar 14, 2017

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.

@badaix badaix added the enhancement label Mar 14, 2017

@aludwiko

This comment has been minimized.

aludwiko commented Nov 3, 2017

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

This comment has been minimized.

aludwiko commented Nov 4, 2017

@Mugridge do you have some script for that?

@Mugridge

This comment has been minimized.

Mugridge commented Nov 16, 2017

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

This comment has been minimized.

FilipLigaarden commented Nov 16, 2017

@Mugridge Thank you.
This is a great workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment