Package Details: snapcast 0.19.0-1

Git Clone URL: https://aur.archlinux.org/snapcast.git (read-only, click to copy)
Package Base: snapcast
Description: Synchronous multi-room audio player
Upstream URL: https://github.com/badaix/snapcast
Keywords: audio multi-room
Licenses: GPL
Submitter: mogwai
Maintainer: mogwai
Last Packager: mogwai
Votes: 20
Popularity: 2.22
First Submitted: 2016-01-01 21:21
Last Updated: 2020-03-15 10:20

Latest Comments

1 2 3 4 Next › Last »

slackline commented on 2019-12-28 06:53

@mogwai : Thanks for taking the time to help me out.

I do still have /etc/default/snapclient and it reads...

cat /etc/default/snapclient

defaults file for snapclient
start snapclient automatically?

START_SNAPCLIENT=true

Allowed options:
--help produce help message
-v, --version show version number
-h, --host arg server hostname or ip address
-p, --port arg (=1704) server port
-l, --list list pcm devices
-s, --soundcard arg (=default) index or name of the soundcard
-d, --daemon [=arg(=-3)] daemonize, optional process priority [-20..19]
--user arg the user[:group] to run snapclient as when daemonized
--latency arg (=0) latency of the soundcard
-i, --instance arg (=1) instance id

USER_OPTS="--user snapclient:audio"

SNAPCLIENT_OPTS="-d -h 192.168.1.21 -p 1704"

Which I seem to have edited in the past since the IP address is that of the system so its unchanged.

It still fails though...

systemctl restart snapclient systemctl status snapclient ● snapclient.service - Snapcast client Loaded: loaded (/usr/lib/systemd/system/snapclient.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2019-12-28 06:40:23 UTC; 5s ago Docs: man:snapclient(1) Process: 11700 ExecStart=/usr/bin/snapclient $SNAPCLIENT_OPTS (code=exited, status=1/FAILURE) Main PID: 11700 (code=exited, status=1/FAILURE)

Dec 28 06:40:23 alarmpi systemd[1]: snapclient.service: Scheduled restart job, restart counter is at 5. Dec 28 06:40:23 alarmpi systemd[1]: Stopped Snapcast client. Dec 28 06:40:23 alarmpi systemd[1]: snapclient.service: Start request repeated too quickly. Dec 28 06:40:23 alarmpi systemd[1]: snapclient.service: Failed with result 'exit-code'. Dec 28 06:40:23 alarmpi systemd[1]: Failed to start Snapcast client.

journalctl reports that the problem is because it can not create the required PID file

journalctl -g snapclient Dec 28 06:40:21 alarmpi audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" h> Dec 28 06:40:21 alarmpi kernel: audit: type=1130 audit(1577515221.819:1262): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe>Dec 28 06:40:21 alarmpi snapclient[11694]: Exception: Could not open PID lock file "/var/run/snapclient/pid" Dec 28 06:40:21 alarmpi systemd[1]: snapclient.service: Main process exited, code=exited, status=1/FAILURE Dec 28 06:40:21 alarmpi systemd[1]: snapclient.service: Failed with result 'exit-code'. Dec 28 06:40:21 alarmpi audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" ho>Dec 28 06:40:22 alarmpi kernel: audit: type=1131 audit(1577515221.959:1263): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe> Dec 28 06:40:22 alarmpi systemd[1]: snapclient.service: Scheduled restart job, restart counter is at 1.

The directory /var/run/snapclient existed since I created it the other day when trying to troubleshoot this, but I didn't set the ownership to that of the snapclient user. Having now done so snapclient starts and runs fine. No idea why the directory disappeared though.

Thanks again for your time and for maintaining the package.

mogwai commented on 2019-12-26 15:07

@slackline: There is only a file called /etc/snapserver.conf; there is no /etc/snapclient.conf. The configuration for the client (started through systemd) should still be put into /etc/default/snapclient, just as before with version 0.15. I think the idea is that mainly the server is run through systemd as a daemon. Usually the client is run as a regular user unless it's a headless system. So, could you try your old 0.15 setup for the client with 0.17.1 again? It should simply work as-is.

slackline commented on 2019-12-25 13:52

Hi,

Just upgraded from 0.15.0 to 0.17.1 and I can't seem to get snapclient working.

I've created /etc/snapclient.conf and set SNAPCLIENT_OPTS there...

cat /etc/snapclient.conf

SNAPCLIENT_USER="--user snapclient:audio"

SNAPCLIENT_OPTS="-d -h 192.168.1.21 -p 1704"

...as these are what is required when initialising with systemctl

alarmpi etc # cat /usr/lib/systemd/system/snapclient.service
[Unit]
Description=Snapcast client
Documentation=man:snapclient(1)
Wants=avahi-daemon.service
After=network.target time-sync.target sound.target avahi-daemon.service

[Service]
EnvironmentFile=-/etc/default/snapclient
ExecStart=/usr/bin/snapclient $SNAPCLIENT_OPTS
User=snapclient
Group=snapclient

very noisy on stdout

StandardOutput=null
Restart=on-failure

[Install]
WantedBy=multi-user.target

But when I try starting I get...

systemctl restart snapclient.service
systemctl status snapclient.service

● snapclient.service - Snapcast client Loaded: loaded (/usr/lib/systemd/system/snapclient.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2019-12-25 13:44:18 UTC; 1min 22s ago Docs: man:snapclient(1) Process: 4135 ExecStart=/usr/bin/snapclient $SNAPCLIENT_OPTS (code=exited, status=1/FAILURE) Main PID: 4135 (code=exited, status=1/FAILURE)

Dec 25 13:44:18 alarmpi systemd[1]: snapclient.service: Scheduled restart job, restart counter is at 5. Dec 25 13:44:18 alarmpi systemd[1]: Stopped Snapcast client. Dec 25 13:44:18 alarmpi systemd[1]: snapclient.service: Start request repeated too quickly. Dec 25 13:44:18 alarmpi systemd[1]: snapclient.service: Failed with result 'exit-code'. Dec 25 13:44:18 alarmpi systemd[1]: Failed to start Snapcast client.

And sure enough its not started...

-- The job identifier is 2750. Dec 25 13:49:32 alarmpi audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" h Dec 25 13:49:33 alarmpi snapclient[4169]: Exception: Could not open PID lock file "/var/run/snapclient/pid" Dec 25 13:49:33 alarmpi snapclient[4169]: daemon terminated. Dec 25 13:49:33 alarmpi systemd[1]: snapclient.service: Main process exited, code=exited, status=1/FAILURE -- Subject: Unit process exited -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- An ExecStart= process belonging to unit snapclient.service has exited. -- -- The process' exit code is 'exited' and its exit status is 1. Dec 25 13:49:33 alarmpi systemd[1]: snapclient.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The unit snapclient.service has entered the 'failed' state with result 'exit-code'. Dec 25 13:49:33 alarmpi audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" ho Dec 25 13:49:33 alarmpi systemd[1]: snapclient.service: Scheduled restart job, restart counter is at 5. -- Subject: Automatic restarting of a unit has been scheduled -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Automatic restarting of the unit snapclient.service has been scheduled, as the result for -- the configured Restart= setting for the unit. Dec 25 13:49:33 alarmpi systemd[1]: Stopped Snapcast client. -- Subject: A stop job for unit snapclient.service has finished -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A stop job for unit snapclient.service has finished. -- -- The job identifier is 2819 and the job result is done. Dec 25 13:49:33 alarmpi audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" h Dec 25 13:49:33 alarmpi audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" ho Dec 25 13:49:33 alarmpi systemd[1]: snapclient.service: Start request repeated too quickly. Dec 25 13:49:33 alarmpi systemd[1]: snapclient.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The unit snapclient.service has entered the 'failed' state with result 'exit-code'. Dec 25 13:49:33 alarmpi systemd[1]: Failed to start Snapcast client. -- Subject: A start job for unit snapclient.service has failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A start job for unit snapclient.service has finished with a failure. -- -- The job identifier is 2819 and the job result is failed.

There are mentiones of a missing /var/run/snapclient/pid file not being accessible and there was no such directory so I created it but it still failed (see last output above for job 2819).

Any pointers on what I should be doing are welcome.

languitar commented on 2019-03-31 11:46

Since some time I have troubles connecting mopidy to snapserver. The internal GStreamer pipeline always terminates immediately with a permission denied error. I just found out that there is a new kernel feature that prevents accessing fifos owned by different users, which is causing this issue: https://unix.stackexchange.com/questions/503111/group-permissions-for-root-not-working-in-tmp

crystaly commented on 2019-02-13 18:10

Problem is fixed now, still don't know what exactly the problem was. Thanks for fixing

mogwai commented on 2019-02-11 14:42

I have changed the source path for sysusers and tmpfiles, even though I was not able to reproduce the problem. Please check if this solves it.

Speranskiy commented on 2019-02-10 19:15

I agree with @crystaly, paths should be fixed.

mogwai commented on 2019-02-10 10:33

@crystaly: Can you please give more elaborate output? Or retry from a clean directory? The package is building fine on my side. I've rebuilt it on 5+ systems from scratch (x64 and armv7h) without problems.

Looking at the PKGBUILD: those relative paths should be "../.." not "../", because the package() function operates from within the src/${pkgname}-${pkgver} directory.

crystaly commented on 2019-02-10 08:59

Package does not build, the path for .sysusers and .tmpfiles should not be ../.. but ../ instead.

mogwai commented on 2019-02-05 09:38

@vknmnn: Should now be fixed. The directories (and users) are now created through sysusers.d and tmpfiles.d. Can you check?