* Ed -- In \src\widgets\Meter.cpp at or near line#469 I see the following comment and wonder who made it and if it sheds some light?

void Meter::Reset(double sampleRate, bool resetClipping)
{
   [...]
   // wxTimers seem to be a little unreliable - sometimes they stop for
   // no good reason, so this "primes" it every now and then...
   mTimer.Stop();
   // While it's stopped, empty the queue
   MeterUpdateMsg msg;
   while(mQueue.Get(msg)) {
   }
   mTimer.Start(1000 / mMeterRefreshRate);

(In reply to comment #1)
> * Ed -- In \src\widgets\Meter.cpp at or near line#469 I see the following
> comment and wonder who made it and if it sheds some light?
> 
> void Meter::Reset(double sampleRate, bool resetClipping)
> {
>    [...]
>    // wxTimers seem to be a little unreliable - sometimes they stop for
>    // no good reason, so this "primes" it every now and then...
>    mTimer.Stop();
>    // While it's stopped, empty the queue
>    MeterUpdateMsg msg;
>    while(mQueue.Get(msg)) {
>    }

Dominic wrote that back in 2004. Easy and quick to see with the CVS Annotate feature in TortoiseCVS, but looks like you need to usethe command line in SVN.

may only affect Windows--not All
not repeatable
may be cured in wxWidgets 2.8.11+
--Ed

Created attachment 12 [details]
Audacity 1.3.13a with wx2.8.11 for testing bug

Sent to Gale but was blocked (most likely due to size of attachment)

1.3.13 alpha built with 2.8.11 still runs past the scheduled end of recording for Peter on Windows XP. 

http://forum.audacityteam.org/viewtopic.php?f=18&t=30701 contains a suggestion that this problem exists on Linux too (1.3.12 on Ubuntu 10.04 against wx 2.8.10).

1.3.13 Nightly build on Windows has contained Nikolay's patch for Bug 43 for a couple of months. It seems to have reduced instances of the bug for Peter bar one occurrence, but the freeze is still happening e.g. for a 1.3.13 alpha user in this Forum thread: http://forum.audacityteam.org/viewtopic.php?f=16&t=36671  

That user seems to get the freeze after 5 seconds of recording, when setting a long recording of several hours to start after a wait of one hour.

Reports have considerably declined of late. Since last comment, Peter Sampson has I think not experienced this issue. Others who were badly afflicted with the issue only see it very occasionally, but 1.3.13 Beta (Win XP SP3) does have one report against it for an hour long recording starting at 21:00 (stereo mix from built-in Realtek device).   

Ubuntu 10.04 user above who had the issue frequently in 1.3.12 reports it stopped as soon as he bought a more modern computer. Another Ubuntu user on 1.3.12 has seen the issue twice (out of a few hundred recordings) since the last comment.

(In reply to comment #7)
One report of apparently frequent occurrences in 1.3.13 on XP 64-bit, weekly show from 23:00 to 01:00 next day. Have asked for more details.

Marked as 'cherry' but now removed again as this is a moonphase.  Consider demoting from P3 due to moonphasiness and reduced incidence.

(In reply to comment #9)
>  Consider demoting from P3 due to moonphasiness and reduced incidence.
Done. I only see a few reports per year of this now (last was six months ago).

I am a very regular user of Timer Record, using it several times a week to timeshift radio shows and internet webcasts.  Whilst it used to exhibit this behaviour for me occasionally with the early-mid 1.3.x releases I can safely say that I do not recall this happening ever on either the 2.0.3 release nor the 2.0.4 alphas that I have tested regularly on.  Nor has this occurred during 2.0.4 RC1 testing.  

Maybe we could consider closing this bug?

(In reply to comment #11)
Since my last comment, a couple of people reported it on Linux (one in 2.0.4-alpha). No reports on Windows or Mac.

I think we should leave it open at P5.

(In reply to comment #12)

I note this is with version 1.3.13. What version of those OSes are they using? 

Has it happened at all on subsequent versions? What about the "replaces all previous versions" phrase we use for each release? 

In other words, is this still a P5? Just asking, because I'm reviewing Timer Record bugs.

I use this feature several times a week on W7-HP 64-bit mainly with Alpha nightlies - and I never get this occurring any more.

Two reports of this in 2.1.2 on Windows 7 and 10. The incident on Windows 7 was a recording spanning midnight. 

I have tried making a timed recording that spans midnight several times on Windows 7 and Windows 10 in 2.1.3-alpha without any failure. 

It is possible the wx3 update has reinvigorated this moonphase issue. Promoted to P4 for now.

Every week I make a two hour recording that spans midnight for the last two years or so - W7 formerly and latterly W7 - it has never faltered .

Where we know the device concerned for the 2.1.2 reports, it is a USB recording device.

Very short Timer Recordings of a few seconds always stop correctly for the affected users.

Peter noted in bug 1379 that on one day only, if he stopped Timer Record after more than about 10 seconds of recording had elapsed, the recording continued regardless. This was not reproducible subsequently, and no-one else could reproduce it at the time. 

This is not dissimilar (in length of time) to behaviour occasionally reported in 2.1.2, where recordings scheduled to last longer than 8 seconds do not stop on completion, but recordings scheduled to last less than 8 seconds stop themselves automatically. More than a dozen users have reported this in 2.1.2 and we now have an indication (see below) that the problem is not the transition to wx3 but subsequent fixes to the progress dialogue. I am raising this to P3 with updated release note and a workaround for some cases.

The URL above now refers to a Forum user on Windows 10 and Server 2016 Preview. For this user, on Win 10, the timer stops counting when Audacity 2.1.2 loses focus and resumes correct count when Audacity regains focus. As long as Audacity has focus when recording is due to stop recording, recording will stop correctly, otherwise not. Gale tried this on Win 10 but cannot reproduce it. 

But for this user on Server 2016, the timer stops counting after 8 seconds whether Audacity has focus or not, so recordings longer than this never stop themselves. This behaviour started from build r9397ae2-2.1.2-alpha-15-aug-15, so presumably https://github.com/audacity/audacity/commit/13c7484 is the cause. But Windows 10 Timer Recording still behaves correctly for this user at b9bc452-2.1.2-alpha-19-aug-15.

The most relevant commit subsequent to 19 Aug 15 appears to be https://github.com/audacity/audacity/commit/6cfce50 but it is not yet verified if this is the point at which Win 10 timing fails.

*** Bug 1379 has been marked as a duplicate of this bug. ***

Another user on Windows 7 finds that the build "r0f79a77-2.1.2-alpha-12-aug-15" stops recording at the requested time, and so does "rdfcad8a-2.1.2-alpha-14-aug-15". 

But "r0235c80-2.1.2-alpha-02-sep-15" does not stop recording at the requested time. The Elapsed and Remaining time stop counting after 14 seconds.

Switching focus from Audacity does not prevent recording completing in "r0f79a77-2.1.2-alpha-12-aug-15". The user has not said yet if leaving focus on "r0235c80-2.1.2-alpha-02-sep-15" enables it to stop recording at the requested time.

Now also reported in 2.1.2 and 2.1.3-alpha on OS X 10.7.5 32-bit, so changed platform and release note.

This bug is 100% repeatable on my Win 10 x64 machine if I build Debug, but still not reproducible at all if I build release.   

Can anyone building Debug on Windows reproduce it? I get it with every Timer Record over 8 seconds. The progress bar and timer countdown stops and recording continues indefinitely (it can't be stopped with the Timer Record progress dialogue). CPU use rises to 50% or so (dual core). 

If no-one else gets it,  in case it's a fluke that will go away after reboot, can someone tell me offlist of any useful information I can produce from debugging inside Visual Studio (baby steps required, sorry, given there isn't a crash).

(In reply to Gale Andrews from comment #22)
I tested this with the 15Jan17 Debug build for Mac on my Macbook Pro with Sierra 10.12.2 and cannot reproduce this at all.

Over the past months I have been using the Timer Record on latest alpha nightlies on my W10 laptop 3 times a week (or more) with one to two hour recordings and it has never failed to honor the set timings, always completing accurately on time and with no over-run.

(In reply to Peter Sampson from comment #23)
> I tested this with the 15Jan17 Debug build for Mac on my Macbook Pro with Sierra 
> 10.12.2 and cannot reproduce this at all.
Debug builds on Mac Sierra and Ubuntu 14.04 32-bit don't exhibit the bug on my machines.

I too have been using Timer Record (both the old and new versions) for many months and have never had this happen to me either.

Very strange behaviour!

Promoted to P2, though still moonphase, given it's being reported once or twice per month, and Peter can now reproduce it sometimes on his Win 10 machine and on his wife's Win 10 notebook.

Whether related to 42 or not, Timer Record clearly uses excessive CPU in 2.1.2 and later. 

In 2.1.1, debug or release build, Timer Record uses about the same CPU (~10% of two cores on my machine) as standard recording. 

In 2.1.2 and later it's 40% to 50% of two cores, whether bug 42 presents or not. It takes about 3 seconds to reach 25% CPU and another 3 seconds to reach 50% CPU. In debug builds, I must stop the Timer Recording within 3 seconds to avoid force quitting Audacity.

(In reply to Gale Andrews from comment #26)
>Whether related to 42 or not, Timer Record clearly uses excessive CPU in 2.1.2 and later. 

I confirm this.

On my W10 laptop normal record takes a maximum 3% CPU loading
With Timer Record it's up to ten times that at maximum 30% CPU  a 10x factor.

But here's the interesting thing - fir the first seven seconds TR takes only the 3% CPU and then rapidly starts to climb to the 30%.  But the other thing to notice is that at 7 seconds (just as the CPU usage climbs) the two slider knobs on the Mixer Toolbar start to flash wildly away and continue to do so - plus you get the occasional flash from some other toolbars.  

It looks as though Audacity is frantically and unnecessarily redrawing the Toolbars (remember the Toolbars are hors de comabt and inaccessible to the user while Timer Record is operational).

Does not occur on 2.1.1 and earlier where the Timer Record consumes just the same maximum 3% that normal Record takes.   Does occur on 2.1.2 and 2.1.3 RC2 and audacity-win-r0efe931-2.1.3-alpha-03-mar-17

On macOS 10.12.3 Sierra, Timer Record users only marginally more CPU than normal record. 40% versus 36%.

And there is no increas after 7 seconds or any flashing of the two slider knobs on the Mixer Toolbar

I experienced this moonphase bug forv the first time in a very long time last night waking to a a still running 8 hours of recording that was scheduled to stop after 2 hours.

The Timed Recording could not be stopped with the Stop button - I was forced to use Task MAnager to abort the Audacity app.

On re-launching Audacity I was fully expecting to see Auto-recovery do its job- but no all it lauched was a clean empty Audacity window with no offer of recovery.

When I had set up the TR last night I had pre-saved the project (empty) and then set TR to automatically save on completeion.

I attempted to open the Audacity project - I got an warning message of thousands of orphan filles - I elected to continue without deleting those.  The project them opened as an empty project. 

On exaining the folder in which I had saved the project I foulnd the .aup file (short and terse) and a folder full of folders and .au files (10.5 GB 10,602 files 42 folders).

What vexes me most is that we go to all the bother of saving all the .au files yet never bother to periodically (say every 5 or ten minutes) save the .aup file.  I would have been quite happy with 7 hours and 50 minutes of project.

W10 audacity-win-rde70727-2.2.0-alpha-23-jun-17

MikeW365 wrote on the Forum on Sunday:
Using Windows 10, Audacity 2.1.3, installed with exe installer.

>Would love to use the automatic save and export in 2.1.3 but after a few 
>seconds of recording, the timer stops, the recording continues, and I can 
>only exit Audacity with Windows Task Manager.
>
>Have tried all permutations, only using save, only export but it always 
>freezes. Have installed 2.1.3 on another pc and my laptop and get same 
>result. Help would be appreciated.

In response to a request from me he retested on 2.2.0 RC1 and the same thing happened

A couple of recent reports (3 users) of this on the Forum:

https://forum.audacityteam.org/viewtopic.php?f=46&t=98242&p=339574
for both users her the time stops at 10-12 seconds but the recording continues until force quit with Task Manager.

https://forum.audacityteam.org/viewtopic.php?f=47&t=93659
see the recent 25Dec17 post for the latest occurrences for user Hogan, whey they report 25-50% occurrence rate.

Since users Turbofiat and FL Coast both report in this Forum thread
https://forum.audacityteam.org/viewtopic.php?f=46&t=98242

that this errant behaviour occurs at the 10 second mark or so, I decided to do a little testing (based on earlier reports in the bug thread of excessive CPU usage by Timer Record - Comment #26 and Comment #27).

So, testing on my whizzy new(ish) 256 SSD W10 laptop I find:
a) Normal recording consumes just under 3%  of CPU
b) Initially Timer Record consumes 3% of CPU
c) After 8-10 seconds Timer Record CPU shoots up by 400%  to 15% or so - and continues that way

So it looks as though some Timer Record event occurs at the 8-10 second mark - but what it is I have no idea (but this may offer a clue).

I also note that when Time Record is underway (testing on W10 on 2.2.1 and 2.2.2 alpha) for the first 8 seconds or so when the CPU usage remains low the sliders are nicely static.

After that time the sliders in the Mixer Toolbar and the Transcription Toolbar flicker as though they are being (unnecessarily) redrawn.

I also observe similar occasional flickering of the icons in the Device Toolbar.

Occurs at full size window and minimized windows for Audacity.


With normnal recording no such flickering occurs.

User feedback (geneware)from the Forum:

Got a new computer running Windows 10 Pro workstation 1709, and installed 2.2.2. For the two times I used timer record, it did not stop. I never had a problem on the old computer. Used task manager to stop it, then recovered the project.
But this last time, after recovery, I then ran a silence finder, and saved the project. No save progress bar popped up, looked like Audacity froze, but a few minutes later the project had been saved.
Then I tried to export multiple, and again no dialog window popped up, Audacity froze.
Could there be a problem with dialog windows not getting the focus? I can't see if there is a window behind the main Audacity window because it is frozen, any click on the main window just gives a warning bell. All other windows/tasks seem fine.
Again I killed it with task manager, recovered the project (warning about orphan files was ignored), tried to save multiple again, and it worked.
So it gets there eventually, just very awkward.
To help with debug, in the same Audacity window that just saved multiple, I asked for a 1 minute timer record. The timer window pops up and says elapsed time=0, time remaining=0. It records past 1 minute, click on the stop button, window pops up to ask if I really want to stop, click on yes and the window goes away, but nothing happens. Time for task manager.



Update on previous post: Don't know if this affects timer record, but all the other issues were due to dialog windows being opened off-screen. I can press Alt-Tab Window shortcut repeatedly to select the hidden window, then Alt-Space to get the move option, and move the window back on screen with arrow keys. Every dialog opened just beyond the upper left corner. But after moving a bunch one by one, I finally closed Audacity, reopened, and now the dialog windows open on top of the main Audacity window. Just needed a clean exit for window locations to be saved?
For the developers, the new computer has dual 4K screens, that may have started this Window confusion.
Then I tested timer record, asked for 1 minute, and exact same events, elapsed time=0, time counters do not move, try to stop the recording after 2 minutes and the stop button window will not close, hangs up and is greyed out. Task manager kill.
Reopened Audacity, tried a 1 minute timer record with auto save/quit Audacity, and no success. Elapsed Time counted up to 12 seconds, then stopped. Recording did not stop, Audacity did not exit. Stop recording window hangs up. Task manager kill.
I will keep trying every month or so, maybe the issue will not be permanent.

And now we have a user for whom Timer Record fails every time:

Deleted old version / downloaded latest version of Audacity 4/18/2018 to my Windows 10 laptop - activated timer record function and while it started on time, it did not shut off at the selected time which was 2 hours and 8 minutes from start...I had to force a stop with Task Manager. I also had this same problem with the earlier version of Audacity. Is there a fix or setting change I've missed?

Yes, it happens every time I use the Timer record function - and the same was true before I updated to the latest version of Audacity...did the update on 4.18.18. I have no problem exporting the file as an mp3 or saving the .au file. I'm just stymied as to why the timer record function does not stop at the pre-determined stop time.

See this Forum thread:  https://forum.audacityteam.org/viewtopic.php?f=46&t=99713

Created attachment 760 [details]
Another user for whom this fails cionsistently on 2.2.2

So now we have a second recent user on the Forum for whom this fails all the time:
https://forum.audacityteam.org/viewtopic.php?f=46&t=99729&start=10

But it is still working consistently and regularly for me, apart from the one moonphase failure last year - see Comment #29

If we continue to get reports of consistent failures we may need to consider raising the priority of this bug to P1

James has created a possible fix for this with:
https://github.com/audacity/audacity/commit/6325b443d6679d59e45c38d9f9fed30bd0d81fb6

I have supplied this test build to 7 users on the Forum who consistently get this bug.

One, FLCoast, has tested and replied so far (looking hopeful) - his response:

Hello Peter,

All I can say is that you and your team are fantastic. The Audacity 2.3.0 Alpha version fixed the Timer Record problem I had on My HP Laptop. I ran it through the paces several times. The Timer Started, Stopped, and Saved as expected.

The only issues I noticed were:

The VU meters were slow to react while recording
The elapsed time was slow updating. It would update every 2 to 11 seconds.
Under “Options” “After Recording completes” “Exit Audacity” would hang on the “Save Project” dialog box until clicked. It may be designed this way, I just never tried it on my desktop.

The first two items would also happen even if you were just recording without the timer. I’m sure these issues are because it is an Alpha version.

I replaced my antiquated desktop recently and the new desktop has Windows 10 Pro, and Audacity Version 2.2.2 Record Timer worked without issues. So the problem was isolated to my laptop with Windows 10 Home.

I hope everyone else that reported this problem and is testing Audacity 2.3.0 Alpha has the same results I’ve had. I am looking forward to the release of the new version.

Again Peter, Thank You and your entire Development Team for the response.

All the Best,
Wayne

Wayne (FLCoast) subsequently wrote:

Peter,
I just realized that I had downloaded Audacity-2.3.0-alpha-4766583.zip last month which was Audacity 2.3.0-alpha-Jun 19 2018, and that is the version I actually ran the test on. So It worked.

I then went back and ran audacity-2.3.0-alpha-52-6325b443d6679d59e45c38d9f9fed30bd0d81fb6.zip, which was Audacity 2.3.0-alpha-Jul 22 2018, the version you had in the drop box and it too worked.

Just to make sure something had not changed on the machine, I went back and tested version2.2.2 again, and it still did not work.

I don't know if your developer had made the change prior to the Jun 19 2018 release or not, but it worked. If he didn't make changes then, what did change?

Sorry for making this confusing.

Wayne

2nd user - geneware reports:

I tested the 2.3.0-alpha-52 version made available by waxcylinder:
Ran a 5 minute timer record with auto save/exit. Everything worked.
Ran my old audacity version 2.2.2, timer record failed as usual.
Ran the alpha version with a 2 minute timer record, no auto save. It worked.
Bug fix looks good!


So that's 2/7 so far

3rd user wrote:

Here are my initial results:
Each recording session did start and stop properly.
Observed that the Progress bar, Lapsed time. Remaining time updated intermittently, not predictably.
One attempt started on time but did not stop until I hit CANCEL. This happened only once. (Setting error?)
Once started, trying to stop a recording by hitting Cancel did not stop the recording. The popup “Do you wish to stop” / “Yes” was there but recording did not stop.
(Also added feature requests and other issues that I will deal with separately

So if the non-stop is user-error as the poster suggests then it looks as though TR is stopping properly.

(In reply to Peter Sampson from comment #41)
User number 4 wrote today:

I downloaded version of Audacity 2.3.0-alpha-Jul 22 2018.

First, the timer worked perfectly and stopped early with no error. Also ran to conclusion and stopped correctly. With the timer working, I tried all other functions, ie, Save Project As, Export Project etc., and all worked perfectly, focus on and focus off. It was obviously just a timer problem.

Running Windows 10 Pro, Version 1803, on a Dell Optiplex 745, 3GB RAM.
1.87 gigahertz Intel Core 2 Duo, 64 bit ready. This is my old machine which, in the past, was unable to use the timer on Audacity 2.1.3.

https://github.com/audacity/audacity/commit/6325b443d6679d59e45c38d9f9fed30bd0d81fb6 appears to have ameliorated the problem.  Audacity now tries to take two events of the queue and process them each time instead of one, and ignores fewer event types.

The significantly improved results from users who had the problem consistently is suggestive that the underlying problem may be extra extraneous events from cheap badly behaving sound cards/drivers.  This is suggested by the fact that on two of the users machines who have reported about it, screen updates are very laggy (11s for a meter and waveform update, 5s for a time update) when recording.

Timer record would be particularly sensitive to extra events, and now less so.  We could perhaps progress that theory by asking one of the users to try with an external sound card with different drivers.  If it works fine with older audacity, that tends to confirm the theory.  If it still is laggy then the built-in soundcard and default driver is not the root cause.

(In reply to James Crook from comment #43)
>Timer record would be particularly sensitive to extra events, and now less so. 
>. We could perhaps progress that theory by asking one of the users to try with 
>an external sound card with different drivers.  If it works fine with older 
>audacity, that tends to confirm the theory.  If it still is laggy then the
>built-in soundcard and default driver is not the root cause.

BUT - what Wayne (FLCoast) wrote was:
>When recording with version 2.2.2 the VU meters and waveform flow smoothly.
>
>When recording with version 2.3.0-alpha the VU meters and waveform are very 
>jerky (erratic) in their advancement. This worsens slightly when using the 
>Timer Record. Playback of the recorded material sounds fine.

So what Wayne us reporting here is a degradation from 2.2.2 (where there were no jerks) to 2.2.3 alpha where he does get jerks - but only on his old machine.  On his new machine 2.3.0 alga Records without jerks in the meters and waveform.


The recording jerks are a secondary residual issue (which should probably be logged as a fresh bug) - thus far we have had 5/5 testers reporting RR success with 2.3.0 alpha - where formerly it failed, and still does, on 2.2.2

So testing with an external soundcard on Wayne's old machine would be a test of the residual (as yet un-logged) bug and not this Bug #42


We are still waiting to hear from a further 2 testers re. this Bug #42

One of my five testers who previously reported a problem with TR on this alpha version now agrees after retesting that it was his sound card that was at fault.

So wenow have 5/5 testers for whom TR used to fail on 2.2.2 and earlier, by not stopping - and for whom it now works and stops pearly at the appointed time with the 2.3.0 test alpha that we supplied to them.  

It is a fortnight since I put out the test call to 7 potential testers - the remaining two have not responded and I thus assume they will not respond.

I am therefore going to close this bug a FIXED

Actually, the success rate is 6/6 with only one non-responder