AntennaPod fails to resume after a phone call

[udif]

When a phone call is received via a Bluetooth headset and 'Pause for interruptions' is set in the settings, the podcast playback stops correctly, but never resumes when the phone call ends.

When on the other hand, it is interrupted by GPS navigation messages (e.g. Waze), it correctly resumes playing the podcast.

I din't think it is relevant, but 'Headphone' disconnect and 'Headphone reconnect' are also enabled.

[LatinSuD]

Not only when using bluetooth headset. After a phone calls not only not resumes playing, but icon in notification area also disappears.

[TomHennen]

I wonder if the OS is stopping us for some reason.

What device and OS are you both using?

[udif]

I'm on 5.1,and this was definitely the same for all 5.x releases. is been a long time since I've ran 4.4.x, but I think it might have been OK back then.

[TomHennen]

I can't quite figure out why this is happening. Android seems to be killing our PlaybackService.

[TomHennen]

I take that back. This was a feature added intentionally in 18372a4 by @danieloeh back in August 2014.

Since it was added intentionally I'm not just going to take it out without any extra thought. Personally, I'd probably prefer the podcast resume. When driving if someone calls, you probably want it to resume. We could always make this an option.

Thoughts?

[mfietz]

Having this as an option sounds good to me.

[TomHennen]

Cool. I'll work on that.

[udif]

Unfortunately , as far as I can tell, this still doesn't work - Antennapod 1.2.54 Nexus 5 Android 5.1.0 (updated since then to 5.1.1) "Resume after call" enabled (also toggled off and on again just to be sure it's not some initialization issue).

Anyone else got this working?

[TomHennen]

This was working for me. I'll take a look in a 5.1 emulator (I only have access to a 5.0 device).

[TomHennen]

So, this is working for me in the 5.1.1 emulator. Would you be willing to run the debug version and send the logcat that gets output when AntennaPod is interrupted in this manner?

[udif]

I did some further checks, and managed to get it to work. I use prestissimo all the time, and since I've been suffering from prestissimo related crashes, I tried removing it. (I will open a separate bug about it)

It did not help. However, after I disabled 'resume after call', quite the application, restarted it, and reenabled it again, then 'resume after call' started working again. Reinstalled prestissimo, and 'resume after call' no longer works.

If you sill want me to run a debug version, no problem, just tell me how to get it.

[TomHennen]

You can find the 1.2 debug version here https://www.dropbox.com/s/4hffb3t2ej8965k/AntennaPod_1.2_debug.apk?dl=0

On Wed, Jun 3, 2015, 4:55 AM udif notifications@github.com wrote:

I did some further checks, and managed to get it to work. I use prestissimo all the time, and since I've been suffering from prestissimo related crashes, I tried removing it. (I will open a separate bug about it)

It did not help. However, after I disabled 'resume after call', quite the application, restarted it, and reenabled it again, then 'resume after call' started working again. Reinstalled prestissimo, and 'resume after call' no longer works.

If you sill want me to run a debug version, no problem, just tell me how to get it.

— Reply to this email directly or view it on GitHub https://github.com/AntennaPod/AntennaPod/issues/753#issuecomment-108252532 .

[udif]

I installed this. I see that it is installed separately from the release version (both icons remain), and doesn't share its database (no podcasts shown).

Is that on purpose? Am I supposed to install a few podcasts separately within tghis version for the tests?

Udi

On Wed, Jun 3, 2015 at 11:02 PM, Tom Hennen notifications@github.com wrote:

You can find the 1.2 debug version here https://www.dropbox.com/s/4hffb3t2ej8965k/AntennaPod_1.2_debug.apk?dl=0

On Wed, Jun 3, 2015, 4:55 AM udif notifications@github.com wrote:

I did some further checks, and managed to get it to work. I use prestissimo all the time, and since I've been suffering from prestissimo related crashes, I tried removing it. (I will open a separate bug about it)

It did not help. However, after I disabled 'resume after call', quite the application, restarted it, and reenabled it again, then 'resume after call' started working again. Reinstalled prestissimo, and 'resume after call' no longer works.

If you sill want me to run a debug version, no problem, just tell me how to get it.

— Reply to this email directly or view it on GitHub < https://github.com/AntennaPod/AntennaPod/issues/753#issuecomment-108252532

.

— Reply to this email directly or view it on GitHub https://github.com/AntennaPod/AntennaPod/issues/753#issuecomment-108597460 .

[TomHennen]

That's correct. That's just how it works on Android. You'll have to add some podcasts and test separately. You could export / import the OPML.

On Wed, Jun 3, 2015, 5:00 PM udif notifications@github.com wrote:

I installed this. I see that it is installed separately from the release version (both icons remain), and doesn't share its database (no podcasts shown).

Is that on purpose? Am I supposed to install a few podcasts separately within tghis version for the tests?

Udi

On Wed, Jun 3, 2015 at 11:02 PM, Tom Hennen notifications@github.com wrote:

You can find the 1.2 debug version here https://www.dropbox.com/s/4hffb3t2ej8965k/AntennaPod_1.2_debug.apk?dl=0

On Wed, Jun 3, 2015, 4:55 AM udif notifications@github.com wrote:

I did some further checks, and managed to get it to work. I use prestissimo all the time, and since I've been suffering from prestissimo related crashes, I tried removing it. (I will open a separate bug about it)

It did not help. However, after I disabled 'resume after call', quite the application, restarted it, and reenabled it again, then 'resume after call' started working again. Reinstalled prestissimo, and 'resume after call' no longer works.

If you sill want me to run a debug version, no problem, just tell me how to get it.

— Reply to this email directly or view it on GitHub <

https://github.com/AntennaPod/AntennaPod/issues/753#issuecomment-108252532

.

— Reply to this email directly or view it on GitHub < https://github.com/AntennaPod/AntennaPod/issues/753#issuecomment-108597460

.

— Reply to this email directly or view it on GitHub https://github.com/AntennaPod/AntennaPod/issues/753#issuecomment-108615059 .

[TomHennen]

Removing this from the 1.2 milestone. We fixed one issue related to it, but not the problem of the person reporting. Hopefully @udif will be able to reproduce and get us a logcat.

[TomHennen]

@udif, were you able to reproduce this problem with the latest AntennaPod? If not I'll close this issue.

[udif]

Sorry, I was away.

I did the following: I added a single podcast to the debug version I downloaded some time ago (Build 54, debug version) downloaded 3 episodes Set the following settings (all other checkmarks are off): Expand Notificatiion Persistent Playback controls Headphone disconnect headphone reconnect Continuous Playback Pause for interruptions Resume after call Set prestissimo settings to x1.0 and x1.2 only

And started playing. Called the phone from another line and the phone stops as expected. Terminated the call from either the caller or the mobile side, but the podcast doesn't resume. Also note that this was without any BT headset (it's in my office not in the car), so it is not Bluetooth related.

I also ran into my other problem (AntennaPod locking up due to prestissimo) but after restarting the app, it played OK.

OK, now where are the logs? I looked under /storage/emulated/0/Android/data/de.danoeh.antennapod.debug but all I see is MP3 files under files/media, the feed under files/cache and one image under files/images .

Please note that the App didn't crash, it simply didn't perform as we expect. Maybe there are no logs in this case?

[TomHennen]

You'll have to pull them using logcat. If you're rooted there are applications in the play store that can do this for you.

Otherwise you can use adb logcat to do it:

• https://www.youtube.com/watch?v=wv1x24CZrvY
• http://wiki.cyanogenmod.org/w/Doc:_debugging_with_logcat

[udif]

OK, I recreated this from scratch with a clean logcat , and filtered only the antennapod events. If you need other events, I still have the original logcat.

https://gist.github.com/udif/30b108d0c2c2f4a5c488

I downloaded one episode from "This American life", let it play for 5 seconds, and called the phone. I answered the call, and hung up from the mobile phone (the one running AntennaPod). Call ended, but playing didn't resume. Resumed playing manually, then called again after 5 seconds. Answered by the mobile phone, and this time hanging up from the calling phone after a few seconds. As before, AntennaPod hadn't resumed.

[TomHennen]

Hmm, could you post the entire logcat (or send it to me privately)?

I would expect to see at least some string with "Call State: ", "Lost audio focus", etc...

You can see the logic in our OnAudioFocusChangeListener:

https://github.com/AntennaPod/AntennaPod/blob/79ab68d56359dd8a02fd00441b8d2826f9c52c62/core/src/main/java/de/danoeh/antennapod/core/service/playback/PlaybackServiceMediaPlayer.java#L792

[udif]

I've just sent you 90% of the log privately.

[TomHennen]

Ok, thanks.

So this part:

I/MediaFocusControl(  750):  AudioFocus  requestAudioFocus() from AudioFocus_For_Phone_Ring_And_Calls req=2flags=0x4
D/AudioManager(14750): AudioManager dispatching onAudioFocusChange(-2) for android.media.AudioManager@3765fae8de.danoeh.antennapod.core.service.playback.PlaybackServiceMediaPlayer$12@204eb501
I/PlaybackSvcMediaPlayer(14750): Call state:1
D/PlaybackSvcMediaPlayer(14750): Lost audio focus

indicates Android is requesting a TRANSIENT audio focus loss (onAudioFocusChange(-2), -2 is AUDIOFOCUS_LOSS_TRANSIENT), that the phone is ringing (Call state: 1), that AntennaPod thinks it should stop playback and not resume (Lost audio focus).

Basically, this conditional is evaluating to true:

if (focusChange == AudioManager.AUDIOFOCUS_LOSS ||
                            (!UserPreferences.shouldResumeAfterCall() && callState != TelephonyManager.CALL_STATE_IDLE)) {

So, the first part of the conditional focusChange == AudioManager.AUDIOFOCUS_LOSS is false, since we know focusChange == AUDIOFOCUS_LOSS_TRANSIENT from the log message.

We know callState != TelephonyManager.CALL_STATE_IDLE is true because CALL_STATE_IDLE == 0 and callState == -1, -1 !=0.

So that only leaves UserPreferences.shouldResumeAfterCall(). the only way we could get in to this if block is if shouldResumeAfterCall is returning false.

I don't really know how that could happen unless 'Resume after Call` in settings was not checked.

Could you verify that it is checked? If it is checked, then there's some problem with the way preferences are being stored on your device. If it isn't checked then, try checking it and seeing if the problem goes away.

[mfietz]

Örm, when I refactored the UserPreferences class, I noticed the resumeAfterCall is only refreshed in the onChange listener, but not loaded when the static instance is created (loadPreferences())... Might this be the problem?

[TomHennen]

Sounds about right. Good catch!

On Wed, Jun 24, 2015, 2:45 AM Martin Fietz notifications@github.com wrote:

Örm, when I refactored the UserPreferences class, I noticed the resumeAfterCall is only refreshed in the onChange listener, but not loaded when the static instance is created (loadPreferences())... Might this be the problem?

— Reply to this email directly or view it on GitHub https://github.com/AntennaPod/AntennaPod/issues/753#issuecomment-114749704 .

[TomHennen]

@mfietz, so I'm guessing this will be fixed now that #941 is merged?

[mfietz]

Yes

[udif]

I just wanted to confirm that with Build 1.3 Alpha 60 the problem is indeed gone.

The only strange thing is that the Play store page indicates that AntennaPod was last updated on Jun 20, 2015 while the relevant commit (91a8cab) was merged by Jun 26 according to the commit log. Upon further inspection of the Play store page on the web, not on my phone, it indicates there version 1.2.1 and the same date, which hints that the date that appears on the play store app is always the release date of the Normal app, not the alpha channel. https://play.google.com/store/apps/details?id=de.danoeh.antennapod