Closed GoogleCodeExporter closed 8 years ago
Can you provide details about what the Media Control "Pause" and "Toggle Pause"
actions do in Tasker? This doesn't seem to be documented where I could easily
identify. I'm not aware of any generic interface for this except for BlueTooth
(which is a separate issue in the tracker), and the Tasker FAQ suggests that
this may be a hack: http://tasker.dinglisch.net/faq-why.html#e. The developer
page (http://tasker.dinglisch.net/developers.html) also suggests that Tasker
needs to know more about the app to handle this (forth bullet point at the top).
Original comment by jeremy.w...@gmail.com
on 15 Jun 2011 at 9:41
Below is what I got from Pent at Tasker, plus my reply. Hope this helps.
Regards, Greg
Thanks, I'll pass this along to the NPR folks.
You said "skipping it if it looks like nothing is playing." Based on my
experience when nothing is playing, it appears Tasker thinks the native
media player is playing all the time. How else to explain that after my
task that reads text messages reads the message, the next instruction cranks
up the native player?
Here is my task:
1) If %INTHECAR ~ yes
2) Media Control *Cmd* Pause *Simulate Media Button* On
3) Say *Text* %SMSRF SENT THIS MESAGE: %SMSRB
4) Media Control *Cmd* Toggle Pause *Simulate Media Button* On
5) End If
I had yanked out the Toggle Pause and was resigned to restarting Pandora
(what I listen to most) manually. I added back in this morning and the
native player did not start up after the incoming message was read. I then
did a couple of quick experiments.
The above behavior holds only if the player has not been invoked since
bootup or last execution of Pandora. i.e Play track on native player, then
pause. Player resumes after text is read. Start Pandora, then quit.
Player does not resume after text is read. If I merely force stop the
native player, the "Music" application, it resumes after text is read.
Same result if a go a little "deeper" and kill the "MediaPlaybackService".
So the system must preserve the native player as the current AUDIO_SERVICE
even after it is killed. Maybe when Pandora exits, it nulls out
AUDIO_SERVICE? Since the native player does not have an explicit "Quit"
function like Pandora, there is no mechanism for nulling AUDIO_SERVICE, so
native player appears active even if killed until another app sets itself as
AUDIO_SERVICE.
Now how about something strange. I started up NPR just to be sure it still
plays right through the text message. It does. However, if the last
"media" thing that had been done before NPR was to manually pause the native
player, the Pause (step 2) seems to start up the native player so all three
streams (native, NPR, text message) are playing at the same time. The
native player then pauses in response to the Toggle Pause command. This
behavior holds whether the native player is paused before or during NPR
play. This is not a real-word problem for me, just a curiosity, but can you
explain it?
Bottom line is that
1) my issues with native player resuming result from it appearing as active
AUDIO_SERVICE even if killed. I'm sure I can figure out a way to work
around this.
2) I suspect that NPR is not following "media rules" like setting
AUDIO_SERVICE or observing the MediaControls.
Regards, Greg
- Hide quoted text -
Original comment by gva...@gmail.com
on 20 Jun 2011 at 7:26
Thanks, Greg.
I got another note from a Droid X user saying the following:
"But...here is my problem, which I don't think is normal. Sometimes when I hit
pause, the icon immediately disappears and the sound stops. Other times when I
pause the NPR program, the icon remains in my menu bar, or icon bar, or
whatever the top line is called that shows what is running on the phone, even
though what I am listening to stops. Either way, exactly 10 minutes later NPR
starts up again on its own, almost like a "snooze" button. The only thing I can
do to get it to not come back on is to use the "Advanced Task Killer" app to
"kill" everything running"
I've explained task killers can be detrimental, but I think Greg might be
correct is thinking there is something odd about how we are shutting down the
audio service. I'm going to rename the bug to better track this issue as I see
it. Perhaps we need to build in a hard kill after 5 minutes of being paused?
Any other ideas?
Original comment by jpenn...@gmail.com
on 22 Jun 2011 at 2:52
Should be improved in version 2.1.
Original comment by jpenn...@gmail.com
on 1 Sep 2011 at 7:59
Original issue reported on code.google.com by
gva...@gmail.com
on 31 May 2011 at 2:00