2.1.2 RC1 & RC2 Update Display during Play problem

Audacity Help Forum Windows
3

I can’t say whether it’s more likely when zoomed or with longer or shorter tracks. I’m usually working on recordings of church services so the length is typically between 80 and 120 minutes. When I posted this, I believe it happened when zoomed in by one step (my most frequent zoom level during playback). I was starting and stopping via the space bar, so I just started it over when I found it wasn’t scrolling. I believe this has been the case on every occasion when this has happened. I’ll post again if it happens under other conditions.

  • DickN
4

Observations:

I had just deleted 1.47 seconds and Horizontal Zoom level was 1 click in. I hit space bar to play from the point of deletion and there was no horizontal scroll. I stopped playback with the space bar, then hit my “History” shortcut. History took an extraordinary time to respond, during which time clicking on the title bar yielded “not responding”. While I was taking notes, History appeared. The Play and Transcription buttons had the “repeat” icons, but I don’t know when these appeared.

I recall that on the occasion of which I posted above I had also deleted audio and was starting play from the point of deletion.

  • DickN
5

Observations 2 (project with single stereo track plus 3 label tracks, about 80 minutes long):

It doesn’t matter which track has focus.
I’ve had it happen with horizontal zoom at Normal and when expanded 1 click.

Sync Lock ON/OFF makes no difference, at least once in the failed state. Deleting seems to be the trigger and I’ve always had Sync Lock ON then.

Displaying Preferences->Tracks and exiting via X or OK, even if “Update display while Playing” is toggled OFF and back ON, does not correct the state. I didn’t exit in the middle of toggling, so I might not have done a valid test. I’ll try that next time.

[EDIT] See my next post (Jan 12). [/EDIT]

Starting Play by clicking anywhere on the Timeline does not fix it, and therefore may be used to test for the state without changing it. I haven’t tested playing a range via the timeline. Starting Play by clicking on the Timeline also seems to have a better chance of producing the problem than starting it via the spacebar.

The failed state can initially appear when Play is started via spacebar. Spacebar does not fix it when it initially appears, but will fix it if used to start it again.
I haven’t determined whether it can initially appear when Play is started via Transport Play button. I’ve only tried this a few times and it hasn’t happened yet.

In a project of this length (about 80 minutes), regions where it happens frequently and regions where it happens infrequently seem to alternate. I wasn’t noting the location of each occurrence, so can’t quantify this yet. Also the opportunities (i.e. where I delete audio) aren’t uniformly distributed, which will make it more challenging.

When automatic scroll is failed, starting Play via either the spacebar or the Transport Play button will fix it. The fix occurs upon start, not stop, so it doesn’t matter how or where (on or off screen) Play is stopped - Transport Stop, spacebar, or reaching end of Select Range - if it was started via Transport Play button or spacebar, it’s fixed.

Deleting some audio (a fraction of a second to a few seconds in my observations, but I haven’t determined whether size matters) seems to be the trigger but it happens only occasionally. If audio is deleted while in the failed state, proper operation may be restored. I’ve tried this only once, so can’t say whether it always works.

Applying a Nyquist (fade by dB) or Audacity (amplify) effect after deleting does not change the state.

  • DickN
6

Unfortunately I cannot get that to happen, but I will keep trying it from time to time.


Gale

7

Just had another occurrence of this using nightly build ‘audacity-win-r53b8fd5-2.1.2-alpha-09-jan-16’ with Windows Vista. I had not deleted anything in the last hundred or so history levels, but I had just started Play with the spacebar and was typing a point label when the display should have wrapped. I’m accustomed to the label jumping in and out of view when I do this, but scrolling had stopped. I closed the label with Enter and stopped Play with the spacebar. I confirmed that scrolling was crippled by clicking on the Timeline to start Play again. I stopped Play again with the spacebar.

This time I turned “update display while playing” OFF, OK’d out of Preferences, then turned it back ON again and OK’d out again. This time the scrolling was restored. I reported in my previous post that this didn’t work, but that time I hadn’t used OK to effect the change.

Another (probably unrelated) observation: 2.1.2 (RC1, RC2 and this one) often takes a very long time to present the History window and to terminate. When terminating, the Audacity window’s contents are cleared fairly promptly but the skeleton of the window remains sometimes for minutes before the program finishes shutting down, even if the project was recently saved.

8

History window slowness moved to new topic https://forum.audacityteam.org/t/history-window-slowness/41159/1


Gale

9

Using Vista, I just experienced this cessation of auto-scroll in 2.1.2, build 1/9/2016. It seems to be a rare occurrence in this build.

I had just deleted 2.93 seconds of audio, added a point label at the deletion using Ctrl-Alt-v and I’m not sure now whether the label was still open. Track duration was 01:55:22+45f, and point was at 01:29:01+49f. Project had a single stereo track, all one clip.

This time, starting play via space bar did not restore auto-scroll as it does in RC1 and RC2. I didn’t try the transport Start button. The steps immediately before I found it working again were:

Select whole track;
Play some of it by clicking on timeline and hitting space bar to stop (after playback cursor had gone off-screen);
Make a point selection after the original point;
Start play via space bar.

Starting play again from the original point did not break auto-scroll again.

Just in case this provides a clue to the programmers, I encountered the auto-scroll problem in 2.1.1, and then found that the “no ‘B’ and ‘C’ commands” bug had abated. These commands continued to be functional after auto-scroll was restored. I can’t say with any certainty that ‘B’ and ‘C’ were not functional before the auto-scroll failure, only that this is the first time I’ve found them working in this rev. They were among my attempts to restore auto-scroll.

10

The “B” and “C” bug ceases in 2.1.1 once you record.

So you were already zoomed in but no-one knows how far, we don’t know the source of the audio (file or recording), also it is not clear whether the duration was 01:55:22+45 CDDA frames before or after the deletion.

I am still not able to reproduce any failure, using your information above. Thanks for pursuing this, but it’s unlikely to be fixed unless you can post a project that can reproduce it at least some of the time.


Gale

11

I had not intentionally been in Record mode, but my recollection is unreliable. It happened Monday and I appended it from my notes while reporting the 2.1.2 event.

Source of the audio was an existing project on which I had been doing various parts of the editing using different Audacity versions for test purposes. Recalling the size of the approx. 3 second selection on screen, I was zoomed in 1 click. 01:55:22+45f was the length after the deletion - I selected the whole track to get this for documenting the event, which was after deleting. Sorry about the ambiguity there. Also, Snap was OFF. I’ve never attempted to learn whether that matters (note to self…). Sync-Lock was ON, but I have found that to not matter.

I’ll go back to RC2 when I’m not splitting a track, since that one did it much more often. I went to this build because I expected to be splitting off mono portions for exports, but didn’t get that far. This is the first time I’ve seen it happen in this build - I thought it was fixed, either collaterally or methodically.

The fact that in this nightly build (1/9/2016) starting play with the space bar doesn’t fix the condition whereas in RC1 and RC2 it does might be the most pertinent clue added by this experience. Sorry I neglected to try the Transport Start button, which fixes it in RC1 & RC2.

12

We are not going to go back to fix 2.1.2 RC2, though. Many changes are now being made to the code which may or may not effect what you are experiencing.

If you have a project that reproduces your issue in 2.1.2 RC2 or 2.1.2 release, and still reproduces in the latest “nightly” build, please let us know.

Thanks

Gale

13

Using 2.1.2 (release version) on Vista.

It looks like you can ignore my report that starting play via space bar doesn’t restore auto scroll on 2.1.2, unless there’s a difference between the 1/9/2016 nightly build and the release version with the same date. In the release version, starting via the space bar or the transport Play button restores the scroll.

I’ve also found (in the release version) that deleting audio is not necessary for this to happen. It might involve zooming in to the point where samples appear. I’ll report anything I observe that looks useful (especially if I find a way to make it happen), and I’d say observations that disprove hypotheses from previous observations qualify.

I just had a diagnostic report generated by 2.1.2 (not coincident with a loss of auto scroll event). Does that get sent automatically, or do I have to send it; if so, I need instructions.

DickN

14

Are you saying that Audacity crashed and you saw the Debug Report Audacity dialogue?

If so there is a zipped report inside the C:\Users<your user name>\AppData\Local\Temp\Audacity_dbgrpt-\ folder. You can attach that zip file in the normal way. Please tell us what you were doing in Audacity before the crash.

Thanks


Gale

15

Ok, here 'tis

16

I finally have a procedure that consistently (for me at least, using 2.1.2 release under Windows Vista) produces this condition and a couple of others.

I had discovered that just starting Repeat-Play (shift-space) and stopping it anywhere in my 93 minute project put Audacity in the crippled-auto-scroll state. Zoom level, location and length of the selection didn’t matter. It also didn’t matter whether I used the spacebar or the Transport buttons to start and stop. It wasn’t even necessary to play the whole selection once in repeat-play mode. I tried this in other existing projects of a few minutes length with 1 or 2 stereo tracks and got the same results. When I started experimenting to see how short a track would suffice, things got really confused. To wit:

Launch Audacity afresh to ensure it’s in the initialized state.
Generate a 3 second chirp (mono).
Zoom in 1 click so track extends beyond the screen boundaries (exact zoom not critical).
Select 0.5 sec within the chirp (nothing special about 0.5 second, can be longer or shorter).
Repeat-play (shift-space) and stop with spacebar. Number of repeats doesn’t matter, can be less than 0.5 sec.
Clicking on timeline anywhere before midpoint of selection now plays to end of selection.
Clicking on timeline anywhere after midpoint of selection now plays to end of track with no scrolling.

Often I got into a state such that clicking anywhere on the timeline plays the whole selection once.
I haven’t managed to track down the steps to get into this state, but I have little doubt that it will occur while you’re trying this.

17

I assume SPACE not stopping playback then pressing SPACE again crashes has not happened to you again? That might cause a freeze of Audacity on Linux systems using pulse, but it is not a known problem on Windows.

It is probably a once only problem.

Gale

18

OK thanks Dick for boiling it down to simple steps. I can reproduce that on Windows 7 so I will put it on Bugzilla if it is not already there.

For me, just standard playing the selection without looping restores auto scrolling.

Gale

19

Yes, it will because Play was started with either the spacebar or the Transport Play button. That’s one of the things that restores it. The other is turning auto scroll off and back on in Preferences (you have to OK both changes for this to work).

20

I had tried that already with one OK and two. Doesn’t fix it for me.


Gale

21

I just tried disabling/enabling “update display while playing” and, as in your test, it didn’t restore auto-scroll. I had reported on Jan 12 that this works, and it did then but the underlying cause of the condition then was related to deleting audio, as in most of my experiences with it. I also tried another caveat which I have documented in my notes but have never reported: Jumping to time=0. This worked once and I made a note of it, but it doesn’t work in this test.

Next time auto-scroll fails for some reason other than this Repeat-Play cause, I’ll try both of these (well, probably only one if the first one I try works).

Have you tried the Repeat-Play test with a 3-second track length? It gets “interesting”.

22

I created the bug report http://bugzilla.audacityteam.org/show_bug.cgi?id=1342.

You don’t need to create any selections. Just loop-play, then Quick-Play and standard scrub won’t scroll.


Gale