Additional Control to Bluetooth Device

8 replies [Last post]
elfofelm
Offline
Joined: 07/28/2010

First of all, thanks for the great app. I just moved from Google Listen and your app is a lot more stable.

Current control options with Bluetooth are: "DoggCatcher supports play, pause, fast forward, and rewind for Android connected headsets"

Sometimes, I am not in the mood to listen to a particular podcast and I'd like to skip to next podcast until I find the one I am interested, just like skipping to a next song. At the same time, I rarely fast forward to 10 sec or 30 sec...

So, it would be great, if you could add "skip to next podcast" to the skip second option or something like long press triggering the skip.

Thanks!

eric
Offline
Joined: 11/06/2008
Skip to next

That's already done and will hit the market on friday - http://mantis.snoggdoggler.com/view.php?id=579

It works pretty well with wired headsets and some bluetooth devices. With the bluetooth, it really depends on the timing of the signals and how it handles long presses.

elfofelm
Offline
Joined: 07/28/2010
Awesome! Thanks!

Eric,

Thanks so much! I will look forward to it!

lorenzolio
Offline
Joined: 08/27/2010
Doesn't work so hot on all headsets

I'm running Doggcatcher v 1.1.1517
My bluetooth headset is a Rocketfish RF-MAB2. According to its manual it supports both skipping to next song and fast forwarding. It says
Select a song: Press and release << or >>
Rewind or fast forward a song: While music is playing press and hold << or >> (Some phones may not support this feature)

I just quote the manual to show that it's set to send different signals for a short press and a long press.

However the real problem I have is for short press. This is what I'm experiencing in DoggCather for a _short_ press:
Pressing << skips back a few seconds
Pressing >> fast forwards a few seconds and THEN immedately skips to the next podcast.

So unfortunately I fear the behaviour you put in for this issue 579 linked above doesn't work for my headset. I would make a guess that for this headset you are interpreting the signals from a short press as a long press. Like you said, it depends on the timing of the signals. Is there room for adjustment? Maybe add a few miliseconds before deciding it was a long press?

I wouldn't have even taken the time to describe it, except that the placement of the buttons on the headset make it really easy to press >> accidentally. You can imagine how frustrating it is to be half way through your hour-long podcast and have it skip accidentally to the end.

eric
Offline
Joined: 11/06/2008
Button presses

Android doesn't distinguish between long and short presses. What the app gets is a notification of which button, when it was pressed and when it was released. So DC is doing the calculation of the duration. DC is seeing getting a significant difference between the press and release time for your device. I could change it but it would likely break for other devices.

What will probably happen first is this - http://mantis.snoggdoggler.com/view.php?id=68

If you read the thread that's linked in the issue, there's description of how I'm going to do it...something like a list of all the events that can occur, and you can pick which action you want to occur. So in your case, you would assign long-prev to rew, and long-next to ff. You'd be stuck doing next though. So I guess in that case you'd need a configurable long-press. I created an issue for this - http://mantis.snoggdoggler.com/view.php?id=629

lorenzolio
Offline
Joined: 08/27/2010
Button presses

Thanks for taking the time to address this.
There is still something that bugs me between what you're describing and what I am seeing.
You say android notifies the app when button is pressed down and then when it is released.
However what I see in DC for my long press is a FF and then then a skip. That sounds like four events to me: down up down up.

eric
Offline
Joined: 11/06/2008
FF/Skip

Where are you seeing a ff and a skip?

lorenzolio
Offline
Joined: 08/27/2010
FF followed by skip

I see it on the seek bar.
Lets say I'm 1:30 into a podcast, and I do one short press of my headset FF button. I see the seek bar jump to 1:40 or 1:41, then a split second later it skips to the next podcast in the playlist. Actually sometimes it does it so fast I don't even see the 1:40.

eric
Offline
Joined: 11/06/2008
Down then up

So I'm pretty sure what's happening is that when you press, DC is registering a FF on the down press and then a skip on the release.

I think the only way around the problem is to handle all the events on the release but that's gonna feel a bit weird. I'll need to play with this to see if it'll work.

Thanks for letting me know about this.