Weboberfläche für Go-Upper

Die Go-Upper UI ist die eigenständige Weboberfläche für upper. Sie startet und überwacht Upper-Instanzen, liest deren Resultate ein, bearbeitet Upload-Daten, verwaltet Templates und Mappings und kann konfigurierte Publishing-Ziele aus einer Warteschlange bedienen.

Die UI ersetzt die upper.config.yml nicht. Jede verwaltete Upper-Instanz benötigt weiterhin eine funktionierende Konfiguration, Pfade, Hoster und gegebenenfalls Zugangsdaten.

Inhalt

1. Installation und Verzeichnisstruktur
2. Start und Zugriff
3. Erste Einrichtung im Dashboard
4. Config und Logs
5. Offene Uploads und Upload-Import
6. Upload bearbeiten, Cover und Auto Complete
7. Templates, Presets, Mappings und Integrationen
8. NFO Suche
9. Remote Sources
10. Publishing über die UI
11. KI Modelle
12. System, Datenbank und Wartung
13. Update und Sicherung
14. Sicherheit und Fehlerbehebung
15. Screenshots im Überblick

Download

Lade die aktuelle Version der Go-Upper UI hier herunter:

Go-Upper UI herunterladen (Latest)

1. Installation und Verzeichnisstruktur

Voraussetzungen

Für den produktiven Betrieb benötigst du:

• eine passende upper-Binary, zum Beispiel upper-linux oder upper-win.exe,
• die separate UI-Binary upper-ui-linux oder upper-ui-win.exe,
• eine gültige config/upper.config.yml,
• Schreibrechte für upper-ui/database/, upper-ui/log/ und die in der Upper-Config gesetzten Arbeits- und Ergebnisordner,
• mindestens einen erreichbaren Ergebnisordner mit JSON-Ausgabe, wenn die Upload-Verwaltung genutzt werden soll.

Empfohlenes Layout

Lege Go-Upper und die Web-UI in einem gemeinsamen Hauptverzeichnis ab. Das Release-Paket verwendet für die UI den Unterordner upper-ui/.

go-upper/
  upper-linux                       # Linux: Upper-Binary
  upper-win.exe                     # Windows: alternativ zur Linux-Binary
  upper-ui/
    run-upper-ui.bat                 # Windows: per Doppelklick starten
    upper-ui-linux                  # Linux: Web-UI-Binary
    upper-ui-win.exe                # Windows: alternativ zur Linux-Binary
    database/
      upper-ui.db                   # wird beim ersten UI-Start angelegt
    log/
      upper-instance-<ID>.log       # Logs von Hintergrundstarts
  config/
    upper.config.yml                # aktive Upper-Konfiguration
    upper.config.dist.yml           # Vorlage
    remote.sources.yml              # optional: FTP/FTPS/SFTP-Quellen
    templates/                      # optionale Template-Dateien
    mappings/                       # optionale Publish-Mappings
  database/
    remote-sources.db               # wird bei Remote Sources verwendet
  files/                            # Standard-Workdir, falls nicht anders konfiguriert
  log/                              # Upper- und UI-Instanzlogs
  result/                           # Standard-Resultordner, falls nicht anders konfiguriert

Wichtig: Starte die UI immer auf demselben Weg aus ihrem Ordner upper-ui/. Beim ersten Start legt sie upper-ui/database/upper-ui.db relativ zum Arbeitsverzeichnis an, sofern keine bestehende Datenbank neben der UI-Binary gefunden wird. Ein Start aus wechselnden Ordnern kann deshalb eine zweite, leere UI-Datenbank erzeugen.

Upper-Konfiguration vorbereiten

Für Dashboard, Upload-Import und Bearbeitung sind insbesondere diese Werte relevant:

result:
  json:
    enabled: true

path:
  scan:
    - '/data/upper/incoming/'
  work: '/data/upper/work/'
  result: '/data/upper/result/'

Unter Windows verwendest du entsprechend Windows-Pfade:

path:
  scan:
    - 'D:\Uploads\incoming\'
  work: 'D:\Uploads\work\'
  result: 'D:\Uploads\result\'

result.json.enabled: true ist wichtig: Die Uploads-Seite importiert die von Upper erzeugten JSON-Ergebnisse in die UI-Datenbank.

2. Start und Zugriff

Linux

Wechsle in den UI-Unterordner und starte die UI-Binary:

cd /opt/go-upper/upper-ui
./upper-ui-linux

Windows

Unter Windows öffnest du im entpackten Go-Upper-Paket den Ordner upper-ui und startest per Doppelklick:

run-upper-ui.bat

Die Batchdatei startet die passende upper-ui-win.exe; ein Terminalbefehl ist für den normalen Windows-Start nicht erforderlich.

Adresse im Browser

Standardmäßig lauscht die UI nur lokal unter:

http://127.0.0.1:3001

Falls Port 3001 bereits belegt ist, kannst du die Adresse über UPPER_UI_ADDR ändern.

Linux:

UPPER_UI_ADDR=127.0.0.1:3002 ./upper-ui-linux

Windows PowerShell:

cd C:\go-upper\upper-ui
$env:UPPER_UI_ADDR = '127.0.0.1:3002'
.\run-upper-ui.bat

Die UI legt beim Start die SQLite-Datenbank an, aktualisiert ihr Schema und importiert lesbare Config-Templates in die Template-Verwaltung.

3. Erste Einrichtung im Dashboard

Nach dem Öffnen landest du im Dashboard. Dort siehst du:

• Anzahl und Status der konfigurierten Upper-Instanzen,
• aggregierte Upload-Zahlen aus Resultaten,
• offene Imports,
• Lizenzstatus der geladenen Config,
• Diagramme zu Uploads und Hostern.

Erste Upper-Instanz hinzufügen

1. Klicke auf Upper Instanz hinzufügen.
2. Trage den vollständigen Pfad zur eigentlichen upper-Binary ein.
3. Vergib einen lesbaren Namen, zum Beispiel Upper Main.
4. Speichere die Instanz.

Beispiele für den Binary-Pfad:

/opt/go-upper/upper-linux
C:\go-upper\upper-win.exe

Die UI sucht die Config einer Instanz relativ zum Ordner ihrer Binary. Das empfohlene Layout mit upper-linux beziehungsweise upper-win.exe direkt neben config/ stellt sicher, dass die richtige config/upper.config.yml gefunden wird.

Instanz starten und stoppen

Der Instanzbereich steht direkt oben im Dashboard vor den Kennzahlen und Diagrammen.

Pro Instanz stehen diese Aktionen zur Verfügung:

• Starten (Web) öffnet ein Browser-Terminal und startet Upper interaktiv.
• Starten (CMD) startet Upper unter Windows über eine sichtbare CMD-Konsole und übernimmt den Debug-Schalter.
• Starten (im Hintergrund) startet Upper ohne Terminal und schreibt die Prozessausgabe in ein Instanzlog.
• Stoppen beendet eine laufende Instanz.
• Bearbeiten ändert den Namen und den Binary-Pfad einer gestoppten Instanz.
• Debug ergänzt beim nächsten Hintergrundstart --debug=true.
• Config und Logs öffnen die instanzbezogenen Detailseiten.
• Die Spalte Version zeigt die aus der Binary gelesene Go-Upper-Version. Die UI prüft die aktuelle Release automatisch: Ist eine neuere Version verfügbar, wird der Button direkt dahinter farbig als Update <Zielversion> hervorgehoben. Ein Häkchen kennzeichnet aktuelle Instanzen; unbekannte Versionen und ein nicht erreichbarer Update-Server erhalten neutrale Symbole. Der Button öffnet den Update-Dialog (wie beim UI-Update: Versionen, Release-Text, Force). Das Update lädt die aktuelle Go-Upper-Release von https://go-toolz.com/dl/upper/ und überschreibt Binaries, Tools, Templates, Mappings sowie *.dist.yml. Deine upper.config.yml, remote.sources.yml, Arbeitsdaten und die UI bleiben unangetastet. Laufende Instanzen sehen den Update-Hinweis ebenfalls, müssen für die Installation aber zuerst gestoppt werden.

UI-Starts übergeben automatisch --disable-licence-prompt=1, damit ein Lizenzablaufhinweis keinen unbeaufsichtigten Prozess blockiert.

4. Config und Logs

Config-Seite

Über das Config-Symbol einer Instanz öffnest du deren upper.config.yml. Die Seite zeigt:

• geladene Config-Datei und Lizenzstatus,
• Workmode, Intervalle und Linkcrypter,
• aktive und inaktive Module,
• wichtige Boolean-Optionen,
• geprüfte Pfade mit Status und Dateizahlen.

Mit Config .dist ansehen öffnest du die mitgelieferte Vorlage upper.config.dist.yml nur zum Lesen (YAML-Highlighting, kein Speichern). So kannst du Standardwerte und neue Optionen mit deiner aktiven Config vergleichen.

Mit Config bearbeiten öffnest du den YAML-Editor für deine aktive upper.config.yml. Beim Speichern wird geprüft, ob der Inhalt gültiges YAML ist; anschließend wird die Datei atomar ersetzt.

Speichere Zugangsdaten nur in deiner lokalen upper.config.yml. Veröffentliche weder diese Datei noch Screenshots, auf denen API-Keys, Passwörter oder Tokens sichtbar sind.

Logs-Seite

Die Logs-Seite zeigt Log-Ausschnitte für die gewählte Instanz. Bei einem Hintergrundstart schreibt die UI außerdem nach:

upper-ui/log/upper-instance-<ID>.log

Ein Start über das Browser-Terminal zeigt die Ausgabe direkt in der Terminalansicht. Terminals bleiben beim Wechsel zwischen UI-Seiten erhalten und können minimiert oder wieder geöffnet werden.

5. Offene Uploads und Upload-Import

Offene Uploads

Die Seite Offene Uploads liest die path.scan-Ordner aller eingetragenen Instanzen. Sie zeigt noch nicht abgeschlossene Kandidaten und berücksichtigt Config-Regeln wie Filter, skip.incomplete, Modified-After und Folder-Ready-Prüfungen.

Mit Go-Upper starten und abarbeiten öffnet die Seite für jede bereite hinterlegte Instanz ein Browser-Terminal und startet Upper genauso wie die Dashboard-Aktion Starten (Web). Bereits laufende Instanzen werden nicht doppelt gestartet.

Mögliche Status sind unter anderem:

• bereit: kann beim nächsten Upper-Lauf verarbeitet werden,
• in Arbeit: im Resultordner liegt eine passende *.progress.json,
• wartet oder gefiltert: eine Config-Regel verhindert aktuell die Verarbeitung.

Für einen hängen gebliebenen Eintrag mit Status in Arbeit gibt es Reset. Stoppe zuvor die zugehörige Upper-Instanz. Der Reset entfernt die Progress-Datei und, falls eindeutig zuordenbar, kopierte Arbeitsordner.

Die Spalte NFO zeigt für jeden Release-Ordner Vorhanden, sobald direkt im Ordner eine Datei mit der Endung .nfo liegt. Fehlt sie, startet Suchen eine parallele Suche über SRRDB, PreDB und xREL. Die UI speichert nur einen exakten Treffer zum Ordnernamen und legt ihn als <Release-Name>.nfo direkt im Release-Ordner ab. Bereits vorhandene NFO-Dateien werden nicht überschrieben.

Uploads importieren

Die Seite Uploads liest Result-JSON-Dateien aus den Resultordnern der konfigurierten Instanzen ein:

• Autoimport läuft alle 10 Sekunden,
• der Button Import startet den Import sofort,
• Alles als erledigt markieren setzt alle noch nicht erledigten importierten Uploads auf den grünen Veröffentlichungsstatus,
• pro Resultdatei werden Roh-JSON, Quelle, Hoster, Links und Status in upper-ui/database/upper-ui.db gespeichert,
• bereits importierte Einträge bleiben in der Datenbank, auch wenn die ursprüngliche JSON-Datei später fehlt.

Die Liste zeigt importierte Uploads aus der UI-Datenbank (noch nicht importierte Result-JSON erscheinen erst nach Import). Sie unterstützt Suche, Filter nach Typ, Hoster, Instanz und Publishing-Status (Alles, Unveröffentlicht, Ziel gewählt, Warteschlange, Fehler, Veröffentlicht), Sortierung und Pagination. Filter und Sortierung greifen serverseitig in der Datenbank; pro Seite werden nur die sichtbaren Zeilen geladen. Sobald die Tabelle tatsächlich horizontal überlaufen würde, werden zuerst Importiert, danach Crypter, Hoster und zuletzt Größe ausgeblendet. Die Optionsspalte bleibt dabei am rechten Tabellenrand sichtbar. Die Suche und Filter bleiben im Browser und in der URL gespeichert, bis du sie mit Clear zurücksetzt. Der blaue Button Veröffentlichen (alle mit Ziel) legt alle datenbankweit im Status Ziel gewählt stehenden Uploads ohne vorherige Auswahl in die Publishing-Warteschlange und ist deaktiviert, solange kein passender Upload vorhanden ist. Markierte Uploads können weiterhin per Hauptbutton einzeln vorgemerkt werden; weitere Massenaktionen wie Aus Warteschlange entfernen, als Veröffentlicht markieren und auf Unveröffentlicht zurücksetzen liegen im Drei-Punkte-Menü. Das Zurücksetzen entfernt die gespeicherten Publishing-Ziele, damit der Listenstatus tatsächlich wieder Unveröffentlicht lautet. Dieselbe Aktion steht im Drei-Punkte-Menü jeder Upload-Zeile bereit. Über die Zeilenaktionen kannst du außerdem die gespeicherte Original-JSON ansehen, bearbeiten, herunterladen oder den UI-Datensatz dauerhaft inklusive Publishing-Zielen und History löschen.

Movie-, TV- und Game-Auto-Publish

Die getrennten Schalter Movie Auto-Publish, TV Auto-Publish und Game Auto-Publish auf der Uploads-Seite gelten für neu importierte und danach bearbeitete Einträge des jeweiligen Typs. Beim Einschalten werden vorhandene Uploads bewusst nicht rueckwirkend veröffentlicht. Für jede betroffene Upper-Instanz muss unter Einstellungen > Presets ein passendes Movie-, TV- beziehungsweise Game-Preset als Auto für diesen Typ gespeichert sein.

Movies benötigen Release-Name, Filmtitel, Erscheinungsjahr, Plot, Genre, eine gültige HTTP(S)-Cover-URL, IMDb- oder TMDB-ID, Größe sowie mindestens einen Download- oder Crypter-Link. Serien benötigen dieselben abgesicherten Metadaten mit Serientitel und einem TV-Preset. Games benötigen Release-Name, Spieletitel, Steam-ID, Beschreibung, Genre, eine gültige Cover-URL, Entwickler, Publisher, Erscheinungsdatum, mindestens eine Sprachangabe, Größe und einen Download- oder Crypter-Link. Außerdem müssen alle Preset-Ziele aktiv und konfiguriert sein; benötigte Templates müssen aufgelöst werden können. Fehlt etwas, bleibt der Upload unveröffentlicht und zeigt in der Spalte Veröffentlicht den konkreten Blockierungsgrund. Nach einer Korrektur im Upload-Editor oder JSON-Editor wird die Prüfung erneut ausgeführt.

Unmittelbar vor dem externen Publishing validiert der Worker dieselben typspezifischen Daten noch einmal. Beim Ausschalten werden nur die automatisch vorgemerkten Ziele des jeweiligen Typs, deren Verarbeitung noch nicht begonnen hat, aus der Warteschlange entfernt. Die anderen Auto-Modi und manuell vorgemerkte Uploads bleiben davon unberührt.

6. Upload bearbeiten, Cover und Auto Complete

Klicke in der Upload-Liste auf einen importierten Upload. Die Bearbeitungsseite besteht aus den Tabs Item, Publishing und History Log.

Item-Daten bearbeiten

Im Tab Item bearbeitest du direkt die gespeicherte Upload-JSON:

• Release-Name, Inhaltstyp, Titel, Jahr, Größe, Genre und Beschreibung,
• Movie-Daten wie IMDB, TMDB und Trailer,
• Game-Daten aus Steam,
• NFO-Pfad und NFO-Inhalt,
• direkte Mirror-Links und Crypter-Links.

Auto Complete

Wenn die zugehörigen Module in contentgrabber aktiviert sind, kannst du Daten erneut abfragen:

• xREL,
• PreDB,
• TMDB,
• IMDB,
• Steam,
• YouTube,
• NFO beziehungsweise SRRDB-Fallback.

Mehrere oder abweichende Treffer werden als Vorschläge angezeigt, bevor du sie übernimmst.
PreDB ergänzt exakte Scene-Release-Daten und schlägt anhand der Section außerdem einen passenden Upper-Inhaltstyp vor.

Cover hochladen

Im Cover-Bereich kannst du eine Cover-URL eintragen und auf den in contentgrabber.imageHoster konfigurierten Imagehoster laden. Die neue gehostete URL wird direkt in der gespeicherten Upload-JSON aktualisiert.

Voraussetzung ist ein eingerichteter Imagehoster, zum Beispiel:

contentgrabber:
  enabled: true
  imageHoster:
    service: 'pixelfox.cc'
    user: ''
    pw: 'DEIN_API_KEY'

Bei PixelFox berücksichtigt die Upper-UI automatisch die Berechtigungen des API-Kontos. Ein Free-Konto lädt das Cover mit einer erlaubten Original-Variante hoch; WebP und AVIF werden nur für Konten angefordert, die diese Formate laut PixelFox-Profil verwenden dürfen.

History Log

Der Tab History Log zeigt die wichtigsten Ereignisse zum Upload:

• wann die Result-JSON in die UI importiert wurde,
• wann Metadaten, Links, Cover oder die gespeicherte Raw-JSON bearbeitet wurden,
• wann Publishing-Ziele gespeichert oder entfernt wurden,
• wann Ziele in die Warteschlange gelegt oder wieder entfernt wurden,
• wann Publishing erfolgreich war, manuell als veröffentlicht markiert wurde oder mit Fehler abgebrochen ist.

7. Templates, Presets, Mappings und Integrationen

Im linken Menü erreichst du Templates, Presets, Mappings, Integrationen, Remote Sources und System über das Aufklappmenü Einstellungen.

Die Seiten Templates, Presets und Mappings erklären direkt unter ihrer Überschrift, wofür die jeweilige Verwaltung gedacht ist und welche Aufgaben dort möglich sind.

Templates

Die Seite Templates verwaltet Inhalte, die beim Publishing gerendert werden können:

• Dateien aus template.templates werden beim UI-Start importiert,
• importierte Template-Dateien werden nicht bei jedem Start überschrieben,
• neue UI-Templates können angelegt und bestehende bearbeitet werden,
• Template-Typen umfassen neben Movie, TV, Game, Music und XXX auch EBook und Software,
• Formate wie HTML, BBCode, XML und Plaintext können gespeichert werden,
• eine Vorschau rendert ein Template mit einer importierten Upload-JSON,
• Templates können exportiert werden.

Ausführliche Template-Variablen findest du unter Einstellungen > Templates.

Presets

Die Seite Presets speichert Ziel- und Template-Auswahlen pro Instanz in der UI-Datenbank. Mit Alle / Global siehst du die Presets aller Go-Upper-Instanzen. Zum Anlegen wählst du eine konkrete Instanz und klickst oben auf Neues Preset; der Editor öffnet sich in einem Layer. Bestehende Presets lassen sich über die Stift-Aktion im selben Layer inklusive Name, Inhaltstyp, Auto-Verhalten, Publishing-Zielen und optionalen Templates bearbeiten.

Beim Target gibt es zwei Modi: Automatisch anhand Upload speichert keine feste Zielkategorie und berechnet beim Anwenden auf einen Upload den passenden Target mit derselben Mapping-Logik wie das Publishing selbst. Dadurch können z.B. SD-, 1080p- und UHD-Filme trotz gleichem Typ movie in unterschiedliche Kategorien laufen. Eine feste Target-Auswahl ist für Spezialfälle gedacht, in denen eine Seite immer in dieselbe Kategorie posten soll.

Mappings

Die Seite Mappings zeigt Publish-Mapping-Dateien aus allen gefundenen upper.config.yml-Dateien, zusätzlich nutzbare Dateien aus den passenden config/mappings-Ordnern und die in der UI eingebetteten Standard-Mappings.

• dieselbe physische Mapping-Datei wird nur einmal angezeigt, auch wenn mehrere Instanzen sie verwenden,
• getrennte Config-/Instanzordner mit eigener Mapping-Datei erscheinen getrennt,
• Standard-Mappings funktionieren auch ohne Datei neben der Upper-Instanz; lokale Anpassungen werden als Override unter config/mappings gespeichert,
• angepasste Mappings können auf den eingebetteten Standard zurückgesetzt werden,
• Mapping-Dateien können als YAML bearbeitet und validiert gespeichert werden,
• ein Match-Test zeigt für einen Titel und optionalen Typ die Kategorie, die auch das Publishing wählen würde.

Integrationen

Die Seite Integrationen fasst die Konfiguration aus dem UI-Arbeitsverzeichnis und allen eingetragenen Instanzen zusammen. Sie zeigt:

• Contentgrabber wie xREL, TMDB, IMDB, Steam, YouTube und NFO,
• Imagehoster für Cover,
• Publishing-Services und deren Mapping- oder Endpoint-Konfiguration,
• ob erforderliche Zugangsdaten gesetzt sind, ohne sie im Klartext auszugeben.

Wenn mehrere Instanzen dieselbe upper.config.yml verwenden, werden sie in der Integrationsübersicht gemeinsam dargestellt.

8. NFO Suche

Unter Tools > NFO Suche kannst du ohne zusätzliche Konfiguration nach einem Titel oder einem vollständigen Release-Namen suchen. Die UI fragt SRRDB, PreDB und xREL parallel ab und führt die Treffer in einer Tabelle zusammen.

Die Ergebnisliste zeigt:

• den vollständigen Release-Namen,
• die NFO-Quelle,
• Section und Release-Gruppe, sofern die Quelle diese Daten liefert,
• NFO View für die Textansicht in einem grossen Layer,
• NFO Download für den direkten Download als .nfo-Datei.

Wenn eine Quelle vorübergehend nicht erreichbar ist, bleiben Treffer der anderen Quellen sichtbar und die Seite zeigt einen entsprechenden Hinweis. xREL stellt bei einigen Einträgen nur ein gerendertes NFO-Bild bereit. Solche Einträge bleiben als Suchtreffer sichtbar, melden beim Textabruf aber gezielt, dass kein Text-NFO verfügbar ist.

9. Remote Sources

Die Seite Remote Sources verwaltet FTP-, FTPS- und SFTP-Quellen. Du erreichst sie über Einstellungen > Remote Sources. Sie eignet sich, wenn Releases nicht in lokalen path.scan-Ordnern liegen, sondern von einem Remote-Server übernommen werden sollen.

Bei mehreren verwalteten Go-Upper-Instanzen wählt die Instanz-Auswahl oben rechts aus, welche upper.config.yml oder externe remoteConfig gelesen, getestet und gespeichert wird.

Remote-Datei vorbereiten

Für eine externe Remote-Konfiguration setze in config/upper.config.yml:

remoteConfig: 'remote.sources.yml'

Die Datei liegt dann unter:

config/remote.sources.yml

Alternativ kann remoteConfig leer bleiben; dann schreibt die UI den remote:-Block direkt in upper.config.yml.

Server über die UI anlegen

1. Öffne Remote Sources.
2. Klicke auf FTP hinzufügen.
3. Wähle FTP, FTPS oder SFTP.
4. Trage Host, Port und Anmeldung ein.
5. Nutze Verbindung testen, bevor du speicherst.
6. Öffne anschließend den Browser, navigiere zum Remote-Ordner und speichere ihn als Section.
7. Aktiviere die Section bewusst über den Schalter.

Der erste Scan einer Section legt nur eine Baseline an. Bereits vorhandene Releases werden dabei nicht sofort geladen. Neue Remote-Releases werden unter path.work/remote/... materialisiert; Teiltransfers liegen in .partial/<release-id> und können fortgesetzt werden.

10. Publishing über die UI

Publishing ist optional und muss in upper.config.yml eingeschaltet werden. Für ein Setup, bei dem nur die UI published:

publish:
  enabled: true
  publishCli: false
  publishUi: true
  services:
    - service: 'myboerse.bz'
      enabled: true
      headless: true
      mappingPath: 'myboerse.mapping'
      credentials:
        username: 'DEIN_BENUTZER'
        password: 'DEIN_PASSWORT'

Je nach Ziel werden Mapping-Dateien aus config/mappings/ oder ein JSON-Endpoint benötigt. Unterstützte UI-Abläufe umfassen XenForo-Ziele, uCMS-Ziele wie byte.to und JSON-Endpoint-Services.

Publishing-Ablauf

1. Importiere eine Result-JSON auf der Seite Uploads.
2. Öffne den Upload und wechsle in den Tab Publishing.
3. Aktiviere pro Seite höchstens ein Ziel und wähle gegebenenfalls ein Template.
4. Speichere den Upload. Mit Alle Aktive wählen + Speichern aktiviert die UI alle nicht ausgegrauten Seiten, speichert die Auswahl und springt zur Upload-Liste zurück.
5. Markiere ihn in der Upload-Liste und klicke Veröffentlichen (zu Warteschlange). Alternativ legt Veröffentlichen (alle mit Ziel) alle Uploads mit dem Status Ziel gewählt gemeinsam in die Warteschlange.
6. Nach mindestens 30 Sekunden verarbeitet der UI-Prozess den Queue-Eintrag im Hintergrund.

Der Status wechselt zu Veröffentlicht oder Fehler; Fehlertexte erscheinen in der Upload-Liste, in der Bearbeitungsseite und im History Log des Uploads.
Wenn du einen Upload mit gemischten Ziel-Status erneut in die Warteschlange setzt, bleiben bereits veröffentlichte Ziele unverändert und nur fehlerhafte oder offene Ziele werden erneut versucht.

In der Upload-Liste zeigt die Veröffentlichungsspalte für vorgemerkte und laufende Jobs einen Fortschrittsbalken mit Prozentwert. Der Fortschritt bezieht sich auf die gespeicherten Publishing-Ziele: ein laufendes Ziel zählt als halber Zielschritt, ein erfolgreich veröffentlichtes Ziel vollständig. Während der Verarbeitung steht darunter beispielsweise Veröffentliche auf darklight.to · Filme. Die Anzeige wird ohne kompletten Seitenreload aktualisiert, damit Suche, Filter, Auswahl und Pagination erhalten bleiben. Bei nur einem Ziel springt der Wert deshalb nachvollziehbar von 0 % über 50 % auf 100 %; ein Byte- oder Browser-Transferfortschritt wird nicht vorgetäuscht.

Publishing-Seiten mit fehlenden Zugangsdaten in der aktiven Config werden im Tab Publishing ausgegraut, zeigen den Hinweis Zugangsdaten fehlen und können nicht als Ziel gespeichert werden.

Die automatische Zielvorauswahl verwendet dieselben match-, exclude-, priority- und fallback-Regeln wie das CLI-Publishing. Für boersecx, data-load.me, darklight.to und myboerse.bz ergänzt sie den Release-Titel um gekennzeichnetes General.Genre, ohne den später geposteten Threadtitel zu verändern. So werden beispielsweise Animationsfilme ohne ANIMATION im Releasenamen trotzdem in die passende Animations- und Qualitätskategorie einsortiert; mehrdeutiges Concert gilt nur bei Musik-Genre oder zusätzlichem Live-Marker als Konzert/Musikvideo, während konkrete Musik-Subgenres wie Punk Rock auch Konzertmitschnitte ohne Titelmarker erkennen. Fehlt der Inhaltstyp in der Result-JSON oder wurde er als - importiert, nutzt die UI zuerst den konfigurierten Quellpfad und danach konservative Film-/Serien-Merkmale im Releasenamen. Bleibt der Typ unbekannt, wird ein explizites Mapping-Fallback statt der ersten Kategorie verwendet. Eine bereits in der UI gespeicherte manuelle Zielwahl bleibt erhalten.

Publishing-Presets verwaltest du unter Einstellungen > Presets für eine konkrete Instanz. Im Publishing-Tab erscheinen gespeicherte Presets oben nur als Buttons; ein Klick setzt die definierte Ziel- und Template-Auswahl erneut. Ist ein Preset für den Upload-Typ als Auto gespeichert, wird es bei neuen Uploads dieses Typs automatisch vorselektiert, solange für den Upload noch keine Publishing-Auswahl gespeichert wurde. Preset-Ziele mit Automatisch anhand Upload werden dabei pro Upload neu über Typ, Release-Titel, Match-/Exclude-Regeln, Priorität und Fallback aufgelöst.

Bei XenForo-Zielen wie boersecx, darklight.to, data-load.me und myboerse.bz sendet die UI-Warteschlange den gerenderten BBCode direkt als Formularwert. Der Browser bleibt für Login, Suche und Formular-Kontext im Einsatz, der BBCode wird aber nicht mehr in den Rich-Text-Editor getippt. Vor einer Antwort in einem vorhandenen Thread öffnet Upper dessen neueste Seite und vergleicht die letzten Beiträge mit der eingeloggten Benutzer-ID beziehungsweise dem Benutzernamen sowie dem normalisierten Zielinhalt inklusive Ziel-Links. Ist derselbe eigene Beitrag bereits vorhanden, wird keine weitere Antwort abgesendet. Kann die Threadseite nicht zuverlässig ausgewertet werden, bricht Publishing konservativ mit einem sichtbaren Fehler ab. Liefert data-load.me vorübergehend weder Treffer noch eine bestätigte No-Result-Meldung, lädt der Browser die Seite einmal neu und wiederholt die vollständige Themensuche. Bleibt die Antwort ungeprüft, bricht das Publishing weiterhin ab, damit nicht versehentlich ein doppelter Thread angelegt wird.

Für darklight.to hält der laufende Upper-UI-Worker einen Browser über mehrere Queue-Einträge und Batches hinweg angemeldet. Vor jedem Ziel bestätigt er die Session am Board und führt den Login nur erneut aus, wenn sie nicht mehr gültig ist. Verschiedene Zugangsdaten oder ein anderer Headless-Modus erhalten getrennte Browser; unterschiedliche Mapping-Dateien können dagegen dieselbe Anmeldung nutzen. Die Arbeit im gemeinsamen Tab ist serialisiert. Jeder einzelne Publishing-Vorgang bleibt auf fünf Minuten begrenzt; danach wird nur dieses Ziel als Fehler markiert, während der wiederverwendbare Browser-Kontext für den nächsten Vorgang erhalten bleibt.

Für Browser-Publishing kannst du zur Diagnose ein sichtbares Chrome-Fenster erlauben:

publish:
  services:
    - service: 'darklight.to'
      headless: false

11. KI Modelle

Unter Einstellungen > KI Modelle verwaltest du die lokalen Sprachmodelle für Typ- und Plausibilitätsprüfungen von Upload-Metadaten. Die Modellverwaltung selbst verändert keine Upload-Daten.

Voraussetzung

Installiere und starte Ollama. Die Upper-UI verbindet sich standardmäßig mit:

http://127.0.0.1:11434

Wenn Ollama unter einer anderen Adresse läuft, setzt du sie vor dem UI-Start über UPPER_AI_OLLAMA_URL:

UPPER_AI_OLLAMA_URL=http://192.168.1.50:11434 ./upper-ui-linux

Alternativ wird eine vorhandene OLLAMA_HOST-Variable berücksichtigt. Die Seite zeigt an, ob der Dienst erreichbar ist; ohne Ollama bleiben Katalog und Hinweise sichtbar, Modellaktionen sind jedoch deaktiviert.

Kuratierte Modelle

Die Angaben sind ungefähre Downloadgrößen. Ollama, Modellkontext und laufende Ausgaben benötigen zusätzlichen RAM beziehungsweise VRAM.

Aktionen

• Download installiert das fest angegebene Modell-Tag und zeigt den von Ollama gemeldeten Fortschritt.
• Testen lädt das Modell einmal, fordert ein strukturiertes JSON-Ergebnis an und zeigt die Laufzeit.
• Aktivieren speichert das Modell als Standardauswahl in upper-ui.db.
• Löschen entfernt ein inaktives Modell aus Ollama. Das aktive Modell muss zuerst durch ein anderes installiertes Modell ersetzt werden.

Die UI verwendet bewusst feste Tags statt latest, damit ein späteres Registry-Update das Verhalten nicht unbemerkt ändert.

Upload mit KI prüfen

Im Upload-Editor steht neben Auto Complete die Aktion KI prüfen zur Verfügung, sobald ein Modell aktiviert wurde. Geprüft wird immer der aktuelle Formularstand im Browser, also auch noch nicht gespeicherte Änderungen. Die Anfrage enthält alle Metadatenfelder und die vollständige NFO. Ungültige Steuerzeichen werden bereinigt; der Inhalt wird nicht still gekürzt. Überschreitet die gesamte Anfrage den Kontext des aktiven Modells, bricht die UI stattdessen mit einer verständlichen Fehlermeldung ab.

Vor dem Modell laufen feste Prüfungen für unter anderem Releasename, Typ, Jahr, URLs, externe IDs und Bewertungen. Ollama erhält anschließend die NFO als nicht vertrauenswürdige Daten und muss ein strukturiertes JSON-Ergebnis mit Typ, Sicherheit, Zusammenfassung und feldbezogenen Hinweisen liefern.

Das Ergebnis verändert den Upload nicht automatisch:

• Ein vorgeschlagener Typ wird erst über Typ übernehmen in das Formular eingesetzt.
• Ein Klick auf einen Hinweis springt zum betroffenen Eingabefeld.
• Dauerhaft gespeichert werden Änderungen weiterhin ausschließlich über den normalen Speichern-Button.
• Nach weiteren Änderungen markiert die UI das vorhandene Prüfergebnis als veraltet.

12. System, Datenbank und Wartung

Die Seite Einstellungen > System zeigt Details zur lokalen SQLite-Datenbank der Upper UI:

• den vollständigen Pfad zur aktiven upper-ui.db,
• Dateigröße, Änderungszeit, Rechte sowie WAL-/SHM-Sidecars,
• SQLite-Version, Journal-Modus, Page Count, Page Size und freie Pages,
• Schema- und Tabellenübersicht mit Zeilen, Spalten und Indexen.

Wenn die Datenbank als Datei vorliegt, bietet die Seite DB herunterladen für einen direkten Download. Der Button VACUUM führt den SQLite-Befehl auf der aktiven UI-Datenbank aus, kompaktiert die Datei und zeigt danach die neue Größe sowie freigebbaren Speicher an.

In der Tabellenübersicht leert Truncate die jeweilige Tabelle vollständig und setzt die SQLite-Sequenz dieser Tabelle zurück. Die Aktion betrifft nur die ausgewählte Tabelle.

13. Update und Sicherung

Upper-Instanz aktualisieren

Die UI prüft im Dashboard automatisch, ob die installierte Version einer Upper-Instanz älter als die aktuelle Release ist. In diesem Fall wächst das kompakte Symbol hinter der Versionsanzeige zu einem farbigen Button Update <Zielversion> mit Neu-Punkt. Bei laufenden Instanzen bleibt er sichtbar, aber bis zum Stoppen deaktiviert. Der Button öffnet einen Dialog analog zum UI-Update mit installierter Version, Zielversion, Release-Text und optionalem Force. Die UI lädt latest.json und latest.zip von https://go-toolz.com/dl/upper/, entpackt das Archiv, überschreibt die Instanzdateien und löscht das temporäre Download-Material wieder.

Geschützt bleiben unter anderem:

• config/upper.config.yml
• config/remote.sources.yml
• files/, log/, database/
• der Unterordner upper-ui/ (eigenes UI-Update)

UI aktualisieren

In der Kopfleiste zeigt die UI ihre eigene Version getrennt von der Go-Upper-Version. Über Update:

1. lädt die UI die aktuelle Release-Information,
2. zeigt Zielversion und Release-Text,
3. lädt bei Bestätigung das Update,
4. prüft eine im Manifest angegebene SHA256-Prüfsumme,
5. installiert das Update und startet die UI neu.

Mit Force kannst du dieselbe UI-Version erneut installieren, wenn eine bestehende Installation repariert werden soll.

Datenbank sichern

Die Datei upper-ui/database/upper-ui.db enthält unter anderem:

• gespeicherte Instanzen,
• importierte Result-JSONs und bearbeitete Upload-Daten,
• UI-Templates,
• Publishing-Ziele und Queue-Status.

Sichere diese Datei vor Updates, Migrationen oder größeren manuellen Änderungen. Stoppe die UI vorher, damit die SQLite-Datei konsistent kopiert wird.

Falls du Remote Sources nutzt, sichere zusätzlich:

database/remote-sources.db
config/remote.sources.yml

14. Sicherheit und Fehlerbehebung

Sicherheit

Die UI ist standardmäßig nur an 127.0.0.1 gebunden. Behalte diese Einstellung, sofern du keinen abgesicherten Zugriff eingerichtet hast.

Sicherheitshinweis: Die Weboberfläche kann Konfigurationen bearbeiten, Upper-Prozesse starten und Publishing auslösen. Der Link Login in der Kopfleiste führt zum Kundenbereich und schützt die lokale UI nicht. Wenn du UPPER_UI_ADDR auf eine Netzwerkadresse bindest, sichere den Zugriff extern, zum Beispiel durch Reverse Proxy, TLS und Authentifizierung.

UI zeigt keine Config

• Starte die UI aus dem Go-Upper-Hauptverzeichnis.
• Prüfe, ob config/upper.config.yml vorhanden und gültiges YAML ist.
• Prüfe bei einer Instanz, ob der Binary-Pfad auf den Ordner mit der passenden config/-Struktur zeigt.

Uploads erscheinen nicht

• Prüfe, ob result.json.enabled: true gesetzt ist.
• Prüfe path.result und ob dort Result-JSON-Dateien liegen.
• Prüfe die Config der eingetragenen Instanz, nicht nur die Config im UI-Arbeitsverzeichnis.
• Nutze auf Uploads einmal den Button Import.

Eine Instanz startet nicht

• Prüfe, ob der eingetragene Binary-Pfad existiert und ausführbar ist.
• Prüfe die Logseite und upper-ui/log/upper-instance-<ID>.log.
• Starte testweise mit aktiviertem Debug.

Offener Upload bleibt in Arbeit

• Stoppe die zugehörige Instanz.
• Prüfe, ob der Job tatsächlich abgebrochen ist.
• Nutze erst dann auf Offene Uploads die Aktion Reset.

Remote-Verbindung schlägt fehl

• Teste Host, Port, Protokoll und Zugangsdaten im Setup-Dialog.
• Prüfe bei FTPS den TLS-Modus und bei SFTP die Host-Key- und Key-Datei-Einstellungen.
• Aktiviere eine erkannte Section erst nach erfolgreichem Test.

Publishing läuft nicht

• Prüfe publish.enabled: true und publish.publishUi: true.
• Prüfe, ob der konkrete Service enabled: true ist.
• Prüfe, ob Ziel und gegebenenfalls Template im Publishing-Tab gespeichert wurden.
• Beachte die Mindestwartezeit von 30 Sekunden in der Warteschlange.
• Prüfe den angezeigten Fehlertext bei einem fehlgeschlagenen Target.
• Browserbasierte XenForo-Ziele werden nach fünf Minuten mit einem Timeout beendet, statt die restliche Warteschlange dauerhaft zu blockieren.

15. Screenshots im Überblick

Die folgenden Screenshots sind in den passenden Abschnitten dieser Seite eingebunden: