- keine Konfigurationsdatei, verwende Standard als Vorlage
- Quelle: sickgear.sh, Aktion: Start, Zeit: Di 13 Jan 2026 00:09:25 EET, Auslastung: 2.19
- Paket: 251226, Dienst: 251226, Bibliothek: 251226
- QPKG aktiviert: true
- Anwendung Auto-Update: true
- Aktiver Git-Branch: main
- Daemon PID: keiner
- Datei vorhanden: /opt/bin/git
> Update 'SickGear' aus entferntem Repository:
{ exec: 'cd /tmp;/opt/bin/git -C "/share/MD0_DATA/.qpkg/SickGear/repo-cache" clean -f;/opt/bin/git -C "/share/MD0_DATA/.qpkg/SickGear/repo-cache" reset --hard origin/main;/opt/bin/git -C "/share/MD0_DATA/.qpkg/SickGear/repo-cache" pull'
HEAD ist jetzt bei 8769b3d Merge branch 'hotfix/3.34.9'
Bereits aktuell.
} exec: abgeschlossen OK (0)
- Aktiver Git-Branch: main
> Lade Ports aus Konfigurationsdatei: OK
> Starte Daemon:
{ exec: '/share/MD0_DATA/.qpkg/SickGear/venv/bin/python3 /share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py --daemon --nolaunch --datadir /share/MD0_DATA/.qpkg/SickGear/config'
} exec: abgeschlossen OK (0)
> Überwache, ob Daemon-Prozessname erscheint (nicht mehr als 120 Sekunden): 1, OK
> Warte 10 Sekunden, um zu bestätigen, dass PID noch aktiv ist: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, fertig
- Daemon PID: 31186
- Daemon Abhöradresse: 0.0.0.0
- HTTPS-Port aktiviert: false
- HTTP-Port: 7181
> Teste Antwort von Port 7181 (nicht mehr als 120 Sekunden): OK
> Aktualisiere QPKG-Icon mit UI-Ports: OK
= Quelle: sickgear.sh, Aktion: Start, Zeit: Di 13 Jan 2026 00:09:42 EET, Ergebnis: OK, verstrichen: 0h:00m:17s, Auslastung: 2.59
Sieht gut aus. 
Jetzt musst du SickGear wieder von Grund auf neu einrichten. 
Kann eine alte Konfiguration verwendet werden, um den Prozess zu erleichtern?
Gab es eine Möglichkeit, aktuelle Shows irgendwie darauf zu scannen?
Scheint, als hättest du ein paar Backups?
[/share/MD0_DATA/.qpkg/SickGear/config] # ll
total 1008K
drwxr-xr-x 4 admin administrators 4.0K 2026-01-13 00:14 ./
drwxrwxr-x 10 admin administrators 4.0K 2026-01-13 00:09 ../
drwx------ 6 admin administrators 4.0K 2026-01-13 00:09 cache/
-rw------- 1 admin administrators 524K 2026-01-13 00:09 cache.db
-rw-r--r-- 1 admin administrators 5.2K 2026-01-13 00:09 config.bak
-rw-r--r-- 1 admin administrators 5.2K 2026-01-13 00:09 config.ini
-rw-r--r-- 1 admin administrators 4.6K 2026-01-12 23:26 config.ini.def
-rw-r--r-- 1 admin administrators 4.6K 2026-01-13 00:09 config.ini.v20
-rw-r--r-- 1 admin administrators 5.2K 2026-01-13 00:09 config.ini.v21
-rw-r--r-- 1 admin administrators 5.2K 2026-01-13 00:09 config.ini.v22
-rw-r--r-- 1 admin administrators 5.2K 2026-01-13 00:09 config.ini.v23
-rw------- 1 admin administrators 16K 2026-01-13 00:09 failed.db
drwx------ 2 admin administrators 4.0K 2026-01-13 00:09 logs/
-rw------- 1 admin administrators 388K 2026-01-13 00:09 sickbeard.db
Zumindest das bak könnte etwas sein, das ich vor langer Zeit erstellt habe…
Die Dateien, die du dir ansiehst, wurden gerade erst erstellt. Es handelt sich nicht um deine ursprünglichen Konfigurationsdateien. Deine originale Konfiguration und Datenbank sind weiterhin im Sherpa-Konfigurations-Backup-Verzeichnis verfügbar.
Das Problem ist: Die Datenbank, die in diesem Backup-Verzeichnis gespeichert ist, wird von deiner aktuellen SickGear-Instanz nicht akzeptiert. Du könntest versuchen, die SickGear-Entwickler um Hilfe zu bitten. Es kann aber auch sein, dass sie dir empfehlen, deine Datenbank komplett neu aufzubauen.
Ich habe momentan keine laufende SickGear-Instanz zur Verfügung, aber in Medusa wählt man das Shows-Menü, dann Bestehende Shows hinzufügen und verweist auf das Verzeichnis mit den vorhandenen Shows. Damit ist ein Massenimport möglich.
Das eigentliche Problem ist deine Konfiguration. Du musst API-Schlüssel und alle deine Einstellungen aktualisieren.
Danke für die Hilfe, es funktioniert jetzt (größtenteils), die Datenbank wurde neu erstellt und ich drücke die Daumen auf dieser Seite. Dieses 3-Post-Limit… danke, dass du meine Rechte erhöht hast.
Was ich nicht herausfinden konnte, ist, warum nzbtomedia/sickgear die Episoden nicht im TV/Show/Season-Ordner speichert, sondern sie im TV-Ordner ablegt, z.B. /share/MD0_DATA/TV/Catastrophe.2015.S01E05.1080p.AMZN.WEB-DL.DD5.1.x264-DRACULA
Wahrscheinlich etwas ganz Offensichtliches, aber ich sehe es einfach nicht.
Sickgear Episoden-Benennung ist Season 02/Show.Name.S02E03.HD.TV-RLSGROUP.ext, Post-Processing bleibt leer…
Sorry, dabei kann ich nicht helfen. Du solltest dich an die SickGear-Leute wenden oder jemanden fragen, der sich mit SickGear-Konfigurationen auskennt.
Außerdem ist mir gerade eingefallen, dass das nzbToMedia-QPKG im November 2025 aktualisiert wurde und jetzt anders funktioniert: How to use the new nzbToMedia QPKG · OneCDOnly/sherpa Wiki · GitHub
Guten Abend, mein Freund – ich bin wieder da! Ich habe in letzter Zeit Probleme mit Sonarr. Jedes Mal, wenn ich das GUI aufrufe, ist es offline. Das QNAP App Center zeigt an, dass es läuft – also muss ich es stoppen und neu starten. Dann funktioniert es wieder einwandfrei – aber irgendwann fährt es wieder herunter.
Laut dem Sonarr-Log versucht es ein Update, fährt herunter, startet aber nie neu. Ich habe wirklich mein Bestes gegeben und versucht, das mit Grok herauszufinden, aber am Ende hatte ich das Gefühl, meinem eigenen Schwanz hinterherzujagen.
Ich weiß, dass du das für mich in weniger als drei Runden lösen kannst… also bin ich wieder hier, um verwöhnt zu werden 
Hi Kumpel.
Versuchen wir, es zu bereinigen:
/etc/init.d/sonarr.sh clean
… und falls es danach nicht startet, bitte starte es:
/etc/init.d/sonarr.sh start
Danke für die Rückmeldung… Nur zur Info – ich bin in die Einstellungen/Allgemein/Updates gegangen und habe die Updates deaktiviert, seitdem ist das System dauerhaft online geblieben.
source: sonarr.sh, action: clean, time: Wed 28 Jan 2026 5:41:31 PM CST, load: 0.55
package: 251226, service: 251226, library: 251226
QPKG aktiviert: true
Anwendung Auto-Update: true
Daemon PID: 11104
Stoppe Daemon PID 11104 mit SIGTERM (nicht länger als 120 Sekunden): 1, OK
Daemon PID: none
Lokales Repository bereinigen: OK
Vorheriges ‘screen’-Sitzungsprotokoll entfernen: OK
Temporären Pfad bereinigen: OK
Dateinamen des neuesten Remote-Release-Pakets abrufen (nicht länger als 5 Sekunden): OK
= Release-Paket-Dateiname: Sonarr.main.4.0.16.2944.linux-x64.tar.gz
Release-Paket-Namensreferenz existiert lokal: false
Release-Paket existiert lokal: false
Neueste Release-Paket herunterladen: OK
Aus Release-Paket extrahieren: OK
Release-Paket-Namensreferenz erstellen: OK
Ports aus Konfigurationsdatei laden: OK
Daemon (in ‘screen’-Sitzung) starten: OK
Auf Auftauchen des Daemon-Prozessnamens warten (nicht länger als 120 Sekunden): 1, OK
Daemon PID: 6105
Daemon lauscht auf Adresse: 0.0.0.0
HTTPS-Port aktiviert: false
HTTP-Port: 8989
Test auf Antwort von Port 8989 (nicht länger als 120 Sekunden): 1, 2, OK
QPKG-Icon mit UI-Ports aktualisieren: OK
= source: sonarr.sh, action: clean, time: Wed 28 Jan 2026 5:41:45 PM CST, result: OK, elapsed: 0h:00m:14s, load: 0.58
[Eric@QNAP451 ~]$
Es lief, als ich den Clean-Befehl ausgeführt habe – und es lief auch, als ich danach nachgesehen habe. Aber wie erwähnt, habe ich die automatische Update-Prüfung deaktiviert… Sollte ich sie wieder aktivieren oder lieber so lassen?
Gute Entscheidung. Ja, bitte lassen Sie die interne automatische Update-Funktion der Anwendung deaktiviert.
Um ein Update durchzuführen, starten Sie das QPKG neu. Dadurch wird automatisch das neueste Anwendungspaket heruntergeladen und installiert.
Ich muss wohl irgendwann unter der Haube herumgespielt und etwas gemacht haben, was ich nicht hätte tun sollen Wenn du sagst, das QPKG neu starten, heißt das einfach, die Anwendung im QNAP App Center zu stoppen und wieder zu starten?
Ja.
Es wäre schön, wenn das interne Anwendungs-Update wie vorgesehen funktionieren würde, aber momentan kann ich es nicht unterstützen. Daher müssen wir die Anwendung aktualisieren, indem wir das QPKG neu starten.
Danke, dass du mich aufgeklärt hast. Das war eigentlich kein Problem… und wie üblich habe ich es geschafft, daraus ein selbstverschuldetes Problem zu machen Vielen Dank, Kumpel…
Heute
Ja, das passt besser zu dem, was es tatsächlich macht. 
Kleines Update:
Es gab kürzlich ein Update der Entware-Pakete, und Python3 wurde auf Version 3.13.9 aktualisiert.
Dadurch werden Mylar3 und Watcher3 nicht mehr unterstützt. Watcher3 wird nicht mehr weiterentwickelt, und die Mylar3-Entwickler haben es nicht eilig, die Kompatibilität zu Python 3.13 sicherzustellen. 
Bitte deinstalliere diese QPKGs über das App Center.
Das Entware-Update hat außerdem die IPKs .git und git-http beschädigt. Das bedeutet, dass jedes QPKG, das Quellcode per git aus einem Repository zieht, fehlschlagen wird
Ich arbeite gerade an einer temporären Lösung und werde sie demnächst veröffentlichen.
Neue Paketveröffentlichungen heute! Ich hoffe, sie funktionieren. 
Außerdem eine wichtige Änderung: QPKGs aktualisieren sich standardmäßig nicht mehr selbst beim Neustart. Dies kann pro QPKG wieder aktiviert werden, muss jedoch vom Betreiber vorgenommen werden. Das sollte zu einer stabileren und schnelleren Erfahrung führen.
QPKG-Name: Status: Letzte Aktion (Ergebnis): QPKG-Version: Appl>
Entware - aktiviert, inaktiv nicht unterstützt 1.03a 1.>
Hallo, was bedeutet inaktiv?!
Das bedeutet, dass Sherpa erkannt hat, dass das Entware-QPKG installiert ist, aber es scheint nicht gestartet und für QTS verfügbar zu sein.
Könnten Sie bitte Entware neu starten?
/etc/init.d/entware.sh restart