More information about the iPad and iPhone volume slider bug - I've been testing it.

Firstly, I've now found that the volume/play-pause toggle is only needed in portrait mode on my iPad. In landscape mode, both functions are now shown in a single display. This seems like a workable compromise to me.

Having said that, however, one can now see the dreaded volume slider bug in action simply by rotating the iPad and watching what happens to the slider as the display switches from portrait to landscape. As the display changes, the slider moves to a different position while the actual playback volume stays the same.

Leaving the slider alone and then rotating back to portrait causes the play-pause display to appear. Then toggling to the volume slier display shows the slider in the same incorrect position as it was in landscape orientation.

If I repeat this portrait to landscape to portrait process but additionally move the volume slider while in landscape orientation which, of course, changes the volume, then when I return to portrait orientation and toggle to the volume display, it shows that the volume slider has moved back again to the same incorrect position that it moved to when rotating from portrait to landscape, i.e. a position that doesn't match up with the actual volume. It’s almost as though there's a default being used or a positional value that keeps being referenced even though it's wrong.

So..... it seems as though there's a data item - probably somewhere on the iPad and referenced by the controller software - wherein volume slider position is stored but only occasionally updated, but also wherein the value that it holds is (incorrectly) referenced every time that the display is altered by toggling or by changing orientation.

Additionally, if I press the iPad home button to view the iPad home screen and then re-enter the BluOS controller app, I can sometimes see the volume slider moving in a blur to that incorrect position without altering actual volume.

There is a cause, and it could be a simple bug involving the use of an incorrect data name. It certainly wouldn’t be the first such instance of this in the IT world, either! It’s easily done. I’m guilty of it!

In short it seems as though when looking for the volume slider position to use when freshly rendering the display of the volume slider, the controller app is looking for it over here in this data item when it should be looking for it over there in that data item.

So, come on guys. All of the clues are probably there now. Isn’t it time to isolate the cause and fix the bug?