OK, das ergibt dann Sinn. Ich konnte mir einfach nicht erklären, wie die Dateien verschwunden waren.
Ich habe SABnzbd auf den /repo-cache-Ordner verwiesen und im Kategorien-Tab ist jetzt wieder alles normal. Ich mache vorsichtshalber ein Backup von autoProcessMedia.cfg, falls später wieder alles zurückgesetzt wird.
Danke für die schnelle Hilfe 
Mehr schlechte Nachrichten (es nimmt kein Ende): Die Entwickler von Lidarr kompilieren ihre Binärdateien jetzt so, dass sie libc 2.29 oder neuer erfordern, was in QTS nicht verfügbar ist. 
Daher kann das Lidarr-Paket derzeit nicht ausgeführt werden. Bestehende Lidarr-Nutzer werden feststellen, dass ihre Installation nach dem nächsten Lidarr-Update nicht mehr funktioniert, und Lidarr wird mit dem nächsten stabilen QPKG-Release aus dem sherpa-Support entfernt.
Im myQNAP-Repository sind verschiedene Versionen verfügbar, falls Sie diese Anwendung weiterhin nutzen möchten, aber dafür ist der Kauf eines Core-QPKG von Stéphane erforderlich.
Möglicherweise können Sie Ihre bestehenden Konfigurationen darauf übertragen. Installieren Sie die myQNAP-Version jedoch erst, nachdem Sie Ihre Konfigurationen manuell gesichert haben.
Ihr sherpa-Lidarr sollte manuell über Ihr QTS App Center deinstalliert werden.
P.S.: Weiß jemand, wie man eine neuere glibc kompiliert und sie einer bestimmten Anwendung zur Verfügung stellt? Falls ja, könnte ich Ihre Hilfe gebrauchen. Bitte kontaktieren Sie mich. 
Hallo,
bezüglich des nzbMedia-Pfades ist mir noch ein kleines Missgeschick aufgefallen.
Letztens haben bei mir die Skripte in SabNZB nicht mehr funktioniert, und dabei ist mir aufgefallen, dass die nzbMedia-Skripte nun unter /share/Public/Downloads verlinkt waren und nicht mehr unter /share/Download.
Deshalb habe ich mal einen Blick in die nzbmedia.sh geworfen:
default_download_share wird aus /etc/config/def_share.info ermittelt. Die sieht bei mir so aus:
[SHARE_DEF]
defPublic = Public
defDownload = Download
defMultimedia = Multimedia
defRecordings = none
defUsb = Usb
defWeb = Web
defVolMP = /share/CACHEDEV1_DATA
Folglich kommt bei mir /share/CACHEDEV1_DATA/Download raus.
Aber dann kommt in nzbmedia.sh diese Abfrage:
if [[ -z $default_download_share ]]||[[ -n $default_download_share && ! -L $default_download_share ]];then
default_download_share=unspecified
fi
Und genau das ! -L $default_download_share ist das Problem.
-L ist „True if file exists and is a symbolic Link.“
Nun ist /share/CACHEDEV1_DATA/Download aber der eigentliche Speicherort des Shares, also ein Ordner und kein Symlink.
/share/Download wäre der passende Symlink.
Somit wird default_download_share=unspecified gesetzt und letztlich der Symlink für die Skripte unter /share/Public/Download erstellt.
Ich habe mir jetzt erstmal damit beholfen, in /etc/config/qpkg.conf folgende Zeile einzufügen: Scripts_Path = /share/Download. Ich bin mir aber nicht sicher, ob das ein Update des nzbMedia-QPKGs überleben wird.
Also falls @OneCD an einem neuen QPKG arbeitet, wäre da vielleicht noch ein kleiner Fix nötig.
Hi Kumpel, und danke fürs Posten deiner Erkenntnisse. 
Das neue nzbToMedia QPKG ist fertiggestellt, wartet aber noch auf das nächste sherpa-Pakete-Release (was hoffentlich dieses Wochenende sein wird). Ich habe die Logik im nzbToMedia QPKG geändert, sodass es jetzt eigenständig ist. Es wird nicht mehr versuchen, auf einen Download-Ort zu verlinken, der von einer anderen Anwendung wie SABnzbd oder nzbget verwendet wird.
Es liegt nun beim Benutzer, diesen Link nach Belieben zu erstellen – ein Symlink ist nicht einmal mehr nötig. Das bedeutet, dass Post-Processing-Skripte nicht mehr im „downloads“-Pfad liegen müssen.
Für bestehende Nutzer gibt es bereits einen Link. Für neue Nutzer (oder bestehende Nutzer, die den Skript-Ort ändern möchten), kann der Speicherort des ‘Scripts Folder’ direkt in SABnzbd (oder nzbget) eingestellt werden.
Alles, was noch bleibt, ist, dass ich eine neue Wiki-Seite erstelle, die das erklärt.
Ein neues sherpa-Paket-Release wurde soeben auf GitHub veröffentlicht: v20251108
Viele Änderungen, daher bitte Rückmeldung bei Problemen. Hoffentlich funktioniert weiterhin alles wie zuvor. 
Auch der Betrieb des nzbToMedia QPKG hat sich geändert: How to use the new nzbToMedia QPKG · OneCDOnly/sherpa Wiki · GitHub
Außerdem sollten Benutzer von Sonarr, Readarr und Whisparr nach dem Upgrade ihrer QPKGs ihr NAS neu starten. Während des Upgrade-Vorgangs können Fehler angezeigt werden: Ignorieren Sie diese und starten Sie trotzdem neu.
Lange nicht gesehen… Der Scripts-Ordner ist verschwunden… im heutigen Update… er befindet sich nicht unter share/CACHEDEV1_DATA/.qpkg/nzbToMedia/repo-cache
Wo ist nzbToMedia installiert?
getcfg nzbToMedia Install_path -f /etc/config/qpkg.conf
Gibt es ein repo-cache unterhalb dieses Verzeichnisses?
ll $(getcfg nzbToMedia Install_path -f /etc/config/qpkg.conf)/repo-cache
Ich musste durchhalten, aber jetzt funktioniert es – die Skripte sind jetzt verfügbar. Danke.
Die Skripte befinden sich jetzt im Stammverzeichnis des Repos.
Die nzbToMedia-Skripte sollten vorhanden sein, wenn das GitHub-Repo geklont wird.
Hast du eigene Skripte zu repo-cache hinzugefügt?
@Potestus, es ist sehr wichtig, dass du keine eigenen Skripte in repo-cache ablegst. Dieser Speicherort wird jedes Mal gelöscht, wenn du nzbToMedia aktualisierst.
Lass mich wissen, falls du eigene Skripte hast, dann finden wir gemeinsam eine Lösung dafür. 
Ich bekomme jetzt Watcher3-Fehler in sab?
Watcher3: Nachbearbeitung fehlgeschlagen – Status auf Deaktiviert geändert!
Ich betreibe das immer noch als Sideload
ClamAV * inkompatibler Autor N/A N/A N/A /share/CAC>
Entware - aktiviert, aktiv nicht unterstützt 1.03a 1.03a /share/CAC>
Headphones - aktiviert, aktiv Start (OK) 251116 dynamisch /share/CAC>
LazyLibrarian - aktiviert, aktiv Start (OK) 251116 dynamisch /share/CAC>
nzbToMedia - aktiviert, aktiv Start (OK) 251116 dynamisch /share/CAC>
OSickGear - aktiviert, aktiv Start (OK) 250628 dynamisch /share/CAC>
Par2turbo - aktiviert, aktiv nicht unterstützt 1.2.0 1.2.0 /share/CAC>
SABnzbd - aktiviert, aktiv Start (OK) 251116 dynamisch /share/CAC>
sherpa - aktiviert, aktiv Start (OK) 251101 251101 /share/CAC>
Unrar - aktiviert, aktiv nicht unterstützt 7.0.8 7.01 beta 1 /share/CAC>
Was soll ich tun… es funktioniert zwar noch, aber der Fehler ist nervig..?
Hi Kumpel. 
Watcher3 wird nicht mehr weiterentwickelt. Es wird weiterhin auf interessante und unvorhersehbare Weise kaputtgehen, da niemand es repariert.
Versuche stattdessen Radarr.
Hallo @onecd… Ich bin es wieder… der bedürftige Neuling, der immer nur auftaucht, wenn etwas schief läuft
Kürzlich hatte mein QNAP ein Update. Ich bin mir nicht sicher, ob es seitdem schief läuft, aber nun bin ich eben hier.
Ich kann die meisten Programme, die von sherpa installiert wurden – radarr, sonarr usw. – öffnen und sehen. Allerdings verbindet sich mein Downloader SABNZBD nicht. Ich habe ihn im App Center gestoppt und neu gestartet, aber wenn ich zur lokalen IP:8900 gehe, bekomme ich eine ERR_CONNECTION_REFUSED-Meldung…
Mit Putty habe ich versucht, sudo sherpa reinstall sabnzbd auszuführen, aber das hat das Problem nicht gelöst… Ich habe es versucht, wirklich…
Ohne dich wäre dieses QNAP schon im Müll gelandet
Hallo, Kumpel.
Kannst du bitte den Status von SABnzbd mit dem Service-Skript überprüfen?
/etc/config/sabnzbd.sh s
- QPKG aktiviert: true
- Anwendung Auto-Update: true
- aktiver Git-Branch: master
- Daemon-PID: none
Ich hoffe, das ist das, was du suchst?
Ja, das ist es. 
Jetzt versuche, es zu starten:
/etc/init.d/sabnzbd.sh start
! Addons können nicht installiert werden: Virtuelle Python-Umgebung existiert nicht
= Quelle: sabnzbd.sh, Aktion: start, Zeit: Mi 3. Dez 2025 23:59:13 CST, Ergebnis:
Hmmm…
Als neuer Nutzer dieses Forums kann ich „vorübergehend“ nur 3 Mal auf dasselbe Thema antworten. Also muss ich das hier bearbeiten (wenn es mir erlaubt wird), um dir zu antworten…
[Eric@QNAP451 ~]$ sudo /etc/init.d/sabnzbd.sh clean
- Quelle: sabnzbd.sh, Aktion: clean, Zeit: Do 4. Dez 2025 00:02:59 CST, Auslastung: 0.18
- Paket: 251121, Dienst: 251121, Bibliothek: 251121
- QPKG aktiviert: true
- Anwendung Auto-Update: true
- Aktiver Git-Branch: master
- Daemon PID: none
> Lokales Repository bereinigen: OK
> Virtuelle Python-Umgebung bereinigen: OK
> PyPI-Cache bereinigen: OK
> Temp-Pfad bereinigen: OK
= Quelle: sabnzbd.sh, Aktion: clean, Zeit: Do 4. Dez 2025 00:02:59 CST, Ergebnis: OK, Dauer: 76ms, Auslastung: 0.18
[Eric@QNAP451 ~]$ sudo /etc/init.d/sabnzbd.sh start
- Quelle: sabnzbd.sh, Aktion: start, Zeit: Do 4. Dez 2025 00:03:14 CST, Auslastung: 0.14
- Paket: 251121, Dienst: 251121, Bibliothek: 251121
- QPKG aktiviert: true
- Anwendung Auto-Update: true
- Aktiver Git-Branch:
- Daemon PID: none
- Datei vorhanden: /opt/bin/git
> 'SABnzbd' aus Remote-Repository erstellen: OK
- Aktiver Git-Branch: master
> Neue virtuelle Python-Umgebung erstellen: fehlgeschlagen
> QPKG 'pip'-Konfiguration erstellen: OK
> Speicherort '/share/CACHEDEV1_DATA/.qpkg/SABnzbd/pip-cache' als 'pip'-Cache hinzufügen: OK
> Speicherort '/share/CACHEDEV1_DATA/.qpkg/SABnzbd/qpkg-wheels' zum 'pip'-Suchpfad hinzufügen: OK
! Addons können nicht installiert werden: Virtuelle Python-Umgebung existiert nicht
= Quelle: sabnzbd.sh, Aktion: start, Zeit: Do 4. Dez 2025 00:03:15 CST, Ergebnis: FEHLGESCHLAGEN, Dauer: 1.431ms, Auslastung: 0.14
[Eric@QNAP451 ~]$
Halte ich sie aktuell? Nicht absichtlich… es sei denn, es passiert automatisch, ich habe keine Befehle dazu ausgeführt. Die Qnap macht das Firmware-Update-Magie, aber ich versuche, mich nicht mit Sherpa zu beschäftigen, da es mir schon unangenehm genug ist, um Hilfe zu bitten…
Ok, lassen Sie uns aufräumen und starten:
/etc/init.d/sabnzbd.sh clean
/etc/init.d/sabnzbd.sh start
Übrigens: Hältst du deine Sherpa-QPKGs eigentlich auf dem neuesten Stand? 