BluOS controller app on Linux
Answered
I'd just like to put in a plug for supporting the BluOS controller app on Linux. All of my home computers run Linux Mint 18.1, which is closely related to Ubuntu, and my work-at-home machine is running RedHat Enterprise Linux 7.6. I realize it's a niche market, but it's growing, and I bet it's pretty similar to MacOS under the covers.
-
@Josh Ellithorpe there are two different parts to create the Linux package for a new version:
1. Create the new patch: this is very much a manual process, quite difficult (if possible at all) to automate. I always start by trying to apply the previous patch, analyze why it does not apply, then manually try to adapt using a text editor. Indeed, if Bluos would accept the patch once, this part of the work would not be required anymore.2. Build the package: this is very accurately documented here: https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/blob/main/.gitlab-ci.yml#L16
0 -
@Ben Simon I follow this thread and had a few follow-ups:
There are two active packages that I know of, both of which host their work on open-source repositories:
- Fabrice's (conventional AppImage packaging): https://gitlab.com/fabrice.aeschbacher
- Mine (Nix packaging): https://github.com/shajra/bluos-nix
One thing you'll notice if you look at these projects is the degree to which we're not patching the code much to get things working. We luck out that Electron applications are so portable:
- Fabrice's patches: https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/tree/main/patches?ref_type=heads
- My patches (very similar): https://github.com/shajra/bluos-nix/blob/main/nix/linux.nix
Fabrice's approach involves patch application. Mine is a textual search/replace. The idea is that maybe I luck out a little more, rather than dealing with hunks that have moved. Still, it's not perfect, and I had to make slight changes when releasing 4.10, removing a hack needed for 4.8 (maybe useful for Fabrice when he gets around to this task).
Because I don't have the personal motivation, I haven't reproduced Fabrice's workflow. But that's not to say he's doing anything mysterious, and if you follow the code he's posted, you could very well get it built. Fabrice does the community a service by running scripts he's comfortable with and publishing built artifacts.
Because of the nature of Nix, my work is highly repeatable. However, it comes at the cost of installing Nix as a package manager, which most people probably aren't using for anything else. My repo has lots of embedded documentation to get you started if you're interested in that.
Of course, it would be great if Bluesound did indeed support Linux packaging. It would take some of the work out of figuring out the pinpoint hacks to get it repackaged. But I don't think either Fabrice or I are going through the Javascript code trying to figure out what features are where. We're just repackaging with the least effort we can muster. Most of the time, we do these updates, and the user experience remains indistinguishable, save for the version number bump. I'd rely on official release notes from Bluesound for more information.Hope this post helps.
0 -
There is a MR up now for 4.10.0. I figured I would help Fabrice out and get it building myself. =)
https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/merge_requests/1
If people are impatient there is an AppImage available on my fork, and the AUR is updated for Arch Linux.
https://gitlab.com/zquestz/bluos-controller-linux/-/packages/424155970 -
4.12.0 has been released, and while 4.10.0 was a pretty easy release, this release seems to have introduced some larger structural changes in the build.
I know a lot of people aren't using Nix, which is what I'm packaging for, but https://github.com/shajra/bluos-nix captures my packaging work. What's released on the main branch is for 4.10.0. I'm still sorting out what changes are needed for 4.12.0. I'll post here when I have that finished. Hopefully, that will help as a reference for other people packaging differently.1 -
I think it didn't end up so bad. I have 4.12.0 packaged for Nix:
https://github.com/shajra/bluos-nix
But if you just want to see what I did to get the build working, this commit has the most important patch:
https://github.com/shajra/bluos-nix/commit/d27b5bc294f9df364e355769681b78cdeba3238bThe main app code was moved to another location, a variable reference for the resource path got a little more complex, and the code to quit upon the last window closing was changed.
Hopefully that helps everyone! One day, we'll have official Linux support. Right? right?
0 -
This time I did not find the time, then I forgot... But Josh Ellithorpe kindly did the work, thank you for your MR, which I did only see today - sorry for that. This allows me to announce:
BluOS published a new version v4.10.0 of the controller, for which I just pushed the patch. To reproduce a build locally, follow the steps in the app-image build job [1].
Or you can download the AppImage built by the pipeline [2].
The Release Notes are quite thin [3][1] https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/blob/main/.gitlab-ci.yml#L16
[2] https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/packages
[3] https://support.bluos.net/hc/en-us/articles/18663655952279-Android-BluOS-Controller-App-4-10-0-and-previous-versions2 -
Whoa... I think if you mention Linux distributions by name or something, posts get flagged for approval. I don't know what's going on there. I removed this one paragraph from my post above, and it seems to have been posted. Anyway, I have 4.12.0 out.
0 -
I have opened a merge request for the 4.12.0 changes!
https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/merge_requests/2
You can also download it from my fork at https://gitlab.com/zquestz/bluos-controller-linux/-/packages0 -
Will there still be an appimage for 4.12.0?
0 -
It seems that my post about that was not published, not sure why. Let's have another try:
BluOS published a new version v4.12.0 of the controller. Thank to Josh Ellithorpe for providing the patch I merged. To reproduce a build locally, follow the steps in the app-image build job [1].
Or you can download the AppImage built by the pipeline [2].
The Release Notes are at [3][1] https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/blob/main/.gitlab-ci.yml#L14
[2] https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/packages
[3] https://support.bluos.net/hc/en-us/articles/35439594062743-Desktop-Windows-macOS-BluOS-Controller-App-4-12-00 -
Thank you guys for your excellent work. I was afraid it had become impossible to get a recent appimage for Linux, due to some developments on the Windows side. This after a scéance with GPT-5 asking why the windows .exe no longer works with WINE. So for us poor Linux users an appimage seems to be the only way now. I hope future versions of WINE can solve the problem.
Also, it seems the Bluesound forum moderator is a bit touchy lately when links and some terms appear in a comment, resulting in delays or loss of comments.
0 -
Thanks guys!
0 -
Looks like there was a minor release of v4.12.1, which I've packaged for Nix. I haven't really looked too hard for release notes to see if there are any observable differences.
https://github.com/shajra/bluos-nix
I know I'm probably the only one here using Nix packaging, but I'm posting to let people know about any build complexities I've noted (in this case, the lack of them). From my end, the same build for v4.12.0 continued to work for v4.12.1, however, I have a search/replace approach to my build, so I don't have to mess with hunks shifting to different line numbers or contexts.
0 -
Work for supporting v4.12.1 for Linux has been completed.
MR is at https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/merge_requests/3
Or you can download my appimage at:
https://gitlab.com/zquestz/bluos-controller-linux/-/package_files/245818399/download0 -
Hi!
I am new here.
Maybe someone can help me?
How can i check that this appimage of the bluos controller ist secure and not infected or malware?
https://gitlab.com/zquestz/bluos-controller-linux/-/package_files/245818399/download
Any help would be nice!
0 -
I am not a developer so am somewhat at sea here. I am trying to use the latest patched versions of the bluos controller (have tried v.4.12 and v.4.12.1) but without success. I am on a SER5 with Pop!_OS 24.4.
I can open and run the software but when I try to add a streaming service (Qobuz) it asks for a login. It then throws an error, saying "invalid character '<' looking for beginning of value".
I have tried rebooting everything, changing the password to something simpler, temporarily disabling security on my ATT router, all without success.
Does anyone have any more suggestions I could try?
One piece of good news - in conversation with the qobuz bot, it said that they are actively working on a Linux version of the controller to add to the downloader. Hopefully soon!
0 -
Sorry for the delay but v4.14.0 is now available for Linux. =)
https://gitlab.com/zquestz/bluos-controller-linux
https://gitlab.com/zquestz/bluos-controller-linux/-/packages/56384009
It is also now available on the AUR for Arch Linux users.
https://aur.archlinux.org/packages/bluos-controller-appimage0 -
Hi Josh,
Thank you for this release!
I'm on Arch Linux and I have issues with your 4.14.0 release (with both AUR and using the appimage directly): the UI does not show up. I noticed this error in the terminal:[113734:0319/110911.511328:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:1640] vaInitialize failed: unknown libva error
With 4.12.1, it is all fine. no error.
I checked libva and it is installed. Any change between 4.12 and 4.14 related to libva?0 -
What GPU are you using? I didn't change anything in regards to libva.
I do have the following ENV on my box.LIBVA_DRIVER_NAME=iHD
Perhaps that needs to be set on your system? The value might be different for you, depending on your GPU.0 -
Hi Josh,
Thanks for your input. It turns out I had not installed the intel drivers for vaapi (libva).
Now my laptop is fully setup and `vainfo` is happy.
`bluos-controller-linux-4.14.0.appimage` no longer complains about `libva`... but still NO window appears.
I have my amplifier turned, on and 4.12 works fine (starts up and connects to the amp and controls it normally) while 4.14 does not (no main window).
From the logs in the terminal, I can't see any difference (no more reported errors).
Thanks for your help!0 -
BTW: I have a firmware upgrade ongoing on my amplifier right now, I'll let you know if that changes anything.
0 -
Amp's firmware is now updated to the latest version (no other update available).
Still 4.14 main window does not show up.
I don't think it is related to the Amp being available in the network or its firmware. With 4.12, the main window pops up even if the amp is not on.I'll do some `strace` on both versions to compare the behaviours...
0 -
I did bump the version of electron that is used for this latest release.
Are you using X11 or Wayland?
I have tested it on my Arch system, and it works great.
Also tested:
- Linux Mint
- Xubuntu (required --no-sandbox)
- Fedora
- Ubuntu MATE (required --no-sandbox)
Note, I do not run any Wayland systems, the above are all X11.0 -
Same problem. I am running Arch Linux under Wayland. Since I updated my system and the controller app from AUR, the gui is not showing up. No error.
0 -
Seems that Electron 41 now defaults to native Wayland when it detects a Wayland desktop. This apparently does not work with BluOS Controller. Here is some info about it.
https://www.electronjs.org/blog/tech-talk-wayland
Can you try launching it in X11 mode, just to see if it works? The old version was running in XWayland, so I think this should fix your issue.bluos-controller --ozone-platform=x110 -
Hi Josh!
That's was it: I got the 4.14.0 GUI pop up with wayland using --ozone-platform=x11.
Thanks for your help!0 -
Hi again!
I just installed 'bluos-controller-appimage-4.14.0-2' from AUR and I noticed you added '--ozone-platform=x11' as a default command line argument in the .desktop file: works great, thanks again!0 -
Thanks Josh! I just updated to the 4.14.0-2 version and the -ozone-platform=x11 also fixes also the problem.
0 -
You can add a electron-flags.conf file in ~/.config/BluOS Controller with the line --ozone-platform=x11 .
0 -
that seems a more elegant solution, but FWIW, I fixed this issue for Fedora 43 by adding
# X11 through XWayland for AppImage
export DISPLAY="${DISPLAY:-:0}"
export XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:-/run/user/$(id -u)}"to my ~/.bashrc file and then reloading the file
0
Please sign in to leave a comment.
Comments
212 comments