chenxiaolong / BCR

A Basic Call Recorder for rooted Android devices
GNU General Public License v3.0
1.76k stars 113 forks source link

Templating in directory name, so folder per phonenumber can be used #357

Closed Mik3yZ closed 1 year ago

Mik3yZ commented 1 year ago

Hello,

would it be possible to use a subdirectory per phonenumber. Maybe by making it possible to add a directory to the filename template;

{phone_number}/{date}[{direction}|][_sim{sim_slot}|][{phonenumber}|][[{contact_name}|{caller_name}|{call_log_name}]|]

chenxiaolong commented 1 year ago

I think is a good idea and doing it via the filename template makes sense, though I'm not sure yet if I'll implement it.

All file access must go through Android's Storage Access Framework, which is not well designed and is already slow. However, traversing subdirectories in particular is especially slow. While Google Pixel, Samsung, and OnePlus devices may be relatively okay, I expect that on some other devices, simplying adding a subdirectory may delay the saving of the call recording by 20+ seconds. Enabling the file retention feature will make it even slower than that.

If I end up implementing this, I'll need to add a very visible warning in BCR's filename template settings so users won't think BCR is broken due to Android being slow.

chenxiaolong commented 1 year ago

I made a very hacky proof of concept for this and it's unfortunately very slow, even on the Google Pixel stock OS (and AOSP).

The main issue is that Android's SAF (Storage Access Framework) has no way to create and open files in subdirectories directly. For example, to create <output directory>/2023/05/filename.oga, SAF requires scanning the entire contents of <output directory>, 2023, and 05. For each file in those directories, it's gathering the file size, modification timestamp, and some other information. Android is doing a significant amount of work for no reason when all we want to do is create a file.

When saving to internal storage, the slowness may be acceptable if there's aren't many existing recordings, but the inefficiency really shows when saving to an SD card or cloud storage.

Until Google fixes this, I won't put any further effort into implementing this feature in BCR.

EDIT: I'm going to leave this issue open because I think it's a good feature and I would like to implement it at some point (when it's able to work well).

symbuzzer commented 1 year ago

Well, is it not possible to save it in a temporary folder and copy it to the relevant folder in the background after the phone call and recording are over?

chenxiaolong commented 1 year ago

Well, is it not possible to save it in a temporary folder and copy it to the relevant folder in the background after the phone call and recording are over?

BCR already does that (as of version 1.35). The slowness would be at the end of the call before the recording complete notification is shown.

symbuzzer commented 1 year ago

Couldn't it be like this then? When the call ends, the notification "Completing call recording..." should be displayed. After everything is done, the "Call saved" notification will be displayed with the option to send and delete.

chenxiaolong commented 1 year ago

Yep, that's definitely possible and is a pretty user-friendly way to handle it. If I ever implement this, I'll most likely do that.

chenxiaolong commented 1 year ago

Screw it, this is useful enough I decided to just implement it now :slightly_smiling_face: #361 has been merged and will be included in version 1.46.