waxcylinder wrote:bwoods wrote:Where do you report bugs?
Currently on the Audacity Wiki - But I've started thinking about a process for moving real bugs (sometimes folks report things that aren't actually bugs) over to the Wiki from here.
Peter, bugs should *not* be reported on the Audacity Wiki, because it is not set up to handle them (if you reported this possible bug there, it was just missed I'm afraid).
Bugs noticed by users should be reported by e-mail to:
feedback AT audacityteam DOT org
after having read this page on the Wiki:
http://audacityteam.org/wiki/index.php? ... rting_Bugs
Alternatively, just e-mail me or send me a PM.
We do need a process for moderators to notify bugs which have been reported by Forum users. Sometimes, bugs can be mentioned merely as an "aside" in a topic and easily missed. Generally, developers aren't going to have time to look here for bugs, even though I do try and keep an eye open.
Ideally our
Known Issues page for Beta issues reported since the last release should be more up-to-date, but for now, checking the
Release Notes for the latest Beta and then
Release Checklist should give you a good idea if we already know about the problem.
Peter, if you found it easier, you could create a "Pending Bug Reports" Wiki page analogous to "Pending Feature Requests" for transferring reports of possible bugs from the Forum, but e-mailing me or the feedback address would work just as well I think, if not better.
waxcylinder wrote:bwoods wrote:I had this same problem. It straddled midnight.
It's odd as this is not consistent for me - it ony seems to happen when the recording straddles midnigh - but it is not consistent, it doesn't always happen. Developers HATE those kind of bugs ....
Yes we do, and we're very interested if anyone can produce a scenario for us that will let us reproduce the problem. Recordings carrying on past the scheduled time if they straddled midnight was reported back in previous Betas but not since, so I thought we had fixed it.
I have identified one issue that I can reproduce that might or might not be related. I reset the system time to 23:57 because it had already passed midnight, and scheduled a recording in Audacity 1.3.8 alpha on Windows XP finishing at 01:07. Everything was going fine until 40 minutes into recording when the utility I have that synchronises with an atomic clock reset the time to the correct 01:27. At that point the progress bar in Audacity Timer Record Progress reset to the beginning, the Elapsed Time and Remaining Time froze, and recording carried on after the intended 70 minutes. However I could click cancel in the Record Progress dialogue to stop the recording and save or export it.
I also tried resetting system time during recording so that system time was now close to the scheduled end of recording (rather than after it), and the progress bar jumped to reflect the changed system time and completed recording at the scheduled time even though the duration requested is not correct. This will need looking into if we can still use the timer that started counting even though the system clock changes during the recording.
Otherwise, can I just ask those doing frequent recordings with Timer Record to keep a note here of unusual behaviour.
* What is the Elapsed Time showing, if the dialogue freezes?
* Does the actual time of freeze (calculated from the Elapsed Time) relate to any system event, such as a change in system time, a Windows Update, a power saving event or anything similar?
* Every report I have seen of this so far has been on Windows, so if you are not on Windows, please state the operating system
Thanks
Gale