Timer recording does not want to stop !

[phabaudac]

Hello,
I am using (and discovering) Audacity 1.3.12-beta (corrected) (Ubuntu 10.04).
On last sunday I tried to use the timer recording feature in order to record a radio broadcast. I configured the timer so that it starts at 10:00 am and it lasts 2 hours. The recording actually started at 10:00, as expected. But later I encountered two problems. The first one is minor but the other one is more annoying:

1) when the recording starts, the window "Audacity Timer Record Progress" is displayed. This window shows the elapsed time and the remaining time, both as text plus graphics. In fact both times are almost never updated. They are refreshed from time to time, but in a manner which seems to be neither periodic nor predictable. So, they are of poor use.

2) the progress window offers also 2 buttons: the first one is supposed to cancel the recording, the second one to stop it (before the end of the recording has been reached). In my case, I left the recording running until the end of the broadcast, that is until 10:00 + 2:00 = 12:00. Actually, nothing happened at 12:00 ! The recording did not stop (the size of the output file was still growing) and furthermore it was impossible to stop it "manually": clicking on the cancel button or on the stop button had no effect. And also clicking on the usual stop button (yellow square at the top of the main window) had no effect. I had to send the INT signal to the related process (in a terminal window) to get Audacity stopping ; and this signal triggered the full stop (exit) of the program (not the end of the recording only), if that. Fortunately I was asked for saving the project before termination and could save the recorded music.

Has anybody been faced to the same trouble ? Is there any workaround ?
Thanks in advance for any help.

[waxcylinder]

Yup, this is a known bug amd is on the bug-list, but it is proving somewhat elsive for the developers to track down as it is not easily repeatable.

I have experienced it with various releases of 1.3 and with the current Beta it has happened to me twice now.

It was thought at one time that it only happened with recordings that straddled midnight, but I have had instances of mid-evening timed recordings that have not honoured the stop time

If you can create conditions which will always make it do this every time, then the developers would be keen to hear from you.

On Windows XP I have to stop the recording with WTM (Windows Task Manager) - and foortunately each time when I then fire up Audacity again the automated recovery process works well and restores the project for me.

WC

[phabaudac]

Yup, this is a known bug amd is on the bug-list, but it is proving somewhat elsive for the developers to track down as it is not easily repeatable.

I have experienced it with various releases of 1.3 and with the current Beta it has happened to me twice now.

It was thought at one time that it only happened with recordings that straddled midnight, but I have had instances of mid-evening timed recordings that have not honoured the stop time

If you can create conditions which will always make it do this every time, then the developers would be keen to hear from you.

On Windows XP I have to stop the recording with WTM (Windows Task Manager) - and foortunately each time when I then fire up Audacity again the automated recovery process works well and restores the project for me.

WC

Thanks a lot WC for you fast reply.
So it's a known bug (as I am a newbie I was wondering whether I was doing something wrong). I'll try again recording different broadcasts (at different times). I'll report the results here.

[phabaudac]

Yup, this is a known bug amd is on the bug-list, but it is proving somewhat elsive for the developers to track down as it is not easily repeatable.

I have experienced it with various releases of 1.3 and with the current Beta it has happened to me twice now.

It was thought at one time that it only happened with recordings that straddled midnight, but I have had instances of mid-evening timed recordings that have not honoured the stop time

If you can create conditions which will always make it do this every time, then the developers would be keen to hear from you.

On Windows XP I have to stop the recording with WTM (Windows Task Manager) - and foortunately each time when I then fire up Audacity again the automated recovery process works well and restores the project for me.

WC

Thanks a lot WC for you fast reply.
So it's a known bug (as I am a newbie I was wondering whether I was doing something wrong). I'll try again recording different broadcasts (at different times). I'll report the results here.

I made a 2 hours recording this morning. I used the timer recording feature, with: start time = 10:00, duration = 1:59. So the end of recording should have occurred at 11:59... Unfortunately Audacity did not stop recording at 11:59. I could neither stop nor canceling it (using both appropriate graphical buttons). Again, I had to kill Audacity using a console window (hopefully I could recover the whole recorded data when I restarted Audacity).
This trial let me think that straddling midday (or midnight) is not the only reason which can make the Audacity timer going mad...

[waxcylinder]

This trial let me think that straddling midday (or midnight) is not the only reason which can make the Audacity timer going mad...

Yup, that midnight-straddle was just an early conjecture as to what might be causing it. Another thought that I have had was whether I had pre-saved an empty project before setting up the timer (thus by-passing the use of the Audacity temp files) - but I have had failures when I have used ther pre-save and when I haven't. It's also happened when Audacity is competing on the PC with other high resource usage applications (live feed from Winter Olympics for example) and when Audacity is the only process on the machine.

This is why the developers have this listed as a "moonphase bug" - i.e. behavior depends on the phase of the moon - basically they have no idea what causes it.

WC

[Gale Andrews]

when the recording starts, the window "Audacity Timer Record Progress" is displayed. This window shows the elapsed time and the remaining time, both as text plus graphics. In fact both times are almost never updated. They are refreshed from time to time, but in a manner which seems to be neither periodic nor predictable. So, they are of poor use.

I cannot replicate that in Audacity SVN (i.e. 1.3.13 alpha) on Ubuntu 10.04. In fact, quite a lot of changes were made a while ago to make the counting work better. When you say you are using "1.3.13 beta" do you mean you are building from SVN (which would give you 1.3.13 alpha)? There is no 1.3.13 Beta yet as released by us. What does Help > About Audacity say?

I made a 2 hours recording this morning. I used the timer recording feature, with: start time = 10:00, duration = 1:59. So the end of recording should have occurred at 11:59... Unfortunately Audacity did not stop recording at 11:59. I could neither stop nor canceling it (using both appropriate graphical buttons). Again, I had to kill Audacity using a console window (hopefully I could recover the whole recorded data when I restarted Audacity).
This trial let me think that straddling midday (or midnight) is not the only reason which can make the Audacity timer going mad...

So is this the same recording you made just now in the Recording freezes when screensaver is activated thread where the screen was set to go to sleep after 30 minutes? You said there was no freeze there - was that a timed recording?

We need to disentangle the different issues a) timer record/any type of recording freezing when a screen saver comes on ( b) timer record failing to stop at the correct time. When b) happens on Windows, the Elapsed Time and Remaining Time in the Audacity Timer Record Progress are frozen at a specific time. You seemed to indicate the elapsed/remaining time was unresponsive anyway. The fact that on Windows the time counters freeze at a specific time has led to a theory that something happening in the system at that time could be responsible. Does Timer Record stop at the end of the scheduled time if you record only for a minute, even if the timers seem to be unresponsive?

Another idea is that updating to Widgets 2.8.11 might help with Timer Record not stopping when the scheduled end is reached. What version of Widgets is Audacity using? You can check at Help > About Audacity then click the "Build Information" tab.

@Peter: Would you like me to send you a build of 1.3.13 against 2.8.11 to try out?


Gale

[phabaudac]

when the recording starts, the window "Audacity Timer Record Progress" is displayed. This window shows the elapsed time and the remaining time, both as text plus graphics. In fact both times are almost never updated. They are refreshed from time to time, but in a manner which seems to be neither periodic nor predictable. So, they are of poor use.

I cannot replicate that in Audacity SVN (i.e. 1.3.13 alpha) on Ubuntu 10.04. In fact, quite a lot of changes were made a while ago to make the counting work better. When you say you are using "1.3.13 beta" do you mean you are building from SVN (which would give you 1.3.13 alpha)? There is no 1.3.13 Beta yet as released by us. What does Help > About Audacity say?

I made a 2 hours recording this morning. I used the timer recording feature, with: start time = 10:00, duration = 1:59. So the end of recording should have occurred at 11:59... Unfortunately Audacity did not stop recording at 11:59. I could neither stop nor canceling it (using both appropriate graphical buttons). Again, I had to kill Audacity using a console window (hopefully I could recover the whole recorded data when I restarted Audacity).
This trial let me think that straddling midday (or midnight) is not the only reason which can make the Audacity timer going mad...

So is this the same recording you made just now in the Recording freezes when screensaver is activated thread where the screen was set to go to sleep after 30 minutes? You said there was no freeze there - was that a timed recording?

Yes, it's the same recording I mentioned in both threads.

We need to disentangle the different issues a) timer record/any type of recording freezing when a screen saver comes on ( b) timer record failing to stop at the correct time. When b) happens on Windows, the Elapsed Time and Remaining Time in the Audacity Timer Record Progress are frozen at a specific time. You seemed to indicate the elapsed/remaining time was unresponsive anyway. The fact that on Windows the time counters freeze at a specific time has led to a theory that something happening in the system at that time could be responsible. Does Timer Record stop at the end of the scheduled time if you record only for a minute, even if the timers seem to be unresponsive?

I have not tried yet to do a timer recording with short duration. I'll do it and report the result.

Another idea is that updating to Widgets 2.8.11 might help with Timer Record not stopping when the scheduled end is reached. What version of Widgets is Audacity using? You can check at Help > About Audacity then click the "Build Information" tab.

@Peter: Would you like me to send you a build of 1.3.13 against 2.8.11 to try out?

Gale

On my machine (Ubuntu 10.04, Audacity 1.3.12-beta (Unicode)) Audacity is using wxWidgets 2.8.10 (Unicode).

[waxcylinder]

@Peter: Would you like me to send you a build of 1.3.13 against 2.8.11 to try out?

Yup I'd be happy to test Timed recordings on that if you can get a 1.3.13 build to me.

WC

[Gale Andrews]

Yup I'd be happy to test Timed recordings on that if you can get a 1.3.13 build to me.
WC

OK, I'm now building the Windows Unicode "Nightly" against 2.8.11:
http://www.gaclrecords.org.uk/audacity- ... -alpha.zip

2.8.11 has been a "stable" release for about a month now, but we haven't officially moved to it, so please keep a lookout for any oddities in dialogues/menus etc.



Gale

[waxcylinder]

Ok Gale, I've downloaded the 1.3.13 build - just doing a short test right now. I need to set up a time recoirding for this afternboon while I will be out - so I will use this as a proper test.

The two minute record test jkust started and stopped ok.

But I note that, even with the updated Edirol drivers that I installed a while back, in 1.3.13 my input and output sliders are still ganged together, the output slider does not control the output volume (to my onboard soundcard, not the Edirol) - and the input slider has no control over the input signal but it is not greyed out.

WC