Skip to content

Expose possible mixer opening errors #1488

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

Open
wants to merge 3 commits into
base: dev
Choose a base branch
from

Conversation

photovoltex
Copy link
Member

This should address the possible panic found in #1478 by exposing the errors that might occur while opening a device.

The binary will now exit when it encounters an issue while opening the mixer.

Fixes #1478

Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

@photovoltex photovoltex force-pushed the handle-mixer-open-errors branch from ec4e265 to 4b45023 Compare April 13, 2025 22:20
@photovoltex
Copy link
Member Author

@ers4691, @kingosticks Could you take a look at the changes and maybe give me some feedback if that is what you had in mind? I just want to be sure I didn't misunderstood the expected behavior you discussed in #1478.

Tl;dr; The binary exits with 1 when encountering issues when starting the mixer. For example when a requested alsa device isn't available.

Copy link
Member

@roderickvd roderickvd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great to get rid of those panics.

@ers4691
Copy link

ers4691 commented Apr 28, 2025

I'm not quite there yet.
First of all, it's great that there is no longer a Panic error.

But think about the use case:
librespot should be running on your home server.
You now want to listen to Spotify on your old stereo system. Switch on your old amplifier, switch on the DAC that is connected to the home server and select the home server as the loudspeaker with your Spotify client (mobile). And now the music should start playing.
In other words, the query if an Alsa mixer is present is too early at the time of starting librespot.

I don't know whether it's worth the effort. Thanks for fixing the panic error.

@photovoltex
Copy link
Member Author

I see. Thanks for that input, I think I understand now what you try to do. It's probably possible (at least when you use zeroconf), but would overload this PR for sure.

Maybe you also search for a solution where librespot is auto started when the DAC is added to the system? Because when you remove/shutdown the DAC, I would suspect that librespot crashes/panics anyways? So you would need to restart it anyways later. Or how is you workflow there? I would like to understand if there is really a use case here, or if this is rather a job for a separate application like spotifyd (don't know if the support something like that, but that application is specifically designed to run as service).

@photovoltex
Copy link
Member Author

Tho if you use an already authenticated librespot device, we would need to change something in the connect implementation.

Otherwise this whole idea of a late player initialization wouldn't be currently possible as the code in the connect implementation is in our control and can't be modified. If that is what you desire you could open a feature request and we might consider/implement it in the future. In terms of work to do, I currently don't see a lot of roadblocks, but that is something you really see when implementing it :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

librespot crashes if alsa device is temporary not available
3 participants