Hello,
I just downloaded DoggCatcher. I have a BT3030 bluetooth headset... when I hit a skip button, DC fast-forwards.
How can I make it _skip_? Long-pressing the buttons on this bluetooth headset does not do anything. (skip works fine in the native android music app)
Thanks!
-denis
I've got a BT3030 also. I actually used it almost exclusively during development of the bluetooth capabilities.
It seems that with bluetooth, there isn't any notion of long pressing. To an android app, it just looks like a lot of single presses really close together. The problem is that each bluetooth device looks differently (different spacing between the presses). I tried to simulate a long-press with the BT3030 but couldn't get it working.
I may take another stab at it. I mainly wanted to get the bluetooth basics out and stable, then out would try to push the boundaries. Another option would be to have configurable actions to take when you single press the buttons.
Hi Eric. Thanks - how about double-pressing to skip? Android headsets do this sort of thing - single button for play/stop vs next. Maybe here you can do single press to fast-forward, vs double to skip?
Double presses are possible to detect with the wired headset but with bluetooth, each device seems to behave differently. I'm not sure I'd be able to come up with something that will work for all of them but I'll take a look.
ok. if all else fails, here is another suggestion :)
- if the feed is paused, ff skips
- if the feed is playing, ff fast forwards
unless this is how it works now (i don't have my headset handy, so i can't check)
still find myself really wishing for a way to skip. maybe:
- if stopped, skip to next, else skip by N minutes
- if I press skip 3 times within 3 seconds (or something along these lines) skip to the end
Yep, I moved the issue to soon.
That's interesting, I'll take a look and see how well that works. I updated this issue with a reference to this post and moved the issue to soon.
http://mantis.snoggdoggler.com/view.php?id=68
Hi Eric,
I am a big fan. I think that skip and FFWD are two different AVRCP codes. The BT3030 that you use for testing only supports the skip message. And this skip command is currently wired up as FFWD in DoggCatcher.
When I use a Nexus One, Jabra Cruiser (car speaker) and the Android Media Player, tapping forward goes to the next track and holding it down for a second fast forwards within the song (as expected). When I switch to Doggcatcher, tapping forward should skip, but instead fast forwards. And holding down forward should fast forward, but nothing happens.
So I think it is the bluetooth device that detects short vs. long presses and sends a different AVRCP code for skip or FFWD. Hopefully the fix is just to implement the missing AVRCP message. See links below.
Thanks,
-HP
---------------
AVRCP spec - page 37 lists "fast forward" vs. "Forward" as two different codes
http://www.bluetooth.com/SiteCollectionDocuments/AVRCP_SPEC_V14.pdf
BT3030 - described as only supporting "next track" function (i.e. forward/skip)
http://www.jabra.com/sites/Jabra/GNImages/Products/WirelessHeadset/BT303...
BT3030 users referencing the fact that it only supports "skip"
http://forum.xda-developers.com/showthread.php?t=352497
Jabra Cruiser manual - page 4 describes the difference in tap vs. press - although not in the context of music playback. But it is clear that the speakerphone is the one detecting the length of the button press and taking a different action based on that - e.g. redialing the last number dialed or sending a different AVRCP code.
http://www.jabra.com/sites/Jabra/GNImages/Products/CRUISER_Manual_8178.pdf
There is an inconsistency between DC and the music player with regards to skip and ff. DC does ff when you press the next button on the bt3030. The reason for that is that most bluetooth devices have prev/next buttons instead of rew/ff buttons, but when listening to podcasts, it's much more common to rew/ff. When listening to music, prev/next is used more often. So I have the buttons that are most common to the functions that are most common...even though the buttons don't match what they are doing.
One of the issues, is that the avcrp codes don't make it directly to the app. Android passes along some events to the apps, which don't always seem to match avcrp codes.
I think what really needs to be done is for DC to be able to detect all of the individual events that android can send to the app, then let the user configure which action should happen when the event is received.
I created an issue for this and scheduled it for the release after next. I'm probably only going to do some analysis at this point so I know what's involved. Then I'll schedule the implementation.
http://mantis.snoggdoggler.com/view.php?id=579
Btw, I think the android music player is handling the long-press and sending a different command to the player. At least that what I remember when I reviewed the music player code last. But long presses could also be added to the list of 'detectable events' I mentioned earlier.
Thanks for all the research.
So what I found is that android supports responding to ff/rew and next/prev, *but* I can't seem to find any *devices* either wired or bluetooth that support ff/rew. Whatever I can find supports only next/prev.
If anyone is aware of a device (wired or bt) that supports ff/rew, please let me know so I can pick one up.
I still think it's the right thing to do to keep the next/prev buttons on the wired and bt devices doing rew/ff for podcasts. What I plan on doing is making a long-press on the next button do the same thing as what happens when you long-press on the next button in the ui...flag the current item as done and play the next.
This gives us access to all the capabilities of the wired/bt headsets...even though the next/prev buttons are mapped to ff/rew functions.
>If anyone is aware of a device
>(wired or bt) that supports ff/rew,
> please let me know so I can pick one up.
The Jabra Cruiser (car speakerphone) supports next/prev and ff/rew. This works well with the Android Music player.
http://www.amazon.com/Jabra-Cruiser-Bluetooth-Car-Speakerphone/dp/B002PY...
Thanks, I just ordered it.
I read a review (I think on cnet) and it only mentioned next/prev for the cruiser.
Eric,
While you are trying to figure out the right way to fix this, maybe you can add an additional choice to the "Skip Seconds" option...
It would be great if you add "skip to next podcast" after the 300 sec option... Then, the event from the Bluetooth device is the same and people who prefers skip/prev can get what is desired.
Thanks!!!
I'm pretty sure that what I'm going to do is have a list of the button events (ff, rew, ff-long, rew-long, play/pause, etc) and then for each event you can choose the action to perform (ff, rew, next). That should cover all the different devices with different buttons and capabilities.
Hi Eric - any news on this skip? It'd be really useful to have it at least as this option.
Btw, other questions came up about next vs play/pause (outside of doggcatcher), and apparently these things are very much hardware-dependent (for instance, some headsets will interpret double-press as next, and some will send two presses).
Option sounds like the best option at this stage.
Perhaps even per-podcast option (imagine 1 hr long podcast where you do want to skip around, vs a bunch of short podcasts where you want to jump to next one). You could maybe have it as one global option and a bunch of overrides per-podcasts (you already do this with a number of settings)
Thanks!
I'm pretty sure the way it will go is for you to be able to configure which action (play/ff/skip) you want to occur with each of the types of events.
I can't say for sure when it will happen though, there are still a few other things in the releases prior to the batch of soon stuff. I would like to see it soon though because it has been a pretty common request and it's important being able to interact properly with your hardware.
Did this get resolved?
I just installed Doggcatcher and I cannot see anyway to skip track to the next podcast with AVRCP steering wheel controls on my car to my EVO 4G with the latest HTC and Sprint software, so I set the Skip Seconds to 300 seconds to try to speed through to the next podcast when I want to skip.
I tried long press and double tapping and it doesn't work for me.
Long-pressing is what currently works for most people but depending on the device, it may not. It works for my car head unit but not all the devices I've tested. The problem is that different devices send different signals so I haven't figure out a way to be able to respond to them all.
You could try doing a long-press, then a dbl press from your car, and then send me the log. I'll see what bluetooth commands are being sent if any.
I just sent the log after trying long presses, short presses and double short presses.
The short press fast forwards the specified number of seconds. I can't get long press to do anything and double press just fast forwards the same amount twice.
I just checked out your log (sorry for the delay).
In order to detect a long press, DC needs to compare the time difference between the DOWN and UP press on the buttons.
One of my test devices sends the down and up events as soon as you press down and then when you release the button, it doesn't send any events. It looks like that's what's happening with you. In that case, there isn't enough time difference between the up/down to detect a long press.
There isn't any handling in DC for double presses. It's pretty likely that down the road, I'll add that. It should also be in a way that you can configure what you want to happen with the dbl press, like skip in your case.
Eric,
I read this sentence and got excited:
"I think what really needs to be done is for DC to be able to detect all of the individual events that android can send to the app, then let the user configure which action should happen when the event is received."
then realized how old this topic is and that it wasn't implemented.
When running or driving I use a bluetooth headset that sends a AVRCP "next track" event which DC interprets as "fast forward". Since I am running or drive I don't want to have to mess with the playlist when that button and function exists on the bluetooth headset.
I would really like to be able to skip to the next track in the playlist, without marking it as done. This is argueably valid in both autoplay on or off modes, because it is a user-initiated function.
I really like the idea you put forward about letting the users define the actions. Then I can set 'skip' to the next track, or 'rewind' a few seconds to listen to something I missed. If I skip forwards, since I didn't listen to the podcast to the end, it shouldn't mark it as 'done'.
It hasn't been done, but it I still think that's the best way to handle it. Any other way will make it tough to satisfy all the individual needs.
hi Eric - any news on this by chance?
I don't have a firm timeline but it shouldn't be too far off. The logitech revue which is getting the market app soon has all audio buttons are pretty hard to work with using dc since we changed the prev/skip buttons to do rew/ff behavior. That makes it pretty awkward.
Hi Eric - any news? Perhaps you could skip to the end if you detect two or three fast-forwards within some time? I find that I skip to the end of podcast much more often than I skip around in the podcast, but I can see the need for both. Detecting multiple presses would satisfy both of these and hopefully be hardware independent.
I still haven't started working on this. Recently I have been primarily focused on fixing all the crashing bugs that existed and some things to make it easier for new users to learn to use the app. Once I wrap up the last of the crashing/usability stuff, I'll be moving on to new features like this. Sorry for the long delay.
Ping? :-) I still want this. Please.