Fairly simple and thought you may find it useful to know that under Server 2016 Technical Preview 5 (and let’s just skip the “why are you running it on that”…) the timed record function does not work correctly. The recording will start at the correct time, but will continue to run indefinitely and will not stop without closing the program via Task Manager.
Technical Preview 5 is freely downloadable via technet/MSDN if you wish to see for yourself this behaviour.
Thank you very much for the report.
It’s good to have people tell us about Audacity experiences on different platforms and variations of platforms.
Koz
Glad to be of assistance. Figured it might be worth looking into the cause/solution for future versions of Audacity.
Thanks - but I very much doubt the issue is confined to that unreleased version of Windows. Server 2016 is based on Windows 10. A very few people on both Windows 10 and Windows 7 have said that Timer Record fails to stop in Audacity 2.1.2. None of us can reproduce the problem.
If you would like to help more, does this build have the same problem on any of the Windows versions you are using http://audacity.tip2tail.scot/builds/20160414-A-tip2tail.zip ?
Gale
The new build unfortunately still has the same problem on testing it. I never experienced this problem under 7 Pro (or Embedded 7), or 8.1, both on the same hardware. If I have the chance I will try it out on 10 (LTSB Edition) shortly. Happy to do what I can here.
Sidenote - very happy to see the addition of the automatic saving option on timed recording. I do a lot of overnight recording, that will not only let me get a safe copy saved as soon as the timer expires when it works, but will mean I can also then set up to kill Audacity’s process shortly after doing so.
I have found a slight difference in behaviour when running these builds on 10 that seems like a hint toward the problem. For the record - same drivers, same hardware.
Basically, when tried under 10 the recording and counter proceeded normally as long as focus was left on the timer window - it would record and stop at the correct time. (The counter also works properly for starting recording no matter what). Something that would cause it not to be in focus (as simple as clicking the clock to bring the calendar up, or any other window) would instantly stop the timer from counting down. And it would pick up again (jumping to the correct number of seconds that had elapsed) the moment the timer was focused on again, then continue and stop as normal at the correct time.
The behaviour on Server is slightly different - interestingly so - in that once the recording starts (again recording starting timer works fine), the remaining time timer will stop counting down after a few seconds (approx 8) even if the focus is left on it, and there seems to be no way to avoid this. Unlike 10, it does not pick up again at all. It’s almost as if Windows is suspending the timer when it isn’t the focus in 10, and suspending it regardless after a few seconds in on Server.
I hope this is of use, and if there’s anything else I can try to help please do ask.
Thanks for the information. Needless to say I don’t see the problem on Windows 10 where the timer loses count when leaving the Audacity window.
Can you say what you are recording? Is it a USB recording device?
Also would you be able to compare these two older builds?
The later build was the first after we moved to wxWidgets 3.0.2. I am guessing that the later will fail for you.
Gale
It is a USB recording device - although the device worked perfectly with Embedded 7 for months prior, and 8.1.
(EDIT: Just tried it with another device - both inbuilt and external mic on the line port not using the usb - and the same behaviour occurs, again after 8-9 seconds in Server regardless of focus.)
I will try to test out those two builds in Server and 10 later.
but you do realise that Windows Server 2016 Technical preview 5 is not a supported platform for Audacity?
Audacity is built using wxWidgets, and that does not officially support Windows Server 2016 Technical preview 5.
And of course, nobody should ever attempt to run software on a new platform and expand the list of platforms known to work perfectly well with it, even in an “unsupported” manner.
The behaviour also exists on Windows 10 - Server with bells and whistles and more running services and processes but identical for 90% of daily tasks. Audacity also worked on previous Server versions. Comparing how it behaves on Server and 10 tells us new things potentially, hinting at what may be the cause of the problem on 10, which is a supported platform. I would presume they aren’t “supported” simply because they are seen as vastly differing by the majority of people due to being uncommon, when in reality, they aren’t when configured properly. Very few programs will specifically “support” Server, mostly because they just don’t know what any change might bring.
I hope that explanation will suffice. Certainly it seemed to hint toward something in 10. Someone noted as Quality Assurance seems interested in trying to figure out why this happens for people, officially supported or not. If I can contribute something by testing here, I’ll do so quite happily.
And as it happens regarding the two posted builds… I have tested these out on Server just now and, well… the timer works.
Yep. Seriously. The problem does not exist in these two builds.
Both builds run, and In BOTH of them, the timer works. Absolutely perfectly. Recordings will start at the correct time on the timer, and stop at the correct time, with absolutely no difference made as to whether focus is left on them or not. I tried several times, and each time it worked as perfectly as it should do.
Haven’t had a chance to try on 10 yet but will do so within a few hours.
Personally I like the fact that some users manage to get Audacity working on unsupported platforms. I was just ensuring that you were aware that Server 2016 Technical Preview 5 is not officially supported, and is unlikely to be officially supported unless it is officially supported by wxWidgets.
As I said further up, the problem does occur for a few people on Windows 7 too.
I largely agree with your points about Server versions of Windows. They are not conceptually a lot different to the more advanced editions of standard Windows. The main issue with Server 2016 is that it is an as yet unfinished release.
I am more interested than if you were only on Server 2016. 
Thanks. Just a note that to test you must shut down the other Audacity version. Executing another version while Audacity is already running will only switch window to the running version.
The complete list of alpha builds is here http://gaclrecords.org.uk/win-nightly/ - just in case you do pinpoint a build where the problem started.
Gale
Personally I like the fact that some users manage to get Audacity working on unsupported platforms. I was just ensuring that you were aware that Server 2016 Technical Preview 5 is not officially supported, and is unlikely to be officially supported unless it is officially supported by wxWidgets.
I guess I misinterpreted slightly some of the bluntness of the post, but that being the case we’re good.
I did close the other versions of Audacity before running another - I’m fairly used to testing software in a more professional manner than most for what it’s worth.
I’ll try out 10 with the other builds tomorrow if able, and I’ll attempt to find the point where the problem starts.
And (at least on Server) I’ve tracked it down. The last build where the timer works properly is the one labeled;
audacity-win-rdfcad8a-2.1.2-alpha-14-aug-15
From audacity-win-r9397ae2-2.1.2-alpha-15-aug-15 onward, the timer will exhibit the behaviours discussed previously, and won’t stop the recording as the timer no longer counts down.
Will try on 10 later to see if the builds act the same there.
EDIT: Builds up to the audacity-win-rb9bc452-2.1.2-alpha-19-aug-15 have worked so far on 10 (where the final release build still doesn’t), so I’ll have to dig through builds after that later today to see where the behaviour kicks in on that too.
Thanks. So I assume this commit https://github.com/audacity/audacity/commit/13c7484 is most likely to be responsible. That commit was fixing an issue that started with the switch to wx3 in r3715b21-2.1.2-alpha-31-jul-15 where there was no metering or waveform during Timer Record.
To assist that, here is the history of the ProgressDialog.cpp file changed in commit 13c7484 above:
https://github.com/audacity/audacity/commits/master/src/widgets/ProgressDialog.cpp.
So you might find it breaks after https://github.com/audacity/audacity/commit/6cfce50 which commit would be in http://gaclrecords.org.uk/win-nightly/index.php?dir=&file=audacity-win-r33cce4e-2.1.2-alpha-03-sep-15.zip, and the build before (http://gaclrecords.org.uk/win-nightly/index.php?dir=&file=audacity-win-r0235c80-2.1.2-alpha-02-sep-15.zip) would not fail.
Gale
I will jump back into testing on 10 in a few days time.
I came here to investigate this problem which I’m seeing with the following build:
Program build date:
Jan 9 2016
Commit Id:
53b8fd5 of Fri Jan 8 22:05:48 2016 +0000
Build type:
Release build
I’m running on Windows 10 Pro. The recording runs indefinitely and I’ve noticed that the focus on the modal dialog is key. If I click ‘stop’ it will grey out the button, but doesn’t stop. If I leave the focus on the dialog then it will eventually stop.
So you have 2.1.2 release.
If you wish to, please tell us if http://gaclrecords.org.uk/win-nightly/index.php?dir=&file=audacity-win-r33cce4e-2.1.2-alpha-03-sep-15.zip fails to stop recording automatically or when Stop is pressed, and if http://gaclrecords.org.uk/win-nightly/index.php?dir=&file=audacity-win-r0235c80-2.1.2-alpha-02-sep-15.zip stops correctly.
We can’t test that ourselves because the problem does not happen for us.
Thanks.
Gale
Just logged on to say I haven’t forgotten this but I will have to return to 10 testing in a few days - hopefully some point next week - due to a failing drive.