Discussion:
[Audacity-devel] My exception handling project is completed and ready for test!
Paul Licameli
2017-04-04 03:55:57 UTC
Permalink
Whew.

PRL
James Crook
2017-04-04 08:29:26 UTC
Permalink
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.
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-04-05 15:24:34 UTC
Permalink
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
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
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
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.
James Crook
2017-04-05 15:55:27 UTC
Permalink
Post by Peter Sampson
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
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.
Post by Peter Sampson
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
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.
Post by Peter Sampson
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-04-05 17:38:13 UTC
Permalink
*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
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.
Peter Sampson
2017-04-06 16:35:34 UTC
Permalink
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 <
Post by Peter Sampson
*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
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.
Gale Andrews
2017-04-06 19:20:09 UTC
Permalink
Post by Peter Sampson
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?
Post by Peter Sampson
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
Post by Peter Sampson
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
Post by Peter Sampson
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-04-06 19:33:26 UTC
Permalink
On Thu, Apr 6, 2017 at 12:35 PM, Peter Sampson <
Post by Peter Sampson
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.
Post by Peter Sampson
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.
Post by Peter Sampson
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
Post by Peter Sampson
On Wed, Apr 5, 2017 at 1:38 PM, Peter Sampson <
Post by Peter Sampson
*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
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.
Gale Andrews
2017-04-06 22:54:19 UTC
Permalink
Post by Paul Licameli
On Thu, Apr 6, 2017 at 12:35 PM, Peter Sampson
Post by Peter Sampson
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.
Post by Peter Sampson
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
Post by Paul Licameli
Post by Peter Sampson
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
Post by Peter Sampson
On Wed, Apr 5, 2017 at 1:38 PM, Peter Sampson
Post by Peter Sampson
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-04-07 00:19:05 UTC
Permalink
Post by Paul Licameli
On Thu, Apr 6, 2017 at 12:35 PM, Peter Sampson
Post by Peter Sampson
I can change the error message to be more concise. That is easy
enough.
Post by Paul Licameli
Post by Peter Sampson
I thought that the error message should at least include some
indication of
Post by Paul Licameli
Post by Peter Sampson
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
Post by Paul Licameli
Post by Peter Sampson
testing
that you should be ready to mark this as Devel Fix-Made as James
suggested
Post by Paul Licameli
Post by Peter Sampson
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
Post by Paul Licameli
you record a new track under an existing one, might not be done in case
the
Post by Paul Licameli
disk exhausts space, because it can also require allocation of block
files
they
Post by Paul Licameli
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
Post by Paul Licameli
is to salvage as much of the new recording as we can.
Post by Peter Sampson
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
Post by Paul Licameli
Post by Peter Sampson
not to leave partial results behind, whether it takes an exceptional
path or
Post by Paul Licameli
Post by Peter Sampson
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
Post by Paul Licameli
kept instead of the partial result.
I think exporting with overwrite should write to a temporary file name,
then
Post by Paul Licameli
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
Post by Paul Licameli
Post by Peter Sampson
It makes sense that Repeat might succeed where Amplify does not,
because
Post by Paul Licameli
Post by Peter Sampson
the first can re-use existing block files, just adding pointers to
them to
Post by Paul Licameli
Post by Peter Sampson
accomplish the repetition in a track. Whereas Amplify really must
make new
Post by Paul Licameli
Post by Peter Sampson
block files for the entire duration, while still saving the old files
so
Post by Paul Licameli
Post by Peter Sampson
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
Post by Paul Licameli
shorter block file, but we keep the original too so that you can undo.
But
Post by Paul Licameli
it's things that require replacement of every block file, like Amplify,
that
Post by Paul Licameli
are more likely to exhaust disk.
PRL
Post by Peter Sampson
On Wed, Apr 5, 2017 at 1:38 PM, Peter Sampson
Post by Peter Sampson
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
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.
------------------------------------------------------------
------------------
Post by Paul Licameli
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-04-07 08:30:32 UTC
Permalink
Post by Paul Licameli
My suggestion is simply to stop export whenever we detect an error, and
delete the
Post by Paul Licameli
incompletely exported file. Let the user clear up space on the device and
try it again.
Post by Paul Licameli
Also, if asked to overwrite a file, still don't do it at once, but write a
temporary, and
Post by Paul Licameli
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.
Post by Paul Licameli
I am not persuaded that we should make an effort to estimate sufficiency
of available
Post by Paul Licameli
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
Peter Sampson
2017-04-07 09:29:25 UTC
Permalink
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.
Gale Andrews
2017-04-08 00:31:50 UTC
Permalink
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
On Thu, Apr 6, 2017 at 12:35 PM, Peter Sampson
Post by Peter Sampson
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
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.
Post by Peter Sampson
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.
Post by Paul Licameli
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
Post by Paul Licameli
Post by Gale Andrews
Post by Paul Licameli
Post by Peter Sampson
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
Post by Peter Sampson
On Wed, Apr 5, 2017 at 1:38 PM, Peter Sampson
Post by Peter Sampson
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-04-05 15:57:47 UTC
Permalink
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.
Loading...