Music Player no longer plays

[sdemills]

The standard Music Player App no longer plays whilst the MWM Service is running.

If the service is already running when the Music Player is started then the track remains paused. The MW Music Controls show the headphones icon and pressing the watch Play button has no impact.

If instead of manually launching the Music Player the new menu item to launch the Music Player is pressed then the Music Player does launch ok but still remains paused.

If the service is not already running when the Music Player is started then the Music Player works properly as normal. If however the MWM Service is started whilst a track is playing then the Music Player immediately enters Pause mode.

This fault was also in the previous build. I upgraded to the current build before reporting it just in case it was fixed in this latest build, but unfortunately it is not.

I'm running on Galaxy GS2 with ICS.

As I have no other way of contacting you, I would like to take this opportunity to praise the excellent work you have been doing with MWM - it is rapidly becoming a powerful and feature-rich App. Thank you for that.

[benjymous]

Thanks for reporting this - did it work fine with an earlier build? I might be able to track down what's changed to cause that behaviour.

[ You can contact me on the metawatch forums - there are discussion threads there: http://www.metawatch.org/forums/board/19/remote-application-development ) or at @benjymous on Twitter :) ]

[sdemills]

Yes it did. I have frozen copies of the Apk files from the earlier builds.
First thing tomorrow I'll find out which one works and let you know.

Kind Regards
Steve
Sent from my Galaxy GS2
On Jul 11, 2012 9:58 PM, "benjymous" <
[email protected]>
wrote:

Thanks for reporting this - did it work fine with an earlier build? I
might be able to track down what's changed to cause that behaviour.

[ You can contact me on the metawatch forums - there are discussion
threads there:
http://www.metawatch.org/forums/board/19/remote-application-development )
or at @benjymous on Twitter :) ]

---

Reply to this email directly or view it on GitHub:
#41 (comment)

[sdemills]

Well you'll probably find this hard to figure but you're the expert and I
the novice...

I reinstalled 0.2.4.rm15 and the player works fine.

Then I reinstalled latest 0.2.4.rm16 and the player still works.

Beats me.

Kind Regards
Steve
Sent from my Galaxy GS2
On Jul 11, 2012 10:48 PM, "Steve Mills" [email protected] wrote:

Yes it did. I have frozen copies of the Apk files from the earlier
builds. First thing tomorrow I'll find out which one works and let you
know.

Kind Regards
Steve
Sent from my Galaxy GS2
On Jul 11, 2012 9:58 PM, "benjymous" <
[email protected]>
wrote:

Thanks for reporting this - did it work fine with an earlier build? I
might be able to track down what's changed to cause that behaviour.

[ You can contact me on the metawatch forums - there are discussion
threads there:
http://www.metawatch.org/forums/board/19/remote-application-development) or at @benjymous on Twitter :) ]

---

Reply to this email directly or view it on GitHub:

#41 (comment)

[sdemills]

Well - forget the last email (in part)...

I disabled Tasker so that as far as possible there is nothing else to muddy
the scene, then I rebooted and ran the installation of v0.2.4.rm15. The
outcome...

(1) v0.2.4.rm15 works fine with the standard Media Player, I then ran the
latest install...

(2) v0.2.4.rm16 does not work with the standard Media Player.

Kind Regards
Steve
Sent by ASUS Transformer Prime
On Jul 11, 2012 11:04 PM, "Steve Mills" [email protected] wrote:

Well you'll probably find this hard to figure but you're the expert and I
the novice...

I reinstalled 0.2.4.rm15 and the player works fine.

Then I reinstalled latest 0.2.4.rm16 and the player still works.

Beats me.

Kind Regards
Steve
Sent from my Galaxy GS2
On Jul 11, 2012 10:48 PM, "Steve Mills" [email protected] wrote:

Yes it did. I have frozen copies of the Apk files from the earlier
builds. First thing tomorrow I'll find out which one works and let you
know.

Kind Regards
Steve
Sent from my Galaxy GS2
On Jul 11, 2012 9:58 PM, "benjymous" <
[email protected]>
wrote:

Thanks for reporting this - did it work fine with an earlier build? I
might be able to track down what's changed to cause that behaviour.

[ You can contact me on the metawatch forums - there are discussion
threads there:
http://www.metawatch.org/forums/board/19/remote-application-development) or at @benjymous on Twitter :) ]

---

Reply to this email directly or view it on GitHub:

#41 (comment)

[sdemills]

Here's a clue - it is being caused by the Auto SpeakerPhone option. If I turn that off then all is well.

[benjymous]

Aha, so, for some reason MWM thinks a call has started or ended. Very peculiar.

Does disabling that "fix" #43 too?

[sdemills]

In CallStateListener, when state IDLE the previousSpeakerPhoneState is restored. However it is never captured anywhere, and is initialised as false. That is the cause of the problem.

Unfortunately my understanding at this point is not sufficient to fix it.

[sdemills]

Yes it does fix #43 too.

[benjymous]

I'm away from home at the moment, so can't try this myself, but you could try adding a static currentCallState var to the CallStateListener class, defaulted to IDLE, then just return from the top of onCallStateChanged if the state hasn't actually changed.

[sdemills]

I'll give that a go soon.

In the meantime I'm already in the midst of trying the following:-

• Several actions in CallStateListener manipulate properties of Call, so
  I moved those actions into Call.java in Call.startRinging and
  Call.endRinging.
• MediaControl - added a getSpeakerphoneState() function
• Call.startRinging detects if going from idle to ringing and then (if
  the option is set) uses getSpeakerPhoneState to pick up the current state
  and put it into Call.previousSpeakerphoneState
• Call.endRinging detects if going from inCall to idle and (if the
  option is set) restores the previousSpeakerPhoneState.

Exported to the phone and did some partially successful tests. I've been
out most of the day and now, having returned, I see that the final Save of
Call.java wasn't done before I did the export so I guess I need to redo the
export and re-test everything.

I also noticed that one of the watch menus that I haven't used before
allows to switch the speakerphoneState from the watch menu but when I
searched the project I didn't see anything else manipulating the
speakerphoneState so I guess I need to check again and confirm that.

Will keep you posted.

On 14 July 2012 15:52, benjymous <
[email protected]

wrote:

I'm away from home at the moment, so can't try this myself, but you could
try adding a static currentCallState var to the CallStateListener class,
defaulted to IDLE, then just return from the top of onCallStateChanged if
the state hasn't actually changed.

---

Reply to this email directly or view it on GitHub:
#41 (comment)

[benjymous]

Should be fixed by the above commit (release 1.17.1)