Bug 31910 - audio-recorder: Filename and timestamp are not synchro?
Summary: audio-recorder: Filename and timestamp are not synchro?
Status: RESOLVED INVALID
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL: https://bugs.launchpad.net/audio-reco...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-05-11 08:44 CEST by Eric Petit
Modified: 2023-05-17 20:52 CEST (History)
2 users (show)

See Also:
Source RPM: audio-recorder-2.2.3-3.mga8
CVE:
Status comment:


Attachments
Audio rec settings (59.92 KB, image/png)
2023-05-13 09:59 CEST, Eric Petit
Details
compar log and files (2.22 KB, text/plain)
2023-05-13 12:34 CEST, Eric Petit
Details
log file with bug (2.02 KB, text/plain)
2023-05-15 13:12 CEST, Eric Petit
Details

Description Eric Petit 2023-05-11 08:44:09 CEST
Hi,
Audio recorder is an amazing tool, but, the author doesn't answer to bug report, sadly the project seems dead.
 Is there workaround or patch option?

rpm -qif /usr/bin/audio-recorder 
Name        : audio-recorder
Version     : 2.2.3
Release     : 3.mga8
Architecture: x86_64


Gnome desktop.
David Walser 2023-05-11 18:29:54 CEST

CC: (none) => geiger.david68210
Summary: Filename and timestamp are not synchro. => audio-recorder: Filename and timestamp are not synchro?

Comment 2 David GEIGER 2023-05-11 20:18:49 CEST
There's not much we can do unfortunately if upstream itself doesn't fix the issue.
Comment 3 Eric Petit 2023-05-11 20:20:22 CEST
hum, dev with c knowledge cannot provide a fix patch as workaround?
Comment 4 Dave Hodgins 2023-05-11 21:36:24 CEST
Just tested in an m8 install.

The file name is based on when the recording starts.

The file timestamp is based on when the recording ends, and is correct in my
limited testing.

The file timestamp can be altered by things such as moving the file. There can
also be differences in how the time is stored or displayed due to time zone
settings, and whether or not the system uses local time or utc.

I always use /etc/sysconfig/clock:UTC=true
On my system all times are stored in utc, but displayed based on my timezone.

The two timestamps are not expected to be identical. I don't think this is
a bug.

CC: (none) => davidwhodgins

Comment 5 Eric Petit 2023-05-11 21:39:14 CEST
yes i'm agree with you, most of time timestamp/filename are correct but, sometime no.
it can have few hours between timestamp and file name for a file of few secondes, few octets
Comment 6 Dave Hodgins 2023-05-11 22:00:19 CEST
Another thing to check.
sysconfig/i18n has the default time zone settings for the system and users time
display while /etc/sysconfig/clock also has a zone setting used by most system
level applications, and some user level applications.

Some desktop environments have their own settings.

Different applications use different ways to determine which timezone is being
used. If the values in the three locations have different values, that may
cause the time to be off by hours when comparing values.

One of the best things about linux is that there are many ways to accomplish a
task. That is also one of the worst things about it. It depends on the author
of the software, which of the many ways of determining the time is used.
Comment 7 Eric Petit 2023-05-12 19:57:14 CEST
Hi,
there is also sometime  file with 0 octet.
here it is my conf :
cat /etc/sysconfig/i18n 
COUNTRY=FR
LANG=fr_FR.UTF-8
LANGUAGE=fr_FR.UTF-8:fr
LC_ADDRESS=fr_FR.UTF-8
LC_COLLATE=fr_FR.UTF-8
LC_CTYPE=fr_FR.UTF-8
LC_IDENTIFICATION=fr_FR.UTF-8
LC_MEASUREMENT=fr_FR.UTF-8
LC_MESSAGES=fr_FR.UTF-8
LC_MONETARY=fr_FR.UTF-8
LC_NAME=fr_FR.UTF-8
LC_NUMERIC=fr_FR.UTF-8
LC_PAPER=fr_FR.UTF-8
LC_TELEPHONE=fr_FR.UTF-8
LC_TIME=fr_FR.UTF-8
SYSFONT=lat0-16


cat /etc/sysconfig/clock
ARC=false
UTC=true
ZONE=Europe/Paris
Comment 8 Eric Petit 2023-05-12 20:00:21 CEST
One idea, if i write a script with a filewatcher to register a log file with timestamp=filename?
Comment 9 Eric Petit 2023-05-12 20:59:23 CEST
well, as you say, audio-recorder use another way.
The following script work with a new text file but not when audio-recorder create or close the file, i can use it as workaround to rename the file :

#!/bin/bash
rm -f ~/tmp/FileEvent.log

    while true
    do 
FileEvent=$(inotifywait -e create -e close_write ./ @./FileEvent.log)

date>> ./FileEvent.log
echo $FileEvent|tee -a ./FileEvent.log
    done
Comment 10 Lewis Smith 2023-05-13 09:06:09 CEST
I have just tried this on a Cauldron/M9 system, timezone Paris, locale GB, LxQt:
 audio-recorder-3.3.4-2.mga9
Note that the version is higher than as reported for M8, 2.2.3-3.mga8

Starting a recording produced a correctly timestamp-named file:
 "File" in the dialogue:      2023-05-13-08-29-27.ogg
 From 'ls -l': Mai  13 08:32  2023-05-13-08-29-27.ogg
It was a 3m recording, whence the later 'last written' timestamp. This concurs with comment 4.

version: 2.2.3 is over 4 years old; version: 3.3.4-jammy just 5 months (and nothing in between).

Perhaps just an update for Mageia 8? (DavidG is already CC'd in case).

@Eric:
if this newer version was put into updates_testing, would you be able to try it to see whether it improved your problem?
If it did not, it would not be worth pushing it for Mageia 8.

CC: (none) => lewyssmith
Source RPM: audio-recorder => audio-recorder-2.2.3-3.mga8

Comment 11 Eric Petit 2023-05-13 09:59:13 CEST
Hi,
In fact i did a mistake in my script and now it is work.
@Lewis i omit to say, i use audio-recorder with sound detection, see screenshot.
Comment 12 Eric Petit 2023-05-13 09:59:45 CEST
Created attachment 13832 [details]
Audio rec settings
Comment 13 Lewis Smith 2023-05-13 10:46:26 CEST
(In reply to Eric Petit from comment #11)
> @Lewis i omit to say, i use audio-recorder with sound detection, see
> screenshot.
This is probably where the confusion comes from. This looks like you ask it to start automatically on a certain condition (voice|mike >= 23%), then stop on another (any silence, or file size reaches 100MB) - plus a "start recording" button...
Is this meant to produce a lot of little files each time the mike is in use, and adapt the filename each time?

Looking again at your original screenshot
 https://launchpadlibrarian.net/665616521/audio-recorderbug.png
it looks as if it started a recording at 00:13, last modified at 02:50;
then another at 08:02, last modified at 08.24.
There does not seem anything to worry about here - that the program touches retrospectively a file it has created. So what?

(In reply to Eric Petit from comment #3)
> hum, dev with c knowledge cannot provide a fix patch as workaround?
Our diminishing packagers are not only very overworked, it is out of the question that they get bogged down in investigating & changing application software.

How would you describe the change you want? Just that the 'last modified' time of a audio-recorder file = its start time + duration?  Given that this *is* the case when you drive it manually (Start|Stop recording), it only seems to apply to automatic use. And does it actually matter?

You yourself could become a packager and look into it if you wanted to:
 https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
Comment 14 Eric Petit 2023-05-13 11:02:43 CEST
Well, I spent time to adjust correctly the mic volume and % détection, so there is no extra sounds files created.

I expected the correct time stamps/filename as proof, evidence in case of intrusion.

Perhaps there is another tool whose have this feature?
Comment 15 Eric Petit 2023-05-13 12:34:50 CEST
Created attachment 13833 [details]
compar log and files

As we can see, when file is created, timestamp and name are correct, but we also see "other events"! 
Most chance the bug are in this ghost events.

 ls -lah ./
total 1,1M
drwxrwxr-x  2 eric users  12K mai   13 12:21 ./
drwx------ 25 eric users 4,0K mai   13 06:21 ../
-rw-r--r--  1 eric users 417K mai   13 12:19 2023-05-13-12:17:55.ogg
-rw-r--r--  1 eric users  50K mai   13 12:19 2023-05-13-12:19:39.ogg
-rw-r--r--  1 eric users 171K mai   13 12:20 2023-05-13-12:20:22.ogg
-rw-r--r--  1 eric users 318K mai   13 12:21 2023-05-13-12:20:52.ogg
-rw-r--r--  1 eric users 130K mai   13 12:22 2023-05-13-12:21:46.ogg
-rw-r--r--  1 eric users 2,3K mai   13 12:30 FileEvent.log
Comment 16 Lewis Smith 2023-05-14 21:51:38 CEST
(In reply to Eric Petit from comment #15)

> As we can see, when file is created, timestamp and name are correct, but we
> also see "other events"! 
> Most chance the bug are in this ghost events.
One strange thing in the attachment is:
sam. 13 mai 2023 12:19:39 CEST
/home/eric/Dropbox/Audio/ CREATE 2023-05-13-12:19:39.ogg
sam. 13 mai 2023 12:19:39 CEST
/home/eric/Dropbox/Audio/ CREATE 2023-05-13-12:19:39.ogg
or is this an editing fault?

We must accept that these files seem to sometimes be touched after they are initially closed. Are they all DropBox, or is that a false trail? If they are, that could be the reason.

There is nothing we can do about this other than update the M8 version of audio-recorder and hope for the best.
@daviddavid : are you willing?
Comment 17 David GEIGER 2023-05-14 22:38:03 CEST
Please test upcoming audio-recorder-3.3.4-1.mga8 in Core/Updates_testing repo!
Comment 18 Eric Petit 2023-05-15 07:59:55 CEST
(In reply to Lewis Smith from comment #16)
> (In reply to Eric Petit from comment #15)
> 
> > As we can see, when file is created, timestamp and name are correct, but we
> > also see "other events"! 
> > Most chance the bug are in this ghost events.
> One strange thing in the attachment is:
> sam. 13 mai 2023 12:19:39 CEST
> /home/eric/Dropbox/Audio/ CREATE 2023-05-13-12:19:39.ogg
> sam. 13 mai 2023 12:19:39 CEST
> /home/eric/Dropbox/Audio/ CREATE 2023-05-13-12:19:39.ogg
> or is this an editing fault?
> 
> We must accept that these files seem to sometimes be touched after they are
> initially closed. Are they all DropBox, or is that a false trail? If they
> are, that could be the reason.
> 
> There is nothing we can do about this other than update the M8 version of
> audio-recorder and hope for the best.
> @daviddavid : are you willing?

i believe there was a file with 5 or 10 secondes and another one at 12:19:39.
yes, all dropbox, do you think it will solve the issue if i use another dir?

@daviddavid :  i check with 3.3.4
Comment 19 Eric Petit 2023-05-15 08:04:50 CEST
David, 3.8.3 version isn't good enough : https://bazaar.launchpad.net/~audio-recorder/audio-recorder/trunk/view/head:/debian/control
Comment 20 Eric Petit 2023-05-15 13:12:51 CEST
Created attachment 13845 [details]
log file with bug

Here, with the last version from testing, we see, file is CREATED but not CLOSE, 2 hours later, new sound detected and re use the same name file.
ls -lah ./
total 800K
drwxrwxr-x  2 eric users  12K mai   15 13:06 ./
drwx------ 25 eric users 4,0K mai   15 13:06 ../
-rw-r--r--  1 eric users 780K mai   15 13:01 2023-05-15-11:05:02.ogg
-rw-r--r--  1 eric users  307 mai   15 13:10 FileEvent.log
Comment 21 Eric Petit 2023-05-15 13:14:59 CEST
Perhap's storing file out of Dropbox dir, then use FSWatcher and use CREATE/CLOSE to validate the name file and then mv to dropbox?
Comment 22 Eric Petit 2023-05-16 09:52:03 CEST
Let's try the following script.

 #!/bin/bash
rm -f /home/eric/Audio/audio-recorder/FileEvent.log

    while true
    do 
FileEvent=$(inotifywait --csv -e create -e close_write /home/eric/Audio/audio-recorder/ @/home/eric/Audio/audio-recorder/FileEvent.log)

date>> /home/eric/Audio/audio-recorder/FileEvent.log
echo $FileEvent|tee -a /home/eric/Audio/audio-recorder/FileEvent.log
a=($(echo $FileEvent | tr ',' "\n"))

pathfs=${a[0]}
evfs=${a[2]}
fs=${a[3]}
#echo $evfs
#echo $fs

if [[ "$evfs" == "CLOSE"* ]]; then
    mv $pathfs$fs /home/eric/Dropbox/Audio/
    echo "$pathfs$fs moved to /home/eric/Dropbox/Audio/$fs"
fi
    done
Comment 23 Lewis Smith 2023-05-16 10:56:12 CEST
(In reply to David GEIGER from comment #17)
> Please test upcoming audio-recorder-3.3.4-1.mga8 in Core/Updates_testing
> repo!
Thanks for doing that.

(In reply to Eric Petit from comment #19)
> David, 3.8.3 version isn't good enough :
> https://bazaar.launchpad.net/~audio-recorder/audio-recorder/trunk/view/head:/
> debian/control
Do not understand this comment:
- did you try Mageia v3.3.4? Does it work? Same problem?
- re the link and 3.8.3, it is different from what we currently cite:
https://launchpad.net/~audio-recorder
which looks old, and stops at 2.2.3. However, it is the home site referred to from the link you gave!
- I could not find anything leading to 3.8.3 from your link, beyond mention of it.
This link looked hopeful:
https://bazaar.launchpad.net/~audio-recorder/audio-recorder/trunk/files/2197
but I could see nothing there that helps. The most recent entries are 1 year ago re 3.3.4, and no sign of a download. It is all flou.
- What do you mean by "3.8.3 version isn't good enough"?
Comment 24 Eric Petit 2023-05-16 11:21:27 CEST
@Lewis yes my last test was from "testing" repo, so 3.34
For 3.8.3 : https://bazaar.launchpad.net/~audio-recorder/audio-recorder/trunk/view/head:/debian/control

With the script; the problem still here :

mar. 16 mai 2023 09:56:01 CEST
/home/eric/Audio/audio-recorder/,CREATE,2023-05-16-09:56:01.ogg
mar. 16 mai 2023 09:56:01 CEST
/home/eric/Audio/audio-recorder/,CREATE,2023-05-16-09:56:01.ogg
mar. 16 mai 2023 10:00:02 CEST

mar. 16 mai 2023 10:05:02 CEST

mar. 16 mai 2023 11:05:38 CEST
/home/eric/Audio/audio-recorder/,"CLOSE_WRITE,CLOSE",2023-05-16-09:56:01.ogg
mar. 16 mai 2023 11:10:02 CEST

My opinion is, in audio recorder, the button have 3 functions, start stop or continues record, so for mystery raison, the record start and rather stop wait to record again, this produce a file with lets say 5 sec of sound at 10h00, wait 1,2 hours and continue to rec 5 or 10 seconde a 12h00, or perhaps it overwrite the file!
Comment 25 Eric Petit 2023-05-16 11:29:32 CEST
My initial config say to stop when if silence | 100MB, but audio recorder pause rather stop, so if i understand the doc, i will try : stop after 100MB | silence 3s
Comment 26 Eric Petit 2023-05-16 11:46:00 CEST
OMG, this not a bug, my computer is noisy, so audio-recorder never got "silence", to solve this :
stop after 100MB | silence 4s 18%
is the good setting!! Sorry for the inconvenance and time loose!

Resolution: (none) => INVALID
Status: NEW => RESOLVED

Comment 27 Lewis Smith 2023-05-17 20:52:12 CEST
Thank you for discovering the problem, and closing this. Yes, it did cause a lot of 'noise' [sic]...

CC: lewyssmith => (none)


Note You need to log in before you can comment on or make changes to this bug.