Opening project hangs Audacity 1.3.7

[dgersic]

If I can figure that out, I'll post an update.

I think I've figured out how to break it. I think I said this already, but what I'm working on is an LP to CD record and conversion project. The recording part was done with Audacity 1.2.2, but I don't think that that matters for this problem.

The problem is the "h=xx" parameter in the *.aup file on the project. Resetting that to 0 allows the project to open without hanging Audacity.

To break it, open a project. Mine are 700M or so, a full length recording of an LP.

Scroll right using the mouse on the scrollbar, to the point where you can see the end of the recording. On my projects, this area contains the end of the music and the final fade out, some garbage from the end of the record, the final pop of the stylus being lifted, then a few seconds of silence. I don't want any of this, so ...

Select an area of the recording. I'm hunting for the end of the final fade out, but just click somewhere to move the cursor to somewhere in this area.

Click and drag to the right - selecting as you, *past* the end of the recording. This highlights from wherever you started, to a few seconds past the end of the project recording data.

Change your mind on this being a good idea. Use Shift-End instead to select from wherever the cursor was to the end of the recording.

Hit Ctrl-X to remove the selected area.

Save the project.

At this point, Audacity may hang. If not, close the project and try to open it. If you try to open this project, Audacity hangs as previously described.

I think what's happening is that the Click-and-Drag to the right is moving the "h=xx" parameter past the end of file, especially after the end of file is moved back a few seconds worth of data by the Shift-End / Ctrl-X delete of the garbage at the end of the recording. Then what happens when Audacity tries to open this project is that it's using the "h=xx" parameter to position back to where you were last working on it, except that "h=xx" now points to an invalid area beyond the end of the project. Boom.

I'm curious to know if you can reproduce this as well. I've done it here a few times now and it seems to kill it every time. Resetting "h=xx" to "h=0" then allows the project to open, and positions it back at the beginning.

[steve]

Congratulations, you seem to have found a bug.
I'm not yet able to reproduce it reliably, but I can reproduce it sometimes. I'll play with this a bit more and see if I can find the missing piece that makes it happen every time and then pass it on to the developers for fixing. (I've also managed to make it happen in the current development version (1.3.8 alpha), so it is a current issue).

I'll post back here to keep you informed of progress.

[steve]

I'm still not able to create the freeze reliably, but the process does produce orphaned block files quite regularly. I'm passing this over to the developers now - let's see what they make of it.

[Gale Andrews]

I think I've figured out how to break it...Click and drag to the right - selecting as you, *past* the end of the recording. This highlights from wherever you started, to a few seconds past the end of the project recording data. Change your mind on this being a good idea. Use Shift-End instead to select from wherever the cursor was to the end of the recording. Hit Ctrl-X to remove the selected area. Save the project. At this point, Audacity may hang. If not, close the project and try to open it. If you try to open this project, Audacity hangs as previously described.

I think what's happening is that the Click-and-Drag to the right is moving the "h=xx" parameter past the end of file, especially after the end of file is moved back a few seconds worth of data by the Shift-End / Ctrl-X delete of the garbage at the end of the recording. Then what happens when Audacity tries to open this project is that it's using the "h=xx" parameter to position back to where you were last working on it, except that "h=xx" now points to an invalid area beyond the end of the project.

Hi,

I don't see how "h" which is the position in seconds where the visible waveform starts could point beyond the end of the project (unless all the audio was behind zero) , and clearly this is not true in Live In Hollywood (Edits).aup as was included in your zip. The h position is approximately 56.437 seconds and the end of the file (after you cut it) 150382016 samples (about 56.5 seconds).

I did have a very similar case on Linux with 1.3.7 where "h" was implicated in a freeze:
http://n2.nabble.com/high-cpu-usage-gra ... 50519.html

Here, setting "h" back to 41 seconds overcame the problem. These were the settings that caused the freeze:

sel0="0.0000000000" sel1="104.3566213215"
vpos="0" h="50.7100941180" zoom="10.6530660950" rate="44100"

However this user said the problem went away after compiling 1.3.8.

I made a stereo project (.aup attached) with identical length, cursor, h and zoom positions to "Live In Hollywood (Edits).aup" and it refused to give problems for me on Windows in 1.3.8. Nor can I get orphaned blockfiles or problems with your end of track routine in an arbitrary file, though I do think editing at the end of tracks is a possible cause of crashes and has done so for me.

If anyone wants to try the attached on Linux, just open an empty project, add a stereo track, generate 150382016 samples of audio, and save and exit. Then replace the data at the top of the .aup file with these settings in the Hollywood file:

sel0="3410.0230385488" sel1="3410.0230385488" vpos="0" h="3403.7405895692" zoom="172.2656250000" rate="44100

and save and reopen the project. If it does not freeze, there must be some other factors going on than merely "h" (to my logic anyway).



Gale

[steve]

If anyone wants to try the attached on Linux, just open an empty project, add a stereo track, generate 150382016 samples of audio, and save and exit. Then replace the data at the top of the .aup file with these settings in the Hollywood file:

sel0="3410.0230385488" sel1="3410.0230385488" vpos="0" h="3403.7405895692" zoom="172.2656250000" rate="44100

and save and reopen the project. If it does not freeze, there must be some other factors going on than merely "h" (to my logic anyway).

Tried that half a dozen times and no freeze and no orphans. My logic agrees that there must be some other factor, but I've not found it yet.

[Gale Andrews]

Leland posted some more information on our developers' mailing list which Steve will have seen but not dgersic. Leland can apparently reproduce the hang by changing the "h=" value in the project to a value that triggers the problem. I'm not sure if this means Audacity is somehow interpreting h values other than those saved in the .aup file. He says "this particular issue is related to a recursion issue "caused" by the ProgressDialog when it yields. Eventually a select() is done on something that never responds and it just hangs."

So I think the only real moral at the moment is change the h value to a lower value, the safest being h="0.0000000000".



Gale

[dgersic]

I don't see how "h" which is the position in seconds where the visible waveform starts could point beyond the end of the project (unless all the audio was behind zero) , and clearly this is not true in Live In Hollywood (Edits).aup as was included in your zip. The h position is approximately 56.437 seconds and the end of the file (after you cut it) 150382016 samples (about 56.5 seconds).

If you read back over this thread, we found that setting sel0, sel1, h, and the envelope data allowed the project to open without hanging. So the next project I had that was affected, I tried one at a time. Changing sel0 and sel1 had no effect. Changing h to 0 allowed the project to open. I didn't change the envelope data.

I can't explain why this happens, I can just report that it does. But if you'd like more sample projects to examine, I can start saving them when they break.

I did have a very similar case on Linux with 1.3.7 where "h" was implicated in a freeze:
http://n2.nabble.com/high-cpu-usage-gra ... 50519.html

Yes, similarly here. Audacity just wedges when the file opens. The menus are greyed out, the CPU spikes, and the only way out is to kill it. Reset "h" to 0, and the project opens fine.

[dgersic]

Leland posted some more information on our developers' mailing list which Steve will have seen but not dgersic. Leland can apparently reproduce the hang by changing the "h=" value in the project to a value that triggers the problem.

Ah, very interesting. Thanks. Is there anything else I can add to help find this and get it fixed?

[steve]

Is there anything else I can add to help find this and get it fixed?

It is generally helpful if someone can find a simple step by step method that allows the bug fixer to reliably reproduce the problem. For example:
1) Generate a tone of 20 seconds
2) select from ....
.....

Posting 700MB projects is usually less helpful.

In this case it looks like Leland is on top of the job, which usually means it gets fixed quickly, so there's probably no need to go to town on this unless you you particularly feel the urge.

[encore]

I am experiencing similar issues with attempting to open .aup files. I have recently upgraded to Jaunty (my first mistake judging by experiences so far with audio problems).
I spent most of the day creating a project on 1.3.7 now 4 times, and the last time I was finally able to at least export to .mp3 once. (the first 3 files would not open once they were saved and the application was closed)

I'm not sure if this has any relevance to the discussion, but I created the project while using 'Sound Activated Recording' turned on. I'm wondering if this somehow confuses Audacity into thinking the project total length is different than actuality.

My set up:
Ubuntu Release 9.04 (Jaunty)
Kernel Linux 2.6.28-15-generic
GNOME 2.6.21
Memory 2.0 GB
Processor Pentium 4 CPU 2.66 GHz
Available Disk Space
OS partition 68.6 Gb
Data partition 442.8 Gb
Audacity 1.3.7

My broken .aup file snippet details

<?xml version="1.0" standalone="no" ?>
<!DOCTYPE project PUBLIC "-//audacityproject-1.3.0//DTD//EN" "http://audacityteam.org/xml/audacityproject-1.3.0.dtd" >
<project xmlns="http://audacityteam.org/xml/" projname="Side-2_data" version="1.3.0" audacityversion="1.3.7" sel0="1010.3765986395" sel1="1010.3765986395" vpos="0" h="1006.8007256236" zoom="86.1328125000" rate="44100">

I can confirm that after attempting to set 'h' to match the total time of the project, and also to match the values of 'sel0/sel1' unsuccessfully, I set 'h' to 0 and was able to open the project.