Problems caused by specific Sense 3 updates.

[Esscee]

Following on from the Sense 3.0.1 Changelog last post by Stephen Healy which closed that thread,
thought it best to start this here in Help section as Stephen kindly suggested.
Regarding the topic of "rolling back" from an update, my point was that can a user do that at present?
If not, is it possible that this could be done at user level rather than waiting for an input from Innuos?

As I mentioned before, on Windows PC if an update causes a problem the user themselves can delete a particular update to go back and have a functioning PC again or if they have used "Create a Restore point" it will allow a "rollback".
Not trying to cause any grief or complicate matters in any way here at all.
I always wait a couple of weeks or so before allowing any Windows updates, due to unforeseen problems a user can incur and allowing MSoft to correct those errors.
Maybe I might use that philosophy with Sense updates too, nothing more annoying than being unable to use Innuos unit after an update when it worked perfectly well prior to update.
@Stephen Healy

 

[mikehughescq]

So, from the closed thread…

I have found this happening too. Seems to relate to having more than one device on the network. In my case it sets itself to the volume of a Naim Muso QB which sits upstairs with the offspring. Interesting because it shouldn’t be choosing that as the default device when it’s second in the list and everything works as expected if you disable it.

Anyways, at this point I’m more concerned about sound quality having deteriorated.

This will be because when you switch off your DAC or main output connection of your Innuos, it reverts to the next one that's available - in your case, the Muso, and it must synchronise to the volume of that device. If the Innuos carried on set to 100 on the Muso, the QB would probably blow up. If you are saying that the synced volume of the QB (let's say 35, for example) is then applying to your main DAC output when you switch back to it then please let us know at support, or raise this as a separate post on the Help section.

@Stephen Healy on the advice of Chord I power down my Chord DAC when not needed and then Zenith until next needed but leave amps on.

Never had this problem until recent updates added the Muso QB as a separate device. Is there a specific reason why the streamer has to move to another device/output? Why can’t the default just be that it stays with whatever the user has designated as the main device.

 

[Stephen Healy]

So, from the closed thread…


This will be because when you switch off your DAC or main output connection of your Innuos, it reverts to the next one that's available - in your case, the Muso, and it must synchronise to the volume of that device. If the Innuos carried on set to 100 on the Muso, the QB would probably blow up. If you are saying that the synced volume of the QB (let's say 35, for example) is then applying to your main DAC output when you switch back to it then please let us know at support, or raise this as a separate post on the Help section.

@Stephen Healy on the advice of Chord I power down my Chord DAC when not needed and then Zenith until next needed but leave amps on.

Never had this problem until recent updates added the Muso QB as a separate device. Is there a specific reason why the streamer has to move to another device/output? Why can’t the default just be that it stays with whatever the user has designated as the main device.

I don't believe there were any changes to SenseUPnP in the past few updates, so unless this is a new bug then the behaviour of switching to the streamer should not be new.
The default behaviour of the system is if the primarily selected output device is lost, then it will switch to the nearest available. We are making changes to SenseUPnP soon and will need to expand on 'multiplayer' control to handle various different endpoints. In this instance, you would indeed need some kind of 'default override' so that the connected USB DAC always overrules any other selected endpoint.
For the time being, all i could suggest would be to disable SenseUPnP, and only turn it on for the occassion that you do want to use Sense to play through Muso, or alternatively revery back to standard UPnP mode and use the standard approach of using the Naim app to control the playback/streaming for the QB.

 

[Stephen Healy]

Following on from the Sense 3.0.1 Changelog last post by Stephen Healy which closed that thread,
thought it best to start this here in Help section as Stephen kindly suggested.
Regarding the topic of "rolling back" from an update, my point was that can a user do that at present?
If not, is it possible that this could be done at user level rather than waiting for an input from Innuos?

As I mentioned before, on Windows PC if an update causes a problem the user themselves can delete a particular update to go back and have a functioning PC again or if they have used "Create a Restore point" it will allow a "rollback".
Not trying to cause any grief or complicate matters in any way here at all.
I always wait a couple of weeks or so before allowing any Windows updates, due to unforeseen problems a user can incur and allowing MSoft to correct those errors.
Maybe I might use that philosophy with Sense updates too, nothing more annoying than being unable to use Innuos unit after an update when it worked perfectly well prior to update.
@Stephen Healy

Hi Escee, I did reply on this topic on the original thread before locking it, but i would ask that you outline the problems you encountering as i don't think i've seen what problems exactly you have had with 3.0.3?

 

[Esscee]

Hi Escee, I did reply on this topic on the original thread before locking it, but i would ask that you outline the problems you encountering as i don't think i've seen what problems exactly you have had with 3.0.3?

Hi Stephen,
As you noted that there is no problems that I have had with 3.0.3 because I have yet to update to it, reason being seeing other users are having some problems therefore I am waiting a while to see if these are fixed.
My original post in the 3.0.1 Changelog was due to some users having some problems and then my suggesting ways ("rollback") for Innuos to help overcome/prevent these glitches occurring.
Trying to be proactive to help you /Innuos and the users rather than Innuos having to be reactive is my reason for the posting.
Apologies if this has caused any misunderstanding.
Please keep up the good work to you and all at Innuos.
Rgds Stephen
@Stephen Healy

 

[Stephen Healy]

Hi Stephen,
As you noted that there is no problems that I have had with 3.0.3 because I have yet to update to it, reason being seeing other users are having some problems therefore I am waiting a while to see if these are fixed.
My original post in the 3.0.1 Changelog was due to some users having some problems and then my suggesting ways ("rollback") for Innuos to help overcome/prevent these glitches occurring.
Trying to be proactive to help you /Innuos and the users rather than Innuos having to be reactive is my reason for the posting.
Apologies if this has caused any misunderstanding.
Please keep up the good work to you and all at Innuos.
Rgds Stephen
@Stephen Healy

I can certainly see the line of reasoning, but a rollback facility is certainly a difficult thing to rollout; besides personal computers, it's not a feature that's available anywhere such as phones, tablets, TVs etc. Also from a support perspective, this starts to become problematic with systems being rolled back to all kinds of different versions based on user preference - paving a way forward to effectively support these becomes problematic, and rollbacks could be instigated for reasons that are in fact nothing to do with the update (take the Qobuz comms issue, for example). Although it certainly requires patience on your part, its more constructive that we can harness the feedback to issue hotfixes as quickly as possible.