https://launchpadlibrarian.net/665616521/audio-recorderbug.png

There's not much we can do unfortunately if upstream itself doesn't fix the issue.

hum, dev with c knowledge cannot provide a fix patch as workaround?

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

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

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.

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

One idea, if i write a script with a filewatcher to register a log file with timestamp=filename?

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

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

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.

Created attachment 13832 [details]
Audio rec settings

(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

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?

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

(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?

Please test upcoming audio-recorder-3.3.4-1.mga8 in Core/Updates_testing repo!

(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

David, 3.8.3 version isn't good enough : https://bazaar.launchpad.net/~audio-recorder/audio-recorder/trunk/view/head:/debian/control

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

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?

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

(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"?

@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!

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

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

Thank you for discovering the problem, and closing this. Yes, it did cause a lot of 'noise' [sic]...

CC: lewyssmith => (none)