Crashing on Yosemite

[Gale Andrews]

OSX sends all files you save (and even those you don't save) in the background to the cloud. That process kicks in when you hit "save". I've had some trouble with it in most DAW's. Excluding a folder from Spotlight, lessens the burdon and might just avoid the crash. Time Machine, Spotlight and iCloud use mutual metadata to index your files.

However iCloud (and Time Machine) are off by default, aren't they? I never enabled Time Machine on my Mac Mini and I only send a few TextEdit files to iCloud just to see what happens. OS X is only an Audacity testing environment for me so I don't need to back up data for it.

However I think Koz here uses Time Machine and never has crash problems when saving or recording.

If you have a problem when saving, it usually is related to one of these background tasks.

Certainly a few people have said that when using the Audacity dialogue to save projects or to import or export, it can be very slow navigating through folders, and much slower than when navigating in other apps.

I thought it was probably Spotlight indexing files that was the delay, but I don't see the delay. The only folders I exclude from Spotlight are network folders, so I let it index all local folders.


Gale

[kozikowski]

I think Koz here uses Time Machine

I do. Three places. I have a large, spinning-metal drive connected with FireWire. It does other things, but in general, I turn it on and do Time Machine backups once a week or sooner if there's something going on. All other times it stays off. So Time Machine has nothing to do and doesn't try to do those quick, in-progress backups which would be more normal.

I'm also on OS-X 10.9.5, not Yosemite. Yosemite had a scary number of problems when it came out.

Koz

[cyrano]

OSX sends all files you save (and even those you don't save) in the background to the cloud.

However iCloud (and Time Machine) are off by default, aren't they?

Yes. But it doesn't stop the background tasks. Since Spotlight also depends on the framework that reads most files, it's running in the background. Disabling parts of it is like playing Mikado on a bus...

And it reads everything: pictures (for facial recognition), video (for geo metadata), text (of course, for Spotlight), but even some CAD files.

I never enabled Time Machine on my Mac Mini and I only send a few TextEdit files to iCloud just to see what happens. OS X is only an Audacity testing environment for me so I don't need to back up data for it.

There are also other processes involved. Messages, calendar data, push fi.

I use Time machine, much like Koz does. I avoid networked disks, as a source and as a destination. TM has been rock solid and I have seen two internal HD's die since I started using it. And I'm on 10.9.5 too. I'm avoiding Yosemite, even when Apple reinstated discoveryd. It's not so much I don't want to upgrade. It's that I don't NEED to upgrade. And I'm not done fixing 10.9 yet (I have a lot of server stuff to align with Debian), so I'll skip Yosemite, thank you!

However I think Koz here uses Time Machine and never has crash problems when saving or recording.

I don't have crashes either. I don't think Audacity has ever crashed on my machine.

But I do have a noticeable delay on save, even a short beachball. And the beachball takes longer if the app has been in the background longer en is allowed to nap.

As this happens on my own system now, I can shoot down suspects. That's how I started slowly to understand the errors that have been pestering some OSX users.

I do cmd-a, cmd-c, cmd-tab, cmd-n, cmd-v, cmd-s about a hundred times a day (config files and such) and it is most noticeable with TexWrangler. Often, when doing audio, TW is napping and I want to copy paste some data to a text file. And then I have to wait for TW to wake up. If a sniffer like Wireshark is running, you'll see an encrypted connection to leon.apple.com (the first name may change). And when that doesn't succeed, the gui is informed that the internet is down. Terminal, blissfully unaware, still continues to function as normal. Browsers don't, as they see no network. Torrents don't care either.

And that gui process "is the internet still up?" is very sensitive to small transmission errors and other stuff along the way. MTU, packet fragmentation, ipV6 bridging and stuff like that breaks handshakes along some routes. That's why you'll find the thread "this forum is slow" on any forum. Oh, and it only affects https of course. But once the bug is triggered, anything that is working in the gui will report a lost connection. Fortunately, launchd will restart something in the chain soon and it usually auto-recovers after... seconds, minutes, hours...

If you have a problem when saving, it usually is related to one of these background tasks.

Certainly a few people have said that when using the Audacity dialogue to save projects or to import or export, it can be very slow navigating through folders, and much slower than when navigating in other apps.

One of the reasons could be that OSX has no "reader" for .aup files?

Also, does Audacity maybe create tmp files outside of /tmp/ ? My Linux stuff sometimes does that when I don't check paths and blindly run make. I think OSX doesn't like that. Don't understand why, though. Maybe there's no OSX "reader" on /tmp/ ?

I thought it was probably Spotlight indexing files that was the delay, but I don't see the delay. The only folders I exclude from Spotlight are network folders, so I let it index all local folders.

Basically, it's because you are far too tidy. You don't mess around enough to provoke this error. People who have all this stuff (Messages, social accounts, TM...) set up don't necessarily see these errors either. But those that mess around (change logins, install a lot of software...) do. That's NOT to say it's their own fault. The system is just too complex. You could almost compare it to the systemd schisma on Linux.

I think Koz here uses Time Machine

I do. Three places. I have a large, spinning-metal drive connected with FireWire...

I used to run with TM active all the time. Till I ran out of disk space one day...

TM backgrounder prepares backups and copies files that "might be open later" to a cache. And sometimes, I don't backup for a week. Or even 3 weeks. If I record and edit in that period, this background file cache eats 200 GB, something I usually can't afford as I only have 750 GB in my Macbook. So I turn off TM.

I'm lucky that I have been able to observe The Error. Before I was under a sneaky suspicion that all these fools had these errors because they upgraded and didn't do a clean install, because they never RTFM, because they invited software like "Clean My mac" and about a hundred other things. But it has taken me two weeks to figure that out, once I could provoke The Error.

[Gale Andrews]

I do have a noticeable delay on save, even a short beachball. And the beachball takes longer if the app has been in the background longer en is allowed to nap.

As this happens on my own system now, I can shoot down suspects. That's how I started slowly to understand the errors that have been pestering some OSX users.

I find Yosemite suffers much less from that.

If you have a problem when saving, it usually is related to one of these background tasks.

Certainly a few people have said that when using the Audacity dialogue to save projects or to import or export, it can be very slow navigating through folders, and much slower than when navigating in other apps.

One of the reasons could be that OSX has no "reader" for .aup files?

AUP is specified as an extension in Audacity's info.plist file.

does Audacity maybe create tmp files outside of /tmp/ ?

Yes but no more than most apps, as far as I know. There are several cases where Audacity creates a temp file while in the process of writing a file, such as when writing the AUTOSAVE temporary project file, or while writing an audio file that overwrites another.


Gale

[cmac185]

I find this discussion very interesting and informative, but as far as I can tell it doesn't apply to my specific situation regarding crashes on saving the file after a recording. I can prevent the crashing just by restarting Audacity between live recording sessions. If I don't restart it then the crash is nearly 100% sure to happen. That seems to fit in with the recent post by RDGEEK where he had crashes with Audacity open for an extended time. I may try to do two recordings back to back without a pause and see if the lack of a long idle period has an effect.

Note also that the crashes are not specifically caused by "saving". That is just what I normally do immediately after the recording. Clicking on the "Fit Project" button will also cause the crash and likely any other action that involves a display rewrite. In reality the crash happens when any change of the display occurs which leads me to repeat my suspicion of the issue being related to the display function which we all know is using an old API that causes the on screen flashing. How the idle time plays into that I can't say, but it is consistent with my observation that any display change after the 2nd recording can trigger the crash.

To document this possible idle time issue mentioned by RDGEEK my sequence for a live recording is as follows:

Wake up laptop, start Audacity and let it sit idle for about 45 minutes.
Start the first recording which is normally about 35 minutes long.
Stop the recording, save the file and quit Audacity.
Restart Audacity almost immediately and let it sit idle for another 45 - 50 minutes
Start the second recording which normally runs 60 - 70 minutes.
Stop the recording and save the file.
Note: This totals over 3 hours of time so if Audacity is not restarted it's been running for quite a while before it has a problem.

If I do the above all is well, BUT if I don't quit Audacity between recordings, but just open up another Audacity window/session then almost for sure it will crash at the saving or really doing almost anything with Audacity after stopping the second recording.

Again, the BIG PUZZLE is that I seldom see a crash at home, though they do happen and sometimes when not even recording, but never as consistently/repeatable as after a live recording session.

BTW, has anyone tried Audacity on El Capitan yet? Supposedly it is a much quicker OS and has a whole new display engine.

Cliff

[kozikowski]

So to be crystal clear, if I try that process and I don't restart Audacity in the middle, I will experience an Audacity crash? When? When I try to save the file? And also, we're talking about Saving a Project, right, not Exporting a WAV or other file? What kind of files are you exporting?

What are you recording for 35 minutes? Do I get the same effect if I just record my idling stereo Line-In for 35 minutes? A USB sound connection or USB microphone?

Koz

[cmac185]

Koz,

I wish it was that simple because if it was the problem would have been tracked down long ago I'm sure.

Let me try and clarify the total situation and answer your questions in the process.

I'm using 2.1.0 on Yosemite 10.10.4. Using 2.0.5 or 2.0.6 on Snow Leopard or Mavericks will NOT result in the same crashing. On those versions of OSx Audacity seems very solid. Have not tried 2.1.0 on the older versions of OSx. App nap is off for Audacity as the display sleep will ruin a recording otherwise.

Recording at home from other sources rarely has a problem, though occasional crashes do occur (see back earlier in this thread), but the above sequence has not specifically been tried. Bringing the recording hardware home I can reproduce the recording corruption issues that have been discussed in a different thread, but I have not tried to duplicate the crashing scenario at home.

Hardware setup is a wireless mic to a receiver with a single cable from the receiver to Line-In on the MBP. Recording is Mono not Stereo, at 44,100 hz. No Internet is available during recording and all major applications have been closed. Spotlight does not index the temp or saving directories. iCloud has never been setup or used.

For troubleshooting I have been live recording in parallel(line input split) with another MBP using Snow Leopard or Mavericks to insure a good recording and to verify that the recording corruption issues were not in the input stream.

I do not know if recording just the noise on the input channel would be the same as the actual voice input as far as the crashing issue. I know it did make a difference with recording quality as recording from a tape or CD had no issues, but the voice recording did, but that was discussed in another thread.

Remember that the crash is not only on Saving the project at the end of the recording, but can be caused by other requests from Audacity such as the "fit project" button to show the whole recording on screen. Again, this is only right at the end of the recording, not later on during editing. Editing seems to be fine and I haven't seen crashing for some time, though there are not long idle times either normally.

So, to answer your basic question is this repeatable on other machines, I don't know. I know it is on mine in the live recording context when Saving the project or other action as explained above. I will try the above sequence recording just idle Line-In here at home and see if it will happen, I suspect not, but maybe it will if the issue is more the idle time than what it is/was being recorded. Recording content is speech, not music of any sort.

I don't have any USB sound connections so can't test that.

I know this is frustrating for you as well as for myself. I have some programming experience and know that we expect software to do the same thing each time, but apparently there are so many parts to this puzzle that we just haven't found them all yet which is why I try to mention everything I see so maybe the picture can be filled in one of these days and a solution found.

Hope the above has clarified things and not muddied the waters.

Cliff

[cyrano]

Is the machine you're recording with connected to wifi or ethernet with a working internet connection in both locations?

I think we need to figure out what the difference is between the two locations. That's the only lead I can imagine.

Meanwhile, I've opened Audacity 2.1.1 on Mavericks and Yosemite and I will keep it running and recording noise. I'll stop the recording in an hour or so, let the machines idle for half an hour and restart the recording.

I'm monitoring with fseventer. See:

http://fernlightning.com/doku.php?id=so ... er%3Astart

[cmac185]

I guess it got lost in all the words I wrote, but there is NO WORKING Internet during the live recording. There is Internet at home.

I think we need to figure out what the difference is between the two locations. That's the only lead I can imagine.

That is exactly what I've been struggling with for 6 months now. Initially my problem was corrupted recordings, which were not able to be duplicated at home unless I brought home the mic setup and recorded voice at home then I could duplicate it. Reducing the Recording Buffer to 15 and App Nap off seems to have fixed that issue. I have not tried to duplicate the crashing issue at home, but will be my next project for Audacity. I'm looking forward to what you find.

I understand that all the developers have desktop Macs not laptops and so far have not been able to duplicate what I've seen. It's hard to imagine that hardware differences could be the issue, but at this point I suppose nothing can be ruled out.

Fseventer looks like an interesting app.

Cliff

[cyrano]

Audacity 2.1.0 has been recording on and off for periods over an hour all evening yesterday. No errors, no crashes either on Mavericks or Yosemite.

I ran all sorts of things in de the background. Both machines had a wireless internet connection all the time. And these machines are a lot like your Macbook, only 13" in stead of 15".

So, it still comes back to "no internet" as only discernible difference...

I'd try a recording at home with Airport on, but no connected internet. No need to connect a source. You could use the internal mic too.

If that doesn't produce the crash at home, I'm sure gremlins are the only logical explanation left