Crashing on Yosemite

[Gale Andrews]

Another crash. This time Audacity was not even visible, i.e. on another "desktop" on my Mac and I plugged in my second monitor. Doing that always flashes the screen. It was at that instant that the crash occurred.

When you plug in the second monitor, does the display switch to the desktop Audacity is in?

Is this the Mission Control desktops or a third-party desktops tool?

Gale

[cmac185]

No it did not switch to the desktop that had Audacity and I was using the built-in Mission Control desktop. I have used the second monitor for Audacity in the past, but this time I started it with the other monitor disconnected so it shouldn't have tried to move it to the second display. I've never seen OSx switch desktops when plugging in the second display.

[RDGEEK]

I'm also experiencing crashes after periods of inactivity. Audacity 2.1.0, Yosemite 10.10.4 (and 10.10.3). Crashes have occurred after leaving Audacity open overnight with other apps open as well, and after about an hour of inactivity. The crash occurs upon switching to the Audacity app.

[Gale Andrews]

I'm also experiencing crashes after periods of inactivity. Audacity 2.1.0, Yosemite 10.10.4 (and 10.10.3). Crashes have occurred after leaving Audacity open overnight with other apps open as well, and after about an hour of inactivity. The crash occurs upon switching to the Audacity app.

Feel free to attach the Mac crash report, in case the report shows anything different to the usual "spin lock". Please see here for how to attach files: http://forum.audacityteam.org/viewtopic ... 49&t=64936.

Thanks

Gale

[cmac185]

Just a report on the current state of recording two live recordings in a row as relates to crashing. I have found two keys that seem to stop the crashing I was seeing.

1. Don't leave the input monitor display going after the initial check that the input is getting in. Leaving that going greatly increases the likely hood of a crash or hang when starting the recording, especially with starting the second recording.

2. Restarting Audacity completely between recordings seems to relieve the crashing on saving the second recording. Without the restart it is almost a 100% chance of crashing on saving or in doing anything with the recording like making it fit on screen.

I find the previous post interesting as that may that also play into the crashing issues on the second recording since there is usually at least 45 minutes between recordings.

Cliff

[Gale Andrews]

1. Don't leave the input monitor display going after the initial check that the input is getting in. Leaving that going greatly increases the likely hood of a crash or hang when starting the recording, especially with starting the second recording.

I have not seen that mentioned by anyone else. Do you mean that having clicked in the recording meter to start monitoring, you need to click again to turn off monitoring before pressing Record?

Is your workflow that after initially clicking in the recording meter to monitor, you wait an extended period of time before starting to record?


Gale

[cmac185]

I have not seen that mentioned by anyone else. Do you mean that having clicked in the recording meter to start monitoring, you need to click again to turn off monitoring before pressing Record?

Is your workflow that after initially clicking in the recording meter to monitor, you wait an extended period of time before starting to record?

Correct on both counts. I initially verify that the input level is ok then click it again to turn it off. if I leave it going and then about 30 - 45 minutes later click the record button it likely to crash Audacity or on rare occasions will hang Audacity and a "force quit" needed to kill it. The probably of it crashing on record start for the second recording raises to nearly 100% if I don't restart Audacity between recordings and leave the monitor display running. I have tested this several times on purpose to verify it is not just a random occurrence. Makes me think that the time sitting idle plays a part in the issue.

FYI, this did not happen on Snow Leopard with 2.0.5. As a matter of fact 2.0.5 was rock solid on Snow Leopard. It seemed to never crash or have a bad recording. Unfortunately on Yosemite it has at least once hung when the monitor display was going and recording started and also has had one bad recording (recording buffer 100 ms), though it has had times of doing just fine on Yosemite so I would have to say it is more stable in general, but not perfect. Never ran 2.0.6 on Snow Leopard so can't report on that, but of course on Yosemite it was quite unstable though on Mavericks it did not seem to have problems.

Cliff

[cyrano]

Could you try turning of Time Machine and/or Spotlight as an experiment?

For Spotlight, it might be handy just to exclude the folder that contains your recordings.

Also, do you use any Cloud services from Apple? Back-to-my-Mac, Password sync with iphone, Messages (push)...

The last question just to satisfy my curiousity, as you can't really turn off that system. You can only try tu fulfill it's needs

[cmac185]

Were you responding to me, CMac185, or RDGeek? If myself then -
1. Not running TimeMachine. Spotlight is set to rather minimal settings, nothing from the web.

2. I assume you mean to turn off the folder for saving the projects and the temp folder in Spotlight. Can do, but I'm curious what do you think is going on with Spotlight that could cause a crash and are you thinking of the recording level monitor issue?

3. No iCloud, Syncing etc. even setup and FWIW, there is no Internet connection when I am recording live.

Cliff

[cyrano]

Were you responding to me?

Since you are the topic starter, yes I was replying to you.

1. Not running TimeMachine. Spotlight is set to rather minimal settings, nothing from the web.

OK, fine.

2. I assume you mean to turn off the folder for saving the projects and the temp folder in Spotlight. Can do, but I'm curious what do you think is going on with Spotlight that could cause a crash and are you thinking of the recording level monitor issue?

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.

3. No iCloud, Syncing etc. even setup and FWIW, there is no Internet connection when I am recording live.

I'm afraid having no user/pw in the setup is sometimes worse than having the cloud set up. I suppose you might have an Apple ID? If so, try testing with your user/pw filled in (in System preferences->iCloud) and no Internet connection.

Apple slowly changed the way OSX detects an internet connection, starting with Lion. OSX now thinks it has a connection if it can reach one Apple server, through DNS. That is incredibly stupid and has lead to all kinds of network problems lately.

You can see this happen if you use any kind of service that doesn't rely on DNS, such as an ip SSH connection, FTP or the Terminal. The internet works, but your browser doesn't. And for most people, the browser is the internet.

When this system fails, all background tasks talking to the cloud remain in Limbo. Some of those consume lots of CPU, others introduce a long delay which needs to time out. And most of these can't be switched off by the user.

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

I've ripped out several of those services, but it is an incredible cluster that is nearly impossible to break down into parts. The good thing was I finally got to see the network problem on one of my machines. The bad thing is, there isn't one simple solution. But any change you can provoke might fix the problem.

I'm running 2.1.0 on Mavericks too. And it is rock solid. So the crash needs to be related to something cutting Audacity from disk access. And that is Apple's background stuff, usually...