Timer Record carries on recording (Bug 42)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Timer Record carries on recording (Bug 42)

Gale
Administrator
http://bugzilla.audacityteam.org/show_bug.cgi?id=42 .

Normally I can only reproduce this in a debug build, but
yesterday, after running Timer Record a few times with
standard record in release build on Win 10, I enabled
Sound Activated Recording.

As soon as I did that, the Timer Record progress counter
did not move from 0 seconds, whether the stream was
loud enough to be recorded or not, and I had to force
quit.

After several force quits, I turned off Sound Activated
Recording, but Timer Record still exhibited the bug until I
rebooted.

Does anyone else see Sound Activated Recording causing
Bug 42?

Is the Timer Record behaviour with Sound Activated Recording
what we want?  Should it just stop recording after the time set,
whether anything was recorded or not, or wait for an achieved
recording of the length requested? This may differ by use case,
but some doing wildlife or surveillance recordings might want
to set an achieved recording length.


Gale

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Timer Record carries on recording (Bug 42)

Cliff Scott

> On May 9, 2017, at 8:46 PM, Gale Andrews <[hidden email]> wrote:
>
> http://bugzilla.audacityteam.org/show_bug.cgi?id=42 .
>
> Normally I can only reproduce this in a debug build, but
> yesterday, after running Timer Record a few times with
> standard record in release build on Win 10, I enabled
> Sound Activated Recording.
>
> As soon as I did that, the Timer Record progress counter
> did not move from 0 seconds, whether the stream was
> loud enough to be recorded or not, and I had to force
> quit.
>
> After several force quits, I turned off Sound Activated
> Recording, but Timer Record still exhibited the bug until I
> rebooted.
>
> Does anyone else see Sound Activated Recording causing
> Bug 42?
>
> Is the Timer Record behaviour with Sound Activated Recording
> what we want?  Should it just stop recording after the time set,
> whether anything was recorded or not, or wait for an achie
> recording of the length requested? This may differ by use case,
> but some doing wildlife or surveillance recordings might want
> to set an achieved recording length.
>
>
> Gale

Gale,

I'm sure you don't want to hear this, but no problem shows on my Mac Sierra Laptop running Audacity build of May 2nd. Tried all combinations of run to the end, stop, sound activation levels, in focus or not. The counters all work as expected and the recording can be stopped or let finish normally.

I can see having both options for Timed record as it is now and also Recorded Length control.

Cliff


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Timer Record carries on recording (Bug 42)

James Crook
On 5/10/2017 4:19 AM, Cliff Scott wrote:

>> On May 9, 2017, at 8:46 PM, Gale Andrews <[hidden email]> wrote:
>>
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=42 .
>>
>> Normally I can only reproduce this in a debug build, but
>> yesterday, after running Timer Record a few times with
>> standard record in release build on Win 10, I enabled
>> Sound Activated Recording.
>>
>> As soon as I did that, the Timer Record progress counter
>> did not move from 0 seconds, whether the stream was
>> loud enough to be recorded or not, and I had to force
>> quit.
>>
>> After several force quits, I turned off Sound Activated
>> Recording, but Timer Record still exhibited the bug until I
>> rebooted.
>>
>> Does anyone else see Sound Activated Recording causing
>> Bug 42?
>>
>> Is the Timer Record behaviour with Sound Activated Recording
>> what we want?  Should it just stop recording after the time set,
>> whether anything was recorded or not, or wait for an achie
>> recording of the length requested? This may differ by use case,
>> but some doing wildlife or surveillance recordings might want
>> to set an achieved recording length.
>>
>>
>> Gale
> Gale,
>
> I'm sure you don't want to hear this, but no problem shows on my Mac Sierra Laptop running Audacity build of May 2nd.
So possibly windows only and not mac.  That may help us narrow down
possible causes.  It helps us progress the bug, and at the same time
tells us about users who are not affected, so good/helpful all round.

> Tried all combinations of run to the end, stop, sound activation levels, in focus or not. The counters all work as expected and the recording can be stopped or let finish normally.
>
> I can see having both options for Timed record as it is now and also Recorded Length control.
>
> Cliff


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Timer Record carries on recording (Bug 42)

Peter Sampson-2
Just tested this on my W10 laptop audacity-win-r09607c2-2.2.0-alpha-08-may-17

And it all works fine - I still can never reproduce this bug

1) Turned on SAR
2) Input set to WASAPI loopback
3) Armed TR for a 1 min recording in 1 mis time
4) After TR start (ewith no input) TR cursor just sits there
5) started and stopped iTunes play a couple of times to create "sound"
6) TR started and recording and stopped recording for the duration
of each burst of sound
7) TR finished at the end the scheduled 1 minute
8) resut was 16 seconds od recording from the two bursts of sound imput

Totally reapeatable with no failures
Tested with no sound at start and end of TR duration
and with sound active at start and end of TR duriation with no sound inbetween

Peter.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Timer Record carries on recording (Bug 42)

Peter Sampson-2
Gale wrote:
>Is the Timer Record behaviour with Sound Activated Recording
>what we want?  Should it just stop recording after the time set,
>whether anything was recorded or not, or wait for an achieved
>recording of the length requested? This may differ by use case,
>but some doing wildlife or surveillance recordings might want
>to set an achieved recording length.

This is a separate issue to Bug 42 so should really be on its own thread.

This is a problem that we have crreated for ourselves in a way due to the
way the dialog inputs were created at the outset.

We have two separate input boxes that control the same thing and are directly
linked: End Date and Time & Duration.   The user can input in either of these
and the other will be updated accordingly.

This can lead to the expectation of the user who inputs via the duration that
they will get a recording of that duration (taking accound of SAR dead air).
Howevever they should note that the End Date and Time has changed too
an is likely to be honoured.

In many ways it may have been better to only allow input cia End Date and Time
with the Duration displayed as informational data and not an input.

If we want to allow the dutaion to become an absolute duration, taking account
of SAR silences then I think we would need to have a radio button or similar
to allow the user to control whether End Date and Time of Duration should
be input modifiable with the other being informational unmodifiable data.

Having said that, however my vote would be for us to leave the controls just as
they are (personally I use both forms of input).   Those using SAR should be
aware that it is the end time that dominates and not the lenftgh of recording
(Duration) its primacy above duration in the input dialog should indicate that..
Maybe we should put a note in the Manual to this effect.

I don't recall TR/SAR users complaining about this on the Forum - have you had
such complaints on feeback@ Gale?

Peter.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Timer Record carries on recording (Bug 42)

Gale
Administrator
In reply to this post by James Crook
The bug was reported last year on OS X 10.7.5 (which I now have),
but I have not tested it there:
http://bugzilla.audacityteam.org/show_bug.cgi?id=42#c21   .


Gale


On 10 May 2017 at 09:00, James Crook <[hidden email]> wrote:
> So possibly windows only and not mac.  That may help us narrow down
> possible causes.  It helps us progress the bug, and at the same time
> tells us about users who are not affected, so good/helpful all round.

> On 5/10/2017 4:19 AM, Cliff Scott wrote:
>>> On May 9, 2017, at 8:46 PM, Gale Andrews <[hidden email]> wrote:
>>>
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=42 .
>>>
>>> Normally I can only reproduce this in a debug build, but
>>> yesterday, after running Timer Record a few times with
>>> standard record in release build on Win 10, I enabled
>>> Sound Activated Recording.
>>>
>>> As soon as I did that, the Timer Record progress counter
>>> did not move from 0 seconds, whether the stream was
>>> loud enough to be recorded or not, and I had to force
>>> quit.
>>>
>>> After several force quits, I turned off Sound Activated
>>> Recording, but Timer Record still exhibited the bug until I
>>> rebooted.
>>>
>>> Does anyone else see Sound Activated Recording causing
>>> Bug 42?
>>>
>>> Is the Timer Record behaviour with Sound Activated Recording
>>> what we want?  Should it just stop recording after the time set,
>>> whether anything was recorded or not, or wait for an achie
>>> recording of the length requested? This may differ by use case,
>>> but some doing wildlife or surveillance recordings might want
>>> to set an achieved recording length.
>>>
>>>
>>> Gale
>> Gale,
>>
>> I'm sure you don't want to hear this, but no problem shows on my Mac Sierra Laptop running Audacity build of May 2nd.
>> Tried all combinations of run to the end, stop, sound activation levels, in focus or not. The counters all work as expected and the recording can be stopped or let finish normally.
>>
>> I can see having both options for Timed record as it is now and also Recorded Length control.
>>
>> Cliff
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Timer Record carries on recording (Bug 42)

Gale
Administrator
In reply to this post by Peter Sampson-2
Thanks for your thoughts, Peter.

No, I don't recall anyone asking for Timer Record to stop after
an achieved recording length rather than absolute length. I
guess most users who think about it assume Sound Activated
incompatible with Timer Record.

It just struck me that if you want to record bat calls above a
certain loudness and also want to save disk space and record
unattended, an "achieved recording length" for Timer Record
could be just the job.


Gale


On 10 May 2017 at 09:30, Peter Sampson <[hidden email]> wrote:

> Gale wrote:
>>Is the Timer Record behaviour with Sound Activated Recording
>>what we want?  Should it just stop recording after the time set,
>>whether anything was recorded or not, or wait for an achieved
>>recording of the length requested? This may differ by use case,
>>but some doing wildlife or surveillance recordings might want
>>to set an achieved recording length.
>
> This is a separate issue to Bug 42 so should really be on its own thread.
>
> This is a problem that we have crreated for ourselves in a way due to the
> way the dialog inputs were created at the outset.
>
> We have two separate input boxes that control the same thing and are
> directly
> linked: End Date and Time & Duration.   The user can input in either of
> these
> and the other will be updated accordingly.
>
> This can lead to the expectation of the user who inputs via the duration
> that
> they will get a recording of that duration (taking accound of SAR dead air).
> Howevever they should note that the End Date and Time has changed too
> an is likely to be honoured.
>
> In many ways it may have been better to only allow input cia End Date and
> Time
> with the Duration displayed as informational data and not an input.
>
> If we want to allow the dutaion to become an absolute duration, taking
> account
> of SAR silences then I think we would need to have a radio button or similar
> to allow the user to control whether End Date and Time of Duration should
> be input modifiable with the other being informational unmodifiable data.
>
> Having said that, however my vote would be for us to leave the controls just
> as
> they are (personally I use both forms of input).   Those using SAR should be
> aware that it is the end time that dominates and not the lenftgh of
> recording
> (Duration) its primacy above duration in the input dialog should indicate
> that..
> Maybe we should put a note in the Manual to this effect.
>
> I don't recall TR/SAR users complaining about this on the Forum - have you
> had
> such complaints on feeback@ Gale?
>
> Peter.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality