Add support for GrapheneOS call recorder (was: File Name Parsing issue)

[tcables]

Describe the bug I am having a hard time with the filename parser recognizing the file name "CallRecord20230619-121746+12192826655.m4a"

Here are my attempts

/CallRecord_\{date\}(?:.+)\{phone_number\}/

CallRecord_{date}(?:.+){phone_number}

CallRecord_{date}_{phone_number}

/CallRecord_\{date\}(?:.+)\{phone_number\}\.m4a/

CallRecord_{date}(?:.+){phone_number}\.m4a

CallRecord_{date}(?:.+){phone_number}.m4a

CallRecord_{date}_{phone_number}\.m4a

CallRecord_{date}_{phone_number}.m4a

any thoughts?

Version

• BCR-GUI version: 0.0.23

[nicorac]

RegExp pattern must be inserted without delimiters and discarding filename extension. So the correct pattern should be CallRecord_{date}_{phone_number}... but your filename has a custom date format and actually BCR-GUI only manages the default BCR date format. So it must be 20230619_121746.000+0000 instead of the shorter 20230619-121746 (please also note the different date/time separator -/_).

Sadly the default BCR date format uses _ as a separator between date and time, so I was forced to parse it exactly with its expected parts lengths. The {date} placeholder actually generates the following RegExp pattern: {date} --> (?<date>\d{8}_\d{6}\.\d{3}[+-]\d{4}).

There's actually no workaround for it, sorry. I could make some parts "optional", but what about the timezone? Shall I use the system one as default?

[tcables]

Hi !

Thanks for getting back to me so quick 🙂

I took a very brief moment to look at that code, and here's my take away:

Would it be possible to instead accept any date parsing pattern, but legibly?

function parseDateTime(str, regex) {

  // Default regex
  const re = /(?<year>[0-9]{4})(?<month>[0-9]{2})(?<day>[0-9]{2})_(?<hour>[0-9]{2})(?<minute>[0-9]{2})(?<second>[0-9]{2})/;

  if(regex) re = regex;

  const match = str.match(re);

  if(!match) return null;

  let year = 2023, month = 1, day = 1;
  let hour = 0, minute = 0, second = 0;

  if(match.groups.year) year = match.groups.year;
  if(match.groups.month) month = match.groups.month; 
  if(match.groups.day) day = match.groups.day;

  if(match.groups.hour) hour = match.groups.hour;
  if(match.groups.minute) minute = match.groups.minute;
  if(match.groups.second) second = match.groups.second;

  return new Date(year, month, day, hour, minute, second);

}

(very rough code, but you get the concept hopefully)

Then standardize it, for storage in the local db? parseDateTime(fileName, xxxxxxx).toString()

Of which then you pull to display in the UI anyhow you wish?

And yes, you could assume the timezone is the system timezone.

I know this is specifically for BCR at the moment, but it would be super nice if it can be a GUI for all call recording programs - one instance being android native call recording that GrapheneOS uses.

[nicorac]

Would it be possible to instead accept any date parsing pattern, but legibly?

Well, it could... but the sample you've posted won't work with BCR in its default format.

A better solution could be to allow additional placeholders (more than the ones defined by BCR), at least for the {date} placeholder.

I mean, leave the {date} as is and add its single parts placeholders, like {date-year}, {date-month}, ...

Let me check if I could build a POC version 😉

I know this is specifically for BCR at the moment, but it would be super nice if it can be a GUI for all call recording programs - one instance being android native call recording that GrapheneOS uses.

Is that filename format the default one of GrapheneOS call recorder? If so, I could add some kind of a "template patterns" menu to quickly set it (together with other ones in the future).

[tcables]

the sample you've posted won't work with BCR in its default format.

Correct, you would need to have a default regex that matches the BCR Format, and then allow any regex that provides the necessary groups to parse for dates and phone number. But yes, very rough, and I dont know where you would have inserted that.

I mean, leave the {date} as is and add its single parts placeholders, like {date-year}, {date-month}, ...

yes, that seems like it would be a good idea for now.

Is that filename format the default one of GrapheneOS call recorder?

yes

"CallRecord20230619-121746+12192826655.m4a"

CallRecord_DATE-TIME_PHONE.m4a

GrapheneOS, thankfully, forced this feature through. Just FYI, there are only two settings available: Output format (codec) and Audio source. They do not allow filename changes or auto recording.

If so, I could add some kind of a "template patterns" menu to quickly set it (together with other ones in the future.

That's also a good idea.

Sorry for the bug tag, you can switch it over to feature request if you like

[nicorac]

I've built a test version (same version code, but it shows 0.0.23-test1 as version number). It supports the new {date:year}, {date:month}, ... placeholders.

The pattern that should work for you is ^CallRecord_{date:year}{date:month}{date:day}-{date:hours}{date:minutes}{date:seconds}_{phone_number}

NOTE: if you click on RESET TO DEFAULT in filename pattern page it will actually set to this new one 😉

Please check it out and let me know if it has any issue... bcr-gui-0.0.23-test1-release.apk.zip

[tcables]

It's working! Thank you! 🥳 🍾 🥂 🎆 🎇 🎉

one issue though, it brings recordings that it could not parse the phone number from, to the very top of the list of calls.

example:

my last call recording was yesterday 12/13/2023.

it brings a call recording CallRecord_20231119-092201_unknown and one from January this year to the top. I've never been able to use BCR, so I'm unfamiliar what happens if you get a blank/blocked number call. it may be best to force recording date/file date to be the first sorting filter, so it handles BCR and graphene.

again, thank you so much!

P.S. you should update the readme & the F-Droid description to state it can handle Graphene Calls, as I think that would be very helpful to others searching

[nicorac]

it may be best to force recording date/file date to be the first sorting filter, so it handles BCR and graphene.

This already is the default sorting mode of BCR-GUI, but can be changed in settings.

it brings a call recording CallRecord_20231119-092201_unknown and one from January this year to the top. I've never been able to use BCR, so I'm unfamiliar what happens if you get a blank/blocked number call.

That behavior is due to the RegExp failing completely, because the phone_number RegExp group expects numbers and +- chars. I've now added the literal unknown to the capture, so it now parses that (unknown caller) filename correctly.

I've also changed the "missing date" behavior: instead of mapping to today, it will be mapped to "Unix epoch time" (1970-01-01-00-00-00).

bcr-gui-0.0.23-test2-release.apk.zip

[nicorac]

P.S. you should update the readme & the F-Droid description to state it can handle Graphene Calls, as I think that would be very helpful to others searching

I've updated the issue title to reflect it 😉

[tcables]

Thank you for another update!

Currently the filename pattern editor does not parse the phone number and time correctly.

.

On the home screen numbers show as + or 8. But time is correct.

.

Here is my file list

.

I also tried a fresh install and it had the same outcome. .

Thanks again!

[nicorac]

Ooops, an extra ? in the new RegExp caused the phone_number capture to be "non-greedy", so it captures only the first digit (or +).

I'm sorry for that. This should be the final version; if no issues arise I'll integrate it into the "official" one. bcr-gui-0.0.23-test3-release.apk.zip

[tcables]

All fixed, Works great!

Thank you so much for being receptive to this idea 🙂

[nicorac]

Just released v0.0.24 with a better filename pattern editor and "official" support to GrapheneOS filename pattern 😉