Difference between revisions of "Proposal: Earlier Disk Over-run Warnings"

Latest revision as of 12:07, 8 January 2022

This proposal has been transferred to GitHub as Issue #2394.

The Problem

Bug #437 relates to this issue and is where it was originally reported. The fix for Bug #437 provides traps just as Audacity is about to run out of space for Recording, project Saves, and Exports - an error message is popped up and Audacity will clean up after such unsuccessful Saves or Exports. Recording will cleanly stop with a partial project.

We could be more helpful to the user by checking in advance that there is sufficient space for what the user is trying to do, popping an error/warning before starting the required action. This would avoid time wasted by a partial and aborted action. There is one place in Audacity where we currently do this and that is in Timer Record where checks are made that there is sufficient space for the required elapsed time of recording and an error is popped if not so.

We do still need the bug #437 traps as the ultimate safeguard.

1. Although a recording that runs out of space now provides the user with a partial project, we could be more helpful by providing earlier warnings. There is the recording time left that shows in the Status bar - but we know that many people overlook the Status Bar
2. The Save Project commands when running out of space only reports when the failure occurs (which could be many minutes later) - Audacity could check before starting the Save that there is sufficient space.
3. Export too, when running out of space only reports when the failure occurs (which could be many minutes later) - Audacity could check before starting the Export that there is sufficient space.
4. Import can easily be asked to import a data set that is too large for the available disk space.
5. The Generate and Effect plug-ins are capable of generating large amounts of audio data with the potential for disk overrun, this is not handled cleanly.
6. Copy & Paste and Repeat are also capable of generating large amounts of data.
7. Even seemingly innocuous commands have the potential to produce sufficient data to overfill the disk.

Proposed Feature

A suitable headroom buffer to be defined - to especially avoid overfilling the user's main drive (C: in the case of Windows). This should be user-settable but deep in Preferences and with a sensible default of 50-100MB say.

• For Recording activities:
  1. Check before recording starts that there is more space available than the headroom buffer
  2. While recording takes place check the available disk space
  3. If and when it reaches the headroom buffer size: Audacity stops with an error message
     • A three-level "traffic-light" green->amber->red warning could be provided ahead of reaching the headroom buffer

• Save commands
  1. check that the volume of data to be created, based on current settings will not overfill the disk capacity minus the headroom buffer
  2. if so disallow the Save with a suitable error message and advise the user to free up some disk space and try again
  3. Particularly a problem if the user has not pre-saved the project and is occupying space in the Audacity Temp directory (which is only cleaned up after the Save is made)
  4. Particularly a problem too if the user has enough space for a Save but not a Save As - we may want to advise them to make a Save and then free up some disk space.

• Export
  1. check that the volume of data to be created, based on current settings and exported file-type, will not overfill the disk capacity minus the headroom buffer
  2. if so disallow the export with a suitable error message

• Import
  1. check that the volume of data, based on current settings and imported file-type, will not overfill the disk capacity minus the headroom buffer
  2. if so disallow the import with an error message

• Generators and effects
  1. Check before the plug-in starts that there is more space available than the headroom buffer
  2. check that the volume of data, based on current settings, will not overfill the disk capacity minus the headroom buffer
  3. If we want to be really secure we would need to check as the plug-in progresses that we are not exceeding the headroom (in case the estimate was inaccurate) and if so stop the plug-in gracefully with an error message.

• Copy & Paste

Neither of these commands appears to generate any noticeable extra disk occupancy, the assumption is that they are using pointers. However once you manipulate the copied data with an effect then the disk size occupancy does increase - but that should be trapped under Generators and effects above.

• All other commands - in fact all commands
  1. Before the command is implemented in any way check that we have more available space than the headroom buffer.
  2. If not then inhibit the command and display an error message

• Regular checking
  1. It may be beneficial that, while Audacity is idling, it makes periodic checks to see if disk-space is being eroded (by other applications) and if so display a suitable "out of space" error message that the user will see on their return to Audacity,

Developer/QA Backing

• Peter: particularly for Record, Save, Export and Import commands as it would mean we could stop the command from even starting to implement if there would be insufficient space.

Use Cases

• While recording, many users overlook the Status Bar time remaining messages, so would be surprised by an abrupt stop and the bug #437 error message.
• The user could be many minutes into the Save of a large project, or an Export from it, only to have it aborted - thus wasting those minutes.

Tables for analysis and subsequent tracking

I would suggest that we use these tables to track the progess as part of Bug #437 rather than raising separate Bugzilla entries for each table entry (there are seventy of them).

File Menu

Edit Menu

Transport Menu

Tracks Menu

This set of commands could be seen as far less critical to trap then the Record and Save commands so sould probably be ignored.

Generate Menu

This set of commands could be seen as far less critical to trap then the Record and Save commands so could probably be ignored.

Effect Menu

This set of commands could be seen as far less critical to trap then the Record and Save commands so could probably be ignored.

Effect Menu below the line

This set of commands could be seen as far less critical to trap then the Record and Save commands so could probably be ignored.

Analyze Menu

This set of commands could be seen as far less critical to trap then the Record and Save commands so could probably be ignored.

Generate/Effect/Analyze Menus

This set of commands could be seen as far less critical to trap then the Record and Save commands so could probably be ignored.

The generators are protected from storage space overrun by the fix(es) for Bug #437 (error message and clean-up)

Details

A souped up progress dialog might be one way to implement this feature. We can't always predict for sure how much space a change will take up. A progress dialog can show a memory dial, and indicate if we look at risk of exhausting memory. That way the complaint of a long operation failing can be addressed. A user can see it may be borderline whether it will complete and fit or not, as the operation progresses.

GUI Examples

TBP

Previous Feature Requests relating to this proposal

• Disk use limit for recording (11 votes)
  • Option to Disable (1 votes)

• Disk space check before exporting: (16 votes) - including indication of expected size of export, and choice to export partial file or cancel if insufficient space available. Would stop user exporting WAV files over the 2/4 GB limit, MP3s in excess of ringtone limits etc.

Could only indicate that space was available at time of checking, could never guarantee the file would be completed if other disk events occurred. However Audacity 2.x does now have a warning if WAV/AIFF exports are not completed.