Trying out template version of bug list
- Bugs with Long Comment Trails.
- Bugs at P2.
- Bugs chosen by James to showcase.
- "Orphaned" or "missing" blockfile errors are found on opening a project. When users accept the "recommended" course to delete orphans, that project is silenced (or other projects that were open at the same time are silenced) - possibly in a patchy way.
- The frequency of reported data loss since 1.3.13 Beta is about once a week (down from previous levels) but there are still reports - now down to one or two per month - of apparently harmless orphans upon relaunching Audacity and opening a project. These can't therefore be clipboard files wrongly detected as orphans (a bug which is now fixed in 1.3.14 alpha).
- Usually errors are associated with multiple projects open at the same time and Audacity putting blockfiles in the wrong _data folder, or with a project that has multiple "d*" folders inside "e00" and Audacity putting the .au file in the wrong subfolder.
- Sometimes edits at the end of a track are implicated, sometimes cutting/duplicating whole tracks to new projects (or to new tracks within the project).
- Audacity has also occasionally been found to move, rename or delete .au files within the current _data folder when re-opening the project, thus creating orphans and/or missing files. This is generally not reproducible even with copies of the original project.
- However bug 451 identifies repeatable deletion of .au files on reopening the project where the .aup file shows blockfiles that have "len" greater than the "maxsamples" permitted for each block in the sequence. It is hoped finding a way to prevent the deletion might prevent unwanted deletions for other reasons.
- Another line of enquiry is that there are Read() or Write() file errors (the returns of these are not tested). For example the .au file isn't written or the .aup file is not updated.
- Another line of enquiry is that Unicode Release is much more fallible than Unicode Debug especially under formal stress testing or on stressed machines in normal multi-task use. Ed surmises that that running under the debugger could mask a timing error or make disc Writes almost infallible.
- When you have a USB device connected, Audacity sliders for the mobo device (and in some cases the USB device also) do not work correctly. Remove the USB device and the sliders for the mobo device work. Uninstall the mobo device and the sliders for the USB device work. Problem in portaudio?
- Significant work done, but problem remains.
- Current speculation is that this is a memory corruption problem of some kind, because once it happens problems in using Audacity continue.
- Possibly this bug is rarer - following a fix by Michael.
- Gale was seeing these problems himself before Michael's fix, but is not seeing them now.
- Leland updated us to latest libsndfile 3-Apr-2011, which if this is a problem in libsndfile may help.
Reduced from P2 to P3, based on rarity/belief that Michael's fix has improved matters (3rd April 2011). Vaughan wonders if the bug's rarity now makes it a 'comet-returns' bug, rather than moonphase.
- If you change the input volume in Audacity and then record, the volume is reset to its original level.
- This appears to occur mostly with a few specific USB devices, and sometimes only on Vista SP1.
- Micheal has tried on vista sp1 64bit to no avail.
- We're keeping this open as a P3 for now, but there is also some support for a WONTFIX.
- This was originally a P3 Linux issue that after importing using (SHIFT+CTRL+I), Space did not play the imported track.
- It was also noted in the bug comments that on Mac and Linux, focus did not always return where it was after opening a dialog, but did on Windows.
- This bug was fixed for a while, except for the Mac/Linux focus issue as above.
- Then it was discovered on Linux that if the new "Importing Uncompressed Audio Files" dialog appeared, the imported WAV/AIFF could not be played using Space. This problem is (mostly) repeatable and is now at bug 370 (Linux-only P3).
- This bug (294) is now demoted to P5 for the Mac/Linux issues where focus does not return to the original place after opening a dialog. We want this to happen for platform consistency.
- We know which Mac dialogs result in focus not returning where it was. We may need discussion about Linux although it is believed most dialogs cause focus to move back to TrackPanel.