Question 1

FLAC のアップデート後、snapclient の「libFLAC.so.8: cannot open shared object file」を修正するにはどうすればよいですか？

Accepted Answer

これは、Snapclient 0.26.0 が古い FLAC 8 soname に対してリンクされている一方で、FLAC 1.4.x が libFLAC.so.12 を提供している場合に発生します。即時の回避策: 互換性のためのシンボリックリンクを作成します:

sudo ln -s /usr/lib/libFLAC.so.12 /usr/lib/libFLAC.so.8

ライブラリが別の場所にある場合は、次で見つけてください:

find /usr/lib* -name 'libFLAC.so.*'

その後、そのディレクトリ内にシンボリックリンクを作成します。よりクリーンな長期的な修正は、更新された FLAC パッケージに対して AUR Snapcast パッケージをクリーンビルドし直す/再インストールすることです。

Question 2

なぜsnapclientはsystemdサービスとしては失敗するのに、Raspberry Piで手動で起動すると動作するのですか？

Accepted Answer

systemd サービスは /etc/default/snapclient 内のオプションで snapclient を起動しますが、SSH で直接 snapclient を実行するとそれらのオプションは無視されます。したがって、SNAPCLIENT_OPTS のサウンドカード設定が間違っていると、手動起動は動作してもサービスが失敗することがあります。

1. 正しい ALSA サウンドカード ID を確認します:
snapclient -l

2. サービスのオプションを編集します:
sudo nano /etc/default/snapclient

3. 正しいサウンドカードを設定します。たとえば JustBoom/AMP HAT の場合:
SNAPCLIENT_OPTS="--player alsa --soundcard sysdefault:CARD=sndrpijustboomd"
sysdefault:CARD=sndrpijustboomd を、お使いのオーディオデバイスで報告された ID に置き換えてください。

4. サービスを再起動します:
sudo systemctl restart snapclient
sudo systemctl status snapclient

それでも失敗する場合は、次のコマンドで詳細なエラーを確認します:
journalctl -u snapclient.service -n 100

Question 3

Raspberry Pi で Snapcast をビルドする際に 'c++: fatal error: Killed signal terminated program cc1plus' を修正する方法は？

Accepted Answer

コンパイラが強制終了されているのは、Raspberry Pi のメモリが不足しているためです。GCC 7.1 の parameter passing の注記は単なる警告です。1 GB の Raspberry Pi では、1 ジョブでビルドし、コンパイル前に swap を増やしてください：

sudo dphys-swapfile swapoff
sudo sed -i 's/^CONF_SWAPSIZE=.*/CONF_SWAPSIZE=2048/' /etc/dphys-swapfile
sudo dphys-swapfile setup
sudo dphys-swapfile swapon
free -h

次に、並列度を制限して再ビルドします：

cmake --build . --parallel 1

それでもメモリが不足する場合は、より大きな swap ファイル（たとえば CONF_SWAPSIZE=4096）を使用するか、より多くの RAM を搭載した Raspberry Pi でビルドするか、ドキュメント化された cross-compilation workflow を使用してください。SD カード上の swap を増やすと遅くなり、フラッシュの摩耗が増える可能性があります。

Question 4

Snapcast が Spotify のトラックをまったく再生しない問題をどう修正すればよいですか？

Accepted Answer

これはアップストリームの librespot 互換性の問題であり、Snapcast のバグではありません。PR #1622 を含む開発ブランチから librespot を再ビルドし、新しいバイナリを使用してください：

git clone https://github.com/librespot-org/librespot.git
cd librespot
git fetch origin pull/1622/head:pr-1622
git checkout pr-1622
cargo build --release

Snapcast が使用する librespot バイナリを target/release/librespot に置き換えるか、それをカスタム Docker イメージにビルドしてください。一時的な代替策は、ホスト上で librespot をビルドし、その出力 FIFO を Snapcast コンテナと共有することです。手動でビルドしたくない場合は、公式に更新された Snapcast コンテナを待ってください。

Question 5

なぜSnapcastはStream.RemoveStreamでTCPストリームを削除した後も、TCPポートをバインドしたままにするのですか？

Accepted Answer

これは Snapcast 0.34.0 のバグです:TCP ストリームオブジェクトが内部で参照され続けるため、acceptor ソケットが破棄されず、ポートがバインドされたままになります(netstat -tunlp | grep <port> で確認できます)。この問題は develop ブランチで、コミット 71900ba75dbc3a79a0b484e8217d6b14cd92b2b9 および ae5661f3626e27bab8c21f7f30bef3c4aa5ffc68 によって修正されています(元々は issue #1455 を修正するためのものでした)。回避策:develop ブランチから snapserver を再ビルドするか、これらのコミットを含むリリースにアップグレードしてください。修正後は、Stream.RemoveStream を呼び出すと TCP ポートが即座に解放され、再利用できるようになります。

snapcast

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト