DoggCatcher (podcatcher) ideas for enhancement

[eric.doggcatcher]

I just tested on my nexus one headset and I'm getting 3 distinct signals for next/prev/playpause. There are four electrical contacts on my nexus one headset, but if your headset looks like this, then having just 3 may be the reason that the only signal the android is receiving is playpause (that's just one signal).

Amazon.com: JBuds J3M Micro Atomic In-Ear Earphones with Microphone (Jet Black, iPhone Compatible)

Hi Eric. I just did a number of tests of the headset button on my motorola cliq, and sent you the logs, and a followup explanatory note as to my test procedure, as you requested.

In net, the behavior I saw seems to be just a simple toggle on the playback, from the play state to the stopped state, and vice versa, with each press of the headset button.

I look forward to learning what you learn from the logs.

 

[MB200]

First off, thanks very much for working on this Eric, looking over my logs, etc. I really appreciate it.

Second, the picture that shows at the Amazon link below for JBuds J3M is strange. IT definitely has only three electrical contacts on the plug (I assume this is a TRS then). However, MY Jbuds J3M's have four electrical contacts (thus, I presume it is a TRRS jack). So that is weird. I'm guessing the Amazon ad has the wrong photo somehow.

I just tested on my nexus one headset and I'm getting 3 distinct signals for next/prev/playpause. There are four electrical contacts on my nexus one headset, but if your headset looks like this, then having just 3 may be the reason that the only signal the android is receiving is playpause (that's just one signal).

Amazon.com: JBuds J3M Micro Atomic In-Ear Earphones with Microphone (Jet Black, iPhone Compatible)

Third, regarding your earlier note (on 23 Feb), I would be happy to do any additional tests, and send you logs, if you need more data on how the J3M button interacts with Android via the button on the earbud cable.

Fourth, your idea to detect the button presses, and decode single-, double-, or triple- based on elapsed time between them seems like a good one.

(from eric.doggcatcher on 23 Feb 2010)
Still looking at it At first glance it's seems that your headset is sending the same signal to android, regardless of how you press the button (single/dbl/triple), so I don't understand how the documentation you have matches what I am seeing.

I have a wired headset that came with my nexus one that has next/prev buttons on it. I need to do some more testing to see how the events the my headset is sending differs from yours.

From your logs, it looks like the only way that a device could do a prev/next is to interpret the delay between the button presses. I'm not sure about this but this is yet, but I'll know more once I compare to my headset.
​

 

[JLab Audio]

Hello,

First let me thank MB200 for giving me a call this morning and letting me know about this discussion. My name is Matt, and I am the Brand Ambassador for JLab Audio. It was brought to our attention that there is an error in the photo of the J3M jack on Amazon's website. This was an oversight on our end and we do appreciate it being brought to our attention.

The J3M does have a TRRS connector, the picture on Amazon is incorrect. The picture on Amazon is the J3 jack with the mic added in. We are working on getting a correct image and will be submitting it to Amazon soon.

Again, thank you for pointing out this error, and please do not hesitate to contact us for any assistance.

Warm Regards,
Matt
Team JLab

 

[MB200]

Good work JLab Audio! I just clicked the Amazon link again and see they now have the correct photo.

Eric -- what do you think about the idea of DoggCatcher software receiving those button clicks (1, 2 or 3 quick presses, or maybe a long press if that is detectable) and then doing some user-configurable action with that input? Let me know if you want any test logs captured on my end.

Hello,

First let me thank MB200 for giving me a call this morning and letting me know about this discussion. My name is Matt, and I am the Brand Ambassador for JLab Audio. It was brought to our attention that there is an error in the photo of the J3M jack on Amazon's website. This was an oversight on our end and we do appreciate it being brought to our attention.

The J3M does have a TRRS connector, the picture on Amazon is incorrect. The picture on Amazon is the J3 jack with the mic added in. We are working on getting a correct image and will be submitting it to Amazon soon.

Again, thank you for pointing out this error, and please do not hesitate to contact us for any assistance.

Warm Regards,
Matt
Team JLab

 

[jbarrett020]

one thing that really drives me crazy is when i am searching for podcasts, in the most popular or recommended, and when i try to page down i almost always add a feed. need a confirmation pop up when adding feed, i think, when browsing the feed lists.

also would love to be able to move items up and down in the listening queue.

 

[eric.doggcatcher]

Which version are you running? Older versions added the feed when you pressed on the row but for a while now, there's a separate button to add the feed.

one thing that really drives me crazy is when i am searching for podcasts, in the most popular or recommended, and when i try to page down i almost always add a feed. need a confirmation pop up when adding feed, i think, when browsing the feed lists.

also would love to be able to move items up and down in the listening queue.

 

[eric.doggcatcher]

The good folks over at JLab Audio have generously sent me a complimentary headset. It's on its way now, I'll report back once it arrives and I get a chance to experiment with it a bit.

Good work JLab Audio! I just clicked the Amazon link again and see they now have the correct photo.

Eric -- what do you think about the idea of DoggCatcher software receiving those button clicks (1, 2 or 3 quick presses, or maybe a long press if that is detectable) and then doing some user-configurable action with that input? Let me know if you want any test logs captured on my end.

 

[MB200]

That's great Eric. Then I'm sure I won't need to collect any logs for you.

Let me know what you find out when you test the one JLab is sending your way, and then let me know what you think about my idea of DC potentially detecting several variations of button-presses from that input device and DC allowing user-configurable actions for each of them.

The good folks over at JLab Audio have generously sent me a complimentary headset. It's on its way now, I'll report back once it arrives and I get a chance to experiment with it a bit.

 

[MB200]

Hi Eric. Did you ever get a chance to test the Jlab Audio J3M earbud headset to see how the cord switch operation is picked up by Android, and by extension, how DoggCatcher can use it?

The good folks over at JLab Audio have generously sent me a complimentary headset. It's on its way now, I'll report back once it arrives and I get a chance to experiment with it a bit.

 

[amozarte]

First off, I just picked up DoggCatcher before the weekend and have been loading up my feeds and tinkering with it on my Motorola Droid for the last few days. Overall I'm pretty pleased and think it's a great app. Solid work!

That said, I have a few small gripes/suggestions...

Having used FeedR for the last few months I immediately noticed some features missing from DC. I hope that these are easy to add, because they would surely make DC as perfect as any app could be. If these are already features and I'm being daft, please excuse me- as I said I've only been using the apps for a couple of days.

*Share Articles

FeedR has a "share" button that allows you to quickly send an article to your Facebook page, Twitter feed, via SMS, or Email. I find this very useful for sharing news I think my friends would be interested in.


*Hide Read Articles

FeedR gives you the option to "hide" any articles you've already read. The green/blue colour coding DC uses for read vs unread is nice, but some of my feeds post 30-40 articles a day. I want to leave the feed set to "capture" all of them, but once I've read an article I'd prefer that they disappear to reduce clutter. If you add this feature I'd also ask that you include the "star" feature of FeedR, which allows you to flag individual articles as exempt from hiding.


Again, thanks for creating a great podcatcher!

 

[eric.doggcatcher]

I did look into this. The android framework is only detecting the button presses as play/pause. Even when I press the buttons repeatedly quickly or hold them down for a while, it looks the same to android. The other headset I tested (nexus one) was detected as distinct events (play/pause, next, prev).

Hi Eric. Did you ever get a chance to test the Jlab Audio J3M earbud headset to see how the cord switch operation is picked up by Android, and by extension, how DoggCatcher can use it?

 

[eric.doggcatcher]

Thank for posting your suggestions. I do have issues for both of these (below).

For the hiding of done items, is this something you would want to set globally for all feeds or something specific to a feed. I was thinking that it was feed specific but I just want to see what you think makes the most sense.

0000387: Hide done items - Mantis
0000181: Ability to share items - Mantis

First off, I just picked up DoggCatcher before the weekend and have been loading up my feeds and tinkering with it on my Motorola Droid for the last few days. Overall I'm pretty pleased and think it's a great app. Solid work!

That said, I have a few small gripes/suggestions...

Having used FeedR for the last few months I immediately noticed some features missing from DC. I hope that these are easy to add, because they would surely make DC as perfect as any app could be. If these are already features and I'm being daft, please excuse me- as I said I've only been using the apps for a couple of days.

*Share Articles

FeedR has a "share" button that allows you to quickly send an article to your Facebook page, Twitter feed, via SMS, or Email. I find this very useful for sharing news I think my friends would be interested in.


*Hide Read Articles

FeedR gives you the option to "hide" any articles you've already read. The green/blue colour coding DC uses for read vs unread is nice, but some of my feeds post 30-40 articles a day. I want to leave the feed set to "capture" all of them, but once I've read an article I'd prefer that they disappear to reduce clutter. If you add this feature I'd also ask that you include the "star" feature of FeedR, which allows you to flag individual articles as exempt from hiding.


Again, thanks for creating a great podcatcher!

 

[MB200]

Thanks very much Eric for looking into this. I will contact the good folks at Jlab and see if they know why the difference in detection by Android between their headset and the Nexus One headset you tested.

I did look into this. The android framework is only detecting the button presses as play/pause. Even when I press the buttons repeatedly quickly or hold them down for a while, it looks the same to android. The other headset I tested (nexus one) was detected as distinct events (play/pause, next, prev).

 

[eric.doggcatcher]

I've just fixed both of these. They will be included in the release after next.

For the first issue, I created a preference to configure whether it jumps to the oldest item or not.
For the second, there was no good reason for this, it's a bug. It now returns to the position of the item that you viewed last...so if you arrow up a bunch while viewing news items, when you press back, the list will jump to the one you last viewed.

Thanks for the feedback.

I love this app and just recently promoted it to my home screen apps, as I pull it up many times daily. My biggest problem with it right now is that after one of the more recent updates (last month or two), when I go to open a feed, the screen jumps to the bottom of the feed and then I have to scroll up to the top of the feed to check out the newest stuff. What's worse is when you read an article and go back, it's back at the bottom again, which is particularly annoying if you have a lot of items set to load by default. I assume this was done for a reason, but I don't really know why. My request is that we have the option to choose whether the display position of a feed starts at the top (or bottom) of the list and that the app remembers our screen position when we go back.

 

[MB200]

Eric -- I have contacted JLab to ask them to look into why the switch functions so differently between the J3M and the Nexus One headset you tested. More specifically, why does Android interpret the Nexus One with more levels of function than the J3M?

 

[MB200]

I got the following info from Eric at DoggCatcher recently. Thought I should put it into the forum so others can benefit from it as well.

Eric: "Yep, they [(the J3M and the Nexus One headsets tested by DoggCatcher labs)] are both using the same [TRRS] connector, but the signal that is detected by the android device is play/pause regardless of how long or how many times you press the button on the jlabs. My guess is that the same electrical signal is transmitted each time you press the button (and no matter how you press it).

"With the nexus one headset, the device detects unique types of button presses depending on whether play/pause, rew, ff is pressed. That headset must transmit unique signals depending on which button is pressed."