My exception handling project is completed and ready for test!

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

My exception handling project is completed and ready for test!

Paul Licameli
Whew.

PRL


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

Re: My exception handling project is completed and ready for test!

James Crook
Whew indeed!  Great stuff.

I saw you have also updated http://bugzilla.audacityteam.org/show_bug.cgi?id=437
437 is one aspect of this, the 'motivating example'.

Paul do you now think you have fixed 437 (as well as improving a lot else besides)?  If so, GREAT.  If your preliminary tests (e.g. with a nearly full USB key) make you think you have fixed 437, please update to DEVEL-FIX MADE, and that will encourage more extensive testing of that particular bug.

--James.




On 4/4/2017 4:55 AM, Paul Licameli wrote:
Whew.

PRL



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



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

Re: My exception handling project is completed and ready for test!

Peter Sampson-2
I've spent some time doing some early-doors testin on this
with audacity-win-rfa62d80-2.2.0-alpha-05-apr-17 on W10.

1) Recording
Testing with a nearly-full USB stick as my project file location

Project recorded for just over a minute and then popped up this ghastly
intimidating unfriendly error message:

>Audacity failed to write to a file at E:\runoutofspacetest_data\e00\d00\e0000fce.au
>,Attempt this operation after removing unnecessary files.
>One way to do that is with the Discard buttonsin the History dialog.
>See the View menu.

All you really need to tell 'em is that you've run out of space while recording.

In the residual one minute project the left channle was sis seconds (one block) longer
that the right channel.

I tried exiting Audcity with the top-right red X
I was invited to save the project - which I did and that and the closure looked ok.

Relaunched Audacity and opened the residual project from the USB stick - and it
opened ok.

So this is better than #347 as it avoids the silent overwrite - but the message is poor.


2) Export as WAV
Testing with a nearly-full USB stick as my project file location
Opened the residual project
created 30 secondsstereo tone at the end
Tried exporting as WAV to the USB drive but in the Save dialog the E: drive was redded
out (correctly) as completely full.

Removed a 3 minte AAC file from te USB stick
Relaunched Audacity
reopened the residual project from the USB stick
Saved the Project to my C: drive
Tried to export as a WAV file to the E: drive USB stick
got the following error message:

>Error while writing WAV (Microsoft)file (disk full?).
>Libsndfile says "System error.

Now bearing in my this is a "user message" they don't really want to be hearing about
under-the-hood technology such as "libsndfile" - nor do they want the unceratinty of the
question in "disk full?" - either it's full (and you can't write any more to it) or it's not.

Looking at the USB E: drive shows that a WAV file was created but of a mere five seconds.
This Wav file could be imported ok into a new Audacaity project.

I would have thought that if we cannot complete any export then rather than leaving behind
an incomplete trucated one (which btw then totally fills up the drive!) we should instead be
cleaning up and deleting it (to leave the user with some headroom - it may be a C: drive)

Better still we should, before the export starts, check to see if there is sufficient room before
even embarking on the export - and if not then aborting the export with a user-friendly
In addition to Exports: Saves, Imports and Generates would particularly  really benefit from this pre-action
space-test approach, as the proposal indicates.

Cheers,
Peter.


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

Re: My exception handling project is completed and ready for test!

James Crook
On 4/5/2017 4:24 PM, Peter Sampson wrote:
I've spent some time doing some early-doors testin on this
with audacity-win-rfa62d80-2.2.0-alpha-05-apr-17 on W10.

*1) Recording*
Testing with a nearly-full USB stick as my project file location

Project recorded for just over a minute and then popped up this ghastly
intimidating unfriendly error message:

Audacity failed to write to a file at
E:\runoutofspacetest_data\e00\d00\e0000fce.au
,Attempt this operation after removing unnecessary files.
One way to do that is with the Discard buttonsin the History dialog.
See the View menu.
All you really need to tell 'em is that you've run out of space while
recording.

+1
Shorter is better.



In the residual one minute project the left channle was sis seconds (one
block) longer
that the right channel.

I tried exiting Audcity with the top-right red X
I was invited to save the project - which I did and that and the closure
looked ok.

Relaunched Audacity and opened the residual project from the USB stick -
and it
opened ok.

So this is better than #347 as it avoids the silent overwrite - but the
message is poor.


*2) Export as WAV*
Testing with a nearly-full USB stick as my project file location
Opened the residual project
created 30 secondsstereo tone at the end
Tried exporting as WAV to the USB drive but in the Save dialog the E: drive
was redded
out (correctly) as completely full.

Removed a 3 minte AAC file from te USB stick
Relaunched Audacity
reopened the residual project from the USB stick
Saved the Project to my C: drive
Tried to export as a WAV file to the E: drive USB stick
got the following error message:

Error while writing WAV (Microsoft)file (disk full?).
Libsndfile says "System error.
Ah.

That's probably outside the scope of Paul's project, as he's been fixing things in Audacity code, rather than in libraries - which would be necessary to know the cause here.

How about:

"Disk probably full.  Could not write WAV file."

I wouldn't put a high priority on cleaning up the partial write, but do see your point.





Now bearing in my this is a "user message" they don't really want to be
hearing about
under-the-hood technology such as "libsndfile" - nor do they want the
unceratinty of the
question in "disk full?" - either it's full (and you can't write any more
to it) or it's not.

Looking at the USB E: drive shows that a WAV file was created but of a mere
five seconds.
This Wav file could be imported ok into a new Audacaity project.

I would have thought that if we cannot complete any export then rather than
leaving behind
an incomplete trucated one (which btw then totally fills up the drive!) we
should instead be
cleaning up and deleting it (to leave the user with some headroom - it may
be a C: drive)

Better still we should, before the export starts, check to see if there is
sufficient room before
even embarking on the export - and if not then aborting the export with a
user-friendly
error message - see this proposal:
http://wiki.audacityteam.org/wiki/Proposal:_improvements_to_Audacity_to_prevent_disk_over-run_issues

In addition to Exports: Saves, Imports and Generates would particularly
really benefit from this pre-action
space-test approach, as the proposal indicates.

Cheers,
Peter.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



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

Re: My exception handling project is completed and ready for test!

Peter Sampson-2
In reply to this post by Peter Sampson-2
On thinking about tgis some more it seems to me that we should be doing
a little more for live Record too.

Bearing in mind that most folk are likely to be using their C: drive (or Mac/Linux)
equivalent as their project file location or temp file location we really shoulfd not
just be filling te disk  and then stopping (though that is better than the previous
silent overwrite behavior).

Rather we should be setting a headroom (configurable?) and checking while
recording that the headroom diskspace remains.  Once the headroom barrier
is reached then recording should stip with a user-friendly error message.

IF a user attempts to record with disce less than or equal to headroom
THEN record would not start - and a user-friendly error message would be popped.


The reason for this is that totally filling a drive that has the user's system on it
is not a clever idea -  I don'y know how smart modern Wondows is with dealing
with ttat (and I don't plan to find out) - but old OSs could just crash.

I once crashed a live theatre ticketing system running on a DEC PDP-11 running
under RSX just by inadvertently leaning a manual on the console Return key !!
Fortunately the recovery software (which I had written) proved robust <phew>.

Peter.

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

Re: My exception handling project is completed and ready for test!

Peter Sampson-2
In reply to this post by James Crook
3) Import with disk fairly full
Free a little room on the USB E: drive
Launch Audacity
Open the truncated project from the USB E: drive
Try Imporrting a three minute WAV file
I get the same error non-user-friendly message as in 1) earlier:

>Audacity failed to write to a file at E:\runoutofspacetest_data\e00\d00\e0000fce.au
>,Attempt this operation after removing unnecessary files.
>One way to do that is with the Discard buttonsin the History dialog.
>See the View menu.

Dismiss the error message.
Nothing is imported.


4) Generate with disk fairly full
Free a little room on the USB E: drive
Launch Audacity
Open the truncated project from the USB E: drive
Try Generating a three minute stereo tone
I get the same error message as in 1) earlier and 4) above.

Dismiss the error message.
Nothing is Generated.


5) Apply an effect with disk fairly full
Free a little room on the USB E: drive
Launch Audacity
Open the truncated project from the USB E: drive
Ctrl+A to select all
Effect>Repeat for 10 tests
Zoom to fit
Looks to repeat ok

now
Ctrl+A to select all
Effect Amplify
I get the same error message as in 1) earlier and 4) above.

Dismiss the error message.
Nothing is amplified.

Apart from the clunky error message this is looking good so far :-)

Peter.

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

Re: My exception handling project is completed and ready for test!

Peter Sampson-2

On Wed, Apr 5, 2017 at 7:53 PM, Paul Licameli <[hidden email]> wrote:
I can change the error message to be more concise.  That is easy enough.  I thought that the error message should at least include some indication of which device runs out of space. 

+1 the device (and probably only the device) should be mentioned
 
The complete path is too much information though.

+1  I agree

Once this message is made more user-friendly, I think from my early-doors testing
that you should be ready to mark this as Devel Fix-Made as James suggested
earlier.

 

The error from libsndfile is put up by code in ExportPCM.cpp that I did not touch.  This is not reaching the places where I throw exceptions.

Nonetheless I agree with Peter that it would be better for failed export not to leave partial results behind, whether it takes an exceptional path or not.  I was independently concluding that this is a gap in the project.

It would be nice if this could be done :-)
 

It makes sense that Repeat might succeed where Amplify does not, because the first can re-use existing block files, just adding pointers to them to accomplish the repetition in a track.  Whereas Amplify really must make new block files for the entire duration, while still saving the old files so that you can undo.

I figured that was the underlying case.
 


On Wed, Apr 5, 2017 at 1:38 PM, Peter Sampson <[hidden email]> wrote:
3) Import with disk fairly full
Free a little room on the USB E: drive
Launch Audacity
Open the truncated project from the USB E: drive
Try Imporrting a three minute WAV file
I get the same error non-user-friendly message as in 1) earlier:

>Audacity failed to write to a file at E:\runoutofspacetest_data\e00\d00\e0000fce.au
>,Attempt this operation after removing unnecessary files.
>One way to do that is with the Discard buttonsin the History dialog.
>See the View menu.

Dismiss the error message.
Nothing is imported.


4) Generate with disk fairly full
Free a little room on the USB E: drive
Launch Audacity
Open the truncated project from the USB E: drive
Try Generating a three minute stereo tone
I get the same error message as in 1) earlier and 4) above.

Dismiss the error message.
Nothing is Generated.


5) Apply an effect with disk fairly full
Free a little room on the USB E: drive
Launch Audacity
Open the truncated project from the USB E: drive
Ctrl+A to select all
Effect>Repeat for 10 tests
Zoom to fit
Looks to repeat ok

now
Ctrl+A to select all
Effect Amplify
I get the same error message as in 1) earlier and 4) above.

Dismiss the error message.
Nothing is amplified.

Apart from the clunky error message this is looking good so far :-)

Peter.



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

Re: My exception handling project is completed and ready for test!

Gale
Administrator
On 6 April 2017 at 17:35, Peter Sampson <[hidden email]> wrote:

>
> On Wed, Apr 5, 2017 at 7:53 PM, Paul Licameli <[hidden email]>
> wrote:
>>
>> I can change the error message to be more concise.  That is easy enough.
>> I thought that the error message should at least include some indication of
>> which device runs out of space.
>
>
> +1 the device (and probably only the device) should be mentioned
>
>>
>> The complete path is too much information though.
>
>
> +1  I agree

+1. But if this message appears only when as per the log

"(error 112: there is not enough space on the disk.)"

then it should say explicitly that there is not enough space to
write the file, ideally in the Title Bar "Out of disk space".

Can we get a Help button in this dialogue, Paul?


> Once this message is made more user-friendly, I think from my early-doors
> testing
> that you should be ready to mark this as Devel Fix-Made as James suggested
> earlier.
>
>
>>
>>
>> The error from libsndfile is put up by code in ExportPCM.cpp that I did
>> not touch.  This is not reaching the places where I throw exceptions.
>>
>> Nonetheless I agree with Peter that it would be better for failed export
>> not to leave partial results behind, whether it takes an exceptional path or
>> not.  I was independently concluding that this is a gap in the project.
>
>
> It would be nice if this could be done :-)

What do we mean by "leave partial results behind"?

We looked before into Audacity checking if it had enough disk space
before exporting. It was deemed this was infeasible because available
space is dynamic.

So the response as I understand it was, just for libsndfile formats,
check if what was exported was the same as what was expected.

When disk space runs out during export, Audacity does for several
formats write properly headered but incomplete files. WAV is one
such format, MP3 is another (for FLAC it seems a corrupted file is
exported instead but I would have to test further to see if it depends
how much space was available).

I always thought writing an incomplete file was more of a feature than
a bug, but the real problem is that except for libsndilfe, no error is
reported when a valid short file or corrupt file is exported due to
lack of disk space. But I don't see how Audacity could refuse to write
a file or delete a partial file unless it can do the sort of checks we
thought infeasible.  I actually think we could say "Right now, you
don't have the disk space to export this file. If you continue, the file
may be shortened or unplayable."

Anyway, the above shows us that the libsndfile message is a little
misleading - it implies no file was written, which will not always be
the case. Can the check Audacity already does identify if a partial
file was written and change the message accordingly?



Gale


>> It makes sense that Repeat might succeed where Amplify does not, because
>> the first can re-use existing block files, just adding pointers to them to
>> accomplish the repetition in a track.  Whereas Amplify really must make new
>> block files for the entire duration, while still saving the old files so
>> that you can undo.
>
>
> I figured that was the underlying case.
>
>>
>>
>>
>> On Wed, Apr 5, 2017 at 1:38 PM, Peter Sampson
>> <[hidden email]> wrote:
>>>
>>> 3) Import with disk fairly full
>>> Free a little room on the USB E: drive
>>> Launch Audacity
>>> Open the truncated project from the USB E: drive
>>> Try Imporrting a three minute WAV file
>>> I get the same error non-user-friendly message as in 1) earlier:
>>>
>>> >Audacity failed to write to a file at
>>> > E:\runoutofspacetest_data\e00\d00\e0000fce.au
>>> >,Attempt this operation after removing unnecessary files.
>>> >One way to do that is with the Discard buttonsin the History dialog.
>>> >See the View menu.
>>>
>>> Dismiss the error message.
>>> Nothing is imported.
>>>
>>>
>>> 4) Generate with disk fairly full
>>> Free a little room on the USB E: drive
>>> Launch Audacity
>>> Open the truncated project from the USB E: drive
>>> Try Generating a three minute stereo tone
>>> I get the same error message as in 1) earlier and 4) above.
>>>
>>> Dismiss the error message.
>>> Nothing is Generated.
>>>
>>>
>>> 5) Apply an effect with disk fairly full
>>> Free a little room on the USB E: drive
>>> Launch Audacity
>>> Open the truncated project from the USB E: drive
>>> Ctrl+A to select all
>>> Effect>Repeat for 10 tests
>>> Zoom to fit
>>> Looks to repeat ok
>>>
>>> now
>>> Ctrl+A to select all
>>> Effect Amplify
>>> I get the same error message as in 1) earlier and 4) above.
>>>
>>> Dismiss the error message.
>>> Nothing is amplified.
>>>
>>> Apart from the clunky error message this is looking good so far :-)
>>>
>>> Peter.
>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: My exception handling project is completed and ready for test!

Paul Licameli
In reply to this post by Peter Sampson-2


On Thu, Apr 6, 2017 at 12:35 PM, Peter Sampson <[hidden email]> wrote:

On Wed, Apr 5, 2017 at 7:53 PM, Paul Licameli <[hidden email]> wrote:
I can change the error message to be more concise.  That is easy enough.  I thought that the error message should at least include some indication of which device runs out of space. 

+1 the device (and probably only the device) should be mentioned
 
The complete path is too much information though.

+1  I agree

Once this message is made more user-friendly, I think from my early-doors testing
that you should be ready to mark this as Devel Fix-Made as James suggested
earlier.

You noticed that the two stereo channels might end up differing by one block's length (about 6 sec with 44100 Hz sampling and 32 bit float).

You may also notice that the latency correction, which should be done when you record a new track under an existing one, might not be done in case the disk exhausts space, because it can also require allocation of block files after the appending is done.  (Try with positive and negative latency:  they take different code paths.  Someone explained to me why positive latency might be useful, and I forget why, but no matter.)

But we will have to agree that these are acceptable flaws, when the purpose is to salvage as much of the new recording as we can.
 

 

The error from libsndfile is put up by code in ExportPCM.cpp that I did not touch.  This is not reaching the places where I throw exceptions.

Nonetheless I agree with Peter that it would be better for failed export not to leave partial results behind, whether it takes an exceptional path or not.  I was independently concluding that this is a gap in the project.

It would be nice if this could be done :-)

More seriously, you might overwrite an existing file, after checking the confirmation dialog, and lose the original, which you might prefer to have kept instead of the partial result.

I think exporting with overwrite should write to a temporary file name, then swap that into place only after success.
 
 

It makes sense that Repeat might succeed where Amplify does not, because the first can re-use existing block files, just adding pointers to them to accomplish the repetition in a track.  Whereas Amplify really must make new block files for the entire duration, while still saving the old files so that you can undo.

I figured that was the underlying case.

There are multiple ways that you might put demands on the disk that fail.  Another I can think of is resampling.  But it would be hard to make an exhaustive list.

Almost all editing operations may create some new block files.  Even deletion can do this, because one block file may need to be replaced with a shorter block file, but we keep the original too so that you can undo.  But it's things that require replacement of every block file, like Amplify, that are more likely to exhaust disk.

PRL

 
 


On Wed, Apr 5, 2017 at 1:38 PM, Peter Sampson <[hidden email]> wrote:
3) Import with disk fairly full
Free a little room on the USB E: drive
Launch Audacity
Open the truncated project from the USB E: drive
Try Imporrting a three minute WAV file
I get the same error non-user-friendly message as in 1) earlier:

>Audacity failed to write to a file at E:\runoutofspacetest_data\e00\d00\e0000fce.au
>,Attempt this operation after removing unnecessary files.
>One way to do that is with the Discard buttonsin the History dialog.
>See the View menu.

Dismiss the error message.
Nothing is imported.


4) Generate with disk fairly full
Free a little room on the USB E: drive
Launch Audacity
Open the truncated project from the USB E: drive
Try Generating a three minute stereo tone
I get the same error message as in 1) earlier and 4) above.

Dismiss the error message.
Nothing is Generated.


5) Apply an effect with disk fairly full
Free a little room on the USB E: drive
Launch Audacity
Open the truncated project from the USB E: drive
Ctrl+A to select all
Effect>Repeat for 10 tests
Zoom to fit
Looks to repeat ok

now
Ctrl+A to select all
Effect Amplify
I get the same error message as in 1) earlier and 4) above.

Dismiss the error message.
Nothing is amplified.

Apart from the clunky error message this is looking good so far :-)

Peter.




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

Re: My exception handling project is completed and ready for test!

Gale
Administrator
On 6 April 2017 at 20:33, Paul Licameli <[hidden email]> wrote:

>
>
> On Thu, Apr 6, 2017 at 12:35 PM, Peter Sampson
> <[hidden email]> wrote:
>>
>>
>> On Wed, Apr 5, 2017 at 7:53 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>> I can change the error message to be more concise.  That is easy enough.
>>> I thought that the error message should at least include some indication of
>>> which device runs out of space.
>>
>>
>> +1 the device (and probably only the device) should be mentioned
>>
>>>
>>> The complete path is too much information though.
>>
>>
>> +1  I agree
>>
>> Once this message is made more user-friendly, I think from my early-doors
>> testing
>> that you should be ready to mark this as Devel Fix-Made as James suggested
>> earlier.
>
>
> You noticed that the two stereo channels might end up differing by one
> block's length (about 6 sec with 44100 Hz sampling and 32 bit float).
>
> You may also notice that the latency correction, which should be done when
> you record a new track under an existing one, might not be done in case the
> disk exhausts space, because it can also require allocation of block files
> after the appending is done.  (Try with positive and negative latency:  they
> take different code paths.  Someone explained to me why positive latency
> might be useful, and I forget why, but no matter.)
>
> But we will have to agree that these are acceptable flaws, when the purpose
> is to salvage as much of the new recording as we can.
>
>>
>>
>>
>>>
>>>
>>> The error from libsndfile is put up by code in ExportPCM.cpp that I did
>>> not touch.  This is not reaching the places where I throw exceptions.
>>>
>>> Nonetheless I agree with Peter that it would be better for failed export
>>> not to leave partial results behind, whether it takes an exceptional path or
>>> not.  I was independently concluding that this is a gap in the project.
>>
>>
>> It would be nice if this could be done :-)
>
>
> More seriously, you might overwrite an existing file, after checking the
> confirmation dialog, and lose the original, which you might prefer to have
> kept instead of the partial result.
>
> I think exporting with overwrite should write to a temporary file name, then
> swap that into place only after success.

Can we know with lossy formats like MP3 that the file was exported
in its entirety?


Gale


>>> It makes sense that Repeat might succeed where Amplify does not, because
>>> the first can re-use existing block files, just adding pointers to them to
>>> accomplish the repetition in a track.  Whereas Amplify really must make new
>>> block files for the entire duration, while still saving the old files so
>>> that you can undo.
>>
>>
>> I figured that was the underlying case.
>
>
> There are multiple ways that you might put demands on the disk that fail.
> Another I can think of is resampling.  But it would be hard to make an
> exhaustive list.
>
> Almost all editing operations may create some new block files.  Even
> deletion can do this, because one block file may need to be replaced with a
> shorter block file, but we keep the original too so that you can undo.  But
> it's things that require replacement of every block file, like Amplify, that
> are more likely to exhaust disk.
>
> PRL
>
>
>>
>>
>>>
>>>
>>>
>>> On Wed, Apr 5, 2017 at 1:38 PM, Peter Sampson
>>> <[hidden email]> wrote:
>>>>
>>>> 3) Import with disk fairly full
>>>> Free a little room on the USB E: drive
>>>> Launch Audacity
>>>> Open the truncated project from the USB E: drive
>>>> Try Imporrting a three minute WAV file
>>>> I get the same error non-user-friendly message as in 1) earlier:
>>>>
>>>> >Audacity failed to write to a file at
>>>> > E:\runoutofspacetest_data\e00\d00\e0000fce.au
>>>> >,Attempt this operation after removing unnecessary files.
>>>> >One way to do that is with the Discard buttonsin the History dialog.
>>>> >See the View menu.
>>>>
>>>> Dismiss the error message.
>>>> Nothing is imported.
>>>>
>>>>
>>>> 4) Generate with disk fairly full
>>>> Free a little room on the USB E: drive
>>>> Launch Audacity
>>>> Open the truncated project from the USB E: drive
>>>> Try Generating a three minute stereo tone
>>>> I get the same error message as in 1) earlier and 4) above.
>>>>
>>>> Dismiss the error message.
>>>> Nothing is Generated.
>>>>
>>>>
>>>> 5) Apply an effect with disk fairly full
>>>> Free a little room on the USB E: drive
>>>> Launch Audacity
>>>> Open the truncated project from the USB E: drive
>>>> Ctrl+A to select all
>>>> Effect>Repeat for 10 tests
>>>> Zoom to fit
>>>> Looks to repeat ok
>>>>
>>>> now
>>>> Ctrl+A to select all
>>>> Effect Amplify
>>>> I get the same error message as in 1) earlier and 4) above.
>>>>
>>>> Dismiss the error message.
>>>> Nothing is amplified.
>>>>
>>>> Apart from the clunky error message this is looking good so far :-)
>>>>
>>>> Peter.
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: My exception handling project is completed and ready for test!

Paul Licameli


On Thu, Apr 6, 2017 at 6:54 PM, Gale Andrews <[hidden email]> wrote:
On 6 April 2017 at 20:33, Paul Licameli <[hidden email]> wrote:
>
>
> On Thu, Apr 6, 2017 at 12:35 PM, Peter Sampson
> <[hidden email]> wrote:
>>
>>
>> On Wed, Apr 5, 2017 at 7:53 PM, Paul Licameli <[hidden email]>
>> wrote:
>>>
>>> I can change the error message to be more concise.  That is easy enough.
>>> I thought that the error message should at least include some indication of
>>> which device runs out of space.
>>
>>
>> +1 the device (and probably only the device) should be mentioned
>>
>>>
>>> The complete path is too much information though.
>>
>>
>> +1  I agree
>>
>> Once this message is made more user-friendly, I think from my early-doors
>> testing
>> that you should be ready to mark this as Devel Fix-Made as James suggested
>> earlier.
>
>
> You noticed that the two stereo channels might end up differing by one
> block's length (about 6 sec with 44100 Hz sampling and 32 bit float).
>
> You may also notice that the latency correction, which should be done when
> you record a new track under an existing one, might not be done in case the
> disk exhausts space, because it can also require allocation of block files
> after the appending is done.  (Try with positive and negative latency:  they
> take different code paths.  Someone explained to me why positive latency
> might be useful, and I forget why, but no matter.)
>
> But we will have to agree that these are acceptable flaws, when the purpose
> is to salvage as much of the new recording as we can.
>
>>
>>
>>
>>>
>>>
>>> The error from libsndfile is put up by code in ExportPCM.cpp that I did
>>> not touch.  This is not reaching the places where I throw exceptions.
>>>
>>> Nonetheless I agree with Peter that it would be better for failed export
>>> not to leave partial results behind, whether it takes an exceptional path or
>>> not.  I was independently concluding that this is a gap in the project.
>>
>>
>> It would be nice if this could be done :-)
>
>
> More seriously, you might overwrite an existing file, after checking the
> confirmation dialog, and lose the original, which you might prefer to have
> kept instead of the partial result.
>
> I think exporting with overwrite should write to a temporary file name, then
> swap that into place only after success.

Can we know with lossy formats like MP3 that the file was exported
in its entirety?


Gale

Gale, in case of PCM export, we use third-party code to produce buffers of data for output, but our own code mediates the writing to disk, and we can detect it when a write fails.

I think this is also true of the other exports.  I must look at the code for each one closer.

My suggestion is simply to stop export whenever we detect an error, and delete the incompletely exported file.  Let the user clear up space on the device and try it again.  Also, if asked to overwrite a file, still don't do it at once, but write a temporary, and replace the original only after the temporary is successfully written in full.

I am not persuaded that we should make an effort to estimate sufficiency of available disk space before writing.

PRL

 


>>> It makes sense that Repeat might succeed where Amplify does not, because
>>> the first can re-use existing block files, just adding pointers to them to
>>> accomplish the repetition in a track.  Whereas Amplify really must make new
>>> block files for the entire duration, while still saving the old files so
>>> that you can undo.
>>
>>
>> I figured that was the underlying case.
>
>
> There are multiple ways that you might put demands on the disk that fail.
> Another I can think of is resampling.  But it would be hard to make an
> exhaustive list.
>
> Almost all editing operations may create some new block files.  Even
> deletion can do this, because one block file may need to be replaced with a
> shorter block file, but we keep the original too so that you can undo.  But
> it's things that require replacement of every block file, like Amplify, that
> are more likely to exhaust disk.
>
> PRL
>
>
>>
>>
>>>
>>>
>>>
>>> On Wed, Apr 5, 2017 at 1:38 PM, Peter Sampson
>>> <[hidden email]> wrote:
>>>>
>>>> 3) Import with disk fairly full
>>>> Free a little room on the USB E: drive
>>>> Launch Audacity
>>>> Open the truncated project from the USB E: drive
>>>> Try Imporrting a three minute WAV file
>>>> I get the same error non-user-friendly message as in 1) earlier:
>>>>
>>>> >Audacity failed to write to a file at
>>>> > E:\runoutofspacetest_data\e00\d00\e0000fce.au
>>>> >,Attempt this operation after removing unnecessary files.
>>>> >One way to do that is with the Discard buttonsin the History dialog.
>>>> >See the View menu.
>>>>
>>>> Dismiss the error message.
>>>> Nothing is imported.
>>>>
>>>>
>>>> 4) Generate with disk fairly full
>>>> Free a little room on the USB E: drive
>>>> Launch Audacity
>>>> Open the truncated project from the USB E: drive
>>>> Try Generating a three minute stereo tone
>>>> I get the same error message as in 1) earlier and 4) above.
>>>>
>>>> Dismiss the error message.
>>>> Nothing is Generated.
>>>>
>>>>
>>>> 5) Apply an effect with disk fairly full
>>>> Free a little room on the USB E: drive
>>>> Launch Audacity
>>>> Open the truncated project from the USB E: drive
>>>> Ctrl+A to select all
>>>> Effect>Repeat for 10 tests
>>>> Zoom to fit
>>>> Looks to repeat ok
>>>>
>>>> now
>>>> Ctrl+A to select all
>>>> Effect Amplify
>>>> I get the same error message as in 1) earlier and 4) above.
>>>>
>>>> Dismiss the error message.
>>>> Nothing is amplified.
>>>>
>>>> Apart from the clunky error message this is looking good so far :-)
>>>>
>>>> Peter.
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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


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

Re: My exception handling project is completed and ready for test!

Peter Sampson-2
Paul wrote:
>My suggestion is simply to stop export whenever we detect an error, and delete the
>incompletely exported file.  Let the user clear up space on the device and try it again. 
>Also, if asked to overwrite a file, still don't do it at once, but write a temporary, and
>replace the original only after the temporary is successfully written in full.

This should really be our last line of defence to avoid a user running out of disk space.
It is less egregious than disk-full on recording - as no data should have been lost, the
project should still be intact and the user can move on to free up some space and
try the export again.


>I am not persuaded that we should make an effort to estimate sufficiency of available
>disk space before writing.

The reason for doing this is that some exports can take a fair amount of time, believe me
me, I know.  As an exporter of 2-3 hour projects I have experience here.

Surely it is better to perform a little, simple, calculation of the required disk space and
compare thiswith remaining disk space - so then the user gets immediate confirmation that
there is insufficient disk space.  This way the user doesn't waste time waiting for an export
to complete, rather they free up space first, or export to a different device nad then get
straight on with an export that will succeeed.

Data overrun on a storage device is far more likely to occur with Export that with recording
as many folk will be recording and editing on the C: system drive (or Mac or Linux equivalent)
whereas quite often thay will be using USB clip drives for the export - I do this myself
for in-car listening.

So the proposal for pre-capture of the condition still stands imo.
http://wiki.audacityteam.org/wiki/Proposal:_Earlier_Disk_Over-run_Warnings
Especially for Export, Import (and possibly generators)
But even just fixing Export and Import would be a grat improvement for users.

Peter



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

Re: My exception handling project is completed and ready for test!

Peter Sampson-2
Postscript:  and of course we really need both approaches.

A user may start off a long export with sufficient space and then do something
else on teir computer that eats space while the export is in progess, thus leading
to a failed export.

My belief is that neither on its own is sufficintly adequate.

Peter.

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

Re: My exception handling project is completed and ready for test!

Gale
Administrator
In reply to this post by Paul Licameli
On 7 April 2017 at 01:19, Paul Licameli <[hidden email]> wrote:

>
>
> On Thu, Apr 6, 2017 at 6:54 PM, Gale Andrews <[hidden email]> wrote:
>>
>> On 6 April 2017 at 20:33, Paul Licameli <[hidden email]> wrote:
>> >
>> >
>> > On Thu, Apr 6, 2017 at 12:35 PM, Peter Sampson
>> > <[hidden email]> wrote:
>> >>
>> >>
>> >> On Wed, Apr 5, 2017 at 7:53 PM, Paul Licameli <[hidden email]>
>> >> wrote:
>> >>>
>> >>> I can change the error message to be more concise.  That is easy
>> >>> enough.
>> >>> I thought that the error message should at least include some
>> >>> indication of
>> >>> which device runs out of space.
>> >>
>> >>
>> >> +1 the device (and probably only the device) should be mentioned
>> >>
>> >>>
>> >>> The complete path is too much information though.
>> >>
>> >>
>> >> +1  I agree
>> >>
>> >> Once this message is made more user-friendly, I think from my
>> >> early-doors
>> >> testing
>> >> that you should be ready to mark this as Devel Fix-Made as James
>> >> suggested
>> >> earlier.
>> >
>> >
>> > You noticed that the two stereo channels might end up differing by one
>> > block's length (about 6 sec with 44100 Hz sampling and 32 bit float).
>> >
>> > You may also notice that the latency correction, which should be done
>> > when
>> > you record a new track under an existing one, might not be done in case
>> > the
>> > disk exhausts space, because it can also require allocation of block
>> > files
>> > after the appending is done.  (Try with positive and negative latency:
>> > they
>> > take different code paths.  Someone explained to me why positive latency
>> > might be useful, and I forget why, but no matter.)
>> >
>> > But we will have to agree that these are acceptable flaws, when the
>> > purpose
>> > is to salvage as much of the new recording as we can.
>> >
>> >>
>> >>
>> >>
>> >>>
>> >>>
>> >>> The error from libsndfile is put up by code in ExportPCM.cpp that I
>> >>> did
>> >>> not touch.  This is not reaching the places where I throw exceptions.
>> >>>
>> >>> Nonetheless I agree with Peter that it would be better for failed
>> >>> export
>> >>> not to leave partial results behind, whether it takes an exceptional
>> >>> path or
>> >>> not.  I was independently concluding that this is a gap in the
>> >>> project.
>> >>
>> >>
>> >> It would be nice if this could be done :-)
>> >
>> >
>> > More seriously, you might overwrite an existing file, after checking the
>> > confirmation dialog, and lose the original, which you might prefer to
>> > have
>> > kept instead of the partial result.
>> >
>> > I think exporting with overwrite should write to a temporary file name,
>> > then
>> > swap that into place only after success.
>>
>> Can we know with lossy formats like MP3 that the file was exported
>> in its entirety?
>>
>>
>> Gale
>
>
> Gale, in case of PCM export, we use third-party code to produce buffers of
> data for output, but our own code mediates the writing to disk, and we can
> detect it when a write fails.
>
> I think this is also true of the other exports.  I must look at the code for
> each one closer.

I think whether we can detect a problem with all exporters is key. If
we might not be able to, then an incomplete but playable file is
better than any risk of changing things so that the file may be corrupt
instead and we don't know.


> My suggestion is simply to stop export whenever we detect an error, and
> delete the incompletely exported file.  Let the user clear up space on the
> device and try it again.  Also, if asked to overwrite a file, still don't do
> it at once, but write a temporary, and replace the original only after the
> temporary is successfully written in full.
>
> I am not persuaded that we should make an effort to estimate sufficiency of
> available disk space before writing.

It seems like reasonable good manners to me and would reduce instances
where we need to fall back on what Peter called the last line of defence.

Another case too, though not directly related to out of disk space - don't
write WAV/AIFF over 4 GB which Audacity knows perfectly well will not
play correctly.  This frequently gets complained about and hopefully
demonstrates that users do sometimes export very long files - not just
music or audio books but "surveillance recordings" of various types.


Gale

>> >>> It makes sense that Repeat might succeed where Amplify does not,
>> >>> because
>> >>> the first can re-use existing block files, just adding pointers to
>> >>> them to
>> >>> accomplish the repetition in a track.  Whereas Amplify really must
>> >>> make new
>> >>> block files for the entire duration, while still saving the old files
>> >>> so
>> >>> that you can undo.
>> >>
>> >>
>> >> I figured that was the underlying case.
>> >
>> >
>> > There are multiple ways that you might put demands on the disk that
>> > fail.
>> > Another I can think of is resampling.  But it would be hard to make an
>> > exhaustive list.
>> >
>> > Almost all editing operations may create some new block files.  Even
>> > deletion can do this, because one block file may need to be replaced
>> > with a
>> > shorter block file, but we keep the original too so that you can undo.
>> > But
>> > it's things that require replacement of every block file, like Amplify,
>> > that
>> > are more likely to exhaust disk.
>> >
>> > PRL
>> >
>> >
>> >>
>> >>
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Apr 5, 2017 at 1:38 PM, Peter Sampson
>> >>> <[hidden email]> wrote:
>> >>>>
>> >>>> 3) Import with disk fairly full
>> >>>> Free a little room on the USB E: drive
>> >>>> Launch Audacity
>> >>>> Open the truncated project from the USB E: drive
>> >>>> Try Imporrting a three minute WAV file
>> >>>> I get the same error non-user-friendly message as in 1) earlier:
>> >>>>
>> >>>> >Audacity failed to write to a file at
>> >>>> > E:\runoutofspacetest_data\e00\d00\e0000fce.au
>> >>>> >,Attempt this operation after removing unnecessary files.
>> >>>> >One way to do that is with the Discard buttonsin the History dialog.
>> >>>> >See the View menu.
>> >>>>
>> >>>> Dismiss the error message.
>> >>>> Nothing is imported.
>> >>>>
>> >>>>
>> >>>> 4) Generate with disk fairly full
>> >>>> Free a little room on the USB E: drive
>> >>>> Launch Audacity
>> >>>> Open the truncated project from the USB E: drive
>> >>>> Try Generating a three minute stereo tone
>> >>>> I get the same error message as in 1) earlier and 4) above.
>> >>>>
>> >>>> Dismiss the error message.
>> >>>> Nothing is Generated.
>> >>>>
>> >>>>
>> >>>> 5) Apply an effect with disk fairly full
>> >>>> Free a little room on the USB E: drive
>> >>>> Launch Audacity
>> >>>> Open the truncated project from the USB E: drive
>> >>>> Ctrl+A to select all
>> >>>> Effect>Repeat for 10 tests
>> >>>> Zoom to fit
>> >>>> Looks to repeat ok
>> >>>>
>> >>>> now
>> >>>> Ctrl+A to select all
>> >>>> Effect Amplify
>> >>>> I get the same error message as in 1) earlier and 4) above.
>> >>>>
>> >>>> Dismiss the error message.
>> >>>> Nothing is amplified.
>> >>>>
>> >>>> Apart from the clunky error message this is looking good so far :-)
>> >>>>
>> >>>> Peter.
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > audacity-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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