Those paths are used to store a local copy of the nzbToMedia repository files from GitHub, and Python modules from PyPI.
Everything in both paths is removed during an upgrade (and/or clean), so don’t store your own files and configs there.
In the new nzbToMedia, I’ll include a config path for that.
OK, that makes sense then. I just couldn’t wrap my head around how the files had gone missing.
I’ve pointed SABnzbd to the /repo-cache folder, and in the categories tab, everything is now back to normal. I’ll make a backup of autoProcessMedia.cfg just in case everything is reset again later.
Thanks for the quick help 
More bad news (it never ends): the developers for Lidarr are now compiling their binaries to require libc 2.29 or-later which isn’t available in QTS. 
So, as-of right-now, the Lidarr package can’t be run. Existing Lidarr users will find their installation broken when Lidarr next updates, and Lidarr will be removed from sherpa support on the next stable QPKG release.
There are various versions available in the myQNAP repository if you’d like to continue using this application, but these require the purchase of a core QPKG from Stéphane.
You may be able to transfer your existing configs across to it. Don’t install the myQNAP version until you’ve manually backed-up your configs though.
Your sherpa Lidarr should be manually uninstalled via your QTS App Center.
p.s. Does anyone know how to compile a later glibc and make it available to a specific application? If-so, I could use your help. Please contact me. 
Hi,
I noticed a little hiccup regarding the nzbMedia path.
Recently, the scripts in SabNZB stopped working for me, and I realized that the nzbMedia scripts were now linked under /share/Public/Downloads instead of /share/Download.
So I took a look at nzbmedia.sh:
default_download_share is determined from /etc/config/def_share.info. Mine looks like this:
[SHARE_DEF]
defPublic = Public
defDownload = Download
defMultimedia = Multimedia
defRecordings = none
defUsb = Usb
defWeb = Web
defVolMP = /share/CACHEDEV1_DATA
So for me, it results in /share/CACHEDEV1_DATA/Download.
But then in nzbmedia.sh, there’s this check:
if [[ -z $default_download_share ]]||[[ -n $default_download_share && ! -L $default_download_share ]];then
default_download_share=unspecified
fi
And exactly the ! -L $default_download_share is the problem.
-L is “True if file exists and is a symbolic Link.”
Now, /share/CACHEDEV1_DATA/Download is the actual storage location of the share, so it’s a folder and not a symlink.
/share/Download would be the appropriate symlink.
Thus, default_download_share=unspecified is set and ultimately the symlink for the scripts is created under /share/Public/Download.
For now, I helped myself by adding the following line to /etc/config/qpkg.conf: Scripts_Path = /share/Download. But I’m not sure if this will survive an update of the nzbMedia QPKG.
So if @OneCD is working on a new QPKG, maybe a small fix is needed there.
Hi mate, and thanks for posting your findings. 
The new nzbToMedia QPKG is complete, but is awaiting the next sherpa packages release (which I hope will be this weekend). I’ve altered the logic in the nzbToMedia QPKG so it’s now self-contained. It will no-longer attempt to link to a download location used by another application like SABnzbd or nzbget.
It will be up-to the user to create this link where-ever they like - a symlink isn’t even needed anymore. This means, post-processing scripts no-longer need to be in a “downloads” path.
For existing users, they already have a link. For new users (or existing users wanting to change the scripts location), set the ‘Scripts Folder’ location directly in SABnzbd (or nzbget).
All that remains is for me to create a new wiki page explaining this.
New sherpa package release has just been pushed to GitHub: v20251108
Lots of changes, so please advise of any issues. Hopefully, things should keep-on working as they did before. 
nzbToMedia QPKG operation has changed too: How to use the new nzbToMedia QPKG · OneCDOnly/sherpa Wiki · GitHub
Also, for users of Sonarr, Readarr and Whisparr only, please reboot your NAS after upgrading your QPKGs. You may see failures reported during the upgrade process: ignore these and reboot anyway.