-
-
Notifications
You must be signed in to change notification settings - Fork 502
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
Comments
@C0D3-M4513R
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:
To re-apply and check the issue with our new package, could you do:
Then please try to play media, when failing please paste:
|
I did the
I don't think, that this is what you want, however shairport-sync -vvv doesn't output anything...
|
@C0D3-M4513R Could you check service status and if if is bound to the port?
|
Btw: the note is just there, because i booted with maxcpus=1, because my pi isn't doing anything. Tested with all cores though. |
By the way:
accepted airplay content |
@C0D3-M4513R
Did you try to uninstall via dietpi-software and use the Debian package, does this play well? Just to be sure, could you try the ARMv6 package:
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:
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 ( |
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.
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.
Oh, and the /run/shairport-sync directory is not required, just like you said, work with and without for the ARMv6 package. |
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? |
@C0D3-M4513R
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. |
So, it turns out, that the Debian package works as well. Oops! On my first test it didn't...
doesn't purge the configfiles? |
And now, after that, the ARMv7 Package, packaged with |
@C0D3-M4513R |
Same issue, reinstalled shairport-sync package with version armv6l, armv7l, dietpi-software and debian repo version could not be downloaded. |
@C0D3-M4513R
and reinstall again. |
This happens now every time, I uninstall...
However:
Automatic Bug report reference code: |
+ 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.
@C0D3-M4513R For now the following should fix dietpi-software uninstall: 1b3180d |
The uninstall is now working as expected, after manually editing the change in. |
and now shairport-sync works as expected again...wtf? |
Also note, that there is still something wrong, with the alsabat and alsabat-test utility;
|
Broke again, after update to v.9.29.1 idk anymore. I'm gonna re image that sd |
Same issue, even after a reimage and upgrade to 6.29.1. Otherwise same hardware
|
@C0D3-M4513R 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 Ah and habe you checked |
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 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 didn't show anything unusual. |
@C0D3-M4513R
Hmm, is it the dpkg package install itself that fails or dietpi-software at another stage? |
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. |
@C0D3-M4513R |
Well no, but the ipv6 ping did |
@C0D3-M4513R |
Well the v6 ping does work now, as well as ipv6 itself. Tested using |
What is with the following statement? normal config
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:
And the device really does exist:
|
AFAIK the mixer control name must not include a device number, only a card number. Try
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 |
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?
|
@C0D3-M4513R 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. |
Yeah, but why didn‘t it work initially? |
Same question and same fear I have. Something about it seems to behave inconsistent. You could try to narrow down a trigger:
|
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? |
@C0D3-M4513R |
Creating a bug report/issue
Required Information
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'
echo $G_DISTRO_NAME
orcat /etc/debian_version
echo $G_DISTRO_NAME
uname -a
Linux raspi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
echo $G_HW_MODEL_DESCRIPTION
or (EG: RPi3)RPi3b+
5V2A Anker
noname
Additional Information (if applicable)
shairport-sync
both tested
don't know for sure, however it should be the case
5179c715-faef-448d-89f7-7d9023461c02
sed -n 5p /DietPi/dietpi/.hw_model
Steps to reproduce
Expected behaviour
Actual behaviour
Extra details
alsabat
andalsabat-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)The text was updated successfully, but these errors were encountered: