Open ericmarkmartin opened 8 years ago
I noticed this too. And also noticed this bad behaviour existed before.
Unfortunately, I believe this is probably a problem with the Spotify AppleScript interface and thus out of our hands, unless someone wants to submit a bug report to Spotify, and I really have no idea what the process looks like especially in terms of time frame.
I don't think anyone really cares or can discern few % diff in the audio level. Will leave this open anyway for some arbitrary point in the future.
Yeah. It's not so much a usability problem but it would make life difficult if I were hypothetically writing a test suite.
This is not (or shouldn't be!) a mission critical app. But even if one were testing, they'd need to code up an approximately_equals operator.
That's what I figured
The following highly unscientific patch seems to work. I don't have an explanation other than to blame floating point arithmetic or something, even though we're supposedly working with integers.
--- a/spotify
+++ b/spotify
@@ -235,16 +235,16 @@ while [ $# -gt 0 ]; do
break ;
elif [ "$2" = "up" ]; then
if [ $vol -le 90 ]; then
- newvol=$(( vol+10 ));
- cecho "Increasing Spotify volume to $newvol.";
+ newvol=$(( vol+10+1 ));
+ cecho "Increasing Spotify volume to $(( newvol-1 )).";
else
newvol=100;
cecho "Spotify volume level is at max.";
fi
elif [ "$2" = "down" ]; then
if [ $vol -ge 10 ]; then
- newvol=$(( vol-10 ));
- cecho "Reducing Spotify volume to $newvol.";
+ newvol=$(( vol-10+1 ));
+ cecho "Reducing Spotify volume to $(( newvol-1 )).";
else
newvol=0;
cecho "Spotify volume level is at min.";
sighs. This is why we need DEC64.
I observed the following behavior:
This behavior also occurs with
spotify vol up
andspotify vol down
. Note that this behavior was not changed when #45 was merged which causedspotify vol [amt]
to print a message that the volume was being changed.Please also note that this behavior is erratic and doesn't always result in the volume being (or being read as) 1 less than the requested volume.