Menu
▾
▴
#60 Recoil plug-ins for XnViewMP/XnConvert on Mac OS-X don't work
The recoil plugins for XnView-MP and XnConvert don't work anymore.
Tested with:
- macOS 10.14.6
- XnViewMP 0.98.1
- XnConvert 1.9.0
- RECOIL 6.0.0
Steps to reproduce:
- Drag the Xrecoil.usr file to XnViewMP.app/Contents/MacOS/Plugins and XnConvert.app/Contents/MacOS/Plugins
- Open XnViewMP or XnConvert
- Try to open any image supported by RECOIL
Result:
The images are not decoded. Behaves exactly as when no plug-in is installed.
"Don't work anymore" - do you mean that RECOIL 5.1.1 works but 6.0.0 doesn't?
I was using an older version of the RECOIL plug-in with XnViewMP and XnConvert (4.3.1, I believe), since I mostly use macOS QuickLook to view the images as it's faster. I they were working for what I needed.
Then I decided to update both XnViewMP and XnConvert alongside with their RECOIL plugins, and found out the new versions were not together anymore. So I have no idea at which point they stopped liking eachother. 😅
Petri Pyy recently reported the plugin not loading on MacOS 10.14 and newer.
Can you confirm that, please? I understand that downgrading the OS is not an option, but can you at least try some previous RECOIL release?
Note that XnView MP has its thumbnail cache, so it may appear that the plugin works while in fact it's just displaying from cache. There's a menu option to clear the cache.
We are working with the XnView MP author on a fix, your help would be appreciated!
Ok.
I tried the RECOIL plug-in down to 4.3.2 on XnViewMP 0.98.1, but it still didn't work.
Then I went back to the plugin 6.0.0, and started XnViewMP 0.98.1 on a terminal. I attached here a file with the contents that were output to the screen. (please bear in mind that I replaced my homedir with ~ on the file)
It's interesting that the plug-in is found and seems to be initialized, but then XnViewMP insists to treat the MSX image files as JPGs.
Last edit: SD Snatcher 2021-02-08
It only says:
Try
so it tries to load the plugin, but macOS doesn't let it.
Humm. How should be the correct output at that part?
Anyway, I tried a trick to convince Gatekeeper to alow the file to be run: After I copied the Xrecoil.usr file to the XnViewMP.app folder, I dragged it to the TextEdit App on the Dock.
This triggered Gatekeeper to open its window to complain that the file was downloaded from the Internet and blablabla. Then I went to Control Panel->Security, and authorized the Xrecoil.usr file there.
After that, I've run XnViewMP from the console again, and the same message "Try" was still shown on the output, and the plug-in still doesn't work.
Last edit: SD Snatcher 2021-02-08
I've experienced the same issue, and I believe the issue is with code-signing. Here are some additional troubleshooting steps:
Since Recoil and XnView MP are developed, compiled, and "notarized" by different developers, they'll have different Team IDs. Further, I believe more recent versions of MacOS will reject apps from launching code that is signed by a different app developer in its own process. I think this is why the XnView MP team supplies plugins with their releases. So one possible solution would be to contact the XnView MP team and ask that they include the plugin with their release. I don't think that XnView MP is open source, so there wouldn't be any option to compile it yourself.
Another option might be to play around with the code signing and entitlements for the XnView MP application as well as the Recoil plugin. For that, the following Stack Overflow link might be helpful.
https://stackoverflow.com/questions/61449772/mapping-process-and-mapped-file-have-different-team-ids
Maybe you solved the problem already. I had the same issue.
Solution was:
sudo codesign -f -s - --timestamp=none --deep /Applications/XnViewMP.app