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:
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 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.
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.
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:
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.
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?
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.
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?
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?
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.
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.
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.