I don’t know if anyone’s had this issue - haven’t had luck finding any - but I’ve had several instances where I’ve cheerfully recorded stuff, and then without warning the application closed and an error report window popped up. Anything in the track I’ve recorded is gone, the aup3 file is down to a handful of kilobytes. The file I’m recording is on an SSD, haven’t had issues with it before and there’s plenty of space to work with. Is this a known problem?
Yes - I mean no - I have not seen any reports of this error. Nor have I noticed two separate error codes in one error report (not that they are particularly meaningful).
(1) SQLITE_ERROR
The SQLITE_ERROR result code is a generic error code that is used when no other more specific error code is available.
(5) SQLITE_BUSY
The SQLITE_BUSY result code indicates that the database file could not be written (or in some cases read) because of concurrent activity by some other database connection, usually a database connection in a separate process.
For example, if process A is in the middle of a large write transaction and at the same time process B attempts to start a new write transaction, process B will get back an SQLITE_BUSY result because SQLite only supports one writer at a time. Process B will need to wait for process A to finish its transaction before starting a new transaction. The sqlite3_busy_timeout() and sqlite3_busy_handler() interfaces and the busy_timeout pragma are available to process B to help it deal with SQLITE_BUSY errors.
An SQLITE_BUSY error can occur at any point in a transaction: when the transaction is first started, during any write or update operations, or when the transaction commits. To avoid encountering SQLITE_BUSY errors in the middle of a transaction, the application can use BEGIN IMMEDIATE instead of just BEGIN to start a transaction. The BEGIN IMMEDIATE command might itself return SQLITE_BUSY, but if it succeeds, then SQLite guarantees that no subsequent operations on the same database through the next COMMIT will return SQLITE_BUSY.
See also: SQLITE_BUSY_RECOVERY and SQLITE_BUSY_SNAPSHOT.
The SQLITE_BUSY result code differs from SQLITE_LOCKED in that SQLITE_BUSY indicates a conflict with a separate database connection, probably in a separate process, whereas SQLITE_LOCKED indicates a conflict within the same database connection (or sometimes a database connection with a shared cache).
=
If you think you possibly have anything other than a blank database remaining you can send it along. I’ll take a look at it.
What stuff, from where, and how long is the recording?
Before or after you pressed STOP at the end of the recording?
If after, what were you doing at the crash point? Shrink the timeline down in preparation for editing?
Do you set up Audacity to constantly update the timeline while you record, or just let it roll off the right-hand edge and just pay attention to the accumulated time in the window on the bottom.
What else is running on the machine at the same time?
Have you ever done a clean shutdown and did it take forever? Shift+Shutdown > Yes > Wait > Start.
That said… there might be a clue there when it comes to busy database? What I do while recording is use labels to mark errors and mistakes. I have a button bound on my mouse to send CTRL+M and Enter with next to no delay. Is it possible that the database crashes in situations where it tries to write both the bookmark and the audio data? It would be a hell of a coincidence, but would it explain why it would happen both rarely and randomly?
What stuff, from where, and how long is the recording?
Single track, about twenty minutes in the last case.
Before or after you pressed STOP at the end of the recording?
Mid-recording - I’m doing an audiobook, for more context, so it’s one long stream. Not sure if it coincided with setting a label, though.
Do you set up Audacity to constantly update the timeline while you record, or just let it roll off the right-hand edge and just pay attention to the accumulated time in the window on the bottom.
Not quite sure what you mean - “Auto-scroll if head unpinned” is checked. I suppose the issue first happened sometime after I turned off the pinned play, but that might be a coincidence.
What else is running on the machine at the same time?
Nothing fancy. Steam, GOG, file explorer, Firefox, etc.
Have you ever done a clean shutdown and did it take forever? Shift+Shutdown > Yes > Wait > Start.
Nope.
OK, I looked at your project and I did not find any audio which confirms what you already suspected due to the small file size - there is no data here to be recovered.
So why a busy database? I don’t really think that binding Ctrl+M and Enter would be enough. Let’s see now, if you exited Audacity then forced it to quit while it was still compacting the database, I suppose sqlite3 could somehow be busy the next time you opened the project. But this is only wild speculation and it makes my head hurt.
I forwarded your information to the developers. Lets see if they have anything to offer.
I record long and difficult “Sections” for LibriVox. My longest section to date was 41 minutes of this, with off-page footnotes, German, Italian, and “please leave space for music”.
I elected to record a page at a time. I am now on JSMill, 415,784 words with 290 footnotes. I am recording one silcrow section (anything from 1 to 10 pages) of convoluted English at a time.
I produce numbered files 01.FLAC, 02.FLAC, 03.FLAC, … and make use of an Audacity macro to glue them together when the recording is done, to produce a large FLAC file as one track.
This does not solve your problem of why Audacity is crashing, but it does reduce the impact, if you like, the analogy of seat-belts.
Cheers
Chris
You have an unstable system and every time you have a crash event, it gets worse. A crash of either Audacity or Windows leaves trash and fragments of work lying around. Those should not be left alone because that makes another crash more likely.
That’s why I brought up Windows Clean Shutdown because that makes Windows “really” start over and do housekeeping and cleaning on the way. Do it twice. It can take a while. Pay attention to the machine while it’s changing and any error messages.
Then, since something happened at the beginning of all this, do a drive test and a memory test. Windows has some of this, but you may need third party applications. Audio (and video) applications use large amounts of continuous memory and hardware problems up there can only appear when you have long productions. This can lead to the posting, “What’s wrong with your application? Other apps work fine.” Other apps may not have the data footprint your production does.
You can have problems with SSDs, too. You shouldn’t try to “optimise” one, but you shouldn’t fill one up either. They like to shuffle work around for even wear and they lose the ability to do that when they start to choke. They can host trash from crashes, too.
As Jademan, above, this much damage is unusual. Not one but two Audacity errors and completely destroyed production sound. That could point to machine hardware problems. You should probably stop production jobs until you get it sorted.
Also, as ChrisGreaves, keep production segments short and backed up. Audiobooks have restrictions on the length of any one chapter or segment. It’s not one long 12-hour sound file. That was another error from elsewhere on the forum.
You can have problems with SSDs, too. You shouldn’t try to “optimise” one, but you shouldn’t fill one up either. They like to shuffle work around for even wear and they lose the ability to do that when they start to choke. They can host trash from crashes, too.
As an update, doesn’t look like it’s the issue with the hard drive - had the same thing happen when I was recording with the project file on spinning rust too, a little before the four-minute mark.
Also, as ChrisGreaves, keep production segments short and backed up. Audiobooks have restrictions on the length of any one chapter or segment. It’s not one long 12-hour sound file. That was another error from elsewhere on the forum.
This isn’t very conclusive, but I ran a recording while I was at work - around nine hours or so, and it got back to it without any crashes. However, later I did the same with bookmarking - basically I set the mouse macro to make a label about every half a second, and it looks like the application crashed around twenty minutes in. However, there might be something more useful here as it looks like the file itself hasn’t imploded this time. I’ve uploaded it here - the “copy” version is before I closed Audacity, as well as the screenshot of what I came back to. Maybe it’ll be of some use? https://1drv.ms/u/s!AkCbmKmmPRt8gdUm1cNiyRC1riisOg?e=NdZgL3
It’s worth a warning about how big the file is. I had to abort it or I would be going to bed with it still downloading. My internet connection is a wet, salty string.
That’s exactly the kind of thing that can help with troubleshooting odd problems. Take the problem apart and see anything turns up. Someone more familiar with the Audacity innards can look at the differences between your two recording techniques.
What process exactly is inserting bookmarks? On a wildest guess, there may be a limit to the number of bookmarks you can have. Also you might have bookmark management stepping on itself from having them too close together.
Oops, yeah, sorry. The file is a bit of a bigg’un.
Bookmarks, label, yeah {is there actually something called bookmarks in Audacity?}. I’ve been using the two words interchangeably in this context. As for the limit of the number of labels one can have, or if there is, I doubt it has bearing on the issue, since the last time this happened was pretty early on in the recording.
As for the process, I have a mouse button bound to press control-m {that’s what I have bound for “add label at track position”} and enter in a quick succession, then I use that to split the track afterwards.
I’ve been using the two words interchangeably in this context.
It’s good to keep them straight. People arriving from video editors are accustomed to “Markers.” They’re nothing like anything in Audacity and New Users are horrified that their best lightning-quick editing technique is missing.
Then there’s the forum format. I know what you’re talking about and you know what you’re talking about but the New User reading this posting right behind us might try to find “Bookmarks” in the instructions.
Tell me again why you’re doing this? To label reading mistakes for future corrections? As you said, you made a really long plain recording with no trouble at all.
What many people do at a mis-read or fluff is pause very briefly, maybe clap or make another loud noise, roll the printed script back a complete sentence and read it again this time correctly. You still have the volume, tempo, expression, and interpretation of the original read and it’s really easy to join the correct parts together later. Do Not depend on you going back next week and drop a correction in. That never works. That can give you this forum post: “HELP. I need to match my voice…”
I have a “studio read” which perfectly illustrates this process, but of course, I can’t find it.
This is a raw read (chopped up for length) from a Zoom H1n recorder. It has a fluff where I lost my place in the script. This is followed by the same read with an edit/patch/correction.
I have a mouse button bound to press control-m {that’s what I have bound for “add label at track position”} and enter in a quick succession
Who presses “Enter” you or the binding? I can see that causing problems. The idea of the label is that a slow, sloppy human be able to type text in the little window, or sloooowly reach over and press the Enter key if no text is needed. If the machine is pressing “Enter,” you could violate some of the assumptions in the code.
You’re using Audacity in an unusual way and by your own testing, everything seems to work OK when used normally.
Logitech Gaming Software, it allows me to bind key or mouse sequences in specific applications.
I see labels but I don’t see audio in any of the projects. Why is that ?
You tell me!
That’s what I’ve been pondering too - I’ll try setting it so there’s about a second or half-second delay between setting a label and hitting enter and see what happens, or fails to happen.
I had some other priorities step in the way, but I wanted to look back into this mystery. I was able to recover the audio from your ’ “copy” version [from] before I closed Audacity’, using the audacity-project-tools options “-recover_db -extract_as_stereo_track” which I had not used before (see here: https://forum.audacityteam.org/t/corrupt-or-otherwise-broken-audacity-project-recovery/64162/1). Let me know if you need this recovered audio.
The same options did NOT recover the audio from your other .aup3 file. The data seems to be there, but the tools did not recover them properly. I didn’t see the the audio data originally as it is at such a low low level and frankly my inspection tool injected more noise than there was from the audio.
So any way, if this error occurs in the future, you now know that you can copy the .aup3 file externally before doing anything else in Audacity, and use the stereo extract audacity recovery tool.
There are two issues here: (1) why does Audacity crash and (2) what happened to my data.
My interest is mainly in seeing that you do not lose your data and to recovery it if at all possible. You now have a work around and you seem to be the only one having this issue. I have reported this issue to developers.
The other issue as to why there is a crash in the first place. You seem to have encountered an apparently rare race condition within Audacity that is triggering this issue. For this, you also seem to have a work around - simply not using this third party Macro.
Please keep us updated on your progress with these two issues.
Will do! And don’t worry about the audio - I simply let the thing record and label while I was at work, so there’s literally nothing there. I’ll also keep poking at it and trying different things to see if I can get something else out of this weird situation. Thanks again for the help!
So I take that back. There is another thread where someone has exactly the same key binding and is getting exactly the same crashes:
I know it has been a while, but if you are still getting these crashes can you try changing your mouse binding to Cltr+M without the Enter or just use Ctrl+M to see if that helps?
