Search Criteria
Package Details: snapcast 0.26.0-1
Package Actions
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: | 31 |
Popularity: | 0.20 |
First Submitted: | 2016-01-01 21:21 (UTC) |
Last Updated: | 2021-12-22 20:43 (UTC) |
Dependencies (11)
- alsa-lib (alsa-lib-git, alsa-lib-minimal-git, alsa-lib-x205ta)
- avahi (avahi-nosystemd, avahi-git, avahi-gtk2)
- expat (expat-git)
- flac (flac-nodocs-git, flac-minimal-git, flac-git)
- libpulse (libpulse-bluedio, pulseaudio-pali, pulseaudio-dummy, libpulse-nosystemd-git, libpulse-nosystemd, libpulse-nosystemd-minimal-git, libpulse-hsphfpd, libpulse-airplay, pulseaudio-git)
- libsoxr (libsoxr-git)
- libvorbis (libvorbis-git, libvorbis-aotuv, libvorbis-aotuv-lancer)
- opus (opus-git)
- alsa-utils (alsa-utils-transparent, alsa-utils-git, alsa-utils-nosystemd-minimal-git) (make)
- boost (boost-git) (make)
- cmake (cmake-git) (make)
Latest Comments
Corubba commented on 2022-01-09 23:42 (UTC) (edited on 2022-01-09 23:43 (UTC) by Corubba)
And why do you believe that?
pkgconf
is part of thebase-devel
group, and following the docs it should not be explicitly included asmakedepends
.cmc commented on 2022-01-09 23:28 (UTC)
Thanks for making the package!
I believe pkgconfig should be in the mandatory dependencies.
mogwai commented on 2021-12-24 20:50 (UTC)
@m040601: This gcc11 patch is unrelated. That code is now in 0.26.0 itself. Please report upstream as this is indeed most likely an out-of-memory issue.
m040601 commented on 2021-12-24 19:46 (UTC) (edited on 2021-12-24 19:59 (UTC) by m040601)
I wonder if anyone can give me any tips or insight before I try to report my problem to upstream Snapcast.
I've been running Archlinux (ARM) and compiling Snapcast on my 1GB memory humble little Raspberry Pi 2 1.1 (32 bit armv7h) for 2 years. Until version 0.26 had no problems. It always took aaaaaaages to compile this C++ thingy, but in the end it bravely managed to do it. Running MPD and Snapcast with Opus encoding was also very smooth, and the CPU and RAM has always been more than enough.
With the latest version 0.26 in December, I'm stuck. I can't finish compiling it, without running out of memory apparently. Tried already several times. It's the exact same system I've been running for 2 years. But somehow I cant get past 15% in the compilation process and makepkg aborts with:
Sometimes I get a kernel "oom kill" thingy. The system runs out of memory, and the kernel aborts the process and reboots.
alarmpi kernel:
and
I have very little understanding of C++, compilation processes etc. But the first thing that occurred to me, is that, with version 0.26, maybe somehow the requirements of Snapcast have changed, are beefier now, and this hardware can't cope with it now.
Tried to shut down all the other non necessary services, and tried over and over to no avail.
But before I report this to Snapcast upstream, I want to be 100% sure, that it's not the PKGBUILD fault.
I noticed something with this PKGBUILD here on AUR. The latest changes to the PKGBUILD removed this line:
So this patch is no longer being applied as was in version 0.25. I dont know what the patch was for but:
Thanks in advance.
PS: Maybe related ? I saw this on Snapcast issues:
About the debian armhf package, https://github.com/badaix/snapcast/issues/960
mogwai commented on 2021-07-25 17:13 (UTC)
@cgirard: I've been trying to get exact solution upstreamed for quite a while now. See upstream issue: https://github.com/badaix/snapcast/issues/486
You're probably right that, in the meantime, I should change the text in the install file to refer to changing the location of the fifo rather than trying to work around the problems with the default location in /tmp
cgirard commented on 2021-07-25 16:31 (UTC)
Hi, instead of advising of disabling protected FIFOs, it would be probably a better idea to just advise to use
/run/snapserver/snapfifo
as you even care to create/run/snapserver
mogwai commented on 2021-05-17 08:22 (UTC)
@Hazzl: Thank you for upstreaming!
Since gcc11 hit the core repository today and no new release is available upstream (yet), I've added your patch. Thanks again for raising this issue.
mogwai commented on 2021-05-16 14:35 (UTC)
@Hazzl: Could you please report this issue upstream?
Hazzl commented on 2021-05-16 14:29 (UTC)
I need the following patch to compile with g++-11.1.0
mogwai commented on 2021-01-16 11:36 (UTC)
@m040601: done
m040601 commented on 2021-01-13 17:55 (UTC) (edited on 2021-01-13 18:06 (UTC) by m040601)
At https://github.com/badaix/snapcast there is the "docs" folder . Its content ends up in /usr/share/doc/snapcast
But there's also some extra usefull stuff besides that "docs" folder.
Could you please also include it ? Thanks.
mogwai commented on 2020-10-15 20:30 (UTC)
Indeed, I just noticed that the original github alert is referring to a different commit than the current 0.22.0 tag. It seems he added one more commit to fix a missing include, and then re-tagged. Glad to have that cleared up. I thought I was going crazy. :-)
CultofRobots commented on 2020-10-15 20:26 (UTC)
Probably happened because snapcast dev pulled v0.22.0 assets about an hour after they uploaded it to github, then uploaded new assets under the same release tag a bit later.
mogwai commented on 2020-10-15 20:18 (UTC)
Thanks for the notification. I don't know what went wrong. I built the package on several hosts (x86_64, armv7h and aarch64) before submitting it, using standard makepkg commands. Anyhow, it should be solved now.
m040601 commented on 2020-10-15 17:18 (UTC) (edited on 2020-10-15 17:18 (UTC) by m040601)
Source sha256sums was not updated, same problem
sgar commented on 2020-10-15 14:13 (UTC) (edited on 2020-10-15 14:14 (UTC) by sgar)
Source sha256sums was not updated..
==> Verification of source files with sha256sums...
snapcast-0.22.0.tar.gz ... ERROR
snapcast.sysusers ... Durchgelaufen
snapcast.tmpfiles ... Durchgelaufen
snapcast.install ... Durchgelaufen
mogwai commented on 2020-07-22 14:04 (UTC)
@m040601 : Actually the doc folder in the package tarball is (primarily) meant for the github online documentation. These are md files that are linked through from the main README.md in the toplevel directory. But I can see some value in adding them to the package nevertheless. I've added them in 0.20.0-2.
m040601 commented on 2020-07-15 11:43 (UTC) (edited on 2020-07-15 11:45 (UTC) by m040601)
Please include the content that this package's "docs" folder provides. It should be installed under '/usr/share/doc/snapcast' It has important information, that is not on the man pages. It is also included in the archive you're pulling from, https://github.com/badaix/snapcast/archive/v${pkgver}.tar.gz
slackline commented on 2019-12-28 06:53 (UTC)
@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 (UTC)
@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 (UTC)
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 (UTC)
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 (UTC)
Problem is fixed now, still don't know what exactly the problem was. Thanks for fixing
mogwai commented on 2019-02-11 14:42 (UTC)
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 (UTC)
I agree with @crystaly, paths should be fixed.
mogwai commented on 2019-02-10 10:33 (UTC)
@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 (UTC)
Package does not build, the path for .sysusers and .tmpfiles should not be ../.. but ../ instead.
mogwai commented on 2019-02-05 09:38 (UTC)
@vknmnn: Should now be fixed. The directories (and users) are now created through sysusers.d and tmpfiles.d. Can you check?
vknmnn commented on 2019-02-03 14:20 (UTC)
Running the client in daemon mode as user snapclient fails to spawn pulseaudio, because /var/lib/snapclient is not being created by this PKGBUILD, so please include it
dvzrv commented on 2018-08-01 13:26 (UTC)
@mogwai: nicely done! :)
One more (minor) thing: You don't have to supply
-o root
or-g root
toinstall
, aspackage()
is run in a fakeroot environment (meaning all files should be installed as root anyhow).mogwai commented on 2018-07-31 20:52 (UTC)
Package has been updated to get rid of external upstream libraries. @dvzrv: The PKGBUILD has also been updated to incorporate your comments.
Note that this will actually not have any impact on the build itself: flac, vorbis, avahi were already linked dynamically to the archlinux package libraries, and all other external dependencies were headers-only libraries so no libraries need to be linked in.
In order to build the new package, two new AUR packages need to be installed: popl and aixlog. These packages are only needed to build snapcast; they can be uninstalled after the build.
dvzrv commented on 2018-07-31 06:33 (UTC)
@mogwai:
You must put $pkgdir and $srcdir in quotes (as they can contain whitespaces)! It's also best practice to remove empty variables from the PKGBUILD.
Please don't use the external libraries from upstream, unless there are important modifications to them (in that case tell upstream to implement them in their respective upstreams), but use the source tarball and rely on dynamic libraries (you will have to create a few more packages)! However, in case you have to include static libs with submodules (which I don't think you have to), this would be the way to do it: https://wiki.archlinux.org/index.php/VCS_package_guidelines#Git_Submodules
jenniferbrownz commented on 2018-06-16 14:17 (UTC)
More digging and this has been addressed upstream in the development version. http://bit.ly/2KpU5Rl
languitar commented on 2017-12-03 20:16 (UTC)
Most of the upstream dependencies of this software have now proper build systems and could be packaged independently instead of submodule. Would be nice if this package could reflect this.
slackline commented on 2017-11-02 22:01 (UTC) (edited on 2017-11-02 22:29 (UTC) by slackline)
slackline commented on 2017-10-18 07:22 (UTC)
mogwai commented on 2017-10-04 11:33 (UTC)
mokman commented on 2017-10-01 10:46 (UTC)
slackline commented on 2017-09-25 08:27 (UTC)
slackline commented on 2017-09-23 20:59 (UTC)
slackline commented on 2017-09-21 08:41 (UTC)
mokman commented on 2017-08-19 13:44 (UTC) (edited on 2017-08-23 11:18 (UTC) by mokman)
mogwai commented on 2017-08-04 14:48 (UTC)
Varakh commented on 2017-07-26 11:43 (UTC)
mogwai commented on 2017-04-19 19:36 (UTC)
brianleu commented on 2017-04-19 02:42 (UTC)
mogwai commented on 2017-03-17 21:42 (UTC)
azrdev commented on 2017-03-15 10:14 (UTC)
languitar commented on 2016-12-26 11:44 (UTC) (edited on 2016-12-26 12:07 (UTC) by languitar)
mogwai commented on 2016-12-25 13:19 (UTC)
languitar commented on 2016-12-24 13:46 (UTC)
mogwai commented on 2016-02-22 14:24 (UTC)
j0s commented on 2016-02-19 11:06 (UTC) (edited on 2016-02-19 11:08 (UTC) by j0s)
mogwai commented on 2016-02-16 10:39 (UTC)