BluOS controller app on Linux

Answered

Comments

160 comments

  • Ben Simons

    Does Bluesound read this forum?

    Could someone from Bluesound explain why this work-around for linux has been going on for 3 years?

    Why still no linux client on https://bluos.net/downloads/  

    I'd like to know. It would help me understand the culture at Bluesound.

    (edit: thank-you Fabrice A)

    b.

    2
  • nibheis

    I totally second that.

    Let me stress again here that I bought my Bluesound card for my NAD amplifier because I read this thread beforehand, confirming support for Linux. I would never have thought that this would go on for so long with Bluesound totally ignoring the great work done here. Many thanks to all those involved.

    Please Bluesound, let us understand what support you plan for your customers.

    1
  • Fabrice A

    I can see the following things Bluesound could do with very limited effort:

    1. Bluesound could just merge the patch [1] which activates the Linux support, and continue to provide only images for MacOS and Windows (and no Linux image). The patch is trivial and there is no risk it can affect the Windows or MacOS code. Building the Linux image would be left to the community like today, but without the burden of manually re-creating a new patch for each new version (this is the most tedious part of the work).

    2. Bluesound could also merge the patch and build the Linux image, providing it as "experimental" and "untested". The community would do the testing anyway, like today.

    Any of these two solutions would require no (or limited) resources from Bluesound, and would be very appreciated by the community.

    [1] https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/tree/main/patches

     

    1
  • Jonathan Anderson

    Thank you Fabrice.

    My understanding is that Bluesound is a small organisation that needs to keep the staff number and load down. Generally these community forums purpose is for users to find help from other users and probably not monitored by Bluesound. The way to get their attention for this, which I believe should be interesting to them, as it offers them to claim Linux compatibility with a very small extra effort, is to email or call them.

    • Call us Monday to Friday 8:00 am - 7:00 pm ET: 1-855-531-4666 (Toll Free in Canada and The United States)

    Which is just what I plan to do in the coming week.

    You all are welcome to do the same to raise the interest :-)

    0
  • Jonathan Anderson

    Or maybe email would be more efficient as it can be forwarded to the right person with all information.

    0
  • krang

    following your pipeline steps, I was able to rebuild within arm64.

    This is great and highly appreciated. 

    0
  • Fabrice A

    @krang Thanks for your feedback

    0
  • edward

    Since Bluesound uses Arch linux why not just create something open source to allow people to submit features and addons like people do for linux distros.

    Better yet why not just make a Arch-based Linux distro called BlueOS-Linux they can make their own repo for folks to submit too and they can have control over what makes it to final build. So many extremely talented devs out their creating all sorts of stuff...pity to let all this good talent and free help go to waste.

     

     

    0
  • Fabrice A

    I pushed a new version for v3.20.3. I did not find the release notes for the changes since last version.

    To reproduce a build locally, follow the app-image build job in [1].
    Or you can download the AppImage built by the pipeline [2].

    [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

    1
  • Sukant Hajra

    I am likely the only person in the entire world using BluOS on the Nix package manager... but if anyone wants to join me, I packaged up v3.20.5 for Nix [1].   The repo has guides on Nix if you're interested.

    [1] https://github.com/shajra/bluos-nix

    1
  • Oscar

    @Fabrice A Any chance to a brief explanation on how to install your solution? Like; what to do with this for 'ubuntu dummies' :-)

    Thanks a lot in advance ;-)

    0
  • Fabrice A

    Hi @Oscar, you just need to download one of the AppImage file from https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/packages

    , store it somewhere on your filesystem, then make it executable ('chmod +x'), and start it.

    For example for v 3.20.5 , in the folder where you downloaded it:

      chmod +x bluos-controller-linux-3.20.5.AppImage
      ./bluos-controller-linux-3.20.5.AppImage

    0
  • Oscar

    How simple things can be :-)

    Excellent! Thanks @Fabrice H

    0
  • Reagan

    @Fabrice A - Would really appreciate it if you could push the AppImage for v3.20.6 to gitlab. I unfortunately lack the knowledge and skills to build it myself. Thanks again for all your efforts in this space. Cheers!

    1
  • Sukant Hajra

    @Reagan's post was a reminder that I have kept my Nix-based build of this application up-to-date with v3.20.6.

        https://github.com/shajra/bluos-nix

    Possible that no one other than me is using this.  But it's there if you're into deterministic builds, and are open to installing the Nix package manager.

    I also wrapped the binary with script to call `daemon` to make it a little more disciplined to start/stop as a service.

    1
  • Fabrice A

    @Reagan I prepared the patch for v3.20.6 , but unfortunately the built AppImage does not work correctly.

    You can try the output of the pipeline from the dev branch:
    https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/jobs/5167116943/artifacts/browse

    I have the same result when building locally. Basically the patch looks exactly like @Sukant Hajra's , maybe the build environment differs 

    0
  • Sukant Hajra

    @Fabrice A, @Reagan, It's definitely true that my environment is different in some subtle ways.  Before diving too far into that, I want to point out that I do more than the patch with build scripts.

    I found the text substitutions more robust than maintaining a patch because lines can easily shift up/down.

    Hope that helps.  If not, I would be happy to give you more information on the exact artifacts in my build environment.

    0
  • edward

    FYI...A new controller is planned to be released Oct 15-ish so it might not be worth the effort seeing that a new OS/Controller will make this obsolete after only 3 weeks.

     

    0
  • Fabrice A

    @Sukant Hajra thanks Thanks for jumping in. Actually the patch I'm using resumes to your patch + your text substitutions. I suspect that the error I get is not related to my patch though:

    Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
        at WebFrameMain.send (node:electron/js2c/browser_init:2:94495)
        at WebContents.send (node:electron/js2c/browser_init:2:79721)
        at /tmp/.mount_bluos-s6axzl/app/resources/app.asar/common/bonjourDiscovery.js:29:43
        at Array.forEach (<anonymous>)
        at Browser.<anonymous> (/tmp/.mount_bluos-s6axzl/app/resources/app.asar/common/bonjourDiscovery.js:28:10)
        at Browser.emit (node:events:513:28)
        at Browser._addService (/tmp/.mount_bluos-s6axzl/app/resources/app.asar/node_modules/bonjour/lib/browser.js:109:8)
        at /tmp/.mount_bluos-s6axzl/app/resources/app.asar/node_modules/bonjour/lib/browser.js:86:14
        at Array.forEach (<anonymous>)
        at /tmp/.mount_bluos-s6axzl/app/resources/app.asar/node_modules/bonjour/lib/browser.js:84:15

    I'm basically building in a 'node:lts' container pulled from docker-hub, apply the patch, and build with: 

    yarn  # fetch dependencies
    yarn run electron-builder -l AppImage
     
    0
  • Sukant Hajra

    @Fabrice, darn.  I was hoping it was simple.  I'm relying on all the dependencies coming down from the latest package set for Nix/NixOS.  I know very little about Electron/JS development.  I understand the rationale for waiting for the next release.  But there's also Murphy's Law, which suggests this problem won't just magically disappear until properly addressed.  That's been my experience with software, at least.

    Have you tried playing around with older `node` container versions?  Another problem could be that the version bounds in some `package.json` somewhere are too wide and need to be narrowed.  I wouldn't have this problem on the Nix side, because there's no dependency resolution done with Yarn.  You just get the exact versions specified by the snapshot of Nixpkgs I pin to.

    Anyway, I'm here to answer questions if you have them about my build.

    0
  • Fabrice A

    @Sukant Hajra I agree with you that chances are low to see the problem magically disappear with next version. I could fix it by selecting a newer version of electron-builder. Thanks for helping!

    0
  • Fabrice A

    I pushed a new version for v3.20.6. To reproduce a build locally, follow the app-image build job in [1].
    Or you can download the AppImage built by the pipeline [2].

    [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

    4
  • Reagan

    @Fabrice A, @Sukant Hajra - Sincerest thanks to the both of you for making this happen. Really appreciate your kind assistance with this.

    0
  • Sukant Hajra

    @Fabrice, nice!  It's good that even if no one else uses Nix but me, having alternate builds gives us different reference points when troubleshooting.

    0
  • krang

    You're not alone ;)

    Thanks Fabrice, still appreciate your input.

    I fear Bluesound's take on a Linux client - like with many other things - will not change in BluOS 4.0 ...

    0
  • Joep Janssen

    Installed Linux App 3.20.6 and it works without any problem.

    Many thanks Fabrice, appreciate your work to make this happen!

     

    0
  • Fabrice A

    Hi, I just pushed a new version for v4.0.1. 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].

    [1] https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/blob/main/.gitlab-ci.yml#L15
    [2] https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/packages

    1
  • Sukant Hajra

    @Fabrice A, thanks for doing this work.  It was all I needed to get my Nix build updated to v4.0.1:

        https://github.com/shajra/bluos-nix

    I noticed that you used Electron 24.  In Nixpkgs, there are Electron versions going up to 27.  Did you have a specific reason to keep to 24?  I just followed your lead for now in my build.  I haven't really poked around the unpacked distribution from Bluesound.  The controller seems to work on 24, so maybe the upgrade to 27 would have no observable effect.  Curious what your thoughts are here.

    Otherwise, Nix is giving me a very deterministic build with everything pinned down... with one hole... Bluesound could delete their download file at any moment.  I assume we'd need permission before setting up a mirror.  I'm just grateful these Linux builds aren't discouraged.

    0
  • Reagan

    @Fabrice A - Just installed your new build and it works like a charm. As always, thanks a bunch for putting this together. Cheers!

    0
  • Fabrice A

    @Sukant Hajra I used electron-builder's v19 for a while. Then for bluos v3.20.6, it stopped working, so I had to update.

    At that time, the newest version was v24.6.4, and it seems to be still the current package's version on npmjs.com. There are indeed newer tags on https://github.com/electron-userland/electron-builder/tags but I did not try them.

    0

Please sign in to leave a comment.