Bugzilla – Bug 15117
Squeezebox server 7.4.1 does not save audio settings correctly on Transporter
Last modified: 2010-04-09 06:46:26 UTC
Sean says that it is a bug, and then I believe it. List below from audiophile forum: Quote: Originally Posted by callesoroe I have a remote controlled outlet, which powers all my equipment off when I got to bed. Does this reset The Transporter. Because my settings regarding effect loop is disabled every day at startup, eventhough I have changed settings to active and saved them in the settings menu in Squeezebox server ??? Answer from Sean Adams: Power cycling will NOT affect any settings saved internally in Transporter - those are only the network settings anyway. All the "interesting" settings that affect audio playback are maintained by the server/. You may have found a bug in SqueezeCenter where it is not properly reinitializing the player when it connects. By the way: The clockfunction to effectloops also goes back to Transporter is master, eventhoug I have saved that external is master. This happens every day and it nearly burned off my Martin Logan speakers, because I thougt that My Tact was master volume, but it has disabled this at startup and it started with 250W output from my amps!!!!!!!
Created attachment 6311 [details] logfile from squeezeboxserver added log
The attached log file does not contain useful information in regards to this error report Please set the following to DEBUG, then produce another log file: player.ui prefs server
Created attachment 6315 [details] with suggested settings Here is n new log with the suggested settings. The error is there after every power on of The Transporter, so there is nothing temporary in this.
Created attachment 6316 [details] With suggested settings Here is a log with the suggested settings for log. The error is there after every power off/on of the transporter, so it is not temporary.
I think it is a major bug, though it can burn off your speakers.....
Michael: Can you have a look at the attached log for any errors? QA tested on Windows Vista / MAC OSx 10.5 but was unable to replicate the bug as reported. This could be specific to ReadyNAS?
What particular settings/prefs are we talking about here? Something particular to the transporter?
It is the settings regarding input to effectloop and clockfunction to effectloops. When I change input to effectloop from Deactivated to AES/EBU and the setting clockfunction to effectloops from "synchronous Transporter Master" to "asynchronous Eksternal processor Master" and save this, then when The Transporter starts up again, the settings are NOT changed. They are back to effectloop disabled and synchronous.
(In reply to comment #8) > It is the settings regarding input to effectloop and clockfunction to > effectloops. > When I change input to effectloop from Deactivated to AES/EBU and the setting > clockfunction to effectloops from "synchronous Transporter Master" to > "asynchronous Eksternal processor Master" and save this, then when The > Transporter starts up again, the settings are NOT changed. They are back to > effectloop disabled and synchronous. And these settings are speciffic for Transporter
Felix - I think this is a firmware issue. It seems to be working perfectly fine eg. on server change. As long as you don't power cycle the device, fxloopSource and fxloopClock are carried along by the player. Changing those prefs on server A will result in them being changed on server B when switching. The prefs stored in the player take precedence over the locally (on the server) stored values. But if you power cycle the transporter, these two prefs are reset to defaults. It looks as if the values were stored in the player's memory, but not written to some non-volatile memory or something.
Some background: The two settings in question are _not_ stored in non-volatile memory (and never were) and therefore cannot survive a power cycle. They need to be reinitialized from the server upon reconnection. Also see Sean's comment in the initial description where he actually states that. I guess something changed on server's side which does not initialize those two values upon reconnection.
> I guess something changed on server's side which does not initialize > those two values upon reconnection. It does, but only after querying the player's values first - which will reset the values. I guess this is needed in case somebody is using the player's firmware menu to select source etc.
Ok, here is what I found. The following settings are handled by 'setd': 0 : Player Name (hostname) 1 : Digital Output Encoding (digital_encoding) 2 : World Clock On S/PDIF Outputs (world_clock_output) 3/4 : Power Off AUDIO (power_off_dac) 5 : Effects Loop Input (fxloop_input) 6 : Effects Loop Clock Mode (fxloop_clock_mode) Now, of the above 'setd' settings only 0, 1, 2, 3 (4) are stored in non-volatile memory and only those can also be changed in Transporter firmware menu via 'Current Settings'. The two settings in question 5 and 6 cannot be changed in 'Current Settings' and are not stored in non-volatile memory which makes sense to me as they cannot be used without streaming music. In other words the effects loop is only interesting when using with a server. So my conclusion is that settings 5 and 6 should never be queried by the server, but just be set to whatever is stored on the server side. BTW: 'Clock Source' is handled by a separate SlimProto command 'audc'.
(In reply to comment #13) > Ok, here is what I found. The following settings are handled by 'setd': > 0 : Player Name (hostname) > 1 : Digital Output Encoding (digital_encoding) > 2 : World Clock On S/PDIF Outputs (world_clock_output) > 3/4 : Power Off AUDIO (power_off_dac) > 5 : Effects Loop Input (fxloop_input) > 6 : Effects Loop Clock Mode (fxloop_clock_mode) > Now, of the above 'setd' settings only 0, 1, 2, 3 (4) are stored in > non-volatile memory and only those can also be changed in Transporter firmware > menu via 'Current Settings'. > The two settings in question 5 and 6 cannot be changed in 'Current Settings' > and are not stored in non-volatile memory which makes sense to me as they > cannot be used without streaming music. In other words the effects loop is only > interesting when using with a server. > So my conclusion is that settings 5 and 6 should never be queried by the > server, but just be set to whatever is stored on the server side. > BTW: 'Clock Source' is handled by a separate SlimProto command 'audc'. It does not make sense, that you shall startup Squeezeboxserver web interface and change settings, before you can start playing music....... Remember that if you are running the effectloop, it is because your AMP's are connected to the Transporter. And if settings is reset then it blow out FULL VOLUME when it starts up!!! and may burn of your speakers.....
Hi there I think you misunderstood my comments. The idea is that the effect loop settings are restored _automatically_ as soon as Transporter connects to Squeezebox Server. There should be no need to go to the web interface and do that manually every time. I hope this clarifies my earlier comments. Sorry for the confusion. Felix
Created attachment 6341 [details] don't read fxloop settings from the player, use server side prefs instead
== Auto-comment from SVN commit #29493 to the slim repo by michael == == https://svn.slimdevices.com/slim?view=revision&revision=29493 == Fixed Bug: 15117 Description: neither clockSource nor fxloop prefs are stored in the player. Set them from the server's prefs when connecting.
Does this fix come in a nightly version??
oh I can see the fix is there now in 7.5 nightly. Sorry for the prior comment.
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release. If you are still seeing this issue, please let us know!
I can confirm that is has been fixed with 7.5 :)