That only verifies and repairs some system permissions. Doesn’t do a thing for user owned data…
Yes - but against that, if the problem was that FFmpeg or LAME are in /usr/local and Mac is blocking read access to that location unless logged in as admin, we know from past experience that repairing permissions can fix that.
And if permissions are messed up, expected behaviour when logged in as standard user or expected behaviour when a folder has a specific permission set may not obtain any longer. Don’t you agree? I have certainly had problems like that on Mac several times.
Given this other user Audacity 2.1.1 and OS X 10.10.4 also had a problem with coming to 2.1.1 from an audacity.cfg file last saved by 2.0.6, I will try switching from 2.0.6 to 2.1.1 some time.
If you find steps to reproduce your (Cyrano’s) issues when switching between Audacity versions, please post the steps.
Gale
In my case the libraries were (and stll are) unter /Library/Application Support/audacity/
OK. That’s still a system location of course, but it is from our experience much less problematic than /usr/local.
Gale
It’s an almost religious thing in the OSX community that fortunately doesn’t do any harm. You can repair users’ home folders, but only after a restart into the recovery partition. See here for a bit more:
Running it from “normal” OSX, only repairs things like the kernel extension folder. I’ve only seen that to fix anything in 3 cases: one was a misbehaving kernel extension from a copy protection software, the other two were corporate management tools. In the last two cases, the Mac didn’t even start and repairing permissions enabled a startup again - once. And that was in the period from Snow to today.
In “El Capitan”, the button “repair permissions” is gone from Disk Utility.
And if permissions are messed up, expected behaviour when logged in as standard user or expected behaviour when a folder has a specific permission set may not obtain any longer. Don’t you agree? I have certainly had problems like that on Mac several times.
Frankly, it’s a complete mystery why it seems to solve something for some problems some of the time. I suspect flushing cashes has something to do with it. According to logic and the docs, it shouldn’t do anything. But usually, users also try a restart. And I believe changing permissions AND restarting will clear some caches.
Given this other user > Audacity 2.1.1 and OS X 10.10.4 > also had a problem with coming to 2.1.1 from an audacity.cfg file last saved by 2.0.6, I will try switching from 2.0.6 to 2.1.1 some time.
If you find steps to reproduce your (Cyrano’s) issues when switching between Audacity versions, please post the steps.
Remember I had the issue before, because I didn’t understand I needed to delete .cfg and not simply restart Audacity?
I also had 2.0.6 on my Mac before I installed 2.1.0. And when I upgraded to 2.1.1 it didn’t catch all prefs from the 2.1.0. I still have 2.1.0 installed and setting for default window behaviour (Waveform (dB) and range 0…120 dB) didn’t stick until I reaffirmed and saved in both versions of Audacity.
The Audacity settings in my admin account were totally different from those in the user account. I suppose that I had run the old version 2.0.6 maybe once from that account, immediately after the installation, just to make sure whether the program was working.
PS:
I have attached the latest audacity.cfg that was still written by v2.0.6 and that I could find on my backup disk. Until the moment where I installed v2.1.1, only export and import paths may have been changed. Except for theses paths, this must be the cfg file that made v2.1.1 crash.
audacity.cfg.txt (5.33 KB)
Again, many (not all) of the problems I have in mind are to do with LAME and FFmpeg installed to /usr/local/ - a problem that started with Lion.
Thanks for that, Cyrano.
Sometimes the Repair Permissions without restart has enabled users to read /usr/local/ again. Other times they had to go in as root to change permissions on that folder or just not use it for LAME or FFmpeg.
And yes sometimes Repair Permissions can “seemingly” fix issues with ~/Library/Application Support/audacity/ (with or without restart and without changing audacity.cfg).
I was recently able to get two instances of Audacity running on Mac from two audacity.cfg’s pointing to the same temp folder - it should have been impossible, but Repair Permissions stopped the problem.
Another problem Repair Permissions fixed without reboot was Audacity apparently reading the audacity.cfg in ~/Library/Application Support/audacity/ when I had audacity.cfg in a Portable Settings folder alongside Audacity which should have been read instead.
So I don’t know… but I can only speculate that system permissions issues were somehow messing up how unchanged user owned file permissions were being read. Repair Permissions is just one thing to try, and a real repair of user owned file permissions that you mentioned looks like another.
OK that’s useful. Did you ever have Audacity 1.2? One thing I noticed in the audacity.cfg for DJDemon and the other user from 2.0.6 was that the temp folder was that which 1.2 used.
Gale
OK - until you said that I was assuming they would be the same (or nearly so) and thus the different permission level behaviour seemed more pertinent.
Thanks for the audacity.cfg file.
Gale
But that sounds like an Audacity bug to me?
So I don’t know… but I can only speculate that system permissions issues were somehow messing up how unchanged user owned file permissions were being read. Repair Permissions is just one thing to try, and a real repair of user owned file permissions that you mentioned looks like another.
It probably also starts a number of maintenance tasks…
It’s a big, big problem that Apple either does not have docs, or hides them in the developer site. That makes a search very ineffective. And the appstore is even worse when it comes to documentation/support.
And in “EL Capitan”, some permissions can’t be changed by root, because OSX is rootless. You can still enable root (or switch OFF rootless, in Apple speak), but then still, you’re not master of your machine. It seems root is no longer able to delete some stuff in the system area. A good thing to protect the system from noob users, but I’m waiting for malware to pick up the trick.
Oh, well, all systems seem to hide more and more stuff from the user. Are we all noobs? Or do they need to hide something from us?
Given this other user > Audacity 2.1.1 and OS X 10.10.4 > also had a problem with coming to 2.1.1 from an audacity.cfg file last saved by 2.0.6, I will try switching from 2.0.6 to 2.1.1 some time.
It seems susceptible to what settings are in the prefs, I think. I tried to retrace (and reinstall 2.0.6) but it didn’t produce the same behaviour…
I also had 2.0.6 on my Mac before I installed 2.1.0. And when I upgraded to 2.1.1 it didn’t catch all prefs from the 2.1.0. I still have 2.1.0 installed and setting for default window behaviour (Waveform (dB) and range 0…120 dB) didn’t stick until I reaffirmed and saved in both versions of Audacity.
OK that’s useful. Did you ever have Audacity 1.2? One thing I noticed in the audacity.cfg for DJDemon and the other user from 2.0.6 was that the temp folder was that which 1.2 used.[/quote]
FWIW, I never had these older Audacity versions on this Mac. I can still remember using 2.0.5, but nothing older and certainly not that far back.
i’m pretty certain I have only one .cfg on this Mac, depite having two Audacity versions. Maybe I need to make a portable install. Do you think that may yield some insight?
Right. Both v2.0.x and v2.1.1 are using the same path and file names to store the settings. IIRC, these were already used by v1.x.
Don’t know if this is related to this specific issue or not, but two of us on different machines with Yosemite 10.10.4 can’t get 2.1.1. to run at all. Found the following in the Console: "
7/19/15 8:55:28.748 PM Audacity[1384]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.4 instead of 10.10.4. Use NSProcessInfo’s operatingSystemVersion property to get correct system version number.
Call location:
7/19/15 8:55:28.749 PM Audacity[1384]: 0 CarbonCore 0x90847291 ___Gestalt_SystemVersion_block_invoke + 135
7/19/15 8:55:28.749 PM Audacity[1384]: 1 libdispatch.dylib 0x9955f0b5 dispatch_once_f + 251
7/19/15 8:55:28.750 PM Audacity[1384]: 2 libdispatch.dylib 0x995600d8 dispatch_once + 31
7/19/15 8:55:28.750 PM Audacity[1384]: 3 CarbonCore 0x907c069d _Gestalt_SystemVersion + 1050
7/19/15 8:55:28.750 PM Audacity[1384]: 4 CarbonCore 0x907bf7c0 Gestalt + 150
7/19/15 8:55:28.750 PM Audacity[1384]: 5 Audacity 0x00462ae2 _Z14UMAInitToolboxtb + 50
7/19/15 8:55:28.750 PM Audacity[1384]: 6 Audacity 0x0046843c _ZN5wxApp10InitializeERiPPw + 44
Could this be related to the latest 10.10.4 update?
Ideas?
Cliff
Don’t have an answer why the console messages I posted in the last post were there, but I finally got 2.1.1 running by renaming the Audacity directory at Library/Application Support/Audacity. Then I stated 2.1.1 and shut it back down and then restarted it again just fine so set some preferences then closed it again. Then I renamed the new directory and restored the name on the original directory. Now 2.1.0 and 2.1.1 both run fine with the old directory. Guess the renaming forced a rewrite of some things that cleared up what the issues were. Pretty strange. BTW, this was with the Zip download.
Cliff
Just usual prefs settings, nothing to do with lame or ffmpeg. These kept working all the time.
With a portable install these problems are gone…
If so, it is a bug that Repair Permissions appeared to hide, unless it was totally fortuitous.
If Audacity cannot read the Portable Settings folder it will look in the default location for audacity.cfg.
Gale
1.3.x.
1.2.x used ~/Library/Preferences/audacity Preferences.
Gale
It’s related to any 10.10 version, not an update to 10.10.4. 2.1.1 not working on 10.10.5 - #3 by Gale_Andrews
Gale
One identified issue that sometime causes 2.1.1 not to start is having a line like
TempDir=/tmp/audacity1.2-<your user name>
in audacity.cfg. 2.1.1 seems unable to write to that location sometimes.
There may be other problems.
Gale
I’ve deleted both portable install folders (after zipping them).
No new file is created anywhere. I’ve checked plugins folder, Application support/audacity, /tmp and so on. I’ve even checked the Melda plugin folder because that contained an “Audacity” folder. I didn’t create that, and I’m not sure why it would be in the Melda plugins folder. Anyhow, deleted that too.
I’ve also cleared ALL caches, rebooted into su mode and ran a disk check. Nothing…
Updated locate db again. No audacity.cfg to be found.
Yet, Audacity 2.1.1 retains its preferences perfectly. And after a short test, 2.1.0 seems to remember prefs too.
Prefs do not copy over completely from 2.1.0 to 2.1.1!
Setting meter waveform dB range passes over.
Tracks/Default view mode (Waveform prefs for the wave window) doesn’t.
You said before that “did not stick” (did not get the same setting in 2.1.1 as 2.1.0).
That and the meter/waveform range had extra choices added for 2.1.1. But they do get transferred over correctly from 2.1.0 on Windows as far as I can see.
I’ll have to try Mac later.
If you change to another view mode in 2.1.1 then go back to 2.1.0, 2.1.0 will stay with its old choice not take 2.1.1’s choice. 2.1.1 uses a different preferences key (so that you do - or should - get the 2.1.0 view mode in 2.1.1).
Gale
OK Mystery solved.
I’m stupid. Definitely. 
The audacity.cfg is where it should be. In:
/users/user/Application support/audacity/
I’ve since discovered that neither locate nor find (the cli versions), nor SpotLight could find it because of permissions.
Something screws things on this Mac. I have an encrypted data partition that shouldn’t be indexed by SpotLight. It’s excluded in System prefs/Spotlight. Yet it is indexed. And it seems SpotLight and locate/find use the same index?
Searching for “Audacity” with locate or find does find a map called “Audacity” in:
/users/user/Application support/MeldaProduction/
Both the folders “Audacity” and “MeldaProduction” have different permissions, but both are owned by the user. And the user has read/write access.
Audicity has drwxr-xr-x
MeldaProduction has 0777.
Audacity’s permissions seem to be like most folders in there. Melda’s are not. And something is changing files in there, even if no plugin using programs are open.
Mmm… Same for LightTable…
Anyhow, mystery solved. Need another beer 