Audacity Bug Summary
••• Introduction •••
••• Keywords •••
    Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla



Bug 1567 - Mac Sierra: LAME, FFmpeg and some plugins disappear. (intermittent)
Mac Sierra: LAME, FFmpeg and some plugins disappear. (intermittent)
Status: RESOLVED FIXED
Product: Audacity
Classification: Unclassified
Component: Other
2.1.3
Per OS macOS
: P2 Repeatable
Assigned To: Default Assignee for New Bugs
: Multiproject
Depends on:
Blocks: 1702
  Show dependency treegraph
 
Reported: 2016-12-24 09:02 UTC by James Crook
Modified: 2018-08-20 11:51 UTC (History)
9 users (show)

See Also:
Steps To Reproduce:
1. Create four projects. 2. File > Close, 3. File > Close (don't save). 4. File > New, Record, Stop, 5. File > New, Record, Stop, 6. File > Close and don't save. 7. Exit Audacity. Problem: The original bug 1567 where LAME and FFmpeg are missing may occur when Audacity is next run. Observation: The AUTOSAVE file and AU files for the closed project are removed, but the project* folder, e* and d* folders remain. If any of these left-behind folders are populated by .DS_Store files before or during removal of the project window, that's when the problem happens when Audacity is next run.
Release Note:
GROUP:Bugs requiring more investigation * '''(macOS) In rare cases, when multiple projects are opened and then closed, then when restarting Audacity, links to the LAME and FFmpeg libraries may disappear, as well as some plug-ins.''' If this happens to you please write to our [http://audacityteam.org/contact/#feedback feedback address] with details of what you were doing when the problem occurred.
First Git SHA:
Group: ---
Workaround:
Closed: 2018-08-20 00:00:00
petersampsonaudacity: Test‑OK‑Win+
petersampsonaudacity: Test‑OK‑Mac+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Crook 2016-12-24 09:02:16 UTC
Observed on Gale's Mac Sierra machine.  1 in 16 times with Audacity installed in /Applications Audacity fails to access FFmpeg and all plugins that are outside the App bundle.  Previously when bundled Nyquist plugins were in the dmg but outside the .app they were also dropped.  This problem happens even with a signed .app.

Once observed, this problem persists even with quitting and restarting Audacity until the mac is rebooted.

The problem can be worked around by either:
1 - Using xattr to tell gatekeeper to accept Audacity.
2 - Using portable settings (within the .app) rather than audacity.cfg.

Provisionally set as P1.  Possibly could reduce to P2 if team accepts the idea of announcing 'partial support for Sierra' in conjunction with the portable settings workaround.
Comment 1 Paul L 2016-12-25 18:41:31 UTC
Clarify please.  Are you repeately installing Audacity?  Or, you installed only once, and this is a problem seen 1 in 16 times that Audacity starts?

An idea I just had is that perhaps the Unix symlink() function could be called to create a symbolic link, whenever plug-ins are found successfully once.  Perhaps this cheap side-effect on the file system would prevent recurrence, without actually copying things into the application folder?
Comment 2 James Crook 2016-12-25 18:46:12 UTC
Re comment 1
My understanding is that Gale installs Audacity once, launches and quits (completely) repeatedly, and hits this problem occasionally.
Comment 3 Gale Andrews 2016-12-25 19:49:27 UTC
(In reply to Paul L from comment #1)
> Or, you installed only once, and this is a problem seen 1 in 16 times that Audacity
> starts?
Even installing once only into /Applications, with all other Audacity installs of the past trashed, about one launch in 16, Audacity won't find plugins or libs that are outside the bundle. 

I should add to this report that if Audacity is installed outside /Applications,  even as sole install, all past installs trashed, then the failure rate on Audacity launch is much higher - about 1 in 3.  

My 10.12.2 is an install over the top of El Capitan. Leland did a fresh install of 10.12.2 (he had to do it twice for some reason). He reports no incidents of this bug on his machine. 

(In reply to Paul L from comment #1)
> perhaps the Unix symlink() function could be called to create a symbolic link, 
> whenever plug-ins are found successfully once.  Perhaps this cheap side-effect 
> on the file system would prevent recurrence, without actually copying things 
> into the application folder?
I am happy to try that, rather than copy things in to the application folder. 

But, are not all plugin search paths for all formats already known? I think they are, if so can we do something with that information to tell Gatekeeper those are good paths? Because Audacity can fail first launch (and did once when it was in /Applications), though first time fail is more likely outside /Applications.
Comment 4 Paul L 2016-12-26 10:01:56 UTC
(In reply to Gale Andrews from comment #3)

Is it certain that plug-ins in the application folder do NOT suffer the problem?

If you can demonstrate the problem reliably enough, then I suggest the experiment:

Open Teriminal, and type:

cd /Applications/Audacity/Audacity.app/Contents/MacOS/Audacity plug-ins/
ln -s <path to LAME or FFmpeg> .

If you then open the application path in Finder you should see icons with arrows in the corner indicating symbolic links, not complete copies.

Then, see if the problem is still present.  (Maybe you also have to tell Audacity to use its own plug-ins folder, in Libraries preferences?)

If this fixes the problem, then maybe I could figure out how to make Audacity do the equivalent of ln -s for you.
Comment 5 Cliff Scott 2016-12-26 12:28:50 UTC
Gale: How do you determine that FFmpeg is not available? Just by looking at the settings libraries page?

Trying it on Sierra 10.12.2 and so far don't see it. Trying installed somewhere other than applications and using a build I did today so the Nyquist plugins are in the app.
Comment 6 Gale Andrews 2016-12-26 20:19:35 UTC
(In reply to Cliff Scott from comment #5)
> How do you determine that FFmpeg is not available? Just by looking at the 
> settings libraries page?
That is one way, or export a WMA, or look at the log entries for FFmpeg which say "image not found".
Comment 7 Gale Andrews 2016-12-26 21:44:26 UTC
(In reply to Paul L from comment #4)
On my machine, any plugins in /Applications/Audacity/Audacity.app/Contents/plug-ins are immune from failure.

I waited for the bug to trigger in Audacity (jc4) in /Applications then did: 

cd /Applications/Audacity/Audacity.app/Contents/plug-ins  

ln -s /Library/Application\ Support/audacity/libs 

(the latter is where the FFmpeg libs are). I now see a folder /Applications/Audacity/Audacity.app/Contents/plug-ins/libs/ with an arrow on it. The folder contains files which are not stated as aliases, unless the original files are. 

When I restart Audacity, FFmpeg is available again and works (I did not change the path in Libraries Preferences). Plugins are still unavailable except for the ones in /Applications/Audacity/Audacity.app/Contents/plug-ins. If I quit Audacity and remove the aliased folder, then restart Audacity, FFmpeg is unavailable again. 

I then trashed Audacity in /Applications and installed jc4 to my Downloads folder. Likewise when I got the bug to appear, I symlinked as above and then I could get FFmpeg to be recognised.  

Of course, unlike plugins, LAME and FFmpeg could be installed anywhere by the user (if they use the ZIP) and a manual path set. In case of difficulty we suggest (for recent Audacity) installing the LAME or FFmpeg libs in the Audacity installation folder alongside Audacity.app. That still works most of the time, but is prone to the intermittent failure issue.
Comment 8 Paul L 2016-12-27 01:42:22 UTC
(In reply to Gale Andrews from comment #7)

Could you try something different:

Install Audacity, and make the links first, before the bug strikes.

Then try repeated restarts, and see whether the bug still strikes again at all, after a simialr number of trials.
Comment 9 Paul L 2016-12-27 10:28:22 UTC
(In reply to Gale Andrews from comment #7)

What exactly is the visible symptom of failrue to load the libraries?

Open the Audacity Log dialog and clear it.  Open Preferences and hit Esc.  Some messages appear in log about locating LAME.  What do you see when the bug strikes compared with when not?

Choose Libraries in Preferences and press Locate for FFmpeg.  I see a Success dialog.  Dismiss the dialog and escape from Preferences.  See the log again.  More messages about locating the FFmpeg libraries.

Here is the log I see.

10:27:18: Audacity 2.1.3-alpha-Dec 27 2016
Log Cleared.
10:27:21: Attempting to load LAME from previously defined path
10:27:21: Loading LAME from /usr/local/lib/audacity/libmp3lame.dylib
10:27:21: Actual LAME path /usr/local/lib/audacity/libmp3lame.dylib
10:27:21: LAME library successfully loaded
10:27:26: Trying to load FFmpeg libraries...
10:27:28: mLibAVFormatPath ('/Library/Application Support/audacity/libs/libavformat.55.dylib') is not empty. Loading from it.
10:27:28: Checking for monolithic avformat from '/Library/Application Support/audacity/libs/libavformat.55.dylib'.
10:27:28: avformat not monolithic
10:27:28: Loading avutil from '/Library/Application Support/audacity/libs/./libavutil.52.dylib'.
10:27:28: Loading avcodec from '/Library/Application Support/audacity/libs/./libavcodec.55.dylib'.
10:27:28: Loading avformat from '/Library/Application Support/audacity/libs/libavformat.55.dylib'.
10:27:28: Actual avutil path /Library/Application Support/audacity/libs/./libavutil.52.dylib
10:27:28: Actual avcodec path /Library/Application Support/audacity/libs/./libavcodec.55.dylib
10:27:28: Actual avformat path /Library/Application Support/audacity/libs/libavformat.55.dylib
10:27:28: Importing symbols...
10:27:28: All symbols loaded successfully. Initializing the library.
10:27:28: Retrieving FFmpeg library version numbers:
10:27:28:    AVCodec version 0x373466 - 55.52.102 (built against 0x373466 - 55.52.102)
10:27:28:    AVFormat version 0x372164 - 55.33.100 (built against 0x372164 - 55.33.100)
10:27:28:    AVUtil version 0x344264 - 52.66.100 (built against 0x344264 - 52.66.100)
10:27:28: FFmpeg libraries loaded successfully.
Comment 10 Gale Andrews 2016-12-27 14:45:36 UTC
(In reply to Paul L from comment #9)
> What exactly is the visible symptom of failrue to load the libraries?
In Libraries Preferences, I see FFmpeg (and LAME) not found where previously the library version number would be shown.

Here is the log after clearing it and opening Preferences after the bug strikes. FFmpeg is at /Library/Application Support/audacity/libs/ and there is no linked folder at plug-ins/libs/. LAME is at /usr/local/lib/audacity. 

18:09:19: Audacity 2.1.3-alpha-Dec 26 2016
Log Cleared
18:09:25: Attempting to load LAME from system search paths
18:09:25: Loading LAME from libmp3lame.dylib
18:09:25: Error: dlopen(libmp3lame.dylib, 1): image not found
18:09:25: load failed
18:09:25: Attempting to load LAME from builtin path
18:09:25: Loading LAME from /usr/local/lib/audacity/libmp3lame.dylib
18:09:25: Error: dlopen(/usr/local/lib/audacity/libmp3lame.dylib, 1): image not found
18:09:25: load failed
18:09:25: (Maybe) ask user for library
18:09:25: Failed to locate LAME library
18:09:25: Trying to load FFmpeg libraries...
18:09:25: mLibAVFormatPath ('libavformat.55.dylib') is not empty. Loading from it.
18:09:26: Checking for monolithic avformat from 'libavformat.55.dylib'.
18:09:26: Error: dlopen(libavformat.55.dylib, 1): image not found
18:09:26: Loading avutil from ''.
18:09:26: Error: dlopen(.bundle, 1): image not found
18:09:26: Loading avcodec from ''.
18:09:26: Error: dlopen(.bundle, 1): image not found
18:09:26: Loading avformat from 'libavformat.55.dylib'.
18:09:26: Error: dlopen(libavformat.55.dylib, 1): image not found
18:09:26: Error: Failed to load FFmpeg libraries.
18:09:26: Trying to load FFmpeg libraries from default path, '/Library/Application Support/audacity/libs/libavformat.55.dylib'.
18:09:26: Checking for monolithic avformat from '/Library/Application Support/audacity/libs/libavformat.55.dylib'.
18:09:26: Error: dlopen(/Library/Application Support/audacity/libs/libavformat.55.dylib, 1): image not found
18:09:26: Loading avutil from ''.
18:09:26: Error: dlopen(.bundle, 1): image not found
18:09:26: Loading avcodec from ''.
18:09:27: Error: dlopen(.bundle, 1): image not found
18:09:27: Loading avformat from '/Library/Application Support/audacity/libs/libavformat.55.dylib'.
18:09:27: Error: dlopen(/Library/Application Support/audacity/libs/libavformat.55.dylib, 1): image not found
18:09:27: Error: Failed to load FFmpeg libraries.
18:09:27: Trying to load FFmpeg libraries from legacy path, '/usr/local/lib/audacity/libavformat.55.dylib'.
18:09:27: Checking for monolithic avformat from '/usr/local/lib/audacity/libavformat.55.dylib'.
18:09:27: Error: dlopen(/usr/local/lib/audacity/libavformat.55.dylib, 1): image not found
18:09:27: Loading avutil from ''.
18:09:27: Error: dlopen(.bundle, 1): image not found
18:09:27: Loading avcodec from ''.
18:09:27: Error: dlopen(.bundle, 1): image not found
18:09:27: Loading avformat from '/usr/local/lib/audacity/libavformat.55.dylib'.
18:09:27: Error: dlopen(/usr/local/lib/audacity/libavformat.55.dylib, 1): image not found
18:09:27: Error: Failed to load FFmpeg libraries.
18:09:27: Trying to load FFmpeg libraries from system paths. File name is 'libavformat.55.dylib'.
18:09:27: Checking for monolithic avformat from 'libavformat.55.dylib'.
18:09:27: Error: dlopen(libavformat.55.dylib, 1): image not found
18:09:27: Loading avutil from ''.
18:09:27: Error: dlopen(.bundle, 1): image not found
18:09:27: Loading avcodec from ''.
18:09:27: Error: dlopen(.bundle, 1): image not found
18:09:27: Loading avformat from 'libavformat.55.dylib'.
18:09:27: Error: dlopen(libavformat.55.dylib, 1): image not found
18:09:27: Error: Failed to load FFmpeg libraries.
18:09:27: Error: Failed to find compatible FFmpeg libraries.

This is the log after I exited Audacity, added your linked folder in plug-ins/libs/ and launched Audacity.

18:28:23: Audacity 2.1.3-alpha-Dec 26 2016
18:28:23: Trying to load FFmpeg libraries...
18:28:23: mLibAVFormatPath ('libavformat.55.dylib') is not empty. Loading from it.
18:28:23: Checking for monolithic avformat from 'libavformat.55.dylib'.
18:28:23: Error: dlopen(libavformat.55.dylib, 1): image not found
18:28:23: Loading avutil from ''.
18:28:23: Error: dlopen(.bundle, 1): image not found
18:28:23: Loading avcodec from ''.
18:28:23: Error: dlopen(.bundle, 1): image not found
18:28:23: Loading avformat from 'libavformat.55.dylib'.
18:28:23: Error: dlopen(libavformat.55.dylib, 1): image not found
18:28:23: Error: Failed to load FFmpeg libraries.
18:28:23: Trying to load FFmpeg libraries from default path, '/Library/Application Support/audacity/libs/libavformat.55.dylib'.
18:28:23: Checking for monolithic avformat from '/Library/Application Support/audacity/libs/libavformat.55.dylib'.
18:28:24: avformat not monolithic
18:28:24: Loading avutil from '/Library/Application Support/audacity/libs/./libavutil.52.dylib'.
18:28:24: Loading avcodec from '/Library/Application Support/audacity/libs/./libavcodec.55.dylib'.
18:28:24: Loading avformat from '/Library/Application Support/audacity/libs/libavformat.55.dylib'.
18:28:24: Actual avutil path /Library/Application Support/audacity/libs/./libavutil.52.dylib
18:28:24: Actual avcodec path /Library/Application Support/audacity/libs/./libavcodec.55.dylib
18:28:24: Actual avformat path /Library/Application Support/audacity/libs/libavformat.55.dylib
18:28:24: Importing symbols...
18:28:24: All symbols loaded successfully. Initializing the library.
18:28:25: Retrieving FFmpeg library version numbers:
18:28:25:    AVCodec version 0x373466 - 55.52.102 (built against 0x373466 - 55.52.102)
18:28:25:    AVFormat version 0x372164 - 55.33.100 (built against 0x372164 - 55.33.100)
18:28:25:    AVUtil version 0x344264 - 52.66.100 (built against 0x344264 - 52.66.100)
18:28:25: FFmpeg libraries loaded successfully.
Comment 11 Gale Andrews 2016-12-27 14:53:15 UTC
(In reply to Paul L from comment #8)
> Could you try something different:
>
> Install Audacity, and make the links first, before the bug strikes.
> Then try repeated restarts, and see whether the bug still strikes again at 
> all, after a simialr number of trials.
Not seen the bug yet if I do that. Tried 25 launches with the sole Audacity installed in /Applications, and 15 launches with the sole Audacity installed in my Downloads folder, with a linked folder added to that installation's bundle.
Comment 12 Paul L 2016-12-27 18:39:39 UTC
Gale, try building this, making sure there are no symlinks of your own making in plug-ins, and then repeatedly restarting Audacity as before.  It should create a symlink automatically to the directory with the ffpmeg libraries, assuming you don't have the bad luck to get the bug on the first trial.  Then try repeatedly.

This should not fix LAME.  Maybe you fill find LAME starts to fail but ffmpeg does not.  That would suggest I should make a similar fix elsewhere and LAME might become immune to the bug too.

But this might not exhaust all the bad cases.  As I said, I suspect it might strike LADSPA and VST effects, and maybe other things, and I have not found a single point in the code to fix it all.

https://github.com/Paul-Licameli/audacity/commit/d93455db44d2610a189ef39ae69a15f0edd93119
Comment 13 Peter Sampson 2016-12-28 10:52:16 UTC
Well I can't sem to reproduce this with LAME or FFmpeg on my Macbook Pro with Sierra 10.12.2 and latest Mac nightly alpha

1) I trashed all my Audacity applications
2) I deleted the .cfg files and Plugins folders in te Application Support>Audacity folder
3) Downloaded the latest nightly32a33bf 28Dec16
4) checked that the Application Support>Audacity folder was still empty, it was
5) Opened Audacity - I needed the right-click and confirm the first time
6) looked in the Application Support>Audacity folder - it had been populated ok
7) checked Preference> Libraries - shoed LAME and FFmpeag as present and correcy
8) Imported an mp3 file and an AAC file
9) exported an mp3 file and an AAC file
10 Quit Audacity
11) repeat 5 through 10 twenty times - all ok

All shipped Nyquist plugins are present and correct and work properly, plus I was able to enable and use SC4 and Classic Filters.  I assume all these effects are now coming in the app bundle in the Applications folder - as the Plug-ins folder in the Application Support>Audacity folder remains empty after the above tests.
Comment 14 Gale Andrews 2016-12-29 14:48:11 UTC
(In reply to Paul L from comment #12)
> https://github.com/Paul-Licameli/audacity/commit/d93455db44d2610a189ef39ae69a15f0edd93119

Thanks, Paul. I was glad to see that if FFmpeg is not yet installed, the symlink folder is immediately created when I locate valid FFmpeg in Preferences.   

This works well for allowing FFmpeg to be found, even when the bug subsequently strikes. When it strikes, then as before, LAME is not found and plugins outside the bundle are missing. I notice that once the symlink folder is created I can move the folder anywhere in the bundle and still keep FFmpeg enabled even after the bug has struck.

You are correct that if the bug strikes on first trial (which I can still make happen by downloading Audacity to different folders outside /Applications) then the symlink folder does not get created. So we still have to accept that fringe case. That said, I can still work round that by creating my own symlink folder in the terminal, then FFmpeg is enabled again. 

Or, so far, it seems I can stop all the problems including LAME, FFmpeg and external plugins by symlinking to /Users/gale/Library/Application Support/audacity


cd /Applications/Audacity.app/Contents/plug-ins       
ln -s /Users/gale/Library/Application\ Support/audacity
 
Creating this folder (it does not need to be in plug-ins) stops the bug if it has already happened, and seems to stop it happening in the first place. I have not tested whether this is viable beyond noting that some settings changes made in Audacity were written to audacity.cfg and respected on restart. But even if viable, it isn't waterproof unless we can create this symlink even when the bug strikes at first test. Perhaps changing the order of events might help?
Comment 15 Paul L 2016-12-29 16:38:44 UTC
(In reply to Gale Andrews from comment #14)

Without my fix, did the bug always strike both libraries, FFmpeg and LAME, at the same time?  Never one without the other?

I expected this fix to treat FFmpeg only.

I understand that you can fix all the problems with
ln -s /Users/gale/Library/Application\ Support/audacity .
rather than
ln -s /Users/gale/Library/Application\ Support/audacity/libs .

So do I infer correctly that the LAME and FFmpeg libraries are both under the first path, but not both under the second?

I am surprised that my wild guess works.  Maybe it is enough, for whatever reason, that some directory, any number of levels above the libraries, be linked into some folder, any number of levels at or below Contents.  I wonder now if simply
ln -s ~ .

would fix it all, but I don't know what other bad consequences that might have.
Comment 16 Gale Andrews 2016-12-29 20:11:38 UTC
(In reply to Paul L from comment #15)
> Without my fix, did the bug always strike both libraries, FFmpeg and LAME,
> at the same time?  Never one without the other? 

Never one without the other.

> I expected this fix to treat FFmpeg only.

The code you posted on GitHub only treats FFmpeg, and depends on the first trial not encountering the bug.  

> I understand that you can fix all the problems with
> ln -s /Users/gale/Library/Application\ Support/audacity .
> rather than
> ln -s /Users/gale/Library/Application\ Support/audacity/libs .

I "seem" to be able to fix all problems with 
  
   ln -s /Users/gale/Library/Application\ Support/audacity . 

> So do I infer correctly that the LAME and FFmpeg libraries are both under the 
> first path, but not both under the second?

I had not moved LAME (which was still at /usr/local/lib/audacity) and I have not moved FFmpeg (which is still at /Library/Application Support/audacity/libs/). 

Before you added symlinking to GitHub I had done  

   ln -s /Library/Application\ Support/audacity/libs .

This only fixed FFmpeg (because only FFmpeg is there, given Audacity does not look there for LAME) . If I move LAME there and set Libraries Preferences to use that path for LAME, then as you expected your GitHub commit still only fixes the bug for FFmpeg.   

I have never done 

  ln -s /Users/gale/Library/Application\ Support/audacity 

(as far as I know Audacity doesn't look there for FFmpeg or LAME). 

> I am surprised that my wild guess works.  Maybe it is enough, for whatever 
> reason, that some directory, any number of levels above the libraries,
> be linked into some folder, any number of levels at or below Contents. 
> I wonder now if simply
>
>  ln -s ~ .

> would fix it all, but I don't know what other bad consequences that might have.

I am not too surprised given we already knew that a Portable Settings folder inside the bundle solved it (on my machine).
Comment 17 Gale Andrews 2016-12-29 20:15:42 UTC
(In reply to Gale Andrews from comment #16)
> I have never done 
>
>  ln -s /Users/gale/Library/Application\ Support/audacity 
>
> (as far as I know Audacity doesn't look there for FFmpeg or LAME). 
Oops that meant I have never done 

ln -s /Users/gale/Library/Application\ Support/audacity/libs which path Paul referred to.
Comment 18 Paul L 2016-12-30 20:57:14 UTC
(In reply to Gale Andrews from comment #14)

"You are correct that if the bug strikes on first trial (which I can still make happen by downloading Audacity to different folders outside /Applications) then the symlink folder does not get created. So we still have to accept that fringe case."

If Audacity is installed outside Applications, does the bug happen always, or only once in sixteen or so?
Comment 19 Gale Andrews 2016-12-30 23:01:10 UTC
(In reply to Paul L from comment #18)
> If Audacity is installed outside Applications, does the bug happen always, or only
> once in sixteen or so?
If Audacity is installed outside /Applications, I get something like one occurrence in three.
Comment 20 Paul L 2016-12-31 01:07:57 UTC
Revised fix adequate for FFmpeg and LAME, please test again with a clean install that does not already have the symbolic links in it:

https://github.com/Paul-Licameli/audacity/commit/b8fbbf19cfbd261ccb34322074594465a67bbb9c

I still don't know, does this problem ever affect LADSPA, lv2, AudioUnit, VST, or Nyquist effects?

If so, separate fixes for each might be needed.  Possible fixes for those, excluding AudioUnit, are in this commit.

https://github.com/Paul-Licameli/audacity/commit/e04d6dd026a99a6560e3c9fcee918a095cf1bddd
Comment 21 Gale Andrews 2016-12-31 11:01:51 UTC
(In reply to Paul L from comment #20)
> I still don't know, does this problem ever affect LADSPA, lv2, AudioUnit, VST, or 
> Nyquist effects?
I have answered that multiple times now. If the bug strikes, any plug-in in any format (VAMP as well) is removed from the Audacity menus if the plugin is not in Audacity's embedded plug-ins folder.
Comment 22 Gale Andrews 2016-12-31 11:13:33 UTC
(In reply to Paul L from comment #20)
So I assume you would like me to clone/test the entire bug 1567 tree, so including the plugin fixes? Shall I wait for a fix for VAMP?
Comment 23 Paul L 2016-12-31 11:25:35 UTC
(In reply to Gale Andrews from comment #21)

I am sorry to make you repeat yourself, but not all the commentary has been collected in this database and I may have overlooked an email.

There are Nyquist effects, which do not dynamically load a code library but simply open a file as text and interpret it.  I would be surprised if these really have the same problem, but then it would be little effort to link these plug-ins too. 

By inspecting the code, I see certain places where dynamic libararies are directly loaded, and each such place requires its separate fix and testing.  These include LADSPA and VST effects.

This also includes some other places that are only experimental as of yet (making a plug-in "host provider" -- the code that implements a plug-in loading protocol like VST -- itself, dynamically loaded and not built-in to Audacity).  I changed those too in the latter commit for completeness.

There are also some places where a dynamic library may be loaded not directly by Audacity but indirectly by third-party code.  These include lv2 and AudioUnit effects.  But so long as I can identify a relevant file path, I can make a similar fix.  Yet it is not obvious in the AudioUnit case how to do that.

I do not know how to exercise each of these cases, so as to satisfy myself that I get at least the linking working right, even if I don't encounter the bug.  I don't have any plug-ins in LADSPA or lv2.  Where can I find a working version of old sc4 for MacOS?

Also the change I made for VST creates the link as needed each time the effect is opened, but for the others, this is done only when the effect is registered.  I think this means the links for those effects will be made only if audacity.cfg is deleted.  Perhaps I should change those others to behave more like the case of VST.
Comment 24 Paul L 2016-12-31 11:29:27 UTC
(In reply to Gale Andrews from comment #22)

Indeed I omitted VAMP from my fix.  That would be another "indirect" case like AudioUnits and lv2.  I will work on this.
Comment 25 Gale Andrews 2016-12-31 12:44:29 UTC
(In reply to Paul L from comment #23)
SC4 is shipped with Audacity.

Yes I understand you see differences in the code. I have observed several times that when the bug triggers, Nyquist files in  ~/Library/Application Support/audacity/plug-ins are removed from the Audacity menus, but those in the embedded plug-ins folder remain (even third-party ones). 

> Also the change I made for VST creates the link as needed each time the effect 
> is opened, but for the others, this is done only when the effect is registered.  I 
> think this means the links for those effects will be made only if audacity.cfg is 
> deleted.  
I think it means only when pluginregistry.cfg is deleted.  

> Perhaps I should change those others to behave more like the case of VST

Already registered effects of all types, when they are removed from the Audacity menus by the bug, can be seen to have moved from "Enabled" to "New" in Plug-In Manager.  I think we have to take more action than just when the effect is registered.

Have you determined any bad effects of a single link to  ~/Library/Application Support/audacity/ (the Audacity configuration folder)? It seems almost too good to be true, but that continues to work for me.
Comment 26 Paul L 2016-12-31 13:19:02 UTC
(In reply to Gale Andrews from comment #25)

Correct, I meant pluginregistry.cfg.

SC4 doesn't get put into place as part of my build procedure.  I can find a .dll on the Web but that is for Windows.  I can't easily find the .so version.

I found one bad effect, that when I put a link in the plug-ins folder back to itself, then this cicularity seemed to cause an infinite loop in the opening of the plug-ins management dialog.  You will not have seen this if you have not yet built the commits I mentioned before.  I can simply fix this circularity by making a different sub-folder called links that is a peer of plug-ins.  links contains the links and nothing else.  But now I wonder if this might cause duplications of Nyquist effects in the dialog?  I may need to do a different fix.

I have figured out the right way to make links for AU and Vamp, and verified it by experiment.  I still have not verified it for LADSPA or lv2.

I have added two commits to the branch in my fork, for the links folder and for AU plus Vamp.  This is the current tip:

https://github.com/Paul-
Licameli/audacity/commit/216fd55c2ea8f603063c38eb8300c72e7fc597ad
Comment 27 Gale Andrews 2016-12-31 20:14:11 UTC
(In reply to Paul L from comment #26)
Paul, you can get SC4 from Leland's nightly builds 
http://www.audacity.homerow.net/index.php?dir=mac/ .
Comment 28 Peter Sampson 2017-01-26 13:47:36 UTC
Testing on Mac Sierra 10.12.2 with 53c3adf 26Jan17 which should have Paul's cjanged in commit a05d039 

Still tests ok on my Mac.

1) Nyquist files are all visible and usable
2) LAME and FFmpeg libraries still visible and usable

Tested with several repears of Closing without Saving.
Comment 29 James Crook 2017-02-25 13:02:50 UTC
I had a look at the residual issue, of creating two projects and then deleting one, and its folders being kept at that point - even though empty.  Unfortunately we can't simply use CleanDir() to clean out those empty folders for that project, because they might legitimately not be empty.  They can hold block files that belong to the clipboard - if the user cuts or copies from within the project before closing it.

So, removing the empty folders will need extra new code that checks they really are empty, rather than blindly using CleanDir().  Doing that will probably still leave a 1567 residual case, when the clipboard has captured from the project just before deleting the project.  So reluctantly am not trying to do this for RC3.
Comment 30 James Crook 2017-03-01 11:16:17 UTC
DEVEL-AMELIORATION-MADE
https://github.com/audacity/audacity/commit/95861bf7f2354b1ee8462573200036ee9e8b8b5a

This fix cleans out the temporary directory of a project when it is closed, in the multi-project case.  It carefully does NOT clean out block files that may be still be being used (by the clipboard), so there is no way it is a complete fix for the problem.  It might ameliorate the problem though.
Comment 31 Gale Andrews 2017-03-03 22:05:36 UTC
(In reply to James Crook from comment #30)
Yes, so if in the multi-project case we don't copy anything in the project to be closed, 1567 does not occur. 

We can make a further amelioration though where we only select over a label. See http://bugzilla.audacityteam.org/show_bug.cgi?id=1521#c4 .
Comment 32 Peter Sampson 2017-08-03 11:10:42 UTC
(In reply to Peter Sampson from comment #28)
 Peter Sampson 2017-01-26 13:47:36 EST

Testing on macOS Sierra 10.12.6 with 53c3adf 03Aug17 3e39771

Still tests ok on my Mac.

1) Nyquist files are all visible and usable
2) LAME and FFmpeg libraries still visible and usable

Tested with several repears of Closing without Saving.


And this has never been a problem for me in all the varius Sierra 10.12.x releases

According I set the OK on Mac flag
Comment 33 James Crook 2017-08-03 12:02:02 UTC
*** STEPS UPDATED ***

It is believed that with the fixes up to comment #30 that the residual issue is that the original problem of disappearing FFmpeg and LAME can still occur, after working with a multi-project.  The bad things seem to happen if there is a ,DS_Store file during removal of the project window.

Additional changes since comment #30 may have fixed the root cause.
Comment 34 Peter Sampson 2017-08-04 11:01:02 UTC
Weel, Ive been testing the multi-project use case in the steps to reproduce with the latest nightlies on W10 and on Mac - and I cannot reproduce this problem.

Works for me even with a multi-project wormcan - my LAME and FFmpeg libraries seem to remain resolutley where they should be - are availbale on sunsequent launches of Audacity and work as expected.
Comment 35 Peter Sampson 2017-09-04 08:45:51 UTC
Tried again with my latest clean install of the Mac Beta 02Seo17

and following the steps - I just cannot get LAME or FFmpeg to disappear - plus I did more testing-around with an even grater number of projects.

And I have never encountered this on any of the many alphas and now the Beta in real life use of Audacity on my Mac.

So I still believe that this is not an issue on Mac - It may well have been on Gale's machine and his environment, but we obviously have no way of testing that now.
Comment 36 Peter Sampson 2017-09-27 13:19:11 UTC
Testing on macOS Sierra 10.12.6 4a0fbf8 27Sep17
(and on the 2.2.0 Beta-1 for Mac)

I still cannot get this to occur.

Nor since the release of Beta-1 for Mac have I seen any complaints on the Forum of this occurring.

I believe this is fixed and that we should close this bug as resolved.
Comment 37 Cliff Scott 2017-09-27 16:30:36 UTC
I agree.
Comment 38 Peter Sampson 2017-10-30 07:15:06 UTC
Tested again on the official 2.2.20 RC1 (signed) on my Macbook Pro macOS 10.13 High Sierra

LAME and FFmpeg found properly, automatically, in my:
a) privileged administrator account
b) normal non-privileged user account
c) totally unprivileged guest account

And no effects, generators or Analyzers missing.

Cliff has posted to say that he has no problems with this either - and I assume from the lack of reports from Bill and Steve that this all works fine on their Mac's too.

The RC1 has been out in the wild for more general testing for a few days now and we have no reports of this issue recurring - so I am going to close these as RESOLVED