Hallo Andy und willkommen im neuen Forum! 
Nach jedem Neustart erkennt sabnzbd das installierte par2cmdline turbo qpkg nicht.
Ich muss beide manuell stoppen und starten, damit par2cmdline turbo von sabnzbd erkannt wird.
Ich denke, par2cmdline turbo muss beim Neustart vor sabnzbd gestartet werden. Gibt es eine Möglichkeit, das zu erreichen?
Das sortmyqpkg-Paket funktioniert leider bekanntermaßen nicht mehr richtig, gibt es also andere Möglichkeiten?
Hi Kumpel. 
Das sollte eigentlich automatisch passieren.
Ich benötige einige Informationen zu deinem Setup. Kannst du bitte die folgenden Befehle jeweils ausführen und die Ergebnisse hier posten?
sherpa about
sherpa list installed
getcfg sabnzbd dependency -f /etc/config/qpkg.conf
getcfg par2turbo enable -f /etc/config/qpkg.conf
[~] # sherpa about
sherpa v251210-stable
dbug: (II) --------------------------------------------------------------------------------------------------------
dbug: () HARDWARE: NAS-Modell: TS-251
dbug: () HARDWARE: CPU: Intel(R) Celeron(R) CPU J1800 @ 2.41GHz
dbug: () HARDWARE: CPU-Kerne: 2
dbug: () HARDWARE: CPU-Architektur: x86_64
(64b)
dbug: () HARDWARE: grundlegender CPU SHA1-Benchmark: 55.0MB/s
dbug: () HARDWARE: RAM: 3.74GiB
dbug: () KERNEL: Name: GNU/Linux
dbug: () KERNEL: Version: 5.10.60-qnap
dbug: () KERNEL: Seitengröße: 4096B
dbug: () FIRMWARE: OS: QTS
dbug: () FIRMWARE: Version: 5.2.8.3332
dbug: () FIRMWARE: Build-Datum: 20251128 (Fr 28 Nov 2025)
dbug: () FIRMWARE: Plattform: X86_BAYTRAIL
dbug: () OS: Status: online
dbug: () OS: Laufzeit: 11h:11m:23s
dbug: () OS: Lastdurchschnitte: 1m:0.23, 5m:0.23, 15m:0.29
dbug: () STORAGE: Standardvolume eingehängt: /share/MD1_DATA
dbug: () STORAGE: grundlegender Schreib-Benchmark: 331MB/s
dbug: () STORAGE: /opt: /share/MD1_DATA/.qpkg/Entware
dbug: () USERSPACE: libc: (GNU libc) 2.21
dbug: () USERSPACE: libc Copyright: Copyright (C) 2015 Free Software Foundation, Inc.
dbug: () USERSPACE: $EUID: 0
dbug: (NA) USERSPACE: $SUDO_UID: N/A
dbug: () USERSPACE: BusyBox Version: BusyBox v1.24.1 (2025-11-28 02:14:32 CST) Multi-Call-Binary.
dbug: () USERSPACE: BusyBox Copyright: BusyBox ist urheberrechtlich geschützt von vielen Autoren zwischen 1998-2015.
dbug: () USERSPACE: BusyBox Funktionsanzahl: 166
dbug: () SCRIPT: QPKG-Version: 250927
(Sa 27 Sep 2025)
dbug: () SCRIPT: Manager-Version: 251210-stable
dbug: () SCRIPT: Manager-Epoch: 1765404323 (Mi 10 Dez 2025 23:05:23 CET)
dbug: () SCRIPT: Objects-Epoch: 1765404318 (Mi 10 Dez 2025 23:05:18 CET)
dbug: () SCRIPT: Packages-Epoch: 1765404085 (Mi 10 Dez 2025 23:01:25 CET)
dbug: () SCRIPT: Log-Pfad: /share/MD1_DATA/.qpkg/sherpa/log
dbug: () QPKG: Pakete-Release: v251211 (Do 11 Dez 2025)
dbug: (NA) QPKG: Unoffizielle erlauben: N/A
dbug: () QPKG: Signatur erforderlich: nein
dbug: () QPKG: Architektur: i64 (Intel x86-64)
dbug: () QPKG: Datum Entware installiert: 2025-10-23 (Do 23 Okt 2025)
dbug: () QPKG: Entware-Typ: std
dbug: (NA) QPKG: SortMyQPKGs: N/A
dbug: (NA) QPKG: IncreaseTimeouts: N/A
dbug: (II) --------------------------------------------------------------------------------------------------------
[~] # sherpa list installed
Entware
Par2turbo
SABnzbd
sherpa
Unrar
[~] # getcfg sabnzbd dependency -f /etc/config/qpkg.conf
Entware:Unrar:Par2turbo
[~] # getcfg par2turbo enable -f /etc/config/qpkg.conf
TRUE
Ich hoffe, das hilft…
Alles sieht gut aus. 
Das bedeutet: Es scheint, dass QTS die QPKGs nicht gemäß ihrer angegebenen Abhängigkeiten startet.
Ich teste momentan tatsächlich auf einer fast identischen Konfiguration (die einwandfrei funktioniert). Allerdings habe ich alle sherpa QPKGs installiert. Ich werde versuchen, auf nur die von dir verwendeten QPKGs zu reduzieren und sehen, ob ich diesen Fehler reproduzieren kann.
Ich melde mich wieder bei dir.
Nein, funktioniert hier einwandfrei.
@jimpoison, meldet SABnzbd, dass es Par2cmdline-turbo nicht finden kann?
Wenn das passiert, kannst du bitte den sherpa Statusbericht ausführen?
sherpa status
Wenn du nur das SABnzbd QPKG neu startest, funktioniert es dann wieder?
Ja, sabnzbd sagt, dass par2cmdline nicht verfügbar ist. Aber der Sherpa-Status zeigt mir, dass par2cmdline nach dem Neustart inaktiv ist. Ich denke, das ist der Grund, warum sabnzbd es nicht erkennt. Wenn ich jedoch par2cmdline neu starte, sagt der Sherpa-Status, dass es aktiv ist und von sabnzbd erkannt wird. Die Frage ist also, warum es nach dem Neustart inaktiv ist?
Wie kurz nach dem Hochfahren überprüfst du den Status von SABnzbd?
Als du den Sherpa-Statusbericht erstellt hast, gab es da eine Benachrichtigung, dass QTS noch dabei war, QPKGs zu starten?
Kannst du bitte das SABnzbd-Service-Log-Skript posten?
/etc/init.d/sabnzbd.sh log
Hallo, ich habe einige Probleme mit SickGear. Es startet, aber stoppt nach wenigen Sekunden wieder. Alles scheint in Ordnung zu sein, ich kann es manuell stoppen und starten, mich einloggen, aber nach ein paar Sekunden ist es tot. Irgendwelche Ideen?
QPKG Name: Status: Letzte Aktion (Ergebnis): QPKG Version: Appl. Version: Speicherort:
* ClamAV * inkompatibler Autor N/A N/A N/A /share/MD0_DATA/.qpkg/ClamAV
Entware - aktiviert, aktiv nicht unterstützt 1.03a 1.03a /share/MD0_DATA/.qpkg/Entware
nzbToMedia - aktiviert, aktiv Neustart (OK) 251226 dynamisch /share/MD0_DATA/.qpkg/nzbToMedia
OSickGear - aktiviert, inaktiv Start (OK) 250124 dynamisch /share/MD0_DATA/.qpkg/OSickGear
Par2turbo - aktiviert, aktiv nicht unterstützt 1.2.0 1.2.0 /share/MD0_DATA/.qpkg/Par2turbo
SABnzbd - aktiviert, aktiv Start (OK) 251226 dynamisch /share/MD0_DATA/.qpkg/SABnzbd
sherpa - aktiviert, aktiv Start (OK) 251212 251212 /share/MD0_DATA/.qpkg/sherpa
Unrar - aktiviert, aktiv nicht unterstützt 7.0.8 7.01 beta 1 /share/MD0_DATA/.qpkg/Unrar
Früher hat alles gut funktioniert, ich bin mir nicht sicher, ob etwas auf meinem QNAP durcheinander ist oder ob es etwas anderes ist. Die Sherpa-Sachen sehen soweit ich es geprüft und verstanden habe gut aus.
Eine Sache ist, dass obwohl sich nichts geändert hat (keine neuen Apps oder Konfigurationen), das QNAP eine hohe Prozessorlast (ca. 50%) und Speicherlast (ca. 30%) hat.
[~] # sherpa about
sherpa v251226-stable
dbug: (II) --------------------------------------------------------------------------------------------------------
dbug: (**) HARDWARE: NAS-Modell: TS-253A
dbug: (**) HARDWARE: CPU: Intel(R) Celeron(R) CPU N3150 @ 1.60GHz
dbug: (**) HARDWARE: CPU-Kerne: 4
dbug: (**) HARDWARE: CPU-Architektur: x86_64 (64b)
dbug: (**) HARDWARE: grundlegender CPU SHA1 Benchmark: 48.7MB/s
dbug: (**) HARDWARE: RAM: 7.69GiB
dbug: (**) KERNEL: Name: GNU/Linux
dbug: (**) KERNEL: Version: 5.10.60-qnap
dbug: (**) KERNEL: Seitengröße: 4096B
dbug: (**) FIRMWARE: OS: QTS
dbug: (**) FIRMWARE: Version: 5.2.8.3359
dbug: (**) FIRMWARE: Build-Datum: 20251225 (Do 25 Dez 2025)
dbug: (**) FIRMWARE: Plattform: X86_BRASWELL
dbug: (**) OS: Status: online
dbug: (**) OS: Laufzeit: 98h:22m:51s
dbug: (**) OS: Lastdurchschnitt: 1m:2.08, 5m:2.77, 15m:3.52
dbug: (**) STORAGE: Standardvolume gemountet: /share/MD0_DATA
dbug: (**) STORAGE: Grundlegender Schreib-Benchmark: 243MB/s
dbug: (**) STORAGE: /opt: /share/MD0_DATA/.qpkg/Entware
dbug: (**) USERSPACE: libc: (GNU libc) 2.21
dbug: (**) USERSPACE: libc Copyright: Copyright (C) 2015 Free Software Foundation, Inc.
dbug: (**) USERSPACE: $EUID: 0
dbug: (NA) USERSPACE: $SUDO_UID: N/A
dbug: (**) USERSPACE: BusyBox Version: BusyBox v1.24.1 (2025-12-25 02:11:02 CST) Multi-Call Binary.
dbug: (**) USERSPACE: BusyBox Copyright: BusyBox ist urheberrechtlich geschützt von vielen Autoren zwischen 1998-2015.
dbug: (**) USERSPACE: BusyBox Funktionsanzahl: 166
dbug: (**) SCRIPT: QPKG Version: 251212 (Fr 12 Dez 2025)
dbug: (**) SCRIPT: Manager Version: 251226-stable
dbug: (**) SCRIPT: Manager Epoch: 1766706808 (Fr 26 Dez 2025 1:53:28 AM EET)
dbug: (**) SCRIPT: Objects Epoch: 1766706803 (Fr 26 Dez 2025 1:53:23 AM EET)
dbug: (**) SCRIPT: Packages Epoch: 1766706667 (Fr 26 Dez 2025 1:51:07 AM EET)
dbug: (**) SCRIPT: Logs Pfad: /share/MD0_DATA/.qpkg/sherpa/log
dbug: (**) QPKG: Packages Release: v251226 (Fr 26 Dez 2025)
dbug: (NA) QPKG: Erlaube Unoffiziell: N/A
dbug: (**) QPKG: Signatur erforderlich: nein
dbug: (**) QPKG: Architektur: i64 (Intel x86-64)
dbug: (**) QPKG: Datum Entware installiert: 2025-11-30 (So 30 Nov 2025)
dbug: (**) QPKG: Entware Typ: std
dbug: (NA) QPKG: SortMyQPKGs: N/A
dbug: (NA) QPKG: IncreaseTimeouts: N/A
dbug: (II) --------------------------------------------------------------------------------------------------------
Danke!
Hallo @Vasarolli und willkommen im neuen Forum.
Du verwendest das alte „OSickGear“-QPKG. Dieses muss durch das neue „SickGear“-QPKG ersetzt werden.
Bitte sieh dir diese Diskussionsseite für weitere Details an: New QPKG names, and how-to start using them · OneCDOnly/sherpa · Discussion #321 · GitHub
Omygod, danke, habe das gar nicht bemerkt, vielleicht sollte ich hier und auf Git regelmäßig vorbeischauen… Das passiert, wenn ich nur bei Problemen versuche, Dinge zu lösen. Ein Newsletter wäre echt super
Scheint, als wäre es nicht erfolgreich gewesen, aber ich bin sicher, du weißt, was als Nächstes zu tun ist.
[~] # sherpa backup osickgear rm osickgear rebuild sickgear
sherpa v251226-stable
done: Aktionen abgeschlossen.
• Paketaktionen gestartet um 23:22:24 Uhr, beendet um 23:32:45 Uhr, Dauer = 10m:21s
• Diese Paketaktionen wurden erfolgreich abgeschlossen:
meta-rebuild SickGear QPKG in 1 Sekunde
download SickGear QPKG in 1 Sekunde
deactivate OSickGear QPKG in 1 Sekunde
backup OSickGear QPKG in 1m:54s
uninstall OSickGear QPKG in 12 Sekunden
reactivate Entware QPKG in 2 Sekunden
install SickGear QPKG in 1m:30s (v251226)
• Diese Paketaktion wurde übersprungen (und warum):
„sign“ SickGear QPKG in 1 Sekunde (bereits signiert)
• Diese Paketaktion ist fehlgeschlagen (und warum):
restore SickGear QPKG in 6m:19s (wurde 4-mal versucht zu starten, keine weiteren Versuche möglich)
[~] #
Könntest du bitte dein SickGear-Service-Log posten?
/etc/init.d/sickgear.sh log
Speziell benötige ich das Log der zuletzt ausgeführten Aktion (die sollte restore sein). Falls du die einzelnen Aktionsblöcke identifizieren kannst, poste bitte nur den letzten.
1 - keine Konfigurationsdatei, Standardvorlage wird verwendet
2 - Anwendung Auto-Update: true
3 ‹E2›‹80›‹A2›
4 - Quelle: sickgear.sh, Aktion: starten, Zeit: Mo 12. Jan 2026 23:24:57 EET, Auslastung: 5,73
5 - Paket: 251226, Dienst: 251226, Bibliothek: 251226
6 - QPKG aktiviert: true
7 - Anwendung Auto-Update: true
8 - aktiver Git-Branch:
9 - Daemon PID: keiner
10 - Datei vorhanden: /opt/bin/git
11 > 'SickGear' aus Remote-Repository erstellen: OK
12 - aktiver Git-Branch: main
13 > neue virtuelle Python-Umgebung erstellen: OK
14 > QPKG 'pip'-Konfiguration erstellen: OK
15 > Speicherort '/share/MD0_DATA/.qpkg/SickGear/pip-cache' als 'pip'-Cache hinzufügen: OK
16 > Speicherort '/share/MD0_DATA/.qpkg/SickGear/qpkg-wheels' zum 'pip'-Suchpfad hinzufügen: OK
17 > problematische PyPI-Module aus 'requirements.txt' ausschließen: OK
18 > problematische PyPI-Module aus 'recommended.txt' ausschließen: OK
19 > PyPI-Module aus 'base.txt' installieren: OK
20 > PyPI-Module aus 'requirements.txt' installieren: OK
21 > PyPI-Module aus 'recommended.txt' installieren: OK
22 > Ports aus Konfigurationsdatei laden: OK
23 > Daemon starten: OK
24 > auf Auftauchen des Daemon-Prozessnamens warten (maximal 168 Sekunden): OK
25 = Prozessname erschien in 1 Sekunde
26 > 14 Sekunden warten, um zu bestätigen, dass PID noch aktiv ist: erledigt
27 - Daemon PID: 27994
28 - Daemon hört auf Adresse: 0.0.0.0
29 - HTTPS-Port aktiviert: false
30 - HTTP-Port: 7181
31 > Test auf Antwort von Port 7181 (maximal 168 Sekunden): OK
32 = Antwort in 0 Sekunden
33 > QPKG-Icon mit UI-Ports aktualisieren: OK
34 = Quelle: sickgear.sh, Aktion: starten, Zeit: Mo 12. Jan 2026 23:26:18 EET, Ergebnis: OK, verstrichen: 0h:01m:22s, Auslastung: 5,8
34 4
35 ‹E2›‹80›‹A2›
36 - Quelle: sickgear.sh, Aktion: wiederherstellen, Zeit: Mo 12. Jan 2026 23:26:26 EET, Auslastung: 5,87
37 - Paket: 251226, Dienst: 251226, Bibliothek: 251226
38 - Daemon PID: 27994
39 > Daemon PID 27994 mit SIGTERM stoppen (maximal 168 Sekunden): OK
40 - gestoppt in 4 Sekunden
41 - Daemon PID: keiner
42 > Konfigurations-Backup wiederherstellen: OK
43 - Daemon PID: keiner
44 - Datei vorhanden: /opt/bin/git
45 > 'SickGear' aus Remote-Repository aktualisieren: OK
46 - aktiver Git-Branch: main
47 > Ports aus Konfigurationsdatei laden: OK
48 > Daemon starten: OK
49 > auf Auftauchen des Daemon-Prozessnamens warten (maximal 168 Sekunden): OK
50 = Prozessname erschien in 1 Sekunde
51 > 14 Sekunden warten, um zu bestätigen, dass PID noch aktiv ist: erledigt
52 - Daemon PID: keiner
53 w Daemon PID-Prüfung fehlgeschlagen: Es scheint einen Fehler nach dem Start gegeben zu haben
54 ~ Wiederholung 1/3
55 > Daemon starten: OK
56 > auf Auftauchen des Daemon-Prozessnamens warten (maximal 144 Sekunden): w Prozessname nicht gefunden (Zeitüberschreitung: 144 Sekunden)
57 > 10 Sekunden warten, um zu bestätigen, dass PID noch aktiv ist: erledigt
58 - Daemon PID: keiner
59 w Daemon PID-Prüfung fehlgeschlagen: Es scheint einen Fehler nach dem Start gegeben zu haben
60 ~ Wiederholung 2/3
61 > Daemon starten: OK
62 > auf Auftauchen des Daemon-Prozessnamens warten (maximal 120 Sekunden): w Prozessname nicht gefunden (Zeitüberschreitung: 120 Sekunden)
63 > 10 Sekunden warten, um zu bestätigen, dass PID noch aktiv ist: erledigt
64 - Daemon PID: keiner
65 w Daemon PID-Prüfung fehlgeschlagen: Es scheint einen Fehler nach dem Start gegeben zu haben
66 ~ Wiederholung 3/3
67 > Daemon starten: OK
68 > auf Auftauchen des Daemon-Prozessnamens warten (maximal 120 Sekunden): OK
69 = Prozessname erschien in 1 Sekunde
70 > 10 Sekunden warten, um zu bestätigen, dass PID noch aktiv ist: erledigt
71 - Daemon PID: keiner
72 w Daemon PID-Prüfung fehlgeschlagen: Es scheint einen Fehler nach dem Start gegeben zu haben
73 ! 4 Startversuche, keine weiteren Wiederholungen möglich
74 = Quelle: sickgear.sh, Aktion: wiederherstellen, Zeit: Mo 12. Jan 2026 23:32:44 EET, Ergebnis: FEHLGESCHLAGEN, verstrichen: 0h:06m:18s, Auslastung: 3,64
75 ‹E2›‹80›‹A2›
76 - Quelle: sickgear.sh, Aktion: stoppen, Zeit: Mo 12. Jan 2026 23:38:24 EET, Auslastung: 2,29
77 - Paket: 251226, Dienst: 251226, Bibliothek: 251226
78 - QPKG aktiviert: false
79 - Anwendung Auto-Update: true
80 - aktiver Git-Branch: main
81 - Daemon PID: keiner
82 = Quelle: sickgear.sh, Aktion: stoppen, Zeit: Mo 12. Jan 2026 23:38:24 EET, Ergebnis: OK, verstrichen: 142ms, Auslastung: 2,29
83 ‹E2›‹80›‹A2›
84 - Quelle: sickgear.sh, Aktion: starten, Zeit: Mo 12. Jan 2026 23:38:34 EET, Auslastung: 3,17
85 - Paket: 251226, Dienst: 251226, Bibliothek: 251226
86 - QPKG aktiviert: true
87 - Anwendung Auto-Update: true
88 - aktiver Git-Branch: main
89 - Daemon PID: keiner
90 - Datei vorhanden: /opt/bin/git
91 > 'SickGear' aus Remote-Repository aktualisieren: OK
92 - aktiver Git-Branch: main
93 > Ports aus Konfigurationsdatei laden: OK
94 > Daemon starten: OK
95 > auf Auftauchen des Daemon-Prozessnamens warten (maximal 120 Sekunden): OK
96 = Prozessname erschien in 1 Sekunde
97 > 10 Sekunden warten, um zu bestätigen, dass PID noch aktiv ist: erledigt
98 - Daemon PID: keiner
99 w Daemon PID-Prüfung fehlgeschlagen: Es scheint einen Fehler nach dem Start gegeben zu haben
100 ~ Wiederholung 1/3
101 > Daemon starten: OK
102 > auf Auftauchen des Daemon-Prozessnamens warten (maximal 132 Sekunden): w Prozessname nicht gefunden (Zeitüberschreitung: 132 Sekunden)
103 > 10 Sekunden warten, um zu bestätigen, dass PID noch aktiv ist: erledigt
104 - Daemon PID: keiner
105 w Daemon PID-Prüfung fehlgeschlagen: Es scheint einen Fehler nach dem Start gegeben zu haben
106 ~ Wiederholung 2/3
107 > Daemon starten: OK
108 > auf Auftauchen des Daemon-Prozessnamens warten (maximal 120 Sekunden): w Prozessname nicht gefunden (Zeitüberschreitung: 120 Sekunden)
109 > 18 Sekunden warten, um zu bestätigen, dass PID noch aktiv ist:
OK, beginnen wir mit einem clean:
/etc/init.d/sickgear.sh clean
… dann ein start im Debug-Modus:
/etc/init.d/sickgear.sh start debug
Wenn Sie sehen, dass die Daemon-Prüfung einmal fehlschlägt, brechen Sie mit CTRL+C ab. Bitte posten Sie anschließend, was Sie während der start-Aktion sehen.
[~] # /etc/init.d/sickgear.sh clean
- Quelle: sickgear.sh, Aktion: clean, Zeit: Mo 12 Jan 2026 23:52:54 EET, Auslastung: 8,48
- Paket: 251226, Dienst: 251226, Bibliothek: 251226
- QPKG aktiviert: true
- Anwendung Auto-Update: true
- aktiver Git-Zweig: main
- Daemon PID: keiner
> lokales Repository bereinigen: OK
> virtuelle Python-Umgebung bereinigen: OK
> PyPI-Cache bereinigen: OK
> temporären Pfad bereinigen: OK
= Quelle: sickgear.sh, Aktion: clean, Zeit: Mo 12 Jan 2026 23:52:56 EET, Ergebnis: OK, Dauer: 2,556ms, Auslastung: 8,20
Bis jetzt gut … jetzt das start mit Debug.
Meinst du das hier?
Erfolgreich installiert: orjson-3.11.5 rapidfuzz-3.14.3
} exec: abgeschlossen OK (0)
> Ports aus Konfigurationsdatei laden: OK
> Daemon starten:
{ 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)
> Warten, bis der Daemon-Prozessname erscheint (nicht mehr als 132 Sekunden): 1, OK
> 11 Sekunden warten, um zu bestätigen, dass die PID noch aktiv ist: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, fertig
- Daemon PID: keine
w Daemon PID-Prüfung fehlgeschlagen: Es scheint einen Fehler nach dem Start gegeben zu haben
~ Wiederholung 1/3
> Daemon starten:
{ 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)
> Warten, bis der Daemon-Prozessname erscheint (nicht mehr als 120 Sekunden): 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, w Prozessname nicht gefunden (Zeitüberschreitung: 120 Sekunden überschritten)
> 10 Sekunden warten, um zu bestätigen, dass die PID noch aktiv ist: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, fertig
- Daemon PID: keine
w Daemon PID-Prüfung fehlgeschlagen: Es scheint einen Fehler nach dem Start gegeben zu haben
~ Wiederholung 2/3
Versuchen wir einen manuellen Start ohne Daemon. Dadurch wird versucht, SickGear im interaktiven Modus zu starten. Bitte kopieren Sie den gesamten untenstehenden Befehl und führen Sie ihn aus:
/share/MD0_DATA/.qpkg/SickGear/venv/bin/python3 /share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py --nolaunch --datadir /share/MD0_DATA/.qpkg/SickGear/config
Früher gab es ein Limit von 3 Beiträgen, vielleicht ist es jetzt weg…
[~] # /share/MD0_DATA/.qpkg/SickGear/venv/bin/python3 /share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py --nolaunch --datadir /share/MD0_DATA/.qpkg/SickGear/config
Starte SickGear von /share/MD0_DATA/.qpkg/SickGear/config/config.ini
00:03:48 INFO TORNADO :: SickGear wird gestartet auf http://0.0.0.0:8081/
00:03:48 INFO MAIN :: Datenbankschema ist aktuell, kein Upgrade erforderlich
00:03:48 INFO MAIN :: Überprüfe Datenbankstruktur...
00:03:48 INFO MAIN :: Überprüfe Datenbankstruktur...
00:03:48 INFO MAIN :: Keine verwaisten Episoden, Überprüfung bestanden
00:03:48 INFO MAIN :: Keine UNAIRED Episoden, Überprüfung bestanden
00:03:48 ERROR MAIN :: Schwerwiegender Fehler beim Ausführen der Abfrage: Datenbank-Disk-Image ist beschädigt
Traceback (letzter Aufruf zuletzt):
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py", line 823, in <module>
SickGear().start()
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py", line 491, in start
sickgear.initialize(console_logging=self.console_logging)
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/__init__.py", line 659, in initialize
return init_stage_2()
^^^^^^^^^^^^^^
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/__init__.py", line 1565, in init_stage_2
db.sanity_check_db(my_db, mainDB.MainSanityCheck)
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/db.py", line 420, in sanity_check_db
sanity_check(connection).check()
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/databases/mainDB.py", line 43, in check
self.fix_scene_exceptions()
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/databases/mainDB.py", line 257, in fix_scene_exceptions
sql_result = self.connection.select(
^^^^^^^^^^^^^^^^^^^^^^^
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/db.py", line 296, in select
sql_results = self.action(query, args).fetchall()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/db.py", line 276, in action
sql_result = self.connection.execute(query)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sqlite3.DatabaseError: Datenbank-Disk-Image ist beschädigt
00:03:48 INFO MAIN :: SickGear.Start() Ausnahme abgefangen Datenbank-Disk-Image ist beschädigt: Traceback (letzter Aufruf zuletzt):
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py", line 823, in <module>
SickGear().start()
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py", line 491, in start
sickgear.initialize(console_logging=self.console_logging)
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/__init__.py", line 659, in initialize
return init_stage_2()
^^^^^^^^^^^^^^
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/__init__.py", line 1565, in init_stage_2
db.sanity_check_db(my_db, mainDB.MainSanityCheck)
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/db.py", line 420, in sanity_check_db
sanity_check(connection).check()
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/databases/mainDB.py", line 43, in check
self.fix_scene_exceptions()
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/databases/mainDB.py", line 257, in fix_scene_exceptions
sql_result = self.connection.select(
^^^^^^^^^^^^^^^^^^^^^^^
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/db.py", line 296, in select
sql_results = self.action(query, args).fetchall()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/db.py", line 276, in action
sql_result = self.connection.execute(query)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sqlite3.DatabaseError: Datenbank-Disk-Image ist beschädigt
Verdammt, es sieht so aus, als würde die ursprüngliche SickGear-Datenbank aus deiner alten Installation nicht akzeptiert werden. 
Ich vermute, du musst deine TV-Serien-Datenbank neu aufbauen. Das bedeutet, die aktuelle Datenbank zu löschen und SickGear mit einer frischen Konfiguration zu starten. Anschließend lässt du SickGear deine vorhandenen TV-Serien erneut scannen.
Lass uns SickGear mit einer sauberen Konfiguration starten und sicherstellen, dass es korrekt lädt:
/etc/init.d/sickgear.sh reset-config
… und dann start im Debug-Modus erneut ausführen:
/etc/init.d/sickgear.sh start debug