iOS Volume Control Issue
-
Official comment
Hi Paul
This week we released BluOS App 4.4.1 for iOS to the App store. It has only been the past 24 hours this has been wide release to everyone. One of the issues addressed was this. Can you please confirm you are on this latest version of the App?
If you are (along with BluOS 4.4.19) can you (or Ian) let us know at support@bluesound.com? You can check in the App under Settings, About.
Thanks -
This issue disappeared when V4 first arrived, but after some bug fixes etc. were deployed the problem returned.
What I don't understand is the complete silence from Bluesound about this issue.
If it's something that they can't fix then perhaps that's why they are saying nothing. However, the result is multiple posts on the worldwide web from unhappy users such as you and I.
If it's something that they can fix, then why the silence?
I find it very puzzling as well as very insulting.
1 -
App was iOS 4.4.0. Manually updated. A very quick visual only check looks like it is corrected. Side note I used Upgrade and it found no update…but maybe that only looks at the BluOS version.
Player is BluOS 4.4.19.Thank you for addressing this issue.
0 -
My iPad is also on 4.4.0 and no upgrade is being offered, and I can say that 4.4.0 along with BluOS 4.4.19 doesn't resolve the volume control issue.
The slider stayed put through a couple of re-renderings wherein I altered screen orientation.
After that, the slider moved itself through things such as turning off the iPad display, maximising the display of the track, returning to the standard portrait display, changing orientation etc..
So, I need to wait for iOS 4.4.1.
I thought that I saw it offered yesterday but I delayed the upgrade by 24 hours and now it isn't being offered. Will the upgrade next be offered after those 24 hours have passed?
0 -
Ian, delete the App and download again from the App Store - quickest way.
0 -
I should be able to try that tomorrow, Saturday. (Got guests.)
0 -
I uninstalled the controller app and installed 4.4.1, and I tested every which way but could not, I say, "Could not!!!!!" get that volume slider to move of its own accord.
So, thank you Bluesound for that fix, but please can comms on such topics be more open from the Bluesound side in the future and, therefore, less contentious and damaging in nature?
0 -
I am now sorry to report that the fix hasn't worked.
Tonight, I set the volume slider to approximately one third and it moved to approximately 50% when I switched orientation.
So I moved it back to one third, pressed the home button on the iPad to minimise the app, went into Safari, popped out of Safari and back into BluOS and it went back to 50%.
Then I set it to one third and closed the app. After restarting the app, the slider was correctly sat at one third.
Then I set it to 50% and flipped the orientation, at which point it reverted to one third.
So, I set it to 10% and closed the app. On restarting the app, it came back as 10%. Then I set it to one third and flipped the orientation, at which point it reverted to 10%.
So... as it stands now, it seems that when the app starts up it correctly picks up the volume setting from the player, stores that setting somewhere for no good reason , and then incorrectly references that newly stored setting whenever it has to repaint the screen as a result of change of orientation, or toggling between play-pause and volume, or minimising and maximising as the user switches between apps.
Since volume can be altered at any time by any one of many simultaneously running instances of the controller app and since, therefore, no individual instance of the controller app can be viewed as "The Master", each individual instance of the controller app should always refer to the player itself for the volume slider position when having to repaint the display. After all, only the player really knows what the volume is.
I also know that this assertion underpins the design of BluOS inasmuch as changing volume using one instance of the controller app causes the sliders in all active instances of the app to reposition themselves to match.
In the case of the iOS/iPadOS controller app, however, it seems to be inappropriately referring to a "locally stored" (in the logical sense) volume setting which, as far as I can tell, is populated only once during start-up and is then incorrectly referred to thereafter.
It is even "held on to" after volume has been amended by another instance of the controller app. I changed volume using my Android phone and the slider on the iPad moved to reflect this, but as soon as I changed orientation on the iPad from portrait to landscape the iPad slider reverted to the position that it picked up when the app first started.
In short there is only one correct value for volume slider position, which is necessarily stored on the player, but iPads and iPhones are referencing another setting, which is initially populated when the controller app is started up and which is referred to thereafter whenever the screen needs to be repainted.
Where that setting or field lives, I can't say, but a deeper dive into the code should be able to answer that question. My guess is that there might be a little bit of legacy code hanging about long after it should have been retired.
The remedy, as far as I can tell, is simply to find and correct the offending line(s) of code that are using the wrong data name when they're executed.
What I can't really comment on is how everything behaves when there are multiple players on the network (I only have my Vault 2) and, therefore, any single instance of the controller app has to know which player it is currently being asked to control and, therefore, which player to go to for all of the data needed to paint the screen. Having never observed the Vault to permanently ignore my commands, however, I suspect that this aspect is fine.
What I can't yet explain is why the volume slider behaved perfectly when I tested it immediately after upgrading the Vault 2 and the iPad but is clearly misbehaving in a consistent, repeatable, and documentable manner now.
From my perspective this would suggest that a specific condition of some kind was either TRUE or FALSE immediately following the upgrade but has since flipped to the opposite value because the condition that is being tested has now changed.
0 -
Another random thought.... what would happen if an instance of the controller app interrogated a player to establish its volume setting but the player didn't respond?
Would the controller crash, or would it leave the slider where it is or..... ?
0 -
The App does nothing but send API commands... if the API command isn't received by the player, nothing will happen. In all likely hood, it will buffer then eventually get there... and then the volume changes.
0 -
What I can't yet explain is why the volume slider behaved perfectly when I tested it immediately after upgrading the Vault 2 and the iPad but is clearly misbehaving in a consistent, repeatable, and documentable manner now.
Network lag - there is a problem with the commands getting from your iOS device to the player. Please select Settings, Send Support Request so our Support Crew may reach out to you and troubleshoot your environment. Our Support Crew is awaiting you to send that file. Thanks...
0 -
Many thanks.
Done.
However, I'm not entirely convinced that it's that simple since I imagine that if there were network lag then I would not be able to watch the volume slider moving on the iPad as I adjusted playback volume using an Android instance of the controller app. Would not the Android instance also misbehave instead?
Also, I'm not yet convinced that network lag would cause the iPad's volume slider to keep reverting to the setting that it was given when the controller app was first started.
How would it know to consistently revert to that exact position after the player has already updated it with new positions multiple times? And why, when repainting the screen would it repeatedly use that specific value given that it isn't the current value? The only way to be able to use that specific value on a consistent basis would be if it were stored separately and accessed on a consistent basis, which is my main point.
So... two instances of "I'm not yet convinced..." although I'm very happy to be convinced by an explanation as to why network lag is the culprit.
0 -
I've just received what looks like the file that has been sent by my Vault 2, and the entries start yesterday, whereas the testing that I carried out and documented took place the previous day. I did some informal stuff yesterday but nothing that I would like to try and track in a log file.
Will the log file be sufficient, or would it help if I performed some scripted testing, capturing the date and time in my written account, and then sending the log file?
0 -
Is there some way to conduct this offline?
It would seem a better way to get to the end result.
0 -
For Paul and Seppi.
I am working with Bluesound on a fuller diagnosis, including making some movies; but my good lady has forced me at gunpoint to go on holiday to Portugal.
So, I am smiling through my tears and crying into my red wine as I say that I miss you all so much and will resume the diagnosis when the agony of the Algarve is finally over for me.
Bom dia!
0 -
Green with envy.
1 -
Yesterday, after lots of to-ing and fro-ing with Bluesound, I wrote two short test scripts that were designed to either prove that the volume slider issue (as reported by me) was localised to me or prove that it was a genuine Bluesound-running-on-iOS/iPadOS-devices bug that could be reproduced consistently and at will.
I sent these test scripts to Bluesound and asked them to run them in-house, which they kindly did. The upshot is that they were able to reproduce the issue in their own test lab, and they are now going to work on a fix.
0
Please sign in to leave a comment.
Comments
17 comments