Contributor I

Sonos is killing a family Xmas tradition.

15 replies
404 views

I have been a Sonos owner for 10 years now. In that time I have accumulated quite a bit of gear which I actually enjoy and, in the past, have recommended to others. But over time it has become quite apparent that we have different goals. First the S1/S2 debacle which was no more than an attempt to push voice assistants everywhere and kill the analog hole. (Funny how my original Play:1 still works on S2 but the connect:amp won’t and the voice apps are still crap) Now I have just discovered that last spring they killed off playing personal music from android devices. How I discovered this is that my family, like many, have accumulated a large collection of holiday music over the years. Many of the albums are not mainstream and some have been in the family for generations. Long ago they were ripped from vinyl to digital and now reside on an android tablet. A device that a year ago worked fine but not now. No holiday gathering listening to unique music handed down from grandparents, but feel free to stream generic commercial offerings that have commercials.

Does Sonos realize that they have devolved existing systems from the equivalent of a high end stereo system to being just a nice table top radio?

Music Library

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.

Show previous replies

S

ssmiejaAuthor

Contributor I

I concede The S1/S2 split was over memory. Although as someone who dabbles in programming IoT devices I know that you can do an awful lot in 32meg. My gripe is that Sonos found it necessary to kill off the local file feature on android devices. I'm sorry but blaming the OS platforms when dozens of other music players don't have an issue playing local files is a weak argument.

jgatie

I concede The S1/S2 split was over memory. Although as someone who dabbles in programming IoT devices I know that you can do an awful lot in 32meg. My gripe is that Sonos found it necessary to kill off the local file feature on android devices. I'm sorry but blaming the OS platforms when dozens of other music players don't have an issue playing local files is a weak argument.

See, you are wrong again. The Sonos app isn’t a music player. It’s a remote control. You could start music playing and toss your phone in the ocean and the music will still play. As such, the music files are not being played on the phone, they are being played on the Sonos device, and Google/Apple have prevented third party devices from accessing files on the phone due to security reasons. So you see, the blame does lie with the OS platform for restricting access by 3rd party hardware.

Ken_Griffiths

I concede The S1/S2 split was over memory. Although as someone who dabbles in programming IoT devices I know that you can do an awful lot in 32meg. My gripe is that Sonos found it necessary to kill off the local file feature on android devices. I'm sorry but blaming the OS platforms when dozens of other music players don't have an issue playing local files is a weak argument.

Again you’re mistaken - The Sonos App is not a music player and the only way to play music stored on an Android device is either by using ‘Casting’, ‘Bluetooth’ or ‘UPnP’ music players and you can (still) use both the latter two playing methods to play locally stored files to Sonos speakers.

For Bluetooth you need a compatible speaker, or a BT RX, linked to line-in, but all Sonos products are UPnP compatible. Just use a compatible music player from the Google App Store.

The reason the ‘On this device’ feature was removed is because Google followed what Apple did a couple of years ago, and that is to stop the device file share/playback over WiFi due to security concerns that were outside of their control and they just firmly shut that door to ensure their casting/bluetooth etc. methods, took back that control. So you need to raise this issue with Google, rather than pointing your finger at Sonos.

The Sonos App would need to become a music player to achieve what you’re looking for here, rather than a remote control. Personally speaking I prefer the ‘remote’ App option anyway, as that allows me to play numerous LAN/WAN audio sources direct from source to my Sonos devices, rather than having to play things indirectly ‘through’ the mobile device.

buzz

Grand Maestro

Although as someone who dabbles in programming IoT devices I know that you can do an awful lot in 32meg. My gripe is that Sonos found it necessary to kill off the local file feature on android devices. I'm sorry but blaming the OS platforms when dozens of other music players don't have an issue playing local files is a weak argument.

Back in the dawn of personal computers I bought a computer that was to be delivered in two months. Documentation was shipped immediately -- in a big box. My printer was not supported, but clear documentation allowed me to write my own driver. I had 128 bytes available for my code. This was a simple dot matrix printer operating out of a serial port. The computer chip supported 64K of RAM and with a simple trick this could easily be expanded to 128K.

This sort of system is not practical for the masses. Not many people would buy a system that could not support their printer, requiring the user to custom code a driver. Once the operating system is expanded to support hundreds of potential printers with one side or double side printing, portrait or landscape, with options to print subsets of the file, or stack multiple pages on a single side, the memory footprint of this print driver is somewhat larger than 128 bytes.

In SONOS each of the players contains a copy of the SONOS music library index, a customized copy of the Linux operating system and data cache large enough to ride through temporary network stalls. You might have noticed that if the network goes down, play will often continue until the end of the current track. Unless you want to store music on a NAS drive or computer, SONOS does not require any external storage.

Internally SONOS uses the Linux operating system to manage things. The Linux system used for S1 is dated and does not support features that modern users demand. For example S1 does not have the capability to run SMBv2 which most computers and NAS drives now demand. Unfortunately, there is not enough RAM available in the older systems to replace and run a more current version of Linux that can handle SMBv2 and more complicated wireless. Maybe a newer version of Linux could be installed, but the process would be similar to changing socks while running. Plus, the new Linux is larger, reducing the memory available for buffering and supporting other modern features. Even without the new features replacing the Linux system is not something that could be accomplished with a single click. This would require user interaction with the system that is not appropriate for a product intended for non technical users. Units would need to be sent to a service center for the update.

Note, I have corrected the original version of this post that incorrectly referenced Android, not Linux

Sorry for the typo.

Stanley_4

Grand Maestro

Kids these days and their fancy dot matrix printers. I was ever so happy to replace my Teletype with a Selectric I/O Writer. The wire-wrapped Z-80 translator (ASCII to magnet code) and magnet driver card had a whole 1K of memory and another of EEPROM.

Folks talking about how much you can do with what amount of memory really need to step back and do some simple math to discover the minimum requirements of the embedded operating system before deciding just how much room there is left for application code.

I’m not going to go back and look it up again but the old S1 gear didn’t have the memory needed to support the newer Linux kernels that were needed to move beyond SMB v1, much less fancier application code.

Sign up

Login to the community