Timer recording does not want to stop !

[Gale Andrews]

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

The two minute record test just 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.

That's expected I'm afraid because nothing has been done about it, and there is no reason to suppose it's a Widgets problem. I've added to the bug description.



Gale

[waxcylinder]

Hi Gale,

my afternoon recording - 70 mins 2pm to 15:10 - stopped and started at the right times. I will continue to use 1.3.13 especially for my timed recordings and will monitor.

Do I remember seeing an email on devel recently where someone was proposing a different method for measuring the elapsed time? Did anything come of it?

Update: I just did a Multiple Export of a WAV file from a project with 1.3.13 - and the Metadata editor popped up on export - even though I have this turned off in preferences. Tested the same project in 1.3.12 and the metadata editor did not appear.

WC

[Gale Andrews]

my afternoon recording - 70 mins 2pm to 15:10 - stopped and started at the right times. I will continue to use 1.3.13 especially for my timed recordings and will monitor.

I'd appreciate that.

Do I remember seeing an email on devel recently where someone was proposing a different method for mreasuring the elapsed tim? Did anything come of it?

Nikolay proposed a patch for bug 43 to calculate recording time internally but use the system clock for the "waiting to start" dialog. It was really meant to address that particular (repeatable) Timer Record problem where a recording fails if the system clock changes in specific circumstances. It's not clear if it would improve the Timer Record unreliability because no-one knows its cause, and I haven't tested the patch. I don't recall what e-mail you mean otherwise.

Update: I just did a Multiple Export of a WAV file from a project with 1.3.13 - and the Metadata editor popped up on export - even though I have this turned off in preferences.

That's because the Nightly has a hack for testing that lets the user pass the metadata from the first file (or turn metadata off) from a "Prompt for metadata" menu in the Export Multiple dialogue. Unfortunately the menu choice was never integrated into Preferences, which I think it should be. The metadata writing is pretty broken anyway, so I probably ought to take the hack out.



Gale

[Gale Andrews]

I will continue to use 1.3.13 especially for my timed recordings and will monitor.

Peter tells me that a timed recording in 1.3.13 from 21:59 to 23:10 carried on recording overnight and had to be force-quit. So wxWidgets 2.8.11 in itself doesn't help, on Windows anyway,



Gale

[phabaudac]

I will continue to use 1.3.13 especially for my timed recordings and will monitor.

Peter tells me that a timed recording in 1.3.13 from 21:59 to 23:10 carried on recording overnight and had to be force-quit. So wxWidgets 2.8.11 in itself doesn't help, on Windows anyway,

Gale

But perhaps it can help for the freeze/screensaver problem (I have not yet installed wxWidgets 2.8.11) ?

[Gale Andrews]

I will continue to use 1.3.13 especially for my timed recordings and will monitor.

Peter tells me that a timed recording in 1.3.13 from 21:59 to 23:10 carried on recording overnight and had to be force-quit. So wxWidgets 2.8.11 in itself doesn't help, on Windows anyway,

I've put Nikolay's patch for system clock changes (Bug 43) into the Windows "Nightly" Build. That patch still uses system time while waiting for recording to start (so would respect for example a daylight savings change to the system clock made in the waiting period), but uses its own timer during recording. So a system clock change during recording (a daylight savings change, or the common case where the system clock is synchronised automatically with internet time) will not now affect the length of the recording at all. That seems a reasonable approach to me. Any views?

So can you download again Peter and work with that version? Apart from the patch, it is still built against 2.8.11.

But perhaps (2.8.11) can help for the freeze/screensaver problem (I have not yet installed wxWidgets 2.8.11) ?

I'm not sure unless you try it because no-one on Linux could make that freeze happen when the screensaver came on. It's just as possible applying Nikolay's patch in the bug report above could help, or both that and 2.8.11 would help. If the screensaver freeze also occurs with normal recordings (not scheduled ones), I doubt those changes will help.

Or is the real reason the screensaver causes Audacity to freeze that the input stops (does it record silence or noise after the screensaver comes on)? Running pasuspender to stop Pulse before recording may help more. I assume you would then record from the appropriate "hw" device in Audacity Preferences, but Steve would know more about that.



Gale

[bgravato]

That patch still uses system time while waiting for recording to start (so would respect for example a daylight savings change to the system clock made in the waiting period), but uses its own timer during recording. So a system clock change during recording (a daylight savings change, or the common case where the system clock is synchronised automatically with internet time) will not now affect the length of the recording at all. That seems a reasonable approach to me. Any views?

Instead of the parameters being start time and end time, it could be start time and duration...

[phabaudac]

But perhaps (2.8.11) can help for the freeze/screensaver problem (I have not yet installed wxWidgets 2.8.11) ?

I'm not sure unless you try it because no-one on Linux could make that freeze happen when the screensaver came on. It's just as possible applying Nikolay's patch in the bug report above could help, or both that and 2.8.11 would help. If the screensaver freeze also occurs with normal recordings (not scheduled ones), I doubt those changes will help.

I did not try yet normal recordings with Audacity: I usuallly use arecord (very simple to use and robust) for not timed recordings. I'll try that with Audacity (and with screen saver enabled) as soon as I have some free time.

Or is the real reason the screensaver causes Audacity to freeze that the input stops (does it record silence or noise after the screensaver comes on)?

No, when Audacity freezes no further data is recorded: everything is frozen.

Running pasuspender to stop Pulse before recording may help more. I assume you would then record from the appropriate "hw" device in Audacity Preferences, but Steve would know more about that.

Gale

I'll try that also.

[waxcylinder]

So can you download again Peter and work with that version? Apart from the patch, it is still built against 2.8.11.

Ok Gale - just downloaded it - did a quick test 1min delay 1min recording and it worked ok. I have two timed recordings to make this evening so I will use this new build for those.

Ooh missus - and Iv'e just noticed we've got linking back in 1.3.13 - no idea how to use it or what it's for though ...

WC

[waxcylinder]

Instead of the parameters being start time and end time, it could be start time and duration...

Bruno,

you can already do that - in the setup dialog box for Timer Record there are three input boxes:
1) Start Date and Time
2) End Date and Time
3) Duration

Setting the duration in box 3 will change the end time in box 2 and vice versa.

And Audacity "remembers" the last duration that was used for initial setting next time around - so from that POV duration is effectively the primary parameter anyway.

WC