DoggCatcher (podcatcher) ideas for enhancement

[MB200]

In another post on Android forums, one of the DoggCatcher developers has been monitoring the forum for ideas for enhancement, and requested Android forums' users share ideas for feature enhancements of their Android podcatcher application.

I'm starting this post to be a place to capture DoggCatcher-specific requests for enhancement of the app. (DoggCatcher does have their own online forum, but I'm starting this thread for those Android users who don't want to maintain an online account and id/password to a forum for each app downloaded onto our Android device.)

Please be sure you try to write a decent Title for each future request post you start. That will make it easier to discuss amongst other users and help ensure we are all on the same page when discussing a potential feature.

 

[MB200]

I wonder if DoggCatcher would consider making the playback slider bar, the red bar on the playback screen that shows how much time has elapsed in podcast playback, more stable so the podcast won't jump to an unintended part of the playback by an inadvertant touch on the screen. For example, making a long touch be necessary, like you already do for the "done" button that is in the lower right corner of the playback screen, would probably solve the problem.

Importantly, once you touch the screen and thus get to the wrong part of the playback (say, finding oneself at minute 45 rather than where one was near the beginning of the podcast), it becomes almost impossible to get back to where you were. There might be some other ideas for working on this problem too (say, an "undo" button???) But I think the first idea of requiring a long press to move the slider bar is better.

 

[eric.doggcatcher]

That's happened to me too. I had a request to disable the seekbar, maybe you should have a choice disable/press/longpress to control how you want it to behave.

I updated my issue for this - 0000272: Ability to disable the seekbar - Mantis

I wonder if DoggCatcher would consider making the playback slider bar, the red bar on the playback screen that shows how much time has elapsed in podcast playback, more stable so the podcast won't jump to an unintended part of the playback by an inadvertant touch on the screen. For example, making a long touch be necessary, like you already do for the "done" button that is in the lower right corner of the playback screen, would probably solve the problem.

Importantly, once you touch the screen and thus get to the wrong part of the playback (say, finding oneself at minute 45 rather than where one was near the beginning of the podcast), it becomes almost impossible to get back to where you were. There might be some other ideas for working on this problem too (say, an "undo" button???) But I think the first idea of requiring a long press to move the slider bar is better.

 

[MB200]

Eric -- I like your idea. Configurable "disable/press/longpress" would be a great software engineering implementation that would get the desired effect for the user interface problem I described.

 

[MB200]

Would it be possible to enable a user-configurable setting that would allow one to utilize the external buttons on an Android smartphone to have software configured functionality?

For example, on my particular smartphone, a Motorola Cliq, I can easily reach the external buttons that are (normally) for volume up and volume down. However, there are two problems using these for podcast playback. 1) once the screen blanks, the buttons are inactive until the screen lock is removed, and 2) I already have a volume control in my earbuds that works just fine.

Might it be possible to software-configure those two buttons for other purposes? For example, skip fwd (or if held down for, say, >1 second, skip backward) on one button, and listen to the next downloaded podcast on the other button?

This would make it easy to leave the smartphone in the holster and manage one's listening with a single hand, rather than have to take out the device, wake up the screen, and use two hands to muck around with the screen user interface.

This is a general request for all Android devices. It is not specific to any one particular device manufacturer like Motorola or HTC.

Can DoggCatcher even get access to these buttons or are they fixed function by the Android OS?

 

[eric.doggcatcher]

I'm pretty sure that once the screen is locked, you're only able to unlock it with a homescreen app. I've seen a few discussions about the hardware buttons in the android forums and there are a couple of the buttons that you can respond to but everyone discourages doing that.

What would seem to me to be the most natural solution is to extend the handling of the media buttons to perform the functions you mention with dbl and long presses. I just added the ability to control bluetooth ff/rew (will be released tonight). I also noticed accidentally that the ff/rew works with the nexus one wired headset. There must be a device that sits in-line between your phone and your headset that has the play/pause/ff/rew buttons. That would be ideal.

If anyone is aware of such a device, I'm sure others would like to hear about it. I think what we are looking for is a TRRS connector - TRS connector - Wikipedia, the free encyclopedia

Would it be possible to enable a user-configurable setting that would allow one to utilize the external buttons on an Android smartphone to have software configured functionality?

For example, on my particular smartphone, a Motorola Cliq, I can easily reach the external buttons that are (normally) for volume up and volume down. However, there are two problems using these for podcast playback. 1) once the screen blanks, the buttons are inactive until the screen lock is removed, and 2) I already have a volume control in my earbuds that works just fine.

Might it be possible to software-configure those two buttons for other purposes? For example, skip fwd (or if held down for, say, >1 second, skip backward) on one button, and listen to the next downloaded podcast on the other button?

This would make it easy to leave the smartphone in the holster and manage one's listening with a single hand, rather than have to take out the device, wake up the screen, and use two hands to muck around with the screen user interface.

This is a general request for all Android devices. It is not specific to any one particular device manufacturer like Motorola or HTC.

Can DoggCatcher even get access to these buttons or are they fixed function by the Android OS?

 

[eggs]

New version is out! UI improvements and bug fixes.

 

[MB200]

Thanks Eric for the response. Two questions:

1) When you say "TRRS" are you implying that a different physical jack would be needed on the Android device, and a different physical plug would be needed on the headset/earbuds? In other words, for the set of functionality you foresee with a TRRS connector (if one were to exist), would it only be useful for future products and not for existing Android devices with 3.5 mm jacks?

2) I could not quite tell from your response, is the screen lock necessarily interconnected to the liveness or deadness of the external hardware buttons? Is there any software way for an app (with proper access permissions, of course) to get control of the external volUp and volDn buttons? If you could, I'd recommend designing such that DoggCatcher retains control only while it is playing back a podcast, and it could willingly cede control of the buttons once, say, an incoming call was detected (by just pausing playback as it now does).

I'm pretty sure that once the screen is locked, you're only able to unlock it with a homescreen app. I've seen a few discussions about the hardware buttons in the android forums and there are a couple of the buttons that you can respond to but everyone discourages doing that.

What would seem to me to be the most natural solution is to extend the handling of the media buttons to perform the functions you mention with dbl and long presses. I just added the ability to control bluetooth ff/rew (will be released tonight). I also noticed accidentally that the ff/rew works with the nexus one wired headset. There must be a device that sits in-line between your phone and your headset that has the play/pause/ff/rew buttons. That would be ideal.

If anyone is aware of such a device, I'm sure others would like to hear about it. I think what we are looking for is a TRRS connector - TRS connector - Wikipedia, the free encyclopedia

 

[Rjohnjr]

What would seem to me to be the most natural solution is to extend the handling of the media buttons to perform the functions you mention with dbl and long presses. I just added the ability to control bluetooth ff/rew (will be released tonight). I also noticed accidentally that the ff/rew works with the nexus one wired headset. There must be a device that sits in-line between your phone and your headset that has the play/pause/ff/rew buttons. That would be ideal.

If anyone is aware of such a device, I'm sure others would like to hear about it. I think what we are looking for is a TRRS connector - TRS connector - Wikipedia, the free encyclopedia

Eric,

At least some headsets already make use of long presses. I am using the Altec-Lansing (Plantronic) Backbeat 903 bluetooth stereo headset -- which seems to work great with DC on my Sprint Samsung Moment. On the backbeat headset, the main button on the right earphone pauses playback. A long press on the same button turns a bass boost feature on or off. A second button or lever controls the volume. A long press on that button skips to the next or previous track. I suspect that other headphone manufacturers have added similar capability to their phones. I mention this because it seems at least possible that adding actions in software might create some sort of unintended conflict with these manufacturer actions. Just fyi.

Oh, and thanks for a great piece of software -- I just love being able to download and listen to my podcasts without having to wait until I can connect to my computer. DC is head and shoulders over any of the competitors I have tried.

 

[eric.doggcatcher]

1 - The nexus one has a trrs jack and I would imagine other devices would as well. Take a read of the wikipedia article, it does a really good job of explaining this...much better than I can.

2 - When you're not a home app, there's only one button you can respond to. I think it's the camera button. This is at least as far as I follow the documentation.

Thanks Eric for the response. Two questions:

1) When you say "TRRS" are you implying that a different physical jack would be needed on the Android device, and a different physical plug would be needed on the headset/earbuds? In other words, for the set of functionality you foresee with a TRRS connector (if one were to exist), would it only be useful for future products and not for existing Android devices with 3.5 mm jacks?

2) I could not quite tell from your response, is the screen lock necessarily interconnected to the liveness or deadness of the external hardware buttons? Is there any software way for an app (with proper access permissions, of course) to get control of the external volUp and volDn buttons? If you could, I'd recommend designing such that DoggCatcher retains control only while it is playing back a podcast, and it could willingly cede control of the buttons once, say, an incoming call was detected (by just pausing playback as it now does).

 

[eric.doggcatcher]

android supports bluetooth play/pause/next/prev. it sounds like your device has some internal mechanism for handling long presses and then sends the appropriate play/pause/next/prev bluetooth command. the bass boost and volume i assume do not translate to bluetooth commands since they are handled internally on your headset.

i did try to handle bluetooth long presses but wasn't able to get it to work...i'm not sure if that's technically possible or not.

glad you like the app.

eric

Eric,

At least some headsets already make use of long presses. I am using the Altec-Lansing (Plantronic) Backbeat 903 bluetooth stereo headset -- which seems to work great with DC on my Sprint Samsung Moment. On the backbeat headset, the main button on the right earphone pauses playback. A long press on the same button turns a bass boost feature on or off. A second button or lever controls the volume. A long press on that button skips to the next or previous track. I suspect that other headphone manufacturers have added similar capability to their phones. I mention this because it seems at least possible that adding actions in software might create some sort of unintended conflict with these manufacturer actions. Just fyi.

Oh, and thanks for a great piece of software -- I just love being able to download and listen to my podcasts without having to wait until I can connect to my computer. DC is head and shoulders over any of the competitors I have tried.

 

[MB200]

Thanks Eric for the input. I decided to give a TRRS pair of earbuds a try, so I purchased a pair of JLAB J3Ms. This uses the TRRS jack you mentioned (with the double (R)ing segments) so, apparently, one additional channel of switch data can be conveyed from the earbuds to the smartphone. JLAB adds a button inline to one of the two earbuds, and calls this a "phone control button": they say that it is compatible with "most phones with a 3 mm jack", but only list iPhone and Blackberry specifically.

It appears that my Motorola Cliq can sense the press of the button, but in my case, it doesn't do what JLAB says it will do. In my case, it only brings up the Android audio dialing application; nothing more. The JLAB info that came with the earbuds says it will do one of these two things:
1) "Use with phone: To make or receive a call, simply press the phone control button once. When you are finished, press the PCB again to return to normal music listening mode."
2) "When listening to music: Quickly press the phone control button twice to skip to the next track, or quickly press it three times to skip to the previous track."

I don't need to do no. 1, as DoggCatcher already pauses the podcast playback when I receive a phone call, or when I make a call. And DC automatically resumes the podcast when the call is over. This is great behavior. My music player works similarly so the button is unnecessary for that.

As to number 2, it seems like DoggCatcher ought to be able to detect the presses (since my phone sees the presses somehow) and then, perhaps with software configurability, do one or two simple behaviors based on the characteristics of the press(es).

If the phone can detect the press, can DoggCatcher access the "press" information and use it as you wish to in your app?

1 - The nexus one has a trrs jack and I would image other devices would as well. Take a read of the wikipedia article, it does a really good job of explaining this...much better than I can.

2 - When you're not a home app, there's only one button you can respond to. I think it's the camera button. This is at least as far as I follow the documentation.

 

[eric.doggcatcher]

It's good that android is able to detect the presses. In order for DC to 'see' them, you'll need to enable the 'bind to headset' preference. That alone may do what you want.

I'm guessing that double-pressing the button is sending a 'next' command to the phone and 'triple-pressing' is sending the prev command.

It that doesn't work, then just do all the actions that the headset does, let me know what you did and email me the log (in the dc menu send log to support at snoggdoggler.com). I should be able to see from that how android is perceiving the button presses.

Thanks Eric for the input. I decided to give a TRRS pair of earbuds a try, so I purchased a pair of JLAB J3Ms. This uses the TRRS jack you mentioned (with the double (R)ing segments) so, apparently, one additional channel of switch data can be conveyed from the earbuds to the smartphone. JLAB adds a button inline to one of the two earbuds, and calls this a "phone control button": they say that it is compatible with "most phones with a 3 mm jack", but only list iPhone and Blackberry specifically.

It appears that my Motorola Cliq can sense the press of the button, but in my case, it doesn't do what JLAB says it will do. In my case, it only brings up the Android audio dialing application; nothing more. The JLAB info that came with the earbuds says it will do one of these two things:
1) "Use with phone: To make or receive a call, simply press the phone control button once. When you are finished, press the PCB again to return to normal music listening mode."
2) "When listening to music: Quickly press the phone control button twice to skip to the next track, or quickly press it three times to skip to the previous track."

I don't need to do no. 1, as DoggCatcher already pauses the podcast playback when I receive a phone call, or when I make a call. And DC automatically resumes the podcast when the call is over. This is great behavior. My music player works similarly so the button is unnecessary for that.

As to number 2, it seems like DoggCatcher ought to be able to detect the presses (since my phone sees the presses somehow) and then, perhaps with software configurability, do one or two simple behaviors based on the characteristics of the press(es).

If the phone can detect the press, can DoggCatcher access the "press" information and use it as you wish to in your app?

 

[MB200]

Thanks for the quick response Eric. I've done the "bind to headset" and did get somewhat different behavior. I will definitely gather the data you are asking for and send it to you, but am buried at present so it will have to wait a few more days. Cheers.

 

[MB200]

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]

I think it would be great if there were a bit of software configurability to the behavior one gets from, say, single-presses, double-presses, and tripple-presses of the headset button, and also long-presses (press and hold) if the DC software is able to detect a long press as different from a short press.

Suggested behaviors that could be tied to various (DC-detectable) button press behaviors:

• stop/start playback of the currently selected feed and podcast (toggle the play state)
• back (software pre-configured) skip seconds in the current podcast
• forward (skip) (software-preconfigured) skip seconds
• next podcast in the current feed
• next feed, start playback of first podcast
• back (software pre-configured) 4 times the default skip seconds

You can probably think of others, but each of these would be extremely useful to me in my situation where getting at the device touch-screen is very awkward, or not allowed per employer work rules, in some situations.

 

[eric.doggcatcher]

I got your logs, thanks for sending them. I'll take a look and let you know what I find.

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.

 

[billtvshow]

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.

 

[dtfamily]

Hi, I love the program and use it alot. However, I am using it with several BT items (Jabra headset and Blueant S1), and the volume is too low on both of them. It would be great if there were a way to incorporate some sort of volume boost, either in hearing the media in the program, or boosting it when downloading, or....

I'm assuming it would be a lot of work- so any other suggestions besides downloading to computer, using Audacity, re-uploading, etc. That's what I like about DC- the automation of the whole process of downloading podcasts!

Thanks,
Dave

 

[eric.doggcatcher]

Yep, it's scrolling to the oldest item so you can start reading from the oldest, which is normally the case. I have heard from a few people that they would like to start at the top. I created an issue to add a preference for this behavior.

Thanks for the suggestion.

0000412: Preference for auto-scrolling to oldest or newest item in feed - Mantis

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.

 

[eric.doggcatcher]

I didn't think this was possible but it look likes it might be.

I created an issue for this - 0000413: Ability to increase volume level - Mantis

Thanks for the idea.

Hi, I love the program and use it alot. However, I am using it with several BT items (Jabra headset and Blueant S1), and the volume is too low on both of them. It would be great if there were a way to incorporate some sort of volume boost, either in hearing the media in the program, or boosting it when downloading, or....

I'm assuming it would be a lot of work- so any other suggestions besides downloading to computer, using Audacity, re-uploading, etc. That's what I like about DC- the automation of the whole process of downloading podcasts!

Thanks,
Dave

 

[MB200]

I recently downloaded the latest update and found you have implemented the "more stable" seekbar. Awesome. The ability to set it up to recognize only a long press to move the seekbar is just what I needed.

I really appreciate how well you support this app!

 

[raistian77]

Love the app use it more than any of the others. The problem I am getting is when I wish to listen to a Podiobook. The entire book downloads in a feed with each chapter being an episode like it should. The problem is when I finish listening to the first chapter, instead of going straight to the next one it either jumps to a new feed or starts at the last chapter and tries to run backward through the chapters. I find I have to unlock the phone and start the next chapter for each one to have then play in the correct order. Since I work in construction often as a painter this is aggravating as I have to clean up and set up the next chapter manually.

Any help would be greatly appreciated, thanks

 

[eric.doggcatcher]

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.

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.

 

[eric.doggcatcher]

It's really great to hear how you are using the app at work, I haven't heard anyone using it while painting before.

The order that the items play in should be the order that they are listed in the playlist. If that's not the case, let me know because that would be a bug.

For virtual feeds, the items should be sorted in the order of the title (filename). What I have heard that some people do is name the files such that they get the order they want. I think if you name them starting with 01, 02, 03...the sort will work out the way you want.

Love the app use it more than any of the others. The problem I am getting is when I wish to listen to a Podiobook. The entire book downloads in a feed with each chapter being an episode like it should. The problem is when I finish listening to the first chapter, instead of going straight to the next one it either jumps to a new feed or starts at the last chapter and tries to run backward through the chapters. I find I have to unlock the phone and start the next chapter for each one to have then play in the correct order. Since I work in construction often as a painter this is aggravating as I have to clean up and set up the next chapter manually.

Any help would be greatly appreciated, thanks