Only default device appears in output device list if squeezelite is set to auto run but fails to run

Issue was discussed in this thread.
https://forums.lyrion.org/forum/user-forums/logitech-media-server/1785058-local-player-and-rpi-os-bookworm-desktop

From my posty on the thread. My understanding of the problem and a suggested fix.

The list of available output devices is generated by the devices routine in Settings.pm.
This routine can have one optional parameter - the path of the squeezelite binary to run.
If the squeezelite binary path is not supplied (as when called by handler2 in Settings.pm) and "autorun" pref is set, then the devices routine will use the path of the squeezelite that is running.
However if squeezelite has failed to run (e.g. output device inacessible/invalid), then devices routine has no path to binary and so returns a list just with "default" entry.

My suggested fix is to add the path to the devices call in Settings.pm handler2.

Line 89 LocalPlayer/Settings.pm
from
my $devices = Plugins::LocalPlayer::Squeezelite->devices;
to
my $devices = Plugins::LocalPlayer::Squeezelite->devices(Slim::Utils::Misc::findbin($bin));

Within the plugin, the determination of which version of squeezelite to run is a bit convoluted (e.g. OS / arch / Docker / pcp) , so I'm not 100% confident this will work for all instances.
However since Slim::Utils::Misc::findbin($bin) is used just a few lines above my changes to determine squeezelite command line options - I think it should be ok.

If it looks to be a fix there are efficiencies and tests that can be added to make it more robust.

I think that's looking ok. How would I test this situation?

gh-8 Define binary to use as we could end up with no known binary so far

The problem can happen if device in inaccessible or if in the additional options, there is some option which cause squeezelite to fail. My test added "- o garbage" to additional options

I think the backtick calling squeelite in devices routine (Squeezelite.pm) needs a check afterwards for a succcess and perhaps log the failure. If it fails the rest of devices routine does nothing.

	# run "squeezelite -l" to get devices and parse result
	my @devices = `$myBinary -l`;

I'll work up a check and do some more test and I can check that mod instatlls & works for various OS - WIndows, PCP, Ubuntu, Raspberry IOS

After putting in "eval" with backticks etc., I got a lot of errors for failed binaries not relevant (e.g. i386 on an X86 system). Looking at "sub binaries", the last update doesn't work.

Regardless of osArch or BinArch - only the binaries from the last "if " will be effective - elsif's are needed.

  	if ($os->{'osArch'} =~ /x86_64/) {
			@binaries = qw(squeezelite-x86-64);
		}
		if ($os->{'binArch'} =~ /i386/) {
			@binaries = qw(squeezelite-i386);
		}
		if ($os->{'binArch'} =~ /arm/) {
			@binaries = qw(squeezelite-armhf squeezelite-aarch64);
		}
		else {
			# fallback to offering all linux options for case when architecture detection does not work
			@binaries = qw(squeezelite-x86-64 squeezelite-i386 squeezelite-armhf squeezelite-aarch64);
		}

I'll update it to be effective as at present except for armv6 or armv7 system - binaries will have "squeezelite-x86-64 squeezelite-i386 squeezelite-armhf squeezelite-aarch64"

While I'm doing a plugin update - I'll update all the squeezelite versions in Bin. Is there any special procedure for this ?

@ralph-irving

Nice finding! Yes, those conditions are not very useful...

Special procedure what for? Updating the binaries? I think I mostly relied on @ralph-irving's work and copied whatever he had built. I've only done this once or twice, so there's not much in terms of experience and routine 😁.

Navigation Menu

Repository navigation

Only default device appears in output device list if squeezelite is set to auto run but fails to run #8

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Only default device appears in output device list if squeezelite is set to auto run but fails to run #8

Description

Activity

michaelherger commented on Sep 8, 2025

bpa-code commented on Sep 9, 2025

bpa-code commented on Sep 17, 2025

michaelherger commented on Sep 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions