Snapcast v0.28.0

[badaix]

Version 0.28.0-beta.1

Features

• Server: Use filename as title for FileStreams

Bugfixes

• Server: Fix noise caused by reading half samples (Issue Snapclient sounds like /dev/urandom just got piped into my speaker #1170)
• Server: Check open syscall error in PipeStream::do_connect (PR Check open syscall error in PipeStream::do_connect #1150)
• Server: Tweak Airplay support (Tweak Airplay #1102)
• Server: Lower log severity for shairport-sync (Issue shairport-sync metadata log errors in snapserver #891)
• Improve connect handling in meta_mopidy.py
• Fix cppcheck issues

General

• CI: Build debian bookworm and bullseye packages for amd64, arm and arm64
• CI: Add cppcheck static analysis
• Update documentation (PR Added more fs.protected_fifos to player_setup and configuration #1130, PR (doc) Adapt mpv process example in player setup #1067)
• Delete deprecated Makefiles, CMake is the only supported buildsystem
• Snapweb: Update to v0.7.0

---

This discussion was created from the release Snapcast v0.28.0.

[kerta1n]

Will there still be support for OpenWRT going forward? I see that the snapos repo is now read-only. If packages are going to be compiled through this repository, I'd be willing to compile all of the packages for this release

[badaix]

Snapos used to be the place where debian packages for ARM and X86 were built, but these are now build again in the Snapcast project itself.
Regarding OpenWRT: I'm not using it on my own and don't have the time to maintain it, nor have the possibility to seriously test and support it. Also building packages (ipk?) for OpenWRT doesn't make sense because of the huge variety of supported hardware platforms. The only thing that would make sense is to get somehow official support by OpenWRT, i.e. getting Snapcast into the official package repository.

[kerta1n]

Makes sense, are you still open to keeping the SDK method open though? It works a lot nicer compared to compiling for buildroot/a whole build of OpenWRT, and also I think I speak for a lot of us end users since it's insane being able to use a USB port on a router to stream music. I understand if maintaining the SDK method is too much though.

[arpena]

I've just tested and succeeded to compile the 0.28.0 release, both server and client, using the SDK method. I've used the package dir from Snapos, replacing the release number and the path for the snap[client|server].default files.
I haven't tested the server on my OpenWRT router, only the client, and it works correctly against a 0.27.0 server.

@badaix, could you add the package dir from Snapos to extras/package? That would be a great help for us OpenWRT users.

[MichaIng]

Is there a reason why Debian packages are now provided as zip archives with client and server packages inside, instead of having individual downloads for them? This raises traffic and efforts for users and the size of the archive is usually larger than the size of the contained DEB packages, since zip cannot further compress xz/LZMA2.

Otherwise, I vote for reverting to the old distribution with individual DEB package artifacts 🙂.

EDIT: Ah, I see this is since those are now done here via new GitHub Actions workflows, and zipping is what the upload-artifact action does by default, and it cannot be avoided: actions/upload-artifact#367
So it would require some work, moving away from that action and uploading the artifacts manually or with a different action. If wanted, I could have a look into this.

[MichaIng]

I see I was a little mistaken. The upload-artifact action creates workflow artifacts only, but does not attach them to releases. This seems to be done manually or with an external workflow. However, surely the workflow artifacts are used for this. The external workflow could extract those and upload the included DEB packages instead. But I see now that builds are per Debian version, while previously there was one package per arch only. This is indeed an enhancement, since previously there were related problems, that the packages could not be installed on Debian Bookworm, since they were depending on libflac8, which is provided up to Bullseye only, else libflac12. Hence the Debian version codename would need to be added to the package filenames as well.

A step could be added, which renames and uploads the plain DEB files via GitHub CLI, in case the workflow was triggered with release tag context:

jobs:
  deb:
    permissions:
      contents: write # release changes require contents write
...
    steps:
...
    - name: Upload release assets
      if: ${{ startsWith(github.ref, 'refs/tags/') }}
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        cd ..
        # Add Debian version codename to package filename
        for file in snap*_${{ matrix.arch }}.deb; do mv "$file" "${file%.deb}-debian-${{ matrix.debian }}.deb"; done
        gh release upload "$GITHUB_REF_NAME" 'snap*_${{ matrix.arch }}-debian-${{ matrix.debian }}.deb' --clobber

Similarly, for Windows the zip archive could be attached to the release by the GitHub workflow automatically, where of course zipping still makes sense.

[seppeel]

i am providing amd64 docker images containing the combination of librespot and snapcast with descriptions how to use it and a repo containg the dockerfile.
If you want to, you can add it to your readme.

https://hub.docker.com/r/bunchofbricks/librespot-snapcast
https://github.com/bunchofbricks/librespot-snapcast

[kerta1n]

Created Alpine images for librespot + snapcast, multiarch for armv7, arm64 + amd64

https://github.com/kerta1n/snapclient-docker
https://github.com/kerta1n/lssc