Closed Lavmint closed 2 years ago
Could you grab the logcat after attempting to make a call? Given that you mentioned this:
Nothing at all (no recordings, no empty files, no errors)
I don't think it's worth looking into the mixer settings just yet. It's likely failing to detect that a call is occurring at all if no output file was created.
When a call comes in, I'd expect it to log the onCallAdded
event from RecorderInCallService
about the call being in the CONNECTING
or RINGING
state. For example:
06-10 13:06:18.698 31723 31723 D RecorderInCallService: onCallAdded: Call [id: TC@1, state: CONNECTING, details: [id: TC@1, state: CONNECTING, pa: ComponentInfo{com.android.phone/com.android.services.telephony.TelephonyConnectionService}, 1, UserHandle{0}, hdl: tel:***********, hdlPres: 1, videoState: Audio Only, caps: [Capabilities: CAPABILITY_SUPPORT_HOLD CAPABILITY_MUTE CAPABILITY_CANNOT_DOWNGRADE_VIDEO_TO_AUDIO], props: [Properties:]]]
If that's not happening, then Android might not be notifying BCR of the call state. This log message should be printed even if call recording is disabled.
I unfortunately can't LineageOS myself. My only device compatible with LineageOS has no VoLTE support, so I can't make calls.
@chenxiaolong without filtering logcat is just a mess, here is the full log after attempting to call to 123456 logs-2022-06-16-22-21-20.zip
Hmm, this part is weird:
logcat.txt:06-16 22:20:03.277 D/RecorderInCallService(8012): onDetailsChanged: Call [id: TC@1, state: DIALING, details: [id: TC@1, state: DIALING, pa: ComponentInfo{com.android.phone/com.android.services.telephony.TelephonyConnectionService}, ***, UserHandle{0}, hdl: tel:****56, hdlPres: 1, videoState: Audio Only, caps: [Capabilities: CAPABILITY_SUPPORT_HOLD CAPABILITY_MUTE CAPABILITY_CANNOT_DOWNGRADE_VIDEO_TO_AUDIO], props: [Properties:]]], [id: TC@1, state: DIALING, pa: ComponentInfo{com.android.phone/com.android.services.telephony.TelephonyConnectionService}, ***, UserHandle{0}, hdl: tel:****56, hdlPres: 1, videoState: Audio Only, caps: [Capabilities: CAPABILITY_SUPPORT_HOLD CAPABILITY_MUTE CAPABILITY_CANNOT_DOWNGRADE_VIDEO_TO_AUDIO], props: [Properties:]]
<...>
logcat.txt:06-16 22:20:08.211 D/RecorderInCallService(8012): onStateChanged: Call [id: TC@1, state: DISCONNECTING, details: [id: TC@1, state: DISCONNECTING, pa: ComponentInfo{com.android.phone/com.android.services.telephony.TelephonyConnectionService}, ***, UserHandle{0}, hdl: tel:****56, hdlPres: 1, videoState: Audio Only, caps: [Capabilities: CAPABILITY_SUPPORT_HOLD CAPABILITY_MUTE CAPABILITY_CANNOT_DOWNGRADE_VIDEO_TO_AUDIO], props: [Properties:]]], 10
It's going from the DIALING
state straight to DISCONNECTING
. I'm not sure what would cause that. It's like the call was ringing, but was hung up before the call was answered. BCR does not record until the call goes into the ACTIVE
state.
Well,
I've also tried calling real person with BCR today, also with no luck. I will try to log call to real person tomorrow and will attach it too, maybe it would have different states flow
@chenxiaolong a tried a few cases
Recordings
- file exists, recorded with soundRecordings
- file exists, recorded without sound (silence). BCR is not enabling/relying on mixer like Axet's recorder? Call Recordings
- file exists, recorded with soundCalling to 123456 is not a proper way to test BCR, this only works with axet since it's expecting other state - ok
I don't get it why I had 1 call that was not recorded without any files and why it's working know. In case 3 I've tested output directory with space between words and it's not the case
Meh, for now the only question I got is about mixer. Shouldn't BCR provide ability to enable it? Since I didn't catch original issue's behavior I'm not attaching any logs
Conclusion and user-exp:
Issue closed for now as of all working and recorded now
What happened
What did I do?
Other
/vendor/etc
/vendor/etc/mixer_paths_tasha.xml
. If to play with switches, it may start working but not for long. Also it seems that skip silence somehow affects recording tooDeviceInfo
Logcat
Mixer