[QPKG] sherpa: ein Mini-Paketmanager (CLI)

OneCD · 24. April 2025 um 17:53

sherpa: ein Mini-Paketmanager für QNAP NAS

Der weltweit erste Multi-Action-CLI-Paketmanager!

Das Paketmanagement mit sherpa bietet Funktionen wie einfache Anwendungs-Backups, Upgrades, Service- und Daemon-Verwaltung, Multi-Thread-Betrieb, Selbstprüfung und Reparatur; alle Vorgänge können über Cron automatisiert werden.

Wichtig: Dies ist ein Kommandozeilen-Paket- und Dienstmanager, befindet sich im Beta-Status und Pakete können durch fehlerhafte Auto-Upgrades kaputtgehen. Wenn du helfen möchtest (und kannst), indem du Diagnosen stellst und Logs bereitstellst, und es dich nicht stört, wenn gelegentlich etwas kaputtgeht, dann nutze dieses Paket gerne. Wenn du vollständige Stabilität suchst und eine „set-and-forget“-Lösung willst, bist du hier noch nicht richtig. Bitte nicht sherpa in Produktionsumgebungen verwenden, außer du bist mit der CLI und dem Debuggen von Bash- und Python-Skripten vertraut und/oder kannst es dir leisten, dass Anwendungen für längere Zeit nicht funktionieren.

Das gesagt: Der Großteil der Entwicklung ist nun abgeschlossen, und ich arbeite derzeit daran, die Stabilität bei Auto-Paket-Upgrades zu erhöhen. sherpa funktioniert wunderbar auf einem frischen (oder neuen) System, kann aber Probleme haben, wenn einzelne Anwendungsupdates veröffentlicht werden.

Hier klicken für installierbare Pakete

Installation

SSH auf dein NAS und installiere das QPKG manuell am Kommandozeilen-Prompt:
curl -skL https://tinyurl.com/get-sherpa > /share/Public/sherpa.qpkg; sudo sh /share/Public/sherpa.qpkg;

Verwendung

Am Kommandozeilen-Prompt ausführen:
sudo sherpa
… und folge dann der Hilfe.

Falls ‘sudo’ in deiner QTS-Version nicht verfügbar ist, SSH dich stattdessen als ‘admin’-Benutzer auf dein NAS und führe aus:
sherpa

Wenn du Vorschläge, Ratschläge, Kommentare oder Bedenken hast, erstelle bitte entweder ein neues Issue, oder du bist herzlich eingeladen, ein neues Diskussionsthema zu starten.

Dieses Projekt ist eine Gemeinschaftsarbeit und wurde mit kombiniertem Feedback vieler Mitglieder des QNAP Community-Forums erstellt. Vielen Dank an alle, die beigetragen haben.

Weitere Informationen findest du im Wiki: https://github.com/OneCDOnly/sherpa/wiki

OneCD · 28. Juni 2025 um 20:19

Leider gibt es schlechte Nachrichten für Readarr-Nutzer: Die Entwickler haben die Arbeit daran eingestellt und der aktuelle Fork (verwendet von sherpa) wurde archiviert: https://www.reddit.com/r/Readarr/comments/1llqji9/announcement_retirement_of_readarr

Falls jemand einen gepflegten Fork kennt, bitte Bescheid geben – dann werde ich das Readarr QPKG darauf umstellen. Falls nicht, bleibt das Readarr QPKG weiterhin verfügbar, wird aber nicht mehr aktualisiert.

OneCD · 21. August 2025 um 22:40

Mehr schlechte Nachrichten: Die Entwickler von TorrServer kompilieren ihre Binärdateien jetzt so, dass sie libc 2.34 benötigen, welche für QTS nicht verfügbar ist.

Das bedeutet, dass das TorrServer-Paket derzeit nicht ausgeführt werden kann. Bestehende TorrServer-Nutzer werden feststellen, dass ihre Installation nach dem nächsten Update von TorrServer nicht mehr funktioniert, und TorrServer wird mit dem nächsten stabilen QPKG-Release aus der sherpa-Unterstützung entfernt.

Es gibt eine ältere Version im myQNAP-Repository: https://www.myqnap.org/product/torrserver/, falls Sie diese Anwendung weiterhin nutzen möchten.

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 TorrServer sollte manuell über das QTS App Center deinstalliert werden.

Shadytree · 18. September 2025 um 08:13

Hallo OneCD, ich hoffe, es geht dir gut?

Nach dem neuesten Sherpa-Update erhalte ich folgenden Fehler bei SickGear.

Fehler
OverflowError('date value out of range')

Traceback
Traceback (letzter Aufruf zuletzt):
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/lib/tornado/web.py", Zeile 1848, in _execute result = await result ^^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/lib/tornado/gen.py", Zeile 796, in run yielded = self.gen.throw(exc) ^^^^^^^^^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/sickgear/webserve.py", Zeile 1044, in get yield self.route_method(route, use_404=True)
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/lib/tornado/gen.py", Zeile 783, in run value = future.result() ^^^^^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/lib/tornado/gen.py", Zeile 796, in run yielded = self.gen.throw(exc) ^^^^^^^^^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/sickgear/webserve.py", Zeile 350, in route_method result = yield self.async_call(method, filter_kwargs) # method(**filter_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/lib/tornado/gen.py", Zeile 783, in run value = future.result() ^^^^^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/lib/sg_futures/py3.py", Zeile 40, in run result = self.fn(*self.args, **self.kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/sickgear/webserve.py", Zeile 359, in async_call raise e
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/sickgear/webserve.py", Zeile 357, in async_call return function(**kw) ^^^^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/sickgear/webserve.py", Zeile 1148, in view_shows return Home(self.application, self.request).view_shows() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/sickgear/webserve.py", Zeile 1758, in view_shows return t.respond() ^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/config/cache/cheetah/_share_CACHEDEV1_DATA__qpkg_OSickGear_repo_cache_gui_slick_interfaces_default_home_tmpl.py", Zeile 441, in respond data_lastdate = VFN(VFN(VFFSL(SL,"SGDatetime",True),"convert_to_setting",False)(VFN(VFFSL(SL,"network_timezones",True),"parse_date_time",False)(VFFSL(SL,"cur_airs_last",True), VFFSL(SL,"cur_show_obj.airs",True), VFFSL(SL,"cur_show_obj.network",True))),"strftime",False)('%Y%m%d%H%M') ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/lib/dateutil/tz/tz.py", Zeile 231, in dst if self._isdst(dt): ^^^^^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/lib/dateutil/tz/tz.py", Zeile 294, in _isdst if self.is_ambiguous(dt): ^^^^^^^^^^^^^^^^^^^^^
Datei "/share/CACHEDEV1_DATA/.qpkg/OSickGear/repo-cache/lib/dateutil/tz/tz.py", Zeile 256, in is_ambiguous (naive_dst != self._naive_is_dst(dt - self._dst_saved))) ~~~^~~~~~~~~~~~~~~~~
OverflowError: date value out of range

Request Info
Methode: GET
URI: /view-shows/
Version: HTTP/1.1
Header:
Body: b''
remote_ip: xxxxxxxxxxxxxxx
Protokoll: http
Host: xxxxxxxxxxxxxxxxxxx
host_name: xxxxxxxxxxxxxxxxxxx
files: {}
connection:
server_connection:
_start_time: 1758182428.793617
_finish_time: None
Pfad: /view-shows/
Query:
arguments: {}
query_arguments: {}
body_arguments: {}
_cookies:

Ich habe bereits einen Neustart und eine Neuinstallation versucht, bekomme aber denselben Fehler. Hast du eine Idee, woran es liegen könnte?

OneCD · 18. September 2025 um 08:14

Hallo Shady, und willkommen im neuen Forum.

Kannst du bitte damit beginnen, eine check-Aktion auszuführen?

sherpa check

Shadytree · 18. September 2025 um 09:35

sherpa check
sherpa v250822-stable
fertig: Aktionen abgeschlossen.

• Paketaktionen gestartet um 10:20:15 Uhr, beendet um 10:20:41 Uhr, verstrichene Zeit = 26 Sekunden

• Diese Paketaktionen wurden erfolgreich abgeschlossen:
Hilfs-PIP in 3 Sekunden installiert
nzbToMedia QPKG in 1 Sekunde reaktiviert
OSickGear QPKG in 16 Sekunden reaktiviert
SABnzbd QPKG in 17 Sekunden reaktiviert

• Diese Paketaktionen wurden übersprungen (und warum):
„sign“ Entware QPKG in 1 Sekunde (bereits signiert)
„sign“ Par2 QPKG in 1 Sekunde (NAS-Architektur nicht kompatibel)
„sign“ Par2turbo QPKG in 1 Sekunde (bereits signiert)
„sign“ sherpa QPKG in 1 Sekunde (bereits signiert)
„sign“ SortMyQPKGs QPKG in 1 Sekunde (QTS-Version nicht kompatibel)
„sign“ Unrar QPKG in 1 Sekunde (bereits signiert)
„sign“ nzbToMedia QPKG in 1 Sekunde (bereits signiert)
„sign“ SABnzbd QPKG in 1 Sekunde (bereits signiert)
„sign“ OSickGear QPKG in 1 Sekunde (bereits signiert)
ClamAV QPKG in 1 Sekunde reaktivieren (nicht installiert)

OneCD · 18. September 2025 um 09:37

Sieht bisher gut aus.

Als Nächstes: Bitte führe eine clean-Aktion auf SickGear aus:

/etc/init.d/sickgear.sh clean

… und versuche dann, es zu starten:

/etc/init.d/sickgear.sh start debug

Shadytree · 18. September 2025 um 10:07

[~] # /etc/init.d/sickgear.sh clean
> Quelle: sickgear.sh, Aktion: clean, Zeit: Do 18 Sep 2025 10:56:11 AM BST, Last: 0.20 
- Paket: 250822, Dienst: 250822, Bibliothek: 250822
> QPKG aktiviert: true
> Anwendung Auto-Update: true
- Aktiver Git-Branch: main
- Daemon PID: 11350
> Stoppe Daemon PID 11350 mit SIGTERM (nicht länger als 120 Sekunden): 1, 2, OK
- Daemon PID: none
> Lokales Repository bereinigen: OK
> Virtuelle Python-Umgebung bereinigen: OK
> PyPI-Cache bereinigen: OK
> Temp-Pfad bereinigen: OK
- Datei existiert: /opt/bin/git
> Erstelle 'OSickGear' aus entferntem Repository: OK
- Aktiver Git-Branch: main
> Neue virtuelle Python-Umgebung erstellen: OK
> QPKG 'pip'-Konfiguration erstellen: OK
> Speicherort '/share/CACHEDEV1_DATA/.qpkg/OSickGear/pip-cache' als 'pip'-Cache hinzufügen: OK
> Speicherort '/share/CACHEDEV1_DATA/.qpkg/OSickGear/qpkg-wheels' zum 'pip'-Suchpfad hinzufügen: OK
> Problematische PyPI-Module aus pip-requirements.txt ausschließen: OK
> Problematische PyPI-Module aus pip-recommended.txt ausschließen: OK
> PyPI-Module aus pip-requirements.txt installieren: OK
> PyPI-Module aus pip-recommended.txt installieren: OK
> Ports aus Konfigurationsdatei laden: OK
> Daemon starten: OK
> Warte auf das Auftauchen des Daemon-Prozessnamens (nicht länger als 120 Sekunden): 1, OK
> Warte 10 Sekunden, um zu bestätigen, dass PID noch lebt: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, fertig
- Daemon PID: 8916
- Daemon hört auf Adresse: 0.0.0.0
> HTTPS-Port aktiviert: false
- HTTP-Port: 7181
> Teste Antwort auf Port 7181 (nicht länger als 120 Sekunden): OK
> QPKG-Icon mit UI-Ports aktualisieren: OK
= Quelle: sickgear.sh, Aktion: clean, Zeit: Do 18 Sep 2025 10:56:36 AM BST, Ergebnis: OK, Dauer: 0h:00m:26s, Last: 0.45 
[~] # /etc/init.d/sickgear.sh start debug
> Quelle: sickgear.sh, Aktion: start, Zeit: Do 18 Sep 2025 10:56:56 AM BST, Last: 0.32 
- Paket: 250822, Dienst: 250822, Bibliothek: 250822
> QPKG aktiviert: true
> Anwendung Auto-Update: true
- Aktiver Git-Branch: main
- Daemon PID: 8916
= Quelle: sickgear.sh, Aktion: start, Zeit: Do 18 Sep 2025 10:56:56 AM BST, Ergebnis: OK, Dauer: 23ms, Last: 0.32

Erledigt. Der Fehler wird weiterhin angezeigt.

OneCD · 18. September 2025 um 10:08

Clean sieht gut aus, und der Start auch (tatsächlich scheint der SickGear-Daemon bereits zu laufen).

Wo siehst du diesen Fehler?

Shadytree · 18. September 2025 um 10:41

http://xxxxxxxxxxxxx:7181/view-shows

Ich kann mich problemlos einloggen, aber beim Aufrufen der Show-Seite tritt ein Fehler auf.

OneCD · 18. September 2025 um 10:45

Haben Sie Ihre Webseite im Browser mit STRG-F5 hart aktualisiert?

Shadytree · 18. September 2025 um 14:40

Ja, immer noch kein Erfolg

OneCD · 18. September 2025 um 20:13

Hmm, ich frage mich, ob ein ungültiger Wert in die SickGear-Datenbank geschrieben wurde?

Zu Testzwecken versuchen wir, SickGear mit einer frischen Datenbank zu starten. Wir sichern zuerst deine bestehende Datenbank und stellen sie danach wieder her. Das ist keine Lösung – nur ein Test.

Um deine aktuellen Datenbankdateien zu sichern:

/etc/init.d/sickgear.sh backup

… dann setze die SickGear-Konfiguration auf die Standardwerte zurück:

/etc/init.d/sickgear.sh reset-config

Versuche nun erneut, auf deine SickGear-Webseite zuzugreifen. Deine TV-Serienliste wird leer sein. Werden irgendwelche Fehler angezeigt?

Nachdem du das ausprobiert hast, stelle deine SickGear-Datenbankdateien wieder her mit:

/etc/init.d/sickgear.sh restore

SickGear wird automatisch gestoppt und gestartet, wie erforderlich. Es ist diesmal nicht nötig, irgendwelche Ausgaben zu posten.

Shadytree · 19. September 2025 um 08:58

Habe ich ausprobiert, Kumpel, aber leider ohne Erfolg. Immer noch die gleiche Fehlermeldung.

OneCD · 19. September 2025 um 21:56

Um das zu bestätigen: Du hast versucht, auf die SickGear-Webseite zuzugreifen, nachdem du deine Konfiguration zurückgesetzt und bevor du sie wiederhergestellt hast? Und denselben Fehler gesehen?

Dieses Problem benötigt möglicherweise die Unterstützung der SickGear-Entwickler: [How to] Report Issues · SickGear/SickGear Wiki · GitHub

Es gibt auch ein „offizielles“ SickGear-Paket, das einen Versuch wert sein könnte: Install SickGear 05 QNAP · SickGear/SickGear Wiki · GitHub

Shadytree · 20. September 2025 um 12:03

Ok, ich habe geschummelt. Ich habe Claude benutzt, um den Fehler zu entschlüsseln

SickGear Date Overflow Error – Problembeschreibung & Lösung

Das Problem:

SickGear warf einen OverflowError('date value out of range'), wenn versucht wurde, die view-shows-Seite zu laden. Der Fehler trat während der Zeitzonenberechnung bei der Verarbeitung von Sendedaten auf.

Ursache:

Die SickGear-Datenbank enthielt Zeitstempel aus dem Jahr 1970 (etwa 9. Januar 1970) anstelle von aktuellen Daten:

Shows: last_update_indexer-Werte um 739435 (entspricht 1970-01-09)
Episoden: airdate-Werte zwischen 738153-738181 (ebenfalls aus 1970)

Diese extrem alten Daten führten dazu, dass Pythons dateutil-Zeitzonenfunktionen bei der Verarbeitung von Sommerzeitumstellungen und Zeitzonenkonvertierungen scheiterten.

Die Lösung:

Zwei SQL-UPDATE-Befehle, um die problematischen Zeitstempel zu korrigieren:

sql

-- Show-Update-Zeitstempel korrigieren (auf aktuelle Zeit setzen)
UPDATE tv_shows SET last_update_indexer = strftime('%s', 'now') WHERE last_update_indexer < 946684800;

-- Episoden-Sendedaten korrigieren (auf NULL/unbekannt setzen)
UPDATE tv_episodes SET airdate = NULL WHERE airdate > 0 AND airdate < 946684800;

Schritte zur Behebung:

SickGear-Dienst gestoppt (PID 31531)
Datenbank gesichert (sickbeard.db)
Die SQL-Korrekturen angewendet, um problematische Daten zu aktualisieren
SickGear neu gestartet mit /share/CACHEDEV1_DATA/.qpkg/OSickGear/sickgear.sh start

Diese Lösung behebt den Overflow-Fehler, indem sichergestellt wird, dass alle Datenbankeinträge im gültigen Bereich für moderne Zeitzonenberechnungen liegen, sodass die SickGear-Weboberfläche wieder ordnungsgemäß funktioniert.

OneCD · 20. September 2025 um 14:02

Oh, schön!

Und hat das das Problem tatsächlich behoben?

Shadytree · 20. September 2025 um 15:30

Ja, funktioniert super. Als jemand ohne Programmierkenntnisse finde ich es wirklich beeindruckend, dass Claude das Problem finden, den Code schreiben und mir erklären kann, wie ich es behebe.

OneCD · 20. September 2025 um 15:36

Erstaunlich!

Trotzdem wäre es sinnvoll, die Entwickler über dieses Problem und die Lösung zu informieren. Das könnte helfen, ein erneutes Auftreten zu verhindern.

HuskerDu · 30. September 2025 um 11:45

Hi, was ist das für ein Fehler?!

[~] # sherpa check
sherpa v250927-stable
done: Aktionen abgeschlossen.

• Paketaktionen gestartet um 14:15:17, beendet um 14:15:24, verstrichene Zeit = 7 Sekunden

• Diese Paketaktionen wurden übersprungen (und warum):
    „signieren“ Entware QPKG in 1 Sekunde (bereits signiert)
    „signieren“ Par2turbo QPKG in 1 Sekunde (bereits signiert)
    „signieren“ sherpa QPKG in 1 Sekunde (bereits signiert)
    „signieren“ OTransmission QPKG in 1 Sekunde (bereits signiert)

• Diese Paketaktion ist fehlgeschlagen (und warum):
    Reaktivieren von OTransmission QPKG in 2 Sekunden (1)