Open noembryo opened 5 days ago
BCR-GUI does not feature an internal media player, it uses the default Android MediaPlayer. Some Android ROMs have very different performances with different codecs.
Do you, by any chance, use the OGG codec? Another user had a similar issue (#130) with that compressor, and fixed it by switching to M4A/AAC, which is the best one IMHO.
Do you, by any chance, use the OGG codec?
Yes since the default format for bcr is .oga
I'll try to convert them to .m4a
to see if that's working..
I converted the files to .m4a
, edit their .json
files and the .bcr-gui-database.json
, and everything is working as it should.
Maybe you could catch the unresponsivness of the player and popup a warning to the user?
Anyway, thank you for your help and your work in general.. 🙏
Maybe you could catch the unresponsivness of the player and popup a warning to the user?
Well, maybe it's possible but... how long shall it wait to be considered "unresponsive"? I suppose this time is strictly related to ROM version/type and hardware performances.
And also, maybe one user could considers 8/10 seconds as "acceptable", while another kills the app after 5/6 seconds... losing the warning 😉
Maybe it's better to add a FAQ section to the main page of this repo, and hope users read it 😂
but... how long shall it wait to be considered "unresponsive"?
In my case the app never recovers, so any warning would be fine.
I don't have to wait for anything GUI related for more than a couple of seconds on this device.
With the .m4a
files there is no waiting at all.
Remember that the bug has to do with the opening of the item's info, not with the playback of the conversation.
It's just that the playback controls freeze too, that I mention them.
Probably it is just accessing/checking the file that is causing the freeze.
No waiting is acceptable there (except in the absence of a .json
file, and that only for the first time, because after that there is the database).
The opening of the info should be instantaneous if a .json
file exists (like in my case), so any blocking should be reported to the user..
I have the same issue with ogg files (haven't tried any other format yet). The thing is, another BCR GUI-type app (BCR Manager) doesn't seem to exhibit the same issue so maybe this warrants further investigation?
maybe this warrants further investigation?
It surely does, but I'm actually unable to reproduce the bug on the 3 devices I use 3 devices for testing 🫤:
The longest conversation I have is 1h:03m in .mpa
format (I've never used OGA since it produces too big files).
So I've converted it to .oga
with ffmpeg:
Original file:
Complete name : test.m4a
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42 (isom/mp42)
File size : 11.1 MiB
Duration : 1 h 3 min
Overall bit rate mode : Constant
Overall bit rate : 24.5 kb/s
Encoded date : 2023-11-01 17:15:02 UTC
Tagged date : 2023-11-01 17:15:02 UTC
com.android.version : 11
Audio
ID : 1
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 1 h 3 min
Source duration : 1 h 3 min
Source_Duration_LastFrame : 32 ms
Bit rate mode : Constant
Bit rate : 24.0 kb/s
Channel(s) : 1 channel
Channel layout : M
Sampling rate : 16.0 kHz
Frame rate : 15.625 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 10.8 MiB (98%)
Source stream size : 10.8 MiB (98%)
Title : SoundHandle
Language : English
Encoded date : 2023-11-01 17:15:02 UTC
Tagged date : 2023-11-01 17:15:02 UTC
mdhd_Duration : 3787488
Errors : Missing ID_END
Conformance errors : 1
AAC : Yes
General compliance : Bitstream parsing ran out of data to read before the end of the syntax was reached, most probably the bitstream is malformed (frame 0, time -00:00:00.064, offset 0xCB0)
Converted file:
Complete name : test.oga
Format : Ogg
File size : 10.6 MiB
Duration : 1 h 3 min
Overall bit rate : 23.4 kb/s
Writing application : Lavc58.134.100 libopus
creation_time : 2023-11-01T17:15:02.000000Z
handler_name : SoundHandle
vendor_id : [0][0][0][0]
major_brand : mp42
minor_version : 0
compatible_brands : isommp42
com.android.version : 11
Audio
ID : 2874279084 (0xAB5204AC)
Format : Opus
Duration : 1 h 3 min
Channel(s) : 1 channel
Channel layout : M
Sampling rate : 16.0 kHz
Compression mode : Lossy
Writing library : Lavf58.76.100
Language : English
While this is a file natively recorded in .oga
:
General
Complete name : original.oga
Format : Ogg
File size : 27.7 KiB
Duration : 4 s 240 ms
Overall bit rate : 53.5 kb/s
Audio
ID : 59516827 (0x38C279B)
Format : Opus
Duration : 4 s 240 ms
Channel(s) : 1 channel
Channel layout : M
Sampling rate : 16.0 kHz
Compression mode : Lossy
Writing library : libopus
As you can see the converted file and the native one have very similar parameters (except for metadata).
Well, the converted file opens immediately on all of my 3 devices 🫤.
I've then tried to generate a 4-hours test file with Audacity (it only contains a 440Hz tone), then exported it to .oga
:
Complete name : 20241020_000000.000+0000_in_012345678_4-Hours-Test.oga
Format : Ogg
File size : 86.3 MiB
Duration : 4 h 42 min
Overall bit rate : 42.7 kb/s
Writing application : Lavf58.76.100
Audio
ID : 1514653252 (0x5A47C644)
Format : Opus
Duration : 4 h 42 min
Channel(s) : 1 channel
Channel layout : M
Sampling rate : 16.0 kHz
Compression mode : Lossy
Writing library : Lavf58.76.100
Guess what?... it opens without issues.
Now I'd like you to try this 4h test file for me. Please copy it to your recording dir and try to open it...
Now I'd like you to try this 4h test file for me. Please copy it to your recording dir and try to open it...
Unfortunately, this file opens immediately.. 😞 There must be something different to the recorded files.
Converted your file to opus
and then renamed it to oga
, using an app of mine that internally uses the libopus
library, like the BCR.
20241020_000000.000+0000_in_012345678_4-Hours-TestX.zip
Unfortunately, it also opens immediately, so maybe it's a different version of libopus
or something completely different.. 😞
Well, since I can't ask you to share your recondings, it should be great to be able to create - on the phone itself - a "fake" audio file, compressed with the same system compressor that BCR uses.
Maybe some kind of a "special/test" number that starts the recording and lasts as long as needed. I've tried with my operator support number, but it drops the call after 2/3 minutes...
@chenxiaolong do you have an idea on how to achieve this...?
OK, but you have to wait.. 😉
This file freezes the app nicely.. 😉 20241020_145005.401+0300_in.oga.zip
Thanks for the test file but... it works on all of my devices 😔
https://github.com/user-attachments/assets/06a41f5a-c7e7-42f7-85e4-42dafe09eb5a
Not being able to reprodice the bug is frustrating. I could try to make some changes, but it's risky since I'll not be able to test them directly...
Anyway in the test version below I've implemented an asynchronous player initialization, so it shouldn't freeze the UI and let initialization itself complete faster. NOTE: it still won't switch correctly between loudspeaker and earpiece, I only need to check if asynchronous initialization is the way to go...
Anyway in the test version below I've implemented an asynchronous player initialization, so it shouldn't freeze the UI and let initialization itself complete faster.
This is an improvement. Now, although the controls of the problematic file are greyed out, the rest of the app works as expected. No more need to force close the app. Unfortunately, the problem of the recording not working, remains..
Something I forget to send you is the .json
file of the recording.
20241020_145005.401+0300_in.json
Just in case it matters..
Something I forget to send you is the
.json
file of the recording.
No, that file it's not relevant for MediaPlayer.
This is an improvement. Now, although the controls of the problematic file are greyed out, the rest of the app works as expected.
Ok, I could now show a message to the user to alert that their Android bundled MediaPlayer has issues with .oga
files and suggest them to switch to another format like .mpa
.
Or I could switch to another MediaPlayer alternative, like:
androidx/media
Jetpack extensionsBoth of them require a lot of work and will introduce new bugs.. 🫤
I was able to reproduce the bug on an old Redmi 4, with LineageOS (A11) 🎉🎉🎉 The application freezes as reported; but after about 5 minutes it loads the file and plays correctly (have you ever tried to wait for such a long time?) So now I have something useful to debug, so I'd like to investigate further to see if I can find something better than replace the whole player and restart from scratch...
The application freezes as reported; but after about 5 minutes it loads the file and plays correctly (have you ever tried to wait for such a long time?)
A 35min file takes ~20sec to load, and the 1h file that I send you takes ~55sec..
Describe the bug Long call conversations are freezing the app if you try to open their info.
To Reproduce Steps to reproduce the behavior:
After this the controls in all conversations are disabled, and the only way to close the app is by force-close.
Expected behavior Just play back the conversation.
Versions (please complete the following information):