Skip to content
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

Shairport-sync breaks with v.6.29.0 #3461

Closed
C0D3-M4513R opened this issue Apr 6, 2020 · 38 comments
Closed

Shairport-sync breaks with v.6.29.0 #3461

C0D3-M4513R opened this issue Apr 6, 2020 · 38 comments
Labels
Beta 🧪 Issues specific to the Beta branch testing
Milestone

Comments

@C0D3-M4513R
Copy link
Contributor

C0D3-M4513R commented Apr 6, 2020

Creating a bug report/issue

Required Information

  • DietPi version | cat /DietPi/dietpi/.version
    G_DIETPI_VERSION_CORE=6
    G_DIETPI_VERSION_SUB=29
    G_DIETPI_VERSION_RC=0
    G_GITBRANCH='beta'
    G_GITOWNER='MichaIng'
  • Distro version | echo $G_DISTRO_NAME or cat /etc/debian_version
    echo $G_DISTRO_NAME
  • Kernel version | uname -a
    Linux raspi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
  • SBC device | echo $G_HW_MODEL_DESCRIPTION or (EG: RPi3)
    RPi3b+
  • Power supply used | (EG: 5V 1A RAVpower)
    5V2A Anker
  • SDcard used | (EG: SanDisk ultra)
    noname

Additional Information (if applicable)

  • Software title | (EG: Nextcloud)
    shairport-sync
  • Was the software title installed freshly or updated/migrated?
    both tested
  • Can this issue be replicated on a fresh installation of DietPi?
    don't know for sure, however it should be the case

5179c715-faef-448d-89f7-7d9023461c02

  • Bug report ID | sed -n 5p /DietPi/dietpi/.hw_model

Steps to reproduce

  1. Have a v.6.28.0 install with or without shairport-sync
  2. Update to v.6.29.0
  3. if you did a migrate do a apt install shairport-sync --reinstall if you upgrade notice missing packeges being installed
  4. or install shairport-sync (or uninstall and install shairport-sync and alsa)

Expected behaviour

  • shairport-sync should be playing the accepted airplay content to the speakers

Actual behaviour

  • shairport-sync is just sitting there, doing (apperantly nothing)

Extra details

  • shairport-sync was working on v.6.28.0 flawlessly (except sometimes under voltage)
  • This is not the audio output not working! I tested that with alsabat and alsabat-test, however i got some strange readings: (every time it tried to play a sound, even if some error popped up before/after it worked)
root@raspi:~# alsabat
alsa-utils version 1.1.8

Entering playback thread (ALSA).
Get period size: 2760  buffer size: 22050
Playing generated audio sine wave
Entering capture thread (ALSA).
Cannot open PCM capture device: Datei oder Verzeichnis nicht gefunden(-2)
Playback completed.
Exit capture thread fail: -2
root@raspi:~# alsabat
alsa-utils version 1.1.8

Entering playback thread (ALSA).
Get period size: 2760  buffer size: 22050
Playing generated audio sine wave
Entering capture thread (ALSA).
Cannot open PCM capture device: Datei oder Verzeichnis nicht gefunden(-2)
Playback completed.
Exit capture thread fail: -2
root@raspi:~# alsabat-test
*******************************************
                BAT Test                   
-------------------------------------------
usage:
  /usr/sbin/alsabat-test <sound card>
  /usr/sbin/alsabat-test <device-playback> <device-capture>
current setting:
  /usr/sbin/alsabat-test default default
============================================
0: ALSA generate mono wav file with default params
-------------------------------------------
alsabat -c1 --saveplay default_mono.wav --log=tmp/0.log
alsa-utils version 1.1.8

fail
============================================
1: ALSA generate dual wav file with default params
-------------------------------------------
alsabat -c2 --saveplay default_dual.wav --log=tmp/1.log
alsa-utils version 1.1.8

fail
@MichaIng MichaIng added the Beta 🧪 Issues specific to the Beta branch testing label Apr 6, 2020
@MichaIng MichaIng added this to the v6.29 milestone Apr 6, 2020
@MichaIng
Copy link
Owner

MichaIng commented Apr 6, 2020

@C0D3-M4513R
Many thanks for your report. We indeed did some changes to our shairport-sync install, however do no forced reinstall. So it is strange that the DietPi update itself broke it in your case.

apt install shairport-sync --reinstall

Note that this will replace our self-compiled package with the one form Debian repo. It ships own binary and config file, but AFAIK our previously installed systemd service stays untouched, hence non-matching binary is used. Could you paste:

systemctl cat shairport-sync

To re-apply and check the issue with our new package, could you do:

apt-get -y purge shairport-sync
cd /tmp
wget https://dietpi.com/downloads/binaries/$G_DISTRO_NAME/shairport-sync_$G_HW_ARCH_NAME.deb
apt-get -y install ./shairport-sync_$G_HW_ARCH_NAME.deb
rm shairport-sync_$G_HW_ARCH_NAME.deb

Then please try to play media, when failing please paste:

journalctl -u shairport-sync

@C0D3-M4513R
Copy link
Contributor Author

I did the apt install shairport-sync --reinstall after migration and then uninstalled (shairport-sync and alsa) via dietpi-software and installed again via dietpi-software, so the package should be normal right now, will do anyways.

root@raspi:~# systemctl cat shairport-sync
# /lib/systemd/system/shairport-sync.service
[Unit]
Description=Shairport Sync - AirPlay Audio Receiver
After=sound.target
Requires=avahi-daemon.service
After=avahi-daemon.service
Wants=network-online.target
After=network.target network-online.target

[Service]
ExecStart=/usr/local/bin/shairport-sync
User=shairport-sync
Group=shairport-sync

[Install]
WantedBy=multi-user.target

I don't think, that this is what you want, however shairport-sync -vvv doesn't output anything...

root@raspi:~# journalctl -u shairport-sync
-- Logs begin at Mon 2020-04-06 15:52:59 BST, end at Mon 2020-04-06 15:54:01 BST. --
Apr 06 15:53:07 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.

@MichaIng
Copy link
Owner

MichaIng commented Apr 6, 2020

@C0D3-M4513R
Okay, service file is correct now. Strange that shairport-sync -vvv really shows nothing. But as long as the service is up, it probably simply fails to bind to the port, hence does not receive any requests.

Could you check service status and if if is bound to the port?

systemctl status shairport-sync
ss -alnp | grep 5000

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 6, 2020

root@raspi:~# systemctl status shairport-sync
● shairport-sync.service - Shairport Sync - AirPlay Audio Receiver
   Loaded: loaded (/lib/systemd/system/shairport-sync.service; enabled; vendor p
reset: enabled)
   Active: active (running) since Mon 2020-04-06 19:38:49 BST; 3min 5
3s ago
 Main PID: 350 (shairport-sync)
    Tasks: 5 (limit: 2319)
   Memory: 2.4M
   CGroup: /system.slice/shairport-sync.service
           └─350 /usr/local/bin/shairport-sync

Apr 06 19:38:49 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receive
r.
Apr 06 19:38:51 raspi shairport-sync[350]: Note: this device may be too slow for
 "soxr" interpolation. Consider choosing the "basic" or "auto" interpolation set
ting.
root@raspi:~# ss -alnp | grep 5000
tcp    LISTEN   0        5                                  0.0.0.0:5000                                             0.0.0.0:*                                   users:(("shairport-sync",pid=350,fd=3))                                        
tcp    LISTEN   0        5                                     [::]:5000                                                [::]:*                                   users:(("shairport-sync",pid=350,fd=5))                                        
root@raspi:~# ps -FHjlp 350
F S UID        PID  PPID  PGID   SID  C PRI  NI ADDR SZ WCHAN    RSS PSR STIME TTY          TIME CMD
4 S shairpo+   350     1   350   350  1  80   0 - 17700 poll_s  6032   0 19:39 ?        00:00:10 /usr/local/bin/shairport-sync

Btw: the note is just there, because i booted with maxcpus=1, because my pi isn't doing anything. Tested with all cores though.
Also the default debian package dumps out A F**K TON with shairport-sync -vvv. It must be some change you made.

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 6, 2020

By the way:

shairport-sync should be playing the accepted airplay content to the speakers

accepted airplay content

@MichaIng
Copy link
Owner

MichaIng commented Apr 7, 2020

@C0D3-M4513R
Okay, so service is up and listening on the correct port. I removed the debug flags from compile-time options indeed, however AFAIK they should only be relevant for debuggers like gdb. Also when I tested it, it gave informational output, although I tested with x86_64 and no explicit audio output due to lack of AirPlay devices.
Ah and there is output btw, although just the startup info:

Apr 06 19:38:51 raspi shairport-sync[350]: Note: this device may be too slow for
 "soxr" interpolation. Consider choosing the "basic" or "auto" interpolation set
ting.

Did you try to uninstall via dietpi-software and use the Debian package, does this play well?
Do you use ALSA (only) and no PulseAudio? Since, as DietPi uses ALSA setups for all audio applications, I didn't compile with PulseAudio support.

Just to be sure, could you try the ARMv6 package:

cd /tmp
wget https://dietpi.com/downloads/binaries/buster/shairport-sync_armv6l.deb
dpkg -i shairport-sync_armv6l.deb
rm shairport-sync_armv6l.deb

You use a Buster image, right? Else replace with "stretch" in the URL.

Ah and just another thing what you can try, which I forgot to check:

mkdir /run/shairport-sync
chown shairport-sync: /run/shairport-sync

Should only be required for PID file, which again is not required for a systemd service, but just to rule it out.

Else, if the Debian package works, I'll rebuild with the same compile-time options that Debian uses, regarding debug flag and optimisation (-g -O2).

@C0D3-M4513R
Copy link
Contributor Author

Apr 06 19:38:51 raspi shairport-sync[350]: Note: this device may be too slow for
 "soxr" interpolation. Consider choosing the "basic" or "auto" interpolation set
ting.

That is only there, because i booted (/boot/cmdline.txt) with maxcpus=1, because my pi isn't doing anything. I'm using just a normal DietPi, meaning no Pulseaudio only Alsa.

apt install shairport-sync --reinstall

Note that this will replace our self-compiled package with the one form Debian repo.

So therefore: Yes, that happens with the Debian package as well.

Interestingly it does work with the ARMv6 package you send.

The restarts is me manually restarting the service, because I made some changes.

root@raspi:/tmp# systemctl status shairport-sync
● shairport-sync.service - Shairport Sync - AirPlay Audio Receiver
   Loaded: loaded (/lib/systemd/system/shairport-sync.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2020-04-07 11:17:12 BST; 1min 21s ago
 Main PID: 21998 (shairport-sync)
    Tasks: 12 (limit: 2319)
   Memory: 2.7M
   CGroup: /system.slice/shairport-sync.service
           └─21998 /usr/local/bin/shairport-sync

Apr 07 11:17:12 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.
root@raspi:/tmp# systemctl cat shairport-sync
# /lib/systemd/system/shairport-sync.service
[Unit]
Description=Shairport Sync - AirPlay Audio Receiver
After=sound.target
Requires=avahi-daemon.service
After=avahi-daemon.service
Wants=network-online.target
After=network.target network-online.target

[Service]
ExecStart=/usr/local/bin/shairport-sync
User=shairport-sync
Group=shairport-sync

[Install]
WantedBy=multi-user.target
root@raspi:/tmp# journalctl -u shairport-sync
-- Logs begin at Thu 2019-02-14 10:12:02 GMT, end at Tue 2020-04-07 11:18:55 BST. --
Apr 06 19:38:49 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.
Apr 06 19:38:51 raspi shairport-sync[350]: Note: this device may be too slow for "soxr" interpolation. Consider choosing the "basic" or "auto" interpolation setting.
Apr 07 11:11:43 raspi systemd[1]: Stopping Shairport Sync - AirPlay Audio Receiver...
Apr 07 11:11:43 raspi systemd[1]: shairport-sync.service: Main process exited, code=killed, status=15/TERM
Apr 07 11:11:43 raspi systemd[1]: shairport-sync.service: Succeeded.
Apr 07 11:11:43 raspi systemd[1]: Stopped Shairport Sync - AirPlay Audio Receiver.
Apr 07 11:11:47 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.
Apr 07 11:17:12 raspi systemd[1]: Stopping Shairport Sync - AirPlay Audio Receiver...
Apr 07 11:17:12 raspi systemd[1]: shairport-sync.service: Main process exited, code=killed, status=15/TERM
Apr 07 11:17:12 raspi systemd[1]: shairport-sync.service: Succeeded.
Apr 07 11:17:12 raspi systemd[1]: Stopped Shairport Sync - AirPlay Audio Receiver.
Apr 07 11:17:12 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.

Oh, and the /run/shairport-sync directory is not required, just like you said, work with and without for the ARMv6 package.

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 7, 2020

Oh and btw: debug output would've been useful here, because it woud've probably contained useful information about what was failing. Maybe try to enable the debug flag for manually debugging?

@MichaIng
Copy link
Owner

MichaIng commented Apr 7, 2020

@C0D3-M4513R
Okay, great that it works with the ARMv6 package. I mean RPi3+ on Raspbian is ARMv7 but all packages from the Raspbian repo are ARMv6 for RPi1/Zero compatibility. We never observed this in any other case, but it might be possible that in this particular case the ARMv7 binary does not harmonise with the ARMv6 libraries.

So therefore: Yes, that happens with the Debian package as well.

This otherwise does not fit to my idea... I'm at least confused now. So our ARMv7 binary and the Debian ARMv6 binary do not work but our ARMv6 binary does. Confusing 🤣. Okay I'll compare the two packages again to assure that both were build exactly the same and in case rebuild the ARMv7 one. If we get some other reports that ARMv7 does not work on RPi2+ while ARMv6 does, we can manually pull that on all RPi devices. This build at least will be exactly what you get when compiling on RPi with Raspbian, so it is something that might be reasonable in all cases actually.

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 7, 2020

So, it turns out, that the Debian package works as well. Oops! On my first test it didn't...
Maybe this:

apt install shairport-sync --reinstall

doesn't purge the configfiles?

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 7, 2020

And now, after that, the ARMv7 Package, packaged with dietpi-software works? Guess apt really doesn't have any reproducibility.
Guess the tool does a better job than me to clean configs,etc. than me?
Or is it, that I had an old build (now 3.3.6)?
Just glad it works!

@MichaIng
Copy link
Owner

@C0D3-M4513R
Many thanks for reporting back. Hmm indeed strange, probably some config file was left or still something mixed up with multiple versions. I'm glad it works now.

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 18, 2020

root@raspi:~# service shairport-sync status
● shairport-sync.service - Shairport Sync - AirPlay Audio Receiver
   Loaded: loaded (/lib/systemd/system/shairport-sync.service; disabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-04-18 17:01:29 BST; 3min 18s ago
 Main PID: 702 (shairport-sync)
    Tasks: 5 (limit: 2319)
   Memory: 3.5M
   CGroup: /system.slice/shairport-sync.service
           └─702 /usr/local/bin/shairport-sync

Apr 18 17:01:29 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.
Apr 18 17:01:30 raspi shairport-sync[702]: Note: this device may be too slow for "soxr" interpolation. Consider cho
osing the "basic" or "auto" interpolation setting.
root@raspi:~# systemctl cat shairport-sync
# /lib/systemd/system/shairport-sync.service
[Unit]
Description=Shairport Sync - AirPlay Audio Receiver
After=sound.target
Requires=avahi-daemon.service
After=avahi-daemon.service
Wants=network-online.target
After=network.target network-online.target

[Service]
ExecStart=/usr/local/bin/shairport-sync
User=shairport-sync
Group=shairport-sync

[Install]
WantedBy=multi-user.target
root@raspi:~# journalctl -u shairport-sync
-- Logs begin at Thu 2019-02-14 10:12:02 GMT, end at Sat 2020-04-18 17:04:59 BST. --
Apr 18 17:01:29 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.
Apr 18 17:01:30 raspi shairport-sync[702]: Note: this device may be too slow for "soxr" interpolation. Consider cho
osing the "basic" or "auto" interpolation setting.
root@raspi:~# apt install shairport-sync --reinstall
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Erneute Installation von shairport-sync ist nicht möglich,
es kann nicht heruntergeladen werden.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Same issue, reinstalled shairport-sync package with version armv6l, armv7l, dietpi-software and debian repo version could not be downloaded.
WTF? I think, there is more going on here. Probably something deeply wrong with my system?! I won't reopen, unless asked, because I think it would go away with a new install and is specific to my system.
also reinstalled alsa and avahi via dietpi-software

@MichaIng
Copy link
Owner

@C0D3-M4513R
Hmm, please try to uninstall Shairport-Sync via dietpi-software, to be sure everything is purged

rm -f /lib/systemd/system/shairport-sync.service /usr/local/bin/shairport-sync /usr/local/etc/shairport-sync.conf* /usr/local/share/man/man7/shairport-sync.7.gz
userdel -rf shairport-sync

and reinstall again.

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 21, 2020

This happens now every time, I uninstall...
While uninstalling (did it manually to show output):

root@raspi:/tmp/DietPi-Software# dpkg --purge shairport-sync
(Reading database ... 28828 files and directories currently installed.)
Removing shairport-sync (3.3.6-dietpi1) ...
Deconfiguring Shairport-Sync systemd service ...
Unit shairport-sync.service does not exist, proceeding anyway.
Failed to disable unit: Unit file shairport-sync.service does not exist.
dpkg: error processing package shairport-sync (--purge):
 installed shairport-sync package pre-removal script subprocess returned error exit status 1
Configuring shairport-sync service user ...
Configuring Shairport-Sync systemd service ...
Failed to enable unit: Unit file shairport-sync.service does not exist.
dpkg: error while cleaning up:
 installed shairport-sync package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 shairport-sync

However:

root@raspi:/tmp/DietPi-Software# /var/lib/dpkg/info/shairport-sync.postinst 
Configuring shairport-sync service user ...
Configuring Shairport-Sync systemd service ...
Failed to enable unit: Unit file shairport-sync.service does not exist.
root@raspi:/tmp/DietPi-Software# /var/lib/dpkg/info/shairport-sync.prerm
Deconfiguring Shairport-Sync systemd service ...
Unit shairport-sync.service does not exist, proceeding anyway.
Failed to disable unit: Unit file shairport-sync.service does not exist.
root@raspi:/tmp/DietPi-Software# 

Automatic Bug report reference code:5179c715-faef-448d-89f7-7d9023461c02
The only way, to get rid of the package is to manually run /var/lib/dpkg/info/shairport-sync.prerm && dpkg --purge shairpiort-sync && rm /var/lib/dpkg/info/shairport-sync.p* (prerm and postinst) && dpkg --purge shairport-sync

MichaIng added a commit that referenced this issue Apr 21, 2020
+ DietPi-Software | Shairport-Sync: Remove package before attempting to remove service, otherwise our self-compiled package fails to uninstall: #3461 (comment) Repackaging needs to be done to allow systemctl to fail within the prerm script.
@MichaIng
Copy link
Owner

@C0D3-M4513R
Okay, looks like we need to allow the service disabling to fail, actively, within the prerm script. I didn't know that dpkg error handles those scripts that strict.

For now the following should fix dietpi-software uninstall: 1b3180d
I'll repack our packages by times to satisfy the dpkg error handler if the service has already been removed.

@C0D3-M4513R
Copy link
Contributor Author

The uninstall is now working as expected, after manually editing the change in.

@C0D3-M4513R
Copy link
Contributor Author

and now shairport-sync works as expected again...wtf?

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 21, 2020

Also note, that there is still something wrong, with the alsabat and alsabat-test utility;
Everytime a sound plaved (except when it was trying with -c2 i think?)

root@raspi:~# alsabat-test 
*******************************************
                BAT Test                   
-------------------------------------------
usage:
  /usr/sbin/alsabat-test <sound card>
  /usr/sbin/alsabat-test <device-playback> <device-capture>
current setting:
  /usr/sbin/alsabat-test default default
============================================
0: ALSA generate mono wav file with default params
-------------------------------------------
alsabat -c1 --saveplay default_mono.wav --log=tmp/0.log
alsa-utils version 1.1.8

fail
============================================
1: ALSA generate dual wav file with default params
-------------------------------------------
alsabat -c2 --saveplay default_dual.wav --log=tmp/1.log
alsa-utils version 1.1.8

fail
============================================
2: ALSA single line mode, playback
-------------------------------------------
alsabat -P default --log=tmp/2.log
alsa-utils version 1.1.8

pass
============================================
3: ALSA single line mode, capture
-------------------------------------------
alsabat -C default --standalone --log=tmp/3.log
alsa-utils version 1.1.8

fail
============================================
4: ALSA play mono wav file and detect
-------------------------------------------
alsabat -P default -C default --file default_mono.wav --log=tmp/4.log
alsa-utils version 1.1.8

fail
============================================
5: ALSA play dual wav file and detect
-------------------------------------------
alsabat -P default -C default --file default_dual.wav --log=tmp/5.log
alsa-utils version 1.1.8

fail
============================================
6: ALSA configurable channel number: 1
-------------------------------------------
alsabat -P default -C default -c1 --log=tmp/6.log
alsa-utils version 1.1.8

fail
============================================
7: ALSA configurable channel number: 2
-------------------------------------------
alsabat -P default -C default -c2 -F 17:16547 --log=tmp/7.log
alsa-utils version 1.1.8

fail
============================================
8: ALSA configurable sample rate: 44100
-------------------------------------------
alsabat -P default -C default -r44100 --log=tmp/8.log
alsa-utils version 1.1.8

fail
============================================
9: ALSA configurable sample rate: 48000
-------------------------------------------
alsabat -P default -C default -r48000 --log=tmp/9.log
alsa-utils version 1.1.8

fail
============================================
10: ALSA configurable duration: in samples
-------------------------------------------
alsabat -P default -C default -n10000 --log=tmp/10.log
alsa-utils version 1.1.8

fail
============================================
11: ALSA configurable duration: in seconds
-------------------------------------------
alsabat -P default -C default -n2.5s --log=tmp/11.log
alsa-utils version 1.1.8

fail
============================================
12: ALSA configurable data format: U8
-------------------------------------------
alsabat -P default -C default -f U8 --log=tmp/12.log
alsa-utils version 1.1.8

fail
============================================
13: ALSA configurable data format: S16_LE
-------------------------------------------
alsabat -P default -C default -f S16_LE --log=tmp/13.log
alsa-utils version 1.1.8

fail
============================================
14: ALSA configurable data format: S24_3LE
-------------------------------------------
alsabat -P default -C default -f S24_3LE --log=tmp/14.log
alsa-utils version 1.1.8

fail
============================================
15: ALSA configurable data format: S32_LE
-------------------------------------------
alsabat -P default -C default -f S32_LE --log=tmp/15.log
alsa-utils version 1.1.8

fail
============================================
16: ALSA configurable data format: cd
-------------------------------------------
alsabat -P default -C default -f cd --log=tmp/16.log
alsa-utils version 1.1.8

fail
============================================
17: ALSA configurable data format: dat
-------------------------------------------
alsabat -P default -C default -f dat --log=tmp/17.log
alsa-utils version 1.1.8

fail
============================================
18: ALSA standalone mode: play and capture
-------------------------------------------
alsabat -P default -C default -F 16547 --standalone --log=tmp/18.log
alsa-utils version 1.1.8

fail
============================================
19: ALSA local mode: analyze local file
-------------------------------------------
alsabat -P default -C default --local -F 16547 --file /tmp/bat.wav.IZQPS1 --log=tmp/19.log
alsa-utils version 1.1.8

fail
============================================
20: ALSA round trip latency test
-------------------------------------------
alsabat -P default -C default --roundtriplatency --log=tmp/20.log
alsa-utils version 1.1.8

fail
============================================
21: ALSA noise detect threshold in SNR(dB)
-------------------------------------------
alsabat -P default -C default --snr-db 26 --log=tmp/21.log
alsa-utils version 1.1.8

fail
============================================
22: ALSA noise detect threshold in noise percentage(%)
-------------------------------------------
alsabat -P default -C default --snr-pc 5 --log=tmp/22.log
alsa-utils version 1.1.8

fail
============================================
23: ALSA power management: S3 test
-------------------------------------------
alsabat -P default -C default -n5s --log=tmp/23.log

[1]+  Angehalten              alsabat-test
root@raspi:~# alsabat
alsa-utils version 1.1.8

Entering playback thread (ALSA).
Get period size: 2760  buffer size: 22050
Playing generated audio sine wave
Entering capture thread (ALSA).
Cannot open PCM capture device: Datei oder Verzeichnis nicht gefunden(-2)
Playback completed.
Exit capture thread fail: -2
root@raspi:~#

@C0D3-M4513R
Copy link
Contributor Author

Broke again, after update to v.9.29.1 idk anymore. I'm gonna re image that sd

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 28, 2020

Same issue, even after a reimage and upgrade to 6.29.1. Otherwise same hardware

root@raspi:~# ss -alnp | grep 5000
tcp    LISTEN   0        0                                  0.0.0.0:5000                                             0.0.0.0:*                                   users:(("shairport-sync",pid=14477,fd=4))                                      
tcp    LISTEN   0        0                                        *:5000                                                   *:*                                   users:(("shairport-sync",pid=14477,fd=5))                                      
root@raspi:~# ps -FHjlp 14477
F S UID        PID  PPID  PGID   SID  C PRI  NI ADDR SZ WCHAN    RSS PSR STIME TTY          TIME CMD
4 S shairpo+ 14477     1 14477 14477  9  80   0 - 22902 poll_s  7080   1 12:23 ?        00:00:31 /usr/local/bin/shairport-sync
root@raspi:~# systemctl status shairport-sync
● shairport-sync.service - Shairport Sync - AirPlay Audio Receiver
   Loaded: loaded (/lib/systemd/system/shairport-sync.service; disabled; vendor preset: enabled)
   Active: active (running) since Tue 2020-04-28 12:23:29 BST; 5min ago
 Main PID: 14477 (shairport-sync)
    Tasks: 5 (limit: 2319)
   Memory: 1.4M
   CGroup: /system.slice/shairport-sync.service
           └─14477 /usr/local/bin/shairport-sync

Apr 28 12:23:29 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.
Apr 28 12:23:31 raspi shairport-sync[14477]: Note: this device may be too slow for "soxr" interpolation. Consider choosing the "basic" or "auto" interpolation setting.
root@raspi:~# journalctl -u shairport-sync
-- Logs begin at Thu 2019-09-26 01:32:00 BST, end at Tue 2020-04-28 12:29:10 BST. --
Apr 28 11:56:49 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.
Apr 28 12:00:18 raspi systemd[1]: Stopping Shairport Sync - AirPlay Audio Receiver...
Apr 28 12:00:18 raspi systemd[1]: shairport-sync.service: Succeeded.
Apr 28 12:00:18 raspi systemd[1]: Stopped Shairport Sync - AirPlay Audio Receiver.
Apr 28 12:11:50 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.
Apr 28 12:11:52 raspi shairport-sync[11719]: Note: this device may be too slow for "soxr" interpolation. Consider choosing the "basic" or "auto" interpolation setting.
Apr 28 12:11:53 raspi systemd[1]: Stopping Shairport Sync - AirPlay Audio Receiver...
Apr 28 12:11:53 raspi systemd[1]: shairport-sync.service: Main process exited, code=killed, status=15/TERM
Apr 28 12:11:53 raspi systemd[1]: shairport-sync.service: Succeeded.
Apr 28 12:11:54 raspi systemd[1]: Stopped Shairport Sync - AirPlay Audio Receiver.
Apr 28 12:18:49 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.
Apr 28 12:18:50 raspi shairport-sync[13321]: Note: this device may be too slow for "soxr" interpolation. Consider choosing the "basic" or "auto" interpolation setting.
Apr 28 12:19:40 raspi systemd[1]: Stopping Shairport Sync - AirPlay Audio Receiver...
Apr 28 12:19:40 raspi systemd[1]: shairport-sync.service: Main process exited, code=killed, status=15/TERM
Apr 28 12:19:40 raspi systemd[1]: shairport-sync.service: Succeeded.
Apr 28 12:19:40 raspi systemd[1]: Stopped Shairport Sync - AirPlay Audio Receiver.
Apr 28 12:22:45 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.
Apr 28 12:22:46 raspi shairport-sync[14201]: Note: this device may be too slow for "soxr" interpolation. Consider choosing the "basic" or "auto" interpolation setting.
Apr 28 12:22:48 raspi systemd[1]: Stopping Shairport Sync - AirPlay Audio Receiver...
Apr 28 12:22:48 raspi systemd[1]: shairport-sync.service: Main process exited, code=killed, status=15/TERM
Apr 28 12:22:48 raspi systemd[1]: shairport-sync.service: Succeeded.
Apr 28 12:22:48 raspi systemd[1]: Stopped Shairport Sync - AirPlay Audio Receiver.
Apr 28 12:23:29 raspi systemd[1]: Started Shairport Sync - AirPlay Audio Receiver.
Apr 28 12:23:31 raspi shairport-sync[14477]: Note: this device may be too slow for "soxr" interpolation. Consider choosing the "basic" or "auto" interpolation setting.
root@raspi:~# por
-bash: por: Kommando nicht gefunden.
root@raspi:~# systemctl cat shairport-sync
# /lib/systemd/system/shairport-sync.service
[Unit]
Description=Shairport Sync - AirPlay Audio Receiver
After=sound.target
Requires=avahi-daemon.service
After=avahi-daemon.service
Wants=network-online.target
After=network.target network-online.target

[Service]
ExecStart=/usr/local/bin/shairport-sync
User=shairport-sync
Group=shairport-sync

[Install]
WantedBy=multi-user.target
root@raspi:~# sed -n 5p /DietPi/dietpi/.hw_model
G_HW_CPUID=0
root@raspi:~# cat /DietPi/dietpi/.version
G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=29
G_DIETPI_VERSION_RC=1
G_GITBRANCH='beta'
G_GITOWNER='MichaIng'
root@raspi:~# cat /etc/debian_version
10.3
root@raspi:~# uname -a
Linux raspi 4.19.75-v7+ #1270 SMP Tue Sep 24 18:45:11 BST 2019 armv7l GNU/Linux
root@raspi:~# 

@C0D3-M4513R C0D3-M4513R reopened this Apr 28, 2020
@MichaIng
Copy link
Owner

@C0D3-M4513R
The service restarts are you trying to fix things, right?

I start believing that it has nothing to do with shairport-sync (version/package/service) but with the connection to either audio sources (AirPlay devices/network) or audio output. The thing still is that the DietPi update does not touch the Shaiport-Sync install in any way, as it did not in the first place. Also this matches the fact that multiple packages/versions did not work first and worked later. The service + process is up, bound to correct ports, no error output etc 🤔.

If the update broke it, then I bet a device or only service restart might do the same.

You could try to play a bid with the settings. I am not sure what happens if the CPU really is not fast enough for soxr or at the border. The new config file should contain all available settings with explainations. Chaning interpolation = "soxr"; to interpolation = "auto"; could be tried and raising the log verbosity by uncommenting and raising log_verbosity.

Ah and habe you checked dmesg for any kernel errors that migh be related?

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 28, 2020

The Service restarts were me reinstalling the service, as the installer wouldn’t complete, due to various things having gone non ideal during the initial setup. The audio output was tested using alsabat and output volume verified using alsamixer. Also the speakers are reliable. The iPhone recognizes shairport-sync, but the sound is just missing.

If there isn’t enough cpu to support soxr the audio will just get stuttery, but it won’t stop completely. I had that before, but I will change to automatic interpolation mode to exterminate any possibilities.

I will try dmesg and log verbosity tomorrow.
I hope the log verbosity is gonna bring some light into this mess.

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 29, 2020

Dmesg didn't show anything unusual.
shairport.txt
The Timestamps are wrong tho

@MichaIng
Copy link
Owner

@C0D3-M4513R
Hmm, also the verbose log does not show any error but that the connection is there and "active". Out of interest, was this verbosity level 3?

The Service restarts were me reinstalling the service, as the installer wouldn’t complete

Hmm, is it the dpkg package install itself that fails or dietpi-software at another stage?

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 29, 2020

This is verbosity level 3. The reinstalls were caused by dietpi-software. Stuff like dns recocnition fails, non available internet, missing packages? and failing wget commands(after package install from dpkg). Everything was fixed tho, by simply selecting install in dietpi-software, but not selecting packages to do the starting install. Took me a while to comprehend tho, as to what “Please do the Starting installation” (not exact wording) meant and where to do it.
I think a jumbled mess of non internet connectivity, as well as ctrl-c’s brought me into that mess.

@MichaIng
Copy link
Owner

@C0D3-M4513R
I can imagine that connection to 1.1.1.1 or DNS resolving of one.one.one.one failed?

@C0D3-M4513R
Copy link
Contributor Author

Well no, but the ipv6 ping did

@MichaIng
Copy link
Owner

@C0D3-M4513R
Ah. Then probably IPv6 needs to be disabled. There are network setups where it causes issues. Probably it is even related to shairport-sync, who knows.

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented Apr 29, 2020

Well the v6 ping does work now, as well as ipv6 itself. Tested using curl https://one.one.one.one/ -6

@C0D3-M4513R
Copy link
Contributor Author

What is with the following statement? normal config

Apr 29 09:46:56 raspi shairport-sync[23009]:          0.000058978 "audio_alsa.c:1001" alsa: i
nit() -- alsa_backend_state => abm_disconnected.

interestingly enough, setting output_device manually to something valid is no issue, but then setting mixer_control_name is somehow breaking it, even if you specify mixer_device:

root@rjournalctl -fu shairport-sync
-- Logs begin at Wed 2020-04-29 08:17:03 BST. --
Apr 29 16:41:16 raspi shairport-sync[3785]:          0.000269046 "shairport.c:1783" no special mdns service interface was requested.
Apr 29 16:41:16 raspi shairport-sync[3785]:          0.000580344 "shairport.c:1787" configuration file name "/usr/local/etc/shairport-sync.conf" resolves to "/usr/local/etc/shairport-sync.conf".
Apr 29 16:41:16 raspi shairport-sync[3785]:          0.000309371 "shairport.c:1793" metadata enabled is 1.
Apr 29 16:41:16 raspi shairport-sync[3785]:          0.000275349 "shairport.c:1794" metadata pipename is "/tmp/shairport-sync-metadata".
Apr 29 16:41:16 raspi shairport-sync[3785]:          0.000269566 "shairport.c:1796" metadata socket address is "226.0.0.1" port 5555.
Apr 29 16:41:16 raspi shairport-sync[3785]:          0.000270557 "shairport.c:1797" metadata socket packet size is "65000".
Apr 29 16:41:16 raspi shairport-sync[3785]:          0.000265971 "shairport.c:1798" get-coverart is 0.
Apr 29 16:41:16 raspi shairport-sync[3785]:          0.000264357 "shairport.c:1816" loudness is 0.
Apr 29 16:41:16 raspi shairport-sync[3785]:          0.000261282 "shairport.c:1817" loudness reference level is -20.000000
Apr 29 16:41:16 raspi shairport-sync[3785]:          0.123090487 "mdns_avahi.c:371" avahi_dacp_monitor_start Avahi DACP monitor successfully started
Apr 29 16:41:18 raspi shairport-sync[3785]:          1.410735948 "shairport.c:199" "basic" interpolation has been chosen.
Apr 29 16:41:24 raspi shairport-sync[3785]:          6.242743822 "rtsp.c:1001" Connection 3: SETUP DACP-ID "8009CDB8BA6C294F" from 2003:f3:3f0f:4900:60fd:bd73:ccf2:bd3 to 2003:f3:3f0f:4900:ba27:ebff:febc:9762 with UDP ports Control: 6001, Timing: 6002 and Audio: 6003.
Apr 29 16:41:24 raspi shairport-sync[3785]:          0.011257495 "audio_alsa.c:530" alsa: output format chosen is "S16".
Apr 29 16:41:24 raspi shairport-sync[3785]:          0.000688244 "audio_alsa.c:570" alsa: output speed chosen is 44100.
Apr 29 16:41:33 raspi shairport-sync[3785]:          9.097058163 "player.c:954" Aliasing of buffer index -- reset.
^C
root@raspi:~# nano /usr/local/etc/shairport-sync.conf 
root@raspi:~# systemctl restart shairport-sync
^[[Aroot@raspijournalctl -fu shairport-sync
-- Logs begin at Wed 2020-04-29 08:17:03 BST. --
Apr 29 16:42:56 raspi shairport-sync[3857]:          0.000600611 "shairport.c:1787" configuration file name "/usr/local/etc/shairport-sync.conf" resolves to "/usr/local/etc/shairport-sync.conf".
Apr 29 16:42:56 raspi shairport-sync[3857]:          0.000329378 "shairport.c:1793" metadata enabled is 1.
Apr 29 16:42:56 raspi shairport-sync[3857]:          0.000292021 "shairport.c:1794" metadata pipename is "/tmp/shairport-sync-metadata".
Apr 29 16:42:56 raspi shairport-sync[3857]:          0.000487970 "shairport.c:1796" metadata socket address is "226.0.0.1" port 5555.
Apr 29 16:42:56 raspi shairport-sync[3857]:          0.000299368 "shairport.c:1797" metadata socket packet size is "65000".
Apr 29 16:42:56 raspi shairport-sync[3857]:          0.000279465 "shairport.c:1798" get-coverart is 0.
Apr 29 16:42:56 raspi shairport-sync[3857]:          0.000284155 "shairport.c:1816" loudness is 0.
Apr 29 16:42:56 raspi shairport-sync[3857]:          0.000271754 "shairport.c:1817" loudness reference level is -20.000000
Apr 29 16:42:56 raspi shairport-sync[3857]:          0.149563424 "mdns_avahi.c:371" avahi_dacp_monitor_start Avahi DACP monitor successfully started
Apr 29 16:42:58 raspi shairport-sync[3857]:          1.372718028 "shairport.c:199" "basic" interpolation has been chosen.
Apr 29 16:43:05 raspi shairport-sync[3857]:          6.916993971 "rtsp.c:1001" Connection 3: SETUP DACP-ID "3B40212D36B91D09" from 2003:f3:3f0f:4900:60fd:bd73:ccf2:bd3 to 2003:f3:3f0f:4900:ba27:ebff:febc:9762 with UDP ports Control: 6001, Timing: 6002 and Audio: 6003.
Apr 29 16:43:05 raspi shairport-sync[3857]: ALSA lib conf.c:4898:(parse_args) Unknown parameter 1
Apr 29 16:43:05 raspi shairport-sync[3857]: ALSA lib conf.c:5031:(snd_config_expand) Parse arguments error: No such file or directory
Apr 29 16:43:05 raspi shairport-sync[3857]: ALSA lib control.c:1375:(snd_ctl_open_noupdate) Invalid CTL hw:0,0
Apr 29 16:43:05 raspi shairport-sync[3857]:          0.048227056 "audio_alsa.c:294" Failed to attach mixer
Apr 29 16:43:05 raspi shairport-sync[3857]:          0.006182729 "audio_alsa.c:530" alsa: output format chosen is "S16".
Apr 29 16:43:05 raspi shairport-sync[3857]:          0.000795466 "audio_alsa.c:570" alsa: output speed chosen is 44100.

And the device really does exist:

root@raspi:~# aplay -D hw:0,0 </dev/random 
Wiedergabe: Rohdaten 'stdin' : Unsigned 8 bit, Rate: 8000 Hz, mono
^CAbbruch durch Signal Unterbrechung ... 
root@raspi:~#
root@raspi:~# aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: ALSA [bcm2835 ALSA], Gerät 0: bcm2835 ALSA [bcm2835 ALSA]
  Sub-Geräte: 7/7
  Sub-Gerät #0: subdevice #0
  Sub-Gerät #1: subdevice #1
  Sub-Gerät #2: subdevice #2
  Sub-Gerät #3: subdevice #3
  Sub-Gerät #4: subdevice #4
  Sub-Gerät #5: subdevice #5
  Sub-Gerät #6: subdevice #6
Karte 0: ALSA [bcm2835 ALSA], Gerät 1: bcm2835 IEC958/HDMI [bcm2835 IEC958/HDMI]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 0: ALSA [bcm2835 ALSA], Gerät 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
root@raspi:~# ls
mount  shairport.txt
root@raspi:~# aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
sysdefault:CARD=ALSA
    bcm2835 ALSA, bcm2835 ALSA
    Default Audio Device
dmix:CARD=ALSA,DEV=0
    bcm2835 ALSA, bcm2835 ALSA
    Direct sample mixing device
dmix:CARD=ALSA,DEV=1
    bcm2835 ALSA, bcm2835 IEC958/HDMI
    Direct sample mixing device
dmix:CARD=ALSA,DEV=2
    bcm2835 ALSA, bcm2835 IEC958/HDMI1
    Direct sample mixing device
dsnoop:CARD=ALSA,DEV=0
    bcm2835 ALSA, bcm2835 ALSA
    Direct sample snooping device
dsnoop:CARD=ALSA,DEV=1
    bcm2835 ALSA, bcm2835 IEC958/HDMI
    Direct sample snooping device
dsnoop:CARD=ALSA,DEV=2
    bcm2835 ALSA, bcm2835 IEC958/HDMI1
    Direct sample snooping device
hw:CARD=ALSA,DEV=0
    bcm2835 ALSA, bcm2835 ALSA
    Direct hardware device without any conversions
hw:CARD=ALSA,DEV=1
    bcm2835 ALSA, bcm2835 IEC958/HDMI
    Direct hardware device without any conversions
hw:CARD=ALSA,DEV=2
    bcm2835 ALSA, bcm2835 IEC958/HDMI1
    Direct hardware device without any conversions
plughw:CARD=ALSA,DEV=0
    bcm2835 ALSA, bcm2835 ALSA
    Hardware device with all software conversions
plughw:CARD=ALSA,DEV=1
    bcm2835 ALSA, bcm2835 IEC958/HDMI
    Hardware device with all software conversions
plughw:CARD=ALSA,DEV=2
    bcm2835 ALSA, bcm2835 IEC958/HDMI1
    Hardware device with all software conversions
root@raspi:~#

@MichaIng
Copy link
Owner

MichaIng commented May 1, 2020

@C0D3-M4513R

ALSA lib control.c:1375:(snd_ctl_open_noupdate) Invalid CTL hw:0,0

AFAIK the mixer control name must not include a device number, only a card number. Try hw:0. Could you paste: cat /etc/asound.conf

audio_alsa.c:1001" alsa: init() -- alsa_backend_state => abm_disconnected.

I was just reading through another issue, where this message doesn't seem to be an issue. Since it is about RPi as well (although a DAC sound device), it is anyway worth reading through it: mikebrady/shairport-sync#952
Running alsamixer checking mute state and checking + using mixer name could be tried as well.

@C0D3-M4513R
Copy link
Contributor Author

I always check alsamixer for volume, and mute status. With the change, that you requested, it now works. However, when I uncomment the lines, it works as well? I left the change in place and rebooted. The change persisted. Solved hopefully?

root@raspi:~# journalctl -fu shairport-sync
-- Logs begin at Thu 2020-04-30 22:17:04 BST. --
Mai 01 16:13:27 raspi shairport-sync[353]:          0.000304269 "shairport.c:1797" metadata socket packet size is "65000".
Mai 01 16:13:27 raspi shairport-sync[353]:          0.000291878 "shairport.c:1798" get-coverart is 0.
Mai 01 16:13:27 raspi shairport-sync[353]:          0.000293076 "shairport.c:1816" loudness is 0.
Mai 01 16:13:27 raspi shairport-sync[353]:          0.000291253 "shairport.c:1817" loudness reference level is -20.000000
Mai 01 16:13:27 raspi shairport-sync[353]:          0.122043733 "mdns_avahi.c:371" avahi_dacp_monitor_start Avahi DACP monitor successfully started
Mai 01 16:13:28 raspi shairport-sync[353]:          1.383098180 "shairport.c:199" "basic" interpolation has been chosen.
Mai 01 16:14:14 raspi shairport-sync[353]:         46.144044799 "rtsp.c:1001" Connection 3: SETUP DACP-ID "9C6E15E5721BB9C9" from 2003:f3:3f11:ad00:c93d:1f08:cb8a:914e to 2003:f3:3f11:ad00:ba27:ebff:febc:9762 with UDP ports Control: 6001, Timing: 6002 and Audio: 6003.
Mai 01 16:14:14 raspi shairport-sync[353]:          0.011713752 "audio_alsa.c:900" Lowest dB value is a mute
Mai 01 16:14:14 raspi shairport-sync[353]:          0.000918952 "audio_alsa.c:530" alsa: output format chosen is "S16".
Mai 01 16:14:14 raspi shairport-sync[353]:          0.000096633 "audio_alsa.c:570" alsa: output speed chosen is 44100.
^C
root@raspi:~# cat /etc/asound.conf
pcm.!default {
	type hw
	card 0
	device 0
}

ctl.!default {
	type hw
	card 0
}
root@raspi:~#

@MichaIng
Copy link
Owner

MichaIng commented May 1, 2020

@C0D3-M4513R
Okay that is great. Let's hope that this is sustainable now.

Based on your asound.conf indeed it should work as well when leaving mixer and output device settings commented out, as, if I interpret the default shairport-sync.conf correctly, "default" is the default value for both of them, but not 100% sure.

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented May 1, 2020

Yeah, but why didn‘t it work initially?
I have a feeling, that there is more to this, and that I‘ll be experiencing this again.

@MichaIng
Copy link
Owner

MichaIng commented May 1, 2020

@C0D3-M4513R

Yeah, but why didn‘t it work initially?
I have a feeling, that there is more to this, and that I‘ll be experiencing this again.

Same question and same fear I have. Something about it seems to behave inconsistent. You could try to narrow down a trigger:

sytemctl restart shairport-sync
apt update && apt upgrade
reboot
dietpi-update -1 # Reapplies the last update

@C0D3-M4513R
Copy link
Contributor Author

C0D3-M4513R commented May 1, 2020

reapplying the last update did nothing, as well as the other things. I rebooted after, to make sure, reapplied defaults to the config, but it kept working. when it breaks again, should I open another issue, and link this, or open a new issue?

@MichaIng
Copy link
Owner

MichaIng commented May 1, 2020

@C0D3-M4513R
IMO you could reopen this issue, so we have all the relevant info right in place. Let's hope it will not be required 😉.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Beta 🧪 Issues specific to the Beta branch testing
Projects
None yet
Development

No branches or pull requests

2 participants