I have two Soundbridge M1001 that have worked flawlessly for years.
Just recently "both" units have stopped responding to remotes if left unattended for an extended period.
Units must have power source removed and re-plugged in then the Soundbridge will work with remote without issue.
Batteries have been changed in remote.
Remotes switched back and forth.

Is this a coincidence that both units would have same lack of response at same time?

I have not reset units back to factory yet as I wanted to hear from others first.

The Soundbridge is still a very usable device even with the favorites and internet radio search functionality being killed

I would get another known good power supply and test.

FrankB wrote:

I would get another known good power supply and test.

I'll have to buy another power supply to try. The 3rd Soundbridge got fried from a power supply bought through either Newegg or amazon in the past year. It fried it earlier this week when checking that possibility.

Take a look at the sticky thread.

Well, I had another working Linksys power supply which produced the same result.
I also used a working Roku 2 XS power supply with the same result.

One thing not mentioned previously is that one Soundbridge has a clock display when not playing music while the other doesn't.
Another is that if Soundbridge is still playing for an extended period of time without using remote the unit won't respond to remote.

I'll see about checking the power supply this weekend with a meter.

The clock display while playing is a setting that probably varies between the two.

I wonder if there is a source of infra red that is locking up the remote sensor. As an experiment, you could cover the sensor with black electrical tape until you wanted to use it, just to see.

I would be inclined to do a factory reset since it's not much to restore the settings just to rule that out.

For S&G's I'm giving your "infra red" conflict theory a try.
I have introduced only one new infra red remote to both locations in the past two years which happens to be the same model GE universal remote.

I took one of the GE remotes and blasted one Soundbridge with typical and random presses for about thirty seconds without any effect.
The other I have covered and will check in the next 24 hours.

Factory resetting has never been an issue for me as I've performed that in the past.
Since it has occurred to both my Soundbridges in pretty much the same time I am hoping to find the root cause if possible before resetting the units.

As expected, blocking one of the soundbridges from receiving any infrared signal for more than 24 hours had no effect on unit.
It was definitely worth a shot.
I have reset that specific soundbridge back to factory settings.
I have set the unit back up with WiFi and added the presets.
Let's see what will happen.

Well guess what happened, no change.
Unit that had been reset to factory settings will NOT respond to remote without pulling the power supply and reinserting it to the soundbridge.
Any further thoughts?

I would explore the irman command on the telnet port 4444.

telnet 192.168.1.45 4444
Trying 192.168.1.45...
Connected to m500office.
Escape character is '^]'.


Welcome to the SoundBridge Shell version 3.0.44 Release
Type '?' for help or 'help <command>' for help on <command>.

SoundBridge> help irman
usage: irman dispatch <key> [up|down]|echo [updown]|intercept [updown]|off|list
       Use the irman command to receive updates every time the user presses
       a key on the remote, or to dispatch a key to the system as if the user
       had pressed it.
       irman dispatch <key> [up|down] - dispatch the named key
               The optional 'up' or 'down' param will allow you to
               separately dispatch KeyUp and KeyDown events.
       irman echo [updown] - echo user keypresses to the shell
               When echoing keys, the key will still get dispatched to
               the system.  The optional 'updown' param will give you
               separate notifications for KeyUp and KeyDown events.
       irman intercept [updown] - intercept user keypresses to the shell
               When intercepting keys, the key will NOT get dispatched to
               the system.  The optional 'updown' param will give you
               separate notifications for KeyUp and KeyDown events.
       irman off - cancel echo or intercept reporting.
       irman list - list known key names.

I have virtually zero knowledge with connecting via telnet so any assistance is appreciated.
Manufacturer test performed as indicated
SoundBridge> mfg
all tests passed

A few remote entries selected and completed.


usage: irman dispatch <key> [up|down]|echo [updown]|intercept [updown]|off|list
type "help irman" for more.

SoundBridge> irman dispatch CK_POWER_OFF
SoundBridge> irman dispatch CK_POWER_ON
SoundBridge> irman dispatch CK_INTERNET_RADIO
SoundBridge> irman dispatch CK_MENU
SoundBridge> irman dispatch CK_SOUTH
SoundBridge>
So, we know at least the commands I selected function.
Now, at a later time with power off and non-responsive to remote I should be able to connect via putty.
The above was performed on the unit that had been reset to factory.

Using "fing" both soundbridge units were showing up in its scan as well as the port scan services.

I had attempted to connect to the other soundbridge via putty but it wouldn't connect until I pulled and reattached the powerer source.
This may sound odd but is there a buffer of any type that would need to be cleared/purged that would have any effect?

"Off subject" I will explain my question above- Our office has a PBX that stopped displaying caller id. 
The authorized service company had to find out from mfgr (after my urging) that there was a buffer limit that once reached would no longer display called id.
Only the mfgr could clear the buffer, not even the authorized service technician. Once done, caller id worked as it should.

One other bit of info I noticed today is with the unit which maintains it's clock display when turned off.
At 1710 hrs I turned unit off.
At 2008 hrs I attempted to turn it back on which it was unresponsive.
What I noticed is that the time was accurate to this point.
After attempting to turn unit on the clock no longer advanced.