In the app Calls, how I could see the details of a call: time and duration?
2 Likes
From what I can tell, it doesn’t look as though that information is collected and presented. Best bet is probably to add desired features to this issue: Call history design (#369) · Issues · GNOME / Calls · GitLab or submit a patch to include the functionality you’d like to see.
1 Like
Looks like it might be collected. A quick look in SQL says that the start and end time, and the answered time where applicable, are stored to µs precision 
. (From that you would have to calculate the duration.)
So this may only be a presentation issue.
3 Likes
The calls are recorded in a small sqlite3 database:
purism@pureos:~$ printf ".tables\n" | sqlite3 .local/share/calls/records.db
_gom_version calls
purism@pureos:~$ printf ".schema calls\n" | sqlite3 .local/share/calls/records.db
CREATE TABLE IF NOT EXISTS 'calls' ('id' INTEGER PRIMARY KEY AUTOINCREMENT,'target' TEXT,'inbound' INTEGER,'start' BLOB,'answered' BLOB,'end' BLOB, 'protocol' TEXT);
purism@pureos:~$ printf "select * from calls where target = '+4989615xxxxx';\n" | sqlite3 .local/share/calls/records.db
726|+4989615xxxxx|0|2023-12-25T17:20:59.212465Z|2023-12-25T17:21:21.674600Z|2023-12-25T17:21:34.507709Z|tel
799|+4989615xxxxx|0|2024-05-30T18:37:07.547621Z|2024-05-30T18:37:17.962572Z|2024-05-30T18:37:29.400250Z|tel
839|+4989615xxxxx|0|2024-07-15T20:01:25.259654Z|2024-07-15T20:01:44.724989Z|2024-07-15T20:02:13.063803Z|tel
841|+4989615xxxxx|0|2024-07-17T18:13:47.587376Z||2024-07-17T18:13:49.675628Z|tel
What is missing in the GUI of Calls is in the list of Recent in each row of the calls in addition to the button for placing the call again another button [i] to pop-up the details of the call.
4 Likes
printf | sqlite3 is a GUI. 
Maybe your bash-fu is good enough to know how to subtract two date/times in ISO 8601 format to give a duration (where it can, I suppose, be assumed that the two date/times are always in the same time zone as each other, and in this case perhaps always in UTC)?
Is there room to show some more information on the list itself, rather than use a [i] button? Other possible implementations would be tapping a right pointing arrow on the right hand side, or temporarily dragging the window leftwards to see information that is otherwise beyond the window off to the right? (The latter is what the iPhone does in the text messages window.)
It seems like most UIs display the start time (or answered time instead) and the duration - rather than start/answered time and end time.
Anyway, my point was that, because the information is being collected, if/when the GUI is fixed then all the information will appear retrospectively on the GUI, as if by magic.
1 Like
Quick and dirty:
purism@pureos:~$ ./callduration.sh +4989615xxxxxx
start: 2023-12-25T17:20:59.212465Z duration: 35.295243978500366
start: 2024-05-30T18:37:07.547621Z duration: 21.85262894630432
start: 2024-07-15T20:01:25.259654Z duration: 47.80414891242981
start: 2024-07-17T18:13:47.587376Z duration: 2.088251829147339
purism@pureos:~$ cat callduration.sh
#!/bin/sh
printf "select target, start, end from calls where target = '%s';\n" $1 | sqlite3 .local/share/calls/records.db > /tmp/result
while read row; do
start=`echo $row | cut -d'|' -f2`
end=`echo $row | cut -d'|' -f3`
cat <<EOF | python3
from dateutil.parser import isoparse
start = isoparse("$start").timestamp()
end = isoparse("$end").timestamp()
print("start:", "$start", "duration:", end-start)
EOF
done < /tmp/result
rm /tmp/result
4 Likes
While polishing a bit the script to a better version (attached below), it turned out that a very few call rows do not have an end time of the call:
$ printf "select target, start, end from calls where end is NULL;\n" | sqlite3 .local/share/calls/records.db
089436xxxxx|2022-04-01T17:12:58.482085Z|
089436xxxxx|2022-04-01T17:13:34.902646Z|
+498961xxxxx|2023-01-19T15:59:43.603870Z|
+4989613xxxxx|2023-03-13T15:22:54.604179Z|
+4989613xxxxx|2023-03-13T15:26:38.976837Z|
089436xxxxx|2023-03-17T16:32:59.348697Z|
+53783xxxxx|2023-12-07T13:33:24.403539Z|
My actual version of the script is:
cat guru/callduration.sh
#!/bin/sh
#
# read the call's database for a given number and print
# start time and duration
# guru@unixarea.de, July 2024
test x$1 = x && {
printf "usage %s\n" +49891234567890 ; exit 1
}
printf "select target, start, end from calls where target = '%s';\n" $1 | sqlite3 .local/share/calls/records.db > /tmp/result
while read row; do
start=`echo $row | cut -d'|' -f2`
end=`echo $row | cut -d'|' -f3`
# echo start $start end $end
test x$end = x && continue
cat <<EOF | python3 | sed 's/.......Z//' | tr 'T' ' ' | sed 's/\(duration:.*\..\)\(.*$\)/\1 secs/'
from dateutil.parser import isoparse
start = isoparse("$start").timestamp()
end = isoparse("$end").timestamp()
print("start:", "$start", "duration:", end-start)
EOF
done < /tmp/result
rm /tmp/result
5 Likes
That seems odd. Are they all vanilla phone calls (protocol)?
I guess that’s unhelpful for your script or indeed for any actual GUI fix.
1 Like
The DB starts in 10/2021 and has 842 rows (calls), 7 are without end, i.e. ~1 percent. The protocol is always tel and the 7 calls are outbound. The start time looks reasonable (during the day) and the phone target are known to me. Two of the 7 have answered time set, 5 not.
More I can’t say.
If there is no end time, you can’t calculate the duration and my script just ignores these calls.
Update
Another interesting observation is that dialed USSD codes like for example *2266 to ask in Cubacell network for some service are stored as well as normal calls in the database.
4 Likes
You could always get the duration in your SQL query - this seems to work
CASE
WHEN answered IS NOT NULL AND end IS NOT NULL
THEN round((julianday(end) - julianday(answered)) * 24 * 60 * 60, 2)
ELSE null
END AS duration_seconds
2 Likes