Hello,



Unfortunately, WINE will no longer be able to be used due to the requirements of the Sonos Controller for PC (.NET 4.0 and Windows Presentation Foundation).



-Clay

---

I was able to install the sonos controller 3.7 using wine 1.4 and the latest winetricks script for dotnet40. It fails to render the splash screen and crashes right after showing the main window (before drawing anything into it).



It doesn't seem impossible in the long run, but I am for now forced to use the Android controller.

---

Hello,



Unfortunately, WINE will no longer be able to be used due to the requirements of the Sonos Controller for PC (.NET 4.0 and Windows Presentation Foundation).



-Clay



How should I now control my sonos system?

Is there a way to downgrade to 3.6 again?

---

really disappointed today, that is not fair.

Now i can't use my desktop computer anymore to control my music 😞

---

really disappointed today, that is not fair.



Not fair? I know of very few commercial products that promise to support Wine, and certainly Sonos doesn't. Maybe "unfortunate" would be more accurate than "not fair".



Isn't Wine only for people who hate the man so much that they choose to have software not work, rather than give evil APPL or MSOFT any $$$?



Also, for Linux support wouldn't one normally expect the FOSS community to provide an open source alternative controller that was Linux native? I think all the protocols are freely available.

---

Not fair? I know of very few commercial products that promise to support Wine, and certainly Sonos doesn't. Maybe "unfortunate" would be more accurate than "not fair".





It worked before. It doesn't now. That's what seems unfair to him.



I agree, though, that it's more unfortunate than unfair, because the fact that it ever worked was good fortune, not because of anything Sonos had actively done.

Isn't Wine only for people who hate the man so much that they choose to have software not work, rather than give evil APPL or MSOFT any $$$?

Is that a serious question? I'll answer it, just in case.



WINE is for anyone who needs to run a Windows app, for whatever reason.



In the Sonos world, WINE is needed to run the Windows controller, because Sonos provides neither a Linux controller nor, more sensibly, a platform-independent controller.

Also, for Linux support wouldn't one normally expect the FOSS community to provide an open source alternative controller that was Linux native? I think all the protocols are freely available.

No, one wouldn't "expect" that. No-one in the world of open source is obliged to provide anyone else with code, particularly when there was no need until a few hours ago, because the proprietary controller worked fine under WINE.



As it happens, the old pre-3.7 DCR can be made to continue to work, but I'll post about that separately.

---

You are basically right - sorry about that.



But Wine is certainly not for "anyone who wants to run a Windows app". I run Windows apps all the time, and I've never use Wine.



I ordered a copy of Windows from newegg.com. It seems to run all my Windows software just fine.



I think even on a machine that naively boots linux you can run a VM that hosts Windows, yes?



So, if you remove my ill advised sarcasm, I guess I'm asking: if you want to run the desktop Sonos clients, why not use one of the operating systems that host it reliably?

---

You are basically right - sorry about that.



But Wine is certainly not for "anyone who wants to run a Windows app". I run Windows apps all the time, and I've never use Wine.





Anyone on a platform that runs WINE, but not Windows. Better?:)

I think even on a machine that naively boots linux you can run a VM that hosts Windows, yes?

Indeed, if you have the VM and a copy of Windows to run on it.

So, if you remove my ill advised sarcasm, I guess I'm asking: if you want to run the desktop Sonos clients, why not use one of the operating systems that host it reliably?

Purchase a copy of Windows and run it under a resource-hungry VM, just so that one can use the desktop controller? I think you're probably pulling my plonka again, but here are just a handful of reasons:



1. Windows is expensive.

2. Sonos don't support that configuration any more than they support WINE.

3. There are likely to be UPnP issues.

4. The old 3.6 controller can be made to work under WINE.

---

You own ten Sonos zone players and you think Windows is expensive? I'm not buying it.



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



Sure an old version worked. So what?



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



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.

---

Crazy as this may sound, Linux is just some people's preferred OS!



I'm a developer and all my computers are dual boot into Windows 7 & Linux... honestly day in day out I prefer using Linux.



As such, I'd love to continue to be able to use Sonos in Linux to save me having to reboot into Windows each time for a simple task like changing music. It has zero to do with money - it's preference and convenience...



If you could tell us how to downgrade to 3.6 in Linux I'd be very grateful! ;-)



Many Thanks

---

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.

---

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.

---

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 😞

---

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'.

---

Hi Ian,



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



many thanks

---

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:







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



You'll see something like this:







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:





or here on a 64 bit one:





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.

---

Yay, that worked great for me. Thanks 😉

---

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.

---

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.

---

Thank you Ian. That worked a treat!



Cheers

---

That works great. I encountered only one problem, as noted below.



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. [...]





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



(pseudolink deleted to permit posting)



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.



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.





When I pulled up the VERSION number of my Zone Player, I got the following: 17.5.51200e. At first I substituted this entire string and the controller crashed when I tried to run it. But then I went back and deleted the "e" and now everything works as before.



I too used vim -b for the editing job. vi takes the same -b flag, so I suspect that will work as well, for those who don't have vim installed.



I really appreciate your posting this.



Cheers.

---

When I pulled up the VERSION number of my Zone Player, I got the following: 17.5.51200e. At first I substituted this entire string and the controller crashed when I tried to run it. But then I went back and deleted the "e" and now everything works as before.





Thanks. My version didn't have a letter appended, so I'll amend my instructions.

I too used vim -b for the editing job. vi takes the same -b flag, so I suspect that will work as well, for those who don't have vim installed.

The original vi didn't have a binary mode, so your vi is still derived from vim. vi --version will tell you if that's the case.



I'm glad this helped you and other people out; and me, of course. 🙂

---

The original vi didn't have a binary mode, so your vi is still derived from vim. vi --version will tell you if that's the case.



On the mark!







So vi users do need to exercise caution.

---

Thanks Ian. Worked like a charm, except that the version number I had to change from was slightly different from 16.7-48310. I did a search on "16." and found a string with the right configuration. This may help others who have slightly different versions. I imagine it's because I hadn't updated to the latest 3.6x version of the software before 3.7 came out.

---

the version number I had to change from was slightly different from 16.7-48310. I did a search on "16." and found a string with the right configuration. This may help others who have slightly different versions. I imagine it's because I hadn't updated to the latest 3.6x version of the software before 3.7 came out.



That's correct. The version number I quoted is the one you'll have if you download and install the version of the DCR that I linked to on the Sonos server. Anyone running an earlier version will have a different number.



If you use the script I've posted in this thread, it will work with any version number, enabling you to update the DLL every time a firmware update renders the old DCR inactive again.

---