Note: This response has been edited upon discovering the problem/solution to the Firewall nag requester in question.
SHORT SUMMARY: The guisettings.xml file stored in Application Support/XBMC/userdata must be deleted from any prior/older install of XBMC such as Eden and let Frodo 12.3 generate a new file. Otherwise, the file will become corrupted (in either direction running old/new or new/old) with incompatible settings. A good solution might be to have newer versions of XBMC that are incompatible with the markup code from older versions to use a different settings file. The code would still need cleaned up to properly import older version settings as Frodo 12.3 clearly does NOT import Eden settings correctly.
Longer Discussion With an Example:
(2014-03-02, 00:21)Ned Scott Wrote: http://forum.xbmc.org/showthread.php?pid...pid1604493
I think the point is that OS X apps aren't supposed to have to be signed or tricked into self-signing. I've got many apps that need Firewall access and NONE keep asking every time I load the program. You approve once and it goes away. Likewise, if you tell it to block a program, it shouldn't ever ask you again either. That's the whole point of asking. But when it asks me again if I want to allow it and I say NO, the setting in the Preference Security Pane does
not change. It's still set to allow. If I manually change it to block in that Firewall pane, it still asks when XBMC loads again. That's not normal for any program. XBMC is doing something wrong to cause that and I now know where the problem is after fuxing around with it for a few hours....
Eden here did NOT cause that requester to appear here at all until this new Frodo came out. In other words, there must be a preference file saved somewhere that is causing it to now appear in Eden also because every single version of XBMC gives this error now and they never did until I ran 12.3 here. I'm guessing if I go in and delete all the saved settings and start Eden again it will be OK once more until I run Frodo 12.3 at which point it will become corrupted again.
That preference file is in ~/Application Support/XBMC/userdata/guisettings.xml
I've discovered that Eden (and god knows how many beta versions, etc.) does not play well with Frodo (and I assume Gotham as well) versions of XBMC. The settings are obviously different in some areas upon comparison. This explains the audio problems I was having as well when I upgraded. The settings are not being properly imported/updated and I think the corruption gets even worse when later running Eden again after Frodo has made its own settings changes. This affects default audio settings, vertical sync settings and some way, some how, the Firewall warnings.
For example,
I examined the various guisettings.xml file outputs stored in my Application Support folder for XBMC and it's obvious it's importing the Eden file incorrectly in Frodo:
Relevant Part of EDEN guisettings.xml with Correct 2.0 Audio Output Setting:
<audiooutput>
<ac3passthrough>false</ac3passthrough>
<audiodevice>CoreAudio:default</audiodevice>
<channellayout>0</channellayout>
<dontnormalizelevels>true</dontnormalizelevels>
<dtspassthrough>false</dtspassthrough>
<mode>0</mode>
<passthroughaac>false</passthroughaac>
<passthroughmp1>false</passthroughmp1>
<passthroughmp2>false</passthroughmp2>
<passthroughmp3>false</passthroughmp3>
</audiooutput>
Relevant Part of FRODO guisetting.xml After running Eden first and then Frodo 12.3 (Shows Up as 2.1 in Frodo):
<audiooutput>
<ac3passthrough>false</ac3passthrough>
<audiodevice>CoreAudio:default</audiodevice>
<channels>2</channels>
<dtspassthrough>false</dtspassthrough>
<guisoundmode>1</guisoundmode>
<mode>0</mode>
<multichannellpcm>true</multichannellpcm>
<normalizelevels>true</normalizelevels>
<passthroughdevice>Built-in Output</passthroughdevice>
<stereoupmix>false</stereoupmix>
</audiooutput>
Relevant Part of FRODO guisettings.xml With Corrected/Working 2.0 Audio AND/OR a Clean Install of Frodo 12.3:
<audiooutput>
<ac3passthrough>false</ac3passthrough>
<audiodevice>CoreAudio:default</audiodevice>
<channels>1</channels>
<dtspassthrough>false</dtspassthrough>
<guisoundmode>1</guisoundmode>
<mode>0</mode>
<multichannellpcm>true</multichannellpcm>
<normalizelevels>true</normalizelevels>
<passthroughdevice>Built-in Output</passthroughdevice>
<stereoupmix>false</stereoupmix>
</audiooutput>
As you can see, <channellayout>0</channellayout> should become <channels>1</channels> to get 2.0 in Frodo, but it becomes <channels>2</channels> instead which results in a 2.1 setting that doesn't work here. Since it doesn't happen on a clean install, I imagine the problem is in parsing/converting the older setting. These are just the stored settings, not the code itself that generated it or imported the previous file where the actual error must be.
This problem is, at least, correctable in the GUI preference pane. Frodo, upon upgrading from an Eden install will select 2.1 audio instead of 2.0 like it should, but at least you can go in and change it back and sound will then work once again. This problem does NOT happen on a fresh install of Frodo, only when running Frodo on an existing install of XBMC Eden. I believe the corrupted vertical sync settings (which are different in Eden and Frodo altogether) end up using the Eden settings when imported back and forth and the newer Frodo version disappears altogether. Obviously, something somewhere in the file is causing the "Allow" nag requester to appear as well since generating either a clean Eden guisettings.xml file or a clean Frodo one will eliminate the nag requester in either version. Run the other version of XBMC without deleting the guisettings.xml file first will result in the nag requester coming back again.
Thus, the workaround FIX is to pick one version of XBMC to use and delete the guisettings.xml file and let that version regenerate it. Make your setting changes to the way you want them and NEVER EVER run the other version of XBMC again unless you want it corrupted all over again (whence the solution is to delete that file and generate a new clean one all over again).
Now knowing where the problem obviously lies in XBMC, the developers COULD fix XBMC so that it correctly imports an older version of the guisettings.xml file from Eden, etc. and updates it correctly rather than in a corrupted manner. However, that would probably not fix the problem of running Eden again, which would corrupt the newer file with its older settings in some places. One would think that XBMC should/would do a version check and use a DIFFERENT guisettings file for the newer/incompatible version of XBMC so that the two versions don't collide like that (e.g. Frodo could/should use guisettingsFrodo.xml and that would completely avoid corrupting the older Eden file in either direction. It would still need to correctly parse/import the Eden file upon its first run to retrieve the old settings, but then would never cause a problem for either version again.