Playback won’t resume after a call
Upload description: telrod11-phone
Made 4 calls, and after each, playback won’t resume. Manual play was pressed from the BT device
Local device
There’s no log uploaded…
Sorry
Should be there now.
4 calls
First call, 18 sec, play resumes
Last three, 40+sec calls, no resumption
What I see in the logs is that there’s manual pause commands sent in some cases, in those case there’s no automatic resuming as expected.
2024-10-31 11:00:03.641 Verbose MediaSessionCallback onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=0, downTime=0, deviceId=-1, source=0x0, displayId=-1 }
2024-10-31 11:00:03.646 Verbose MediaSessionCallback onPause
2024-10-31 11:00:03.647 Verbose MediaSessionCallback onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_UP, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=0, downTime=0, deviceId=-1, source=0x0, displayId=-1 }
2024-10-31 11:00:09.088 Verbose MediaSessionCallback onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=0, downTime=0, deviceId=-1, source=0x0, displayId=-1 }
2024-10-31 11:00:09.093 Verbose MediaSessionCallback onMediaButton: android.intent.action.MEDIA_BUTTON - KeyEvent { action=ACTION_UP, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=0, downTime=0, deviceId=-1, source=0x0, displayId=-1 }
From the logs the last call did not receive any pause command and did resume correctly.
2024-10-31 11:01:08.489 Verbose MusicPlayer New audio focus: 0
2024-10-31 11:01:08.497 Verbose ExoPlayer playWhenReady [eventTime=2505.53, mediaPos=69.62, window=0, period=0, false, USER_REQUEST]
2024-10-31 11:01:08.499 Verbose MusicPlayer onPlayWhenReadyChanged: false
2024-10-31 11:01:08.514 Verbose ExoPlayer isPlaying [eventTime=2505.53, mediaPos=69.62, window=0, period=0, false]
2024-10-31 11:01:59.489 Verbose MusicPlayer New audio focus: 2
2024-10-31 11:01:59.507 Verbose MusicPlayer New audio focus: 2
2024-10-31 11:01:59.509 Verbose ExoPlayer playWhenReady [eventTime=2556.51, mediaPos=69.63, window=0, period=0, true, USER_REQUEST]
2024-10-31 11:01:59.512 Verbose MusicPlayer onPlayWhenReadyChanged: true
2024-10-31 11:01:59.513 Verbose MediaSessionCallback onPlay
2024-10-31 11:01:59.523 Verbose ExoPlayer isPlaying [eventTime=2556.51, mediaPos=69.63, window=0, period=0, true]
Maybe you answer calls or start calls from a button on the BT device and it wrongly send audio commands too.
All the calls are taken from the handset in these tests, and the call ended with the handset.
It’s funny that the “short” call of 18 sec resumed without intervention, but the other three did not.
Is there anything else I can do to test while logging to isolate this?
The third one did resume from the logs.
The question is why there’s pause commands send.
Ok, you’re not going to want to hear this, but I just did another test…
I turned off auto play on Symfonium
I have Poweramp installed on my phone also. I turned on auto play on BT on Poweramp, and it functions with the phone cal resumption flawlessly.
Sorry, but for whatever reason, we do have an issue here.
You’re not going to want to hear this but:
I don’t give a shit about what happens in other app, because this is 100% f…g irrelevant to what happens in Symfonium in this case.
So again in the logs something send pause commands via media session so what happens is normal due to those events.
BTW there’s also a :
2024-10-31 10:59:00.228 Error Notification Unable to start foregroundService
android.app.ForegroundServiceStartNotAllowedException: Service.startForeground() not allowed due to mAllowStartForeground false: service app.symfonik.music.player/app.symfonik.core.playback.service.PlayerService
at android.app.ForegroundServiceStartNotAllowedException$1.createFromParcel(ForegroundServiceStartNotAllowedException.java:54)
at android.app.ForegroundServiceStartNotAllowedException$1.createFromParcel(ForegroundServiceStartNotAllowedException.java:50)
at android.os.Parcel.readParcelableInternal(Parcel.java:5064)
at android.os.Parcel.readParcelable(Parcel.java:5046)
at android.os.Parcel.createExceptionOrNull(Parcel.java:3226)
at android.os.Parcel.createException(Parcel.java:3215)
at android.os.Parcel.readException(Parcel.java:3198)
at android.os.Parcel.readException(Parcel.java:3140)
at android.app.IActivityManager$Stub$Proxy.setServiceForeground(IActivityManager.java:7193)
at android.app.Service.startForeground(Service.java:776)
at t7.b.a(Unknown Source:167)
at app.symfonik.core.playback.service.PlayerService.s(Unknown Source:195)
at b9.y0.r(Unknown Source:11)
at ry.a.p(Unknown Source:5)
at oz.e0.run(Unknown Source:103)
at android.os.Handler.handleCallback(Handler.java:991)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loopOnce(Looper.java:232)
at android.os.Looper.loop(Looper.java:317)
at android.app.ActivityThread.main(ActivityThread.java:8787)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:591)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:871)
that indicate that the app is not excluded from battery exclusions.
I’ll live with the phone call issue then, as I have tried everything I know to relieve the battery issue.
I apologize for bringing up how other apps work. As an engineer, the only way I am able to diagnose issues sometimes, is to see what works, and then what doesn’t, and to try and see what changes.
Thanks
As explained this is not a battery issue this time … First rule of engineer is to read 
This is caused by something sending sometimes the pause command, you can easily check the logs yourself
So as an engineer, you have how to gather the logs, what to look for and all the necessary explanations to actually try to debug this on your side, something I can’t do as the command comes from outside the app.
And it’s highly possible that the other app just ignore pause commands sent during a focus loss, I consider this bad design as it prevent you from controlling what happens when the call ends.
So again, try to actually read what I write and the docs.