Build 537 borked BluOS and Squeezbox players

Core Machine (Operating system/System info/Roon build number)

Mac-mini Roon Server 1.7, build 537

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Eero Mesh network

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Logitech Transporter - wired
Logitech Transporter SE- wired
Bluesound Node 2- wired
RPi/Ropeee x 2- wireless
Bluesound Pulse- wireless
Bluesound Pulse mini- wired

Description Of Issue

Problem began after installing build 537. In 536 there was an option to put the Transporters in Sleep mode, which I enabled. with the upgrade to 537 this option went away, and both Transporter displays went dark. Roon would still play to them however. I was able to fix the non-SE transporter by reverting to default settings in Roon, and removing power, and plugging back in. this did not work with the SE, which, after performing the reset has disappeared from Roon altogether, and will not power on at all.

Separately, with the upgrade to 537, Roon has lost control of a Bluesound Node 2. the issue seems the same as in this thread:

Roon sees the device, but will not play to it, and will not allow me to name it or change settings. Roon playback to Pulse and Pulse mini work fine, as does BluOS playback to all three devices.

Lastly, i’m receiving the Metadata Improver error others have noted:

update: rebooting core machine resolved Node 2 issue.

Transporter SE still borked.

Hi @woodford,

That’s strange, do you see any lights flashing on it at all? Do the Ethernet lights still blink?

Could you please use these instructions to send me a copy of your Roon logs? The best way to send them to me would be via a shared Dropbox / Google Drive / Send.firefox.com link.

Thanks!

no lights. i hear a “click” when power is reapplied.

looking for the logs, but haven’t found them yet. using roonserver. which folder should they be in (MacOS 10.14.5)

@noris confirming i sent logs, have you received them?

Hi @woodford,

Thanks for sending the logs over, I can confirm I received them properly. I will discuss the logs with our technical team and once I have further information I will reach out once more. I appreciate your patience here!

thanks- can confirm the Transporter SE appears completely dead, save the “click” when power is applied. no lights on ethernet, no display on, and it does not respond to any button pushes on the front panel.

Hi @woodford,

Thanks for clarifying the error state. Are you still able to use the Transporter with Logitech LMS or is it not functioning with that as well?

i don’t currently have an instance of LMS running, but since SE no longer boots, nor appears to connect to the network (no ethernet lights), i assume it is completely dead.

to be clear, this is the state both transporters were in after installing 537, but i was able to revive one of them.

Hi @woodford,

I spoke to our technical team regarding this issue, and they haven’t seen such behavior before, where a Roon update caused an issue with audio devices powering on.

At this time, we suspect that something else triggered this behavior and the Roon update was just a coincidence that it occurred at the same time.

If you haven’t yet, you could try performing an Xilix reset on the Transporter, this might help get it back on track:

http://wiki.slimdevices.com/index.php/Transporter_xilix_reset

If the Xilix reset doesn’t help, our next suggestion would be to reach out to the manufacturer directly for hardware troubleshooting.

Thanks!

i think you need to remeber the sequence. Build 536 had a sleep option for the transporter, which i enabled. 537 removed this option. i suspect something in the roon code which removed the sleep option also prevented the device for waking up.

Hello @woodford,

We’ve done some testing with our Squeezebox devices in the QA lab, they are working with b357 without issue—and the standby button is still available on our Squeezebox Classic.

Before we continue with diagnostics, can you confirm if the device is pulling an IP address from your router? Do the ethernet port lights on the switch/router that the Transporter is plugged into show any activity when the transporter is connected to power?

-John

no standby button in 537 on my standard transporter. it was there in 536, and disappeared in 537. i think this is the source of the problem.

the transporter SE does not get an IP address, and no lights on the ethernet port on the devices, nor on the port on the switch.

Hello @woodford ,

I see that @noris suggested a Xilix reset on the device, have you also tried to perform a factory reset (hold down “plus” button when power cable is connected)?

We have not have not received any other reports of this behavior with Squeezebox Transporter units on the latest build—we reached out to a few users directly to confirm. Our next step is to figure out what makes your setup different that ultimately culminated in this issue.

While researching this issue I found another report with similar anecdotes about the Squeezebox Transporter. I recommend reading the conversation in this thread to see if any of the information is helpful in getting your unit back online: Logitech Transporters hanging when connected to roon

Another possibility is that there was a latent hardware or software issue on the Transporter SE that was triggered by the reconnection cycle to the new Roon instance. Unfortunately, this would be impossible for us to determine remotely.

-John

i’ve tried the xiilix reset, to no avail, but this post from the linked thread seems to corroborate my suspicion that the “sleep” functionality that was present in 536 being removed in 537 is what caused the issue.

you stated earlier that i should still see the sleep function in 537, but i don’t. why is that?

@john I’ve managed to resurrect the Transporter SE by replacing the power supply board, as described in this thread:

https://forums.slimdevices.com/showthread.php?100509-Need-help-for-broken-Transporter&highlight=dead+transporter

luckily, the process is fairly cheap and straightforward.

however, it still does not explain why this happened with the change from 536 to 537. as i stated previously, the “sleep” option disappeared with this upgrade. still, both Transporters, including the SE, go into sleep mode now when no music has player for a bit.

you’ve never explained why this is so, nor why the option disappeared with this build. can you?

Hello @woodford,

Glad to hear you’re back up and running.

I’m going to speak with the development team about the specifics of our Squeezebox implementation during our meeting this week. I’ve noted your questions and will return with answers later this week.

-John

1 Like

Hello @woodford,

Thanks for your patience, I was able to discuss your ticket with the development team.

They stated that the “Standby” control that mistakenly appeared in-app was never “connected” to any code that would affect the Squeezebox players. They also provided the context that Squeezebox does not support “Standby” in a proper sense, and that the “Standby Display” option in Roon simply changes what is drawn on the Squeezebox display and has no impact on the power state of the device.

-John

Thanks John. the fact is, both transporters now go into “display standby”, ie switching off the display, when playback stops. they did not do this prior to setting the standby option in 536.

how do i adjust this behavior now?

Hello @woodford,

Under the Device Setup > Show Advanced page for the Squeezebox, what do you have the “Standby Display” option set to?

-John