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.
CC: (none) => geiger.david68210Summary: Filename and timestamp are not synchro. => audio-recorder: Filename and timestamp are not synchro?
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) => lewyssmithSource 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) => INVALIDStatus: NEW => RESOLVED
Thank you for discovering the problem, and closing this. Yes, it did cause a lot of 'noise' [sic]...
CC: lewyssmith => (none)