On Mon, Apr 7, 2014 at 1:28 PM, John Rigg <[email protected]> wrote:

> Sorry about the long post, but I've just experienced a nasty bug while
> using
> non-timeline. For the last few days I've been working on a fairly complex
> recording. Today I added a track to a session that already contained 13
> tracks,
> and set up a couple of punch ranges. Next I set up a playback range
> starting
> slightly before the first punch range and stopping just past the end of the
> range. I'd already used this approach earlier in the session without a
> problem.
>
> This time the playhead didn't stop after the end of the playback range and
> wouldn't respond to the space bar or the play button. At this point top was
> showing about 38% CPU for non-timeline, but it was only ~3.5% before this
> occurred. It overran the end and showed no signs of returning to normal so
> I aborted the session in NSM. After quite a long delay it stopped.
>
> On restarting the session looked OK. The second punch range had been
> recorded
> over so I went to delete the region. It refused to delete, so I clicked on
> Undo. As well as undoing the last recorded region, it undid everything
> else,
> leaving a blank non-timeline window. The latter half of the history file
> was
> full of "destroy" instructions for every item.
>
> The sources are still intact. I was able to restore everything by editing
> the
> history file to remove all the "destroy" instructions. The playhead now
> stops
> where its supposed to, but the region that refuses to be deleted is still
> there. Trying to remove it with Undo gives a repeat of the total history
> undo, so I'll try editing to get rid of it.
>
> I've copied the history file as it was after the first total undo below.
> The system is Debian 7.4 amd64 running on a 2.5GHz Athlon IIx4, with
> current
> git versions of non and JACK2.
>
> Any ideas what could have caused the problem with the playhead in the first
> place?
>
> John
>

<snip>


Yeah, I think I know what this is. I have some changes that completely
rework the way punch in/out is handled to avoid this and some other related
bugs, but I haven't been able to test it adequately for publication.

You should be fine editing the history file (but keep a backup!). No matter
how messed up it is, you can always go back to a point where it wasn't.

Until I get the fix published, punch in/out will not be 100% reliable.

Reply via email to