Skip to main content
Contributor I
March 20, 2012

Sonos Update to 3.7 and Linux

  • March 20, 2012
  • 71 replies
  • 56985 views
Sloved / Solution in page 3.

Hello,

Who has a success with updating the Sonos 3.7 on Ubuntu + Wine desktop ?

From my side, I get :
- in the wine windows
"The wizard was interrupted before Sonos ..."

and

- on shell
"fixme:ole:DllRegisterServer stub

fixme:storage:create_storagefile Storage share mode not implemented.

fixme:storage:create_storagefile Storage share mode not implemented.

wine: Install Mono 2.8 or greater for Windows to run .NET 4.0 applications.

err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1627

err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1627
"

Could you please help me ?

Rochefoucault
    This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

    71 replies

    Enthusiast II
    March 21, 2012
    I can easily believe that there are many people who prefer to run Linux. I'm just skeptical that many of them are planning on running commercial software with a GUI.

    Maybe someone can write a Sonos control app that runs in Emacs.
    Retired Sonos Staff
    March 21, 2012
    As a note on the VM topic - so long as you're not using a NAT configuration and instead use a bridged ethernet emulation, connections will work fine. During testing of the 3.7 controller, I utilized both pieces of software - one in a VM and one in my native OS (10.7.2 for those interested) and seamlessly jumped between them.
    Lyricist II
    March 21, 2012
    Well, indeed you are right, v3.7 does work fine in my VM of Win7 under Ubuntu 11.10.
    But i prefered when i had my Sonos app on my desktop, easily clickable. It was just simple. Now i have to boot Win7, which uses 1/3 of my RAM, just for that Sonos controller.
    It is not a question of paying for Microsoft, but in my case heavy vs light 😞
    ianmacd
    Contributor III
    March 21, 2012
    You own ten Sonos zone players and you think Windows is expensive? I'm not buying it.


    I'm not buying it, either. Cue claxons and canned laughter.

    Yes, I think it's expensive, because I don't need it for anything else. I'd also have to fork out for a copy of VMware (unless an equivalent free VM has come along in the meantime; I haven't run a VM in a few years now, so I haven't looked into this).

    I therefore tend to look at it as the total cost of running a desktop controller. In other words, do I want to spend more on a software controller than I would on a hardware one, whilst simultaneously bogging down my PC with an extra operating-system that I use for just a single application?

    No, I don't, and if I can avoid putting any money in Microsoft's pocket, that's a bonus.


    Sure a VM is not supported, but they tend to always work. More than Wine does. Agreed?


    Truer in the past than now. WINE works with a bewildering number of things and doesn't have the resource overhead of a whole operating-system loaded under a VM. Unfortunately, the 3.7 desktop controller isn't one of the things that works.

    Now that the new desktop controller has been released, however, a bug can be filed about it on WINE's site. That wasn't possible while it was still in beta.

    Then again, there's nothing compelling to me in the new desktop controller, anyway. The packaging may have been redesigned, but it's still the same functionality inside. I still can't search a WM-served library and all of my music is WM-served. It does me no good at all that a search function I can't use was improved.


    Sure an old version worked. So what?


    Er, working controllers are better than non-working controllers. Was it a trick question?


    Do you have a reason to think UPNP wouldn't work?


    Propagation across subnets was my initial fear, if the guest OS were on a different subnet than the host.


    I run WinXP in VMWare on my work computer. I'll try bringing it home and see if Sonos Controller runs on it, if you are interested.


    I'm sure it would work if both host and guest were on the same subnet, but please don't go to any trouble on my account.

    There's no way I would ever run a separate OS on my desktop just to be able to use the new controller. The 3.6 controller works just as well for my purposes as the 3.7 one would if it didn't crash, which is to say 'adequately'.
    Lyricist II
    March 21, 2012
    Hi Ian,

    Any chance of you telling us how to downgrade to 3.6...?

    many thanks
    ianmacd
    Contributor III
    March 21, 2012
    Any chance of you telling us how to downgrade to 3.6...?


    My pleasure, but just to be clear, your firmware will stay at whichever version it's at now. Only the desktop controller will go back to 3.6.

    The following assumes you're a Linux user, but the same trick would work on Windows for any user with an incentive to go back.

    First of all, remove the 3.7 DCR from your system. Go through the proper uninstall procedure under WINE.

    Next, reinstall 3.6. If you don't have the installation .exe still lying around, you can currently still obtain it from Sonos, but I strongly advise you to save a copy of this somewhere safe, as Sonos will probably remove it from their server at some point as obsolete.

    Install the controller under WINE and associate it with your Sonos system. Then, exit the program.

    Step 3 is to go to the following address in a Web browser:

    code:
    http://x.x.x.x:1400/status/VERSION


    Replace x.x.x.x with the IP address of one of your zone players.

    You'll see something like this:

    code:
    contents of /VERSION
    xx.x-xxxxx


    Whichever version number you see is unimportant. Just note it down. It's actually just the build number available under About My Sonos System on the controllers, but it appears here in punctuated form and we'll need that string for the next step.


    Edit: If your version happens to have a letter following the final five digits, drop the letter. Thanks to MDBill.


    Finally, pull up pcdcr.dll in a binary editor. Unless you're running an odd WINE configuration, it will have landed here on a 32 bit machine:

    code:
    ~/.wine/drive_c/Program Files (x86)/Sonos/pcdcr.dll

    or here on a 64 bit one:

    code:
    ~/.wine/drive_c/Program Files (x86)/Sonos/pcdcr.dll

    I use vim with the -b flag as my binary editor. Whichever tool you use doesn't matter, so long as it treats the file as a binary. All hell will break loose when you save this file if your editor treats the contents as text, so do make sure you are operating in binary mode.

    Locate the string 16.7-48310 in this file and replace it with the version number returned in step 3 above. The two strings should be identical in length. Then, save the file. Did I mention that you must ensure you do this in binary mode? Good.

    That's it!

    Fire up the old desktop controller and it will now be fooled into thinking that it's up to date with the rest of the system. You won't be prompted to upgrade it, so neither will it baulk and refuse service.

    It's a hack, but it works.

    You will need to repeat the binary edit part of this procedure every time Sonos update the firmware to a new major revision number. At that point, the desktop controller will see that it lags behind the minimum required version number and prompt you to upgrade it. What we are doing here is defeating that check by convincing the desktop controller that it has the same version number as the firmware running on the rest of the system.

    Hopefully, the day will soon come that the 3.7 DCR runs on Linux. Until then, there's this.

    Thanks to Henkelis for the idea.
    Lyricist II
    March 22, 2012
    Yay, that worked great for me. Thanks 😉
    Trending Lyricist I
    March 22, 2012
    This does indeed work for running the 3.6 desktop controller with a sonos system upgraded to firmware 3.7 (just tested on a Ubuntu 10.4 64bit), but I suspect the controller will start misbehaving when the control protocol changes.

    There will have to be a Wine based solution in the long run (or a native controller). I don't appreciate the idea of running a complete extra operating system on each computer just for controlling music.
    ianmacd
    Contributor III
    March 22, 2012
    I suspect the controller will start misbehaving when the control protocol changes.


    It doesn't change, at least not in any meaningful way. This solution should continue to work into the future.


    There will have to be a Wine based solution in the long run


    Of course, being able to run either the old style or the new style DCR would be better than only being able to run one of them.
    Lyricist II
    March 22, 2012
    Thank you Ian. That worked a treat!

    Cheers