This should be a proper fix for bug #7003, now that I've spent a bit more time
reading the code. The options are now stored as part of the export format
state.
Some Mixbus users (on Windows) have reported seeing ludicrously high figures for the amount of disk space that'll be recovered if they choose to clean up unused sources. I can't see anything obviously wrong in Ardour's code - except for one situation where we don't check a return value after calling 'g_stat()'.
On Windows, the relevant path should be (hopefully!) in UTF8 format and the first thing that g_stat() does is to convert it to UTF16. If that conversion fails for some reason, g_stat() will return an error status and statbuf will be uninitialized - but at the moment, we're not checking this. As an experiment, let's check the returned value and find out if these user reports go away.
Unfortunately, if it does fix the problem then we've got an even bigger problem - because somehow, a Windows user can create source files with invalid names which can't be later deleted!!
Often one needs to make sure that all the relevant settings are made
before one actually starts recording. The Lua interface can take care of
this task easily, that the operater by just one action can make sure
that the relevant settings (e.g. recenables, playhead position, etc.)
are ready for recording. This example was written with a quasi live
podcast scenario in mind.
See `scripts/prepare_record_example.lua` for details.
Clearing location markers is a frequent task and should be automizable. For
example it is handy to clear all the markers when restarting the recording
from scratch after a failed recording.
There were two issues:
The first is that TrimDrag::aborted was calling TrimDrag::finished with a null
GdkEvent which caused a segfault when dereferencing. So avoid that by passing
in a dummy event as we are just going to undo the operation in the next step
anyway so it shouldn't matter if it is valid(AFAICT).
The other is that TrimDrag:aborted was calling Editor::undo() which was in turn
calling TrimDrag::aborted leading to infinite recursion and stack overflow.
Calling Session::undo() directly seems to avoid that issue.
This fix feels like a bit of a hack...but it seems to work and is better than a
crash.
If a Session is saved and then the start or end session markers are moved,
closing the Session will not result in "Unsaved Session" dialog being presented
even though the Session has been modified. This change sets the Session as
modified when either the Session start or end markers are modified.
