v4.1u3: %VOLM Variable Value State context not firing after Media Volume action

[Alex Peters]

For testing purposes I have a "Variable Value %VOLM == 1" profile that triggers these actions:

1. flash "\%VOLM is 1; setting to zero"
2. wait 2 seconds
3. Media Volume 0, display: yes
4. flash "\%VOLM is now %VOLM"

This profile works entirely as expected--manually setting media volume to 1 causes the first flash to appear, then two seconds later the Android media volume pop-up shows a media volume of 0 and Tasker flashes "%VOLM is now 0."

I also have a "Variable Value %VOLM == 0" context profile that triggers only this action:

• flash "yes, \%VOLM really is zero"
  

I expect this profile to activate immediately after the first profile's task completes, but this is not the case.

Additionally, Tasker's UI shows the first profile as active and the second as inactive even after the media volume is zeroed.

It appears that %VOLM is being set correctly by the Media Volume action, but not in the necessary way to cause relevant State contexts to see the change in value.

For what it's worth, changing the "Variable Value ==" contexts to "Variable Value ~" contexts had no different effect.

Also, both profiles have their "restore settings on exit" setting disabled.

[Alex Peters]

I should also add that turning the screen off and on causes the contexts to work correctly, as does manually changing the ringer volume.

[Brandon Horwath]

What are you trying to accomplish?

If it is setting your phone to silent, that's not the suggested way.

[Pent]

It doesn't respond to changes immediately after it's changed the volume to avoid getting into fights with
other volume controlling apps and/or loops.

Or something like that, I didn't check the code.

Pent

[Alex Peters]

Brandon, I have a task that ramps music down slowly to zero, then a profile intended to detect when the music has been zeroed.  I could theoretically combine the two into one task but decided not to, specifically because I want as much of the logic in profile contexts as possible.

Pent, is there a way to circumvent this behaviour?

Failing that, what are the chances of this behaviour being removed?

I understand that it's in place to prevent people from shooting themselves in the foot, but:

1. it prevents legitimate uses; and
2. I'd argue that if two profiles interfere with each other, they're wrong and need fixing by the user who wrote them; and
3. two profiles with "Restore Settings" enabled can cause this problem anyway.

[Pent]

Pent, is there a way to circumvent this behaviour?

You can't, it's pretty standard behaviour for apps changing volume.

Failing that, what are the chances of this behaviour being removed?

None at this time, it would create horrible loops for people who are (not knowingly) relying on it ATM,
e.g. for volume locking: 'event volume changed -> task set volume to x'

Pent

[Brandon Horwath]

How about, instead of moving to volume zero, moving to mode: silent on?