Konfiguration von go-upper

go-upper verwendet die Datei:

config/upper.config.yml

Auch hier gibt es in der Regel eine Vorlage upper.config.dist.yml.
Du kopierst sie nach upper.config.yml und passt deine Werte an.

In diesem Dokument erklären wir die wichtigsten Abschnitte und Optionen in einfachen Worten.

---

1. Lizenz

license: '' # REQUIRED | your license -> buy your license here: http://go-toolz.com

• Trage hier deinen Lizenzschlüssel ein.
• Ohne gültige Lizenz kann go-upper nicht arbeiten.

Beispiel:

license: 'ABCDEF-123456-UPPER'

---

2. Arbeitsmodus (workmode)

workmode: 'normal' # REQUIRED | 'normal' or 'lite'

Mögliche Werte:

• normal

  • Standardmodus.
  • Ordner werden ggf. heruntergeladen/kopiert, RAR‑Archive erstellt, hochgeladen, Links gecryptet, Ergebnisse geschrieben, optional Backups angelegt.

• lite

  • Schnellere Variante, wenn in den Scan‑Ordnern bereits fertige RAR‑Archive liegen.
  • Es wird weniger an den Dateien geändert, der Workflow ist schlanker.

Empfehlung:
Für neue Setups erst mit normal starten. Wenn alles läuft und du deine Ordnerstruktur kennst, kannst du testen, ob lite besser zu deinem Szenario passt.

---

3. Allgemeine Einstellungen (general)

Auszug aus upper.config.dist.yml:

general:
  extractRARs: true
  createRARs: true
  slowmode: 10
  checkinterval: 600
  retryfaileduploads: 5
  cleanWorkDir: true
  cleanScanDir: false
  overwriteByDownload: false
  checkFreeSpace: false
  skipUploadProcess: false
  ignore:
    enabled: false
    keywords:
      - ''
  contains:
    enabled: false
    keywords:
      - 'upload-me'
  modifiedAfter:
    enabled: false
    dateTime: '10.04.2025 - 10:00'
  parallel:
    hoster: 1
    copy: 1
  copy:
    enabled: true
    exclude:
      enabled: false
      keywords:
        - 'sample'
  folderReady:
    enabled: false
    requiredStableChecks: 3
    quietSeconds: 30
    maxWaitMinutes: 0
    minReadySizeMB: 50
    minFiles: 2
    minParts: 0
    minFolderAgeMinutes: 0
    blockIncomplete:
      enabled: true
      patterns:
        - '.part'
        - '.filepart'
        ...

Wichtige Felder:

• extractRARs

  • true = vorhandene RAR‑Archive im Eingangsordner werden entpackt.
  • Sinnvoll, wenn du Material erst neu packen willst.
  • Ebenfalls erforderlich, wenn FFProbe oder MediaInfo den Hauptfilm analysieren sollen, dieser aber nur innerhalb eines RAR-Archivs vorliegt. Typische Sample-Dateien werden bei der Primärvideo-Auswahl nicht verwendet.

• createRARs

  • true = go-upper erstellt RAR‑Archive für den Upload.
  • false = keine neuen RAR‑Archive, nur bestehende genutzt.

• slowmode

  • Wartezeit (Sekunden) nach einem fertigen Upload‑Job.

• checkinterval

  • Intervall in Sekunden, in dem go-upper neue Ordner und Jobs sucht und den Status prüft.

• retryfaileduploads

  • Anzahl der Upload‑Wiederholungen bei Fehlern.

• cleanWorkDir / cleanScanDir

  • cleanWorkDir löscht das Workdir nach erfolgreichem Job.
  • cleanScanDir löscht auch die Originalordner im Scan‑Verzeichnis (vorsichtig!).

• overwriteByDownload

  • Schützt vor mehrfachem Herunterladen, wenn der Ordner schon im Workdir vorhanden ist.

• skipUploadProcess

  • Wenn true, wird nichts hochgeladen – nützlich für Tests des Vorprozesses (Kopieren/Packen).

• ignore / contains

  • Wie bei go-reupper: bestimmte Ordner ausschließen (ignore) oder nur bestimmte Ordner einschließen (contains).

• modifiedAfter

  • Wenn enabled: true, werden nur Ordner verarbeitet, die nach einem bestimmten Datum/Uhrzeit geändert/erstellt wurden.
  • Datum im Format DD.MM.YYYY - HH:MM.

• parallel (hoster/copy)

  • Regelt parallele Uploads und Kopierprozesse.
  • Höhere Werte = schneller, aber mehr Last und mögliche Hosterlimits.

• copy

  • enabled: true = Dateien werden ins Workdir kopiert.
  • exclude mit keywords kann bestimmte Dateien (z. B. sample) vom Kopieren ausschließen.

• folderReady

  • Hilft, „unfertige“ Ordner (z. B. noch laufende Downloads) zu erkennen.
  • Es wird geprüft, ob sich Größe/Anzahl über eine gewisse Zeit nicht mehr ändern, ob Mindestgröße erfüllt ist, etc.
  • maxWaitMinutes legt fest, wie viele Minuten maximal gewartet wird, bevor ein nicht bereiter Ordner für diesen Lauf übersprungen wird. 0 oder ein fehlender Wert behält den Standard von 30 Minuten bei.
  • Sehr hilfreich bei FTP‑Dumps oder laufenden Downloads.

---

4. Bandbreite (bandwidth)

Der Block funktioniert ähnlich wie bei go-reupper:

bandwidth:
  quota:
    enabled: false
    resetInterval: 'month'
    resetDay: 1
    download: 1099511627776
    #upload: 0

Siehe Bandbreiten‑Erklärung bei go-reupper – auch hier steuerst du, wie viel Traffic maximal verbraucht werden darf.

---

5. Stream‑Upload (stream)

stream:
  exclude:
    enabled: false
    keywords:
      - 'sample'

Dieser Block ist relevant, wenn du Streamhoster nutzt:

• exclude.enabled = true → bestimmte Dateien (z. B. mit „sample“ im Namen) werden bei Stream‑Uploads ausgeschlossen.

---

6. Skip‑Einstellungen (skip)

skip:
  incomplete:
    enabled: false
    pattern:
      - '- COMPLETE)'

• enabled: true bedeutet: Ordner, die bestimmte Muster nicht enthalten, gelten als „unfertig“ und werden übersprungen.
• Die Muster in pattern definieren, woran ein „fertiger“ Ordner erkannt wird (z. B. - COMPLETE)).

Dieser Block ist hilfreich, um halbfertige Dumps zu ignorieren.

---

7. Ergebnisse (result)

result:
  json:
    enabled: true
    seperated: false
    addNfo: false
  txt:
    enabled: false
    path: ''
    caseSensitive: true
  sendTo:
    enabled: false
    url: ''
    auth:
      type: no-auth
      basicAuth:
        user: ''
        pw: ''
      bearerToken:
        token: ''
      apiKey:
        param: 'api-key'
        key: ''

go-upper kann:

• JSON‑Dateien mit allen wichtigen Infos speichern (für Duplikatschutz/Weiterverarbeitung).
• TXT‑Listen führen (einfacher Überblick über bearbeitete Ordner).
• Resultate per HTTP an einen Webhook/Endpoint senden.

Wichtige Felder:

• json.enabled – JSON‑Ergebnisse an/aus.
• seperated – ob für jeden Eintrag eigene Unterordner angelegt werden.
• addNfo – NFO‑Inhalt mit in die JSON‑Datei schreiben.
• txt.enabled und txt.path – einfache Textliste pflegen.
• sendTo.enabled / url – JSON‑Ergebnisse an einen HTTP‑Endpoint schicken (z. B. eigenes Script).
• auth.type – no-auth, basic-auth, bearer-token, api-key.

---

8. Pfade (path)

path:
  scan:
    - '/var/www/ftp/'
    - 'C:\Users\You\Videos\'
  winrar: ''
  result: ''
  base: ''
  work: ''

Dieser Block ist ähnlich wie bei go-reupper:

• scan – Eingangsordner, die überwacht und verarbeitet werden.
• winrar – Pfad zu WinRAR (Windows) oder rar (Linux).
• result – Ordner für Ergebnisdateien (wenn leer, wird ein Standardpfad genutzt).
• base – Basis‑Pfad zum Tool (meist leer lassen, automatische Erkennung).
• work – Arbeitsverzeichnis für temporäre Dateien.

Remote-Quellen (remote)

Zusätzlich zu lokalen path.scan-Ordnern ist ein neuer, standardmäßig deaktivierter remote-Block vorgesehen. Wenn Upper und Reupper dieselben FTP/FTPS/SFTP-Quellen nutzen sollen, kann der Block optional in eine gemeinsame Datei ausgelagert werden:

remoteConfig: '' # optional, z.B. 'remote.sources.yml'
remote:
  enabled: false
  statePath: 'database/remote-sources.db'
  firstScanMode: 'baseline-only'
  scanIntervalSeconds: 600
  servers: []

• remoteConfig ist leer = der inline remote:-Block aus dieser Config wird benutzt.
• remoteConfig: 'remote.sources.yml' = der externe remote:-Block aus config/remote.sources.yml wird geladen und ersetzt den inline Block.
• Der Pfad wird relativ zur jeweiligen Haupt-Config aufgeloest; upper.config.yml und reupper.config.yml koennen also dieselbe Datei referenzieren.
• Eine Vorlage liegt in config/remote.sources.dist.yml.
• Unterstützt werden FTP, FTPS (explicit mit AUTH TLS oder implicit mit Port-990-Default) und SFTP.
• Der erste Scan eines Servers oder einer Section legt nur eine Baseline an; es wird noch nichts automatisch heruntergeladen.
• Automatisch erkannte Sections werden sichtbar gespeichert, bleiben aber deaktiviert, bis du sie aktivierst.
• Upper und Reupper verwenden denselben Remote-Download-Cache.
• Ein eigener cachePath existiert aktuell nicht; Remote-Releases landen weiter unter path.work/remote/....
• Downloads laufen zuerst in .partial/<release-id> und werden erst nach erfolgreichem Abschluss in den finalen Cache verschoben.
• Vorhandene Partial-Dateien werden beim naechsten Versuch fortgesetzt: FTP/FTPS nutzt REST, SFTP nutzt Seek.
• transferSlots/maxConnections begrenzen parallele Remote-Downloads pro Server.
• SFTP nutzt known_hosts oder bewusst gesetztes insecure Host-Key-Handling und unterstützt Passwort- sowie Private-Key-Auth.
• Remote-Downloads werden in die bestehende Bandwidth-Quota eingerechnet.
• Die Upper-UI kann Remote-Ordner ueber GET /api/upper/remote/browse?server=<id>&path=/ listen; mit instance=<id> wird eine konkrete Instanz-Config verwendet.
• Ein schneller Server-Test ist ueber GET /api/upper/remote/test?server=<id>&path=/ verfuegbar und wird in der Remote-Sources-Seite genutzt.
• Der Button FTP hinzufuegen oeffnet einen gefuehrten Dialog fuer FTP, FTPS oder SFTP. Host, Port und Login bleiben direkt sichtbar; TLS/SSH, Discovery, DrFTPD-Kompatibilitaet und Transfer-Slots liegen in erklaerten erweiterten Gruppen.
• Verbindung testen prueft einen Formularentwurf vor dem Speichern. Beim Bearbeiten werden gespeicherte Passwoerter nicht angezeigt; ein leeres Passwortfeld behaelt den vorhandenen Wert.
• Ist remoteConfig gesetzt und die externe Datei noch nicht vorhanden, legt der Setup-Dialog sie beim ersten Speichern an.
• Die Remote-Sources-Seite speichert Section-Checkboxen ueber PUT /api/upper/remote/section in die aktive upper.config.yml oder, falls gesetzt, in die externe remoteConfig-Datei; automatisch erkannte Sections bleiben bis dahin sichtbar, aber deaktiviert.
• Das Browser-Popup kann den aktuell geoeffneten Remote-Ordner ueber denselben Endpunkt als neue deaktivierte Section speichern.

Siehe auch Beispiele in „Erste Schritte mit go-upper“.

---

9. Backup (backup)

backup:
  enabled: false
  files: false
  archives: false
  subdir: true
  path:
    - ''

Funktioniert wie bei go-reupper:

• enabled – Backup an/aus.
• files – Originaldateien sichern.
• archives – RAR‑Archive sichern.
• path – Liste der Ziel‑Ordner.

---

10. Linkcrypter (linkcrypter)

Der Block ist analog zu go-reupper (Filecrypt, ToLink, Hide.cx):

linkcrypter:
  service: 'filecrypt'
  apikey: ''
  multiHosterMode: false
  options:
    password: ''
    captcha: false
    cnl: true
    dlc: true
    links: true
  backup:
    enabled: false
    services:
      - service: 'hidecx'
        apikey: ''

Siehe die Erklärung unter „Konfiguration von go-reupper → Linkcrypter“ – die Logik ist die gleiche.

---

11. Archiv‑Einstellungen (archive)

Hier steuerst du, wie go-upper Archive erzeugt (RAR‑Modus, Partgröße, Passwort, Zusatzdateien, WinRAR‑Schalter):

archive:
  mode: 'rar'
  partsize: '200m'
  pw: ''
  md5change:
    enabled: false
    md5mode: 1
    iterations: 1
  randomname: false
  addfolder: false
  separatefiles: false
  includefiles:
    path: ''
    addToFolder: true
  winrar:
    options:
      extractRecursive: true
      extractOriginal: false
      silent: true
      exclude:
        - '*.json'
      customExtract: ''
      customCreate: ''

Wichtige Felder:

• mode und partsize definieren Format und Splitting (z. B. 200m).
• pw setzt ein Archiv‑Passwort.
• md5change fügt kleine Änderungen hinzu, damit sich die Prüfsumme ändert (fortgeschritten).
• randomname, addfolder, separatefiles steuern den Aufbau der Archive.
• includefiles.path kann Dateien in jedes erzeugte Archiv hinzufügen.
• winrar.options erlaubt Ausschlüsse und Experten‑Flags für Extract/Create.

---

12. Content‑Grabber (contentgrabber)

Der Bereich contentgrabber ist in go-upper der zentrale Block für externe Metadaten (xREL, PreDB, IMDB, TMDB, Steam, YouTube).

contentgrabber:
  enabled: false
  useLocalCover: true
  imageHoster:
    service: 'pixelfox.cc'
    uploadURL: ''
    user: ''
    pw: ''
    galleryID: ''
  nfo:
    enabled: false
    fetchIfNotExist: true
    parseIMDB: true
  xrel:
    enabled: false
    coverUpload: false
    skipIfNotAvailable: false
  predb:
    enabled: false
    skipIfNotAvailable: false
  imdb:
    enabled: false
    coverUpload: false
    language: 'DE'
  tmdb:
    enabled: false
    coverUpload: false
    coverSize: 'medium'
    language: 'DE'
    withTrailer: true
    removeFromName:
      enabled: true
      words:
        - ' GERMAN'
        - ' DL'
  steam:
    enabled: false
    coverUpload: false
    language: 'DE'
  youtube:
    enabled: false
    apiKey: ''
    language: 'DE'

Wichtige Punkte:

• contentgrabber.enabled ist der Master‑Schalter für das gesamte Modul.
• useLocalCover bevorzugt lokale Cover-Dateien (.jpg/.png) aus dem Quellordner.
• imageHoster.service wählt den Uploader für Cover und Bilder. Unterstützt werden unter anderem imgur.com, directupload.eu, imgbb.com, pixhost.to, fastpic.org, postimages.org und pixelfox.cc.
• Für pixelfox.cc kannst du den API-Key entweder in user oder pw hinterlegen. go-upper nimmt automatisch das Feld, das nicht leer ist.
• Für pixelfox.cc liest go-upper vor dem Upload die erlaubten Formate aus limits.allowed_thumbnail_formats des Account-Profils. Free-Konten fordern nur original/medium an; webp/medium und avif/medium werden ausschließlich bei entsprechender Kontoberechtigung ergänzt.
• Für PixelFox werden keine small-Thumbs angefordert. Falls eine Processing-Policy zwischen Profilabfrage und Session-Erstellung abgelehnt wird, fällt der Upload einmalig auf das dokumentierte Profil original_only zurück.
• Pixelfox liefert für Uploads bevorzugt die stabile medium-URL in dieser Reihenfolge: avif, dann webp, dann original.
• uploadURL wird nur für Chevereto-kompatible Dienste wie imgbb.com benötigt.
• galleryID ist nur für directupload.eu relevant.
• nfo.parseIMDB hilft, IMDB‑IDs direkt aus NFOs zu ziehen.
• xrel.skipIfNotAvailable kann Releases überspringen, wenn xREL nichts findet.
• predb.enabled speichert exakte Scene-Release-Daten wie Section, Group, Pretime, Nuke-Status und NFO-Links im Block ExternalInfo.PreDB.
• predb.skipIfNotAvailable kann Releases überspringen, wenn kein exakter Treffer auf predb.net existiert. Die offizielle API ist auf 30 Requests pro 60 Sekunden begrenzt.
• imdb.language, tmdb.language, steam.language steuern die Sprache (DE, EN, bei TMDB/Steam auch mehrfach wie DE,EN).
• tmdb.removeFromName bereinigt Suchbegriffe vor dem TMDB‑Lookup.
• youtube.enabled benötigt einen gültigen API‑Key (youtube.apiKey).
• Die Unterblöcke nfo, xrel, predb, imdb, tmdb, steam und youtube steuern, welche zusätzlichen Datenquellen abgefragt werden und ob deren Cover ebenfalls hochgeladen werden sollen.

Praxis‑Hinweis:

• Für viele Setups reicht als Start: tmdb.enabled: true, tmdb.coverUpload: true, nfo.enabled: true.
• Wenn imdb.coverUpload und tmdb.coverUpload gleichzeitig aktiv sind, wird laut Dist‑Kommentar das TMDB‑Cover bevorzugt.

---

13. Filehoster & Streamhoster

Die Hoster‑Konfiguration in upper.config.yml entspricht im Prinzip der von go-reupper:

• filehoster.options und filehoster.active – globale Optionen + Liste aktiver Hoster.
• filehoster.services – Zugangsdaten (API‑Keys, Nutzer/Passwörter, Parallel‑Uploads usw.) je Hoster.
• streamhoster.active und streamhoster.services – das gleiche für Video‑Hoster.
• Bei uploadg.com gehört in filehoster.services.uploadg.apikey der Bearer-Token aus https://uploadg.com/account-settings.
• uploadg.com nutzt automatisch den Multipart-S3-Upload und ist damit auch für große Dateien gedacht; der alte /uploads-Endpunkt wird nicht mehr verwendet.

Wenn du schon mit der Reupper‑Config vertraut bist, findest du dich hier sehr schnell zurecht.

---

14. Erweiterungen & Add-ons

Im unteren Teil der upper.config.dist.yml gibt es mehrere zusätzliche Module.
Hier nur ein kurzer Überblick (Details findest du jeweils direkt in den Kommentaren der Dist‑Datei):

Für konkrete Schritt-für-Schritt-Setups siehe zusätzlich „Go-Upper → How-Tos“.

• emule

  • Erzeugt große RAR‑Dateien und eD2k‑Links für eMule und verschiebt diese an einen Zielort.

• nfoMover

  • Verschiebt NFO‑Dateien nach erfolgreichem Upload an einen speziellen Ordner.

• ffprobe / mediainfo

  • Lesen technische Informationen aus Video‑Dateien aus und ergänzen die JSON‑Ergebnisse (z. B. Laufzeit, Auflösung).

• afterupload

  • Ermöglicht, nach Abschluss der Uploads das System herunterzufahren oder andere Programme/Skripte aufzurufen.

• curl

  • Wie bei go-reupper: Hoster‑Uploads können über curl abgewickelt werden, um Speicher zu sparen.

• notification

  • Pushover‑Benachrichtigungen bei Fehlern oder Erfolgen.

• workingtime

  • Zeitplan, zu welchen Uhrzeiten go-upper aktiv sein darf.

• zoom / proxies

  • Erweiterte Upload‑Steuerung über ZOOM WebControl sowie optionale SOCKS5‑Proxylisten.

• template

  • Automatische Template‑Erzeugung nach dem Upload (BBCode/XML/Text).
  • Details siehe Seite „Templates in go-upper“.

• moviethumbnail

  • Integration von mtn (Movie Thumbnailer), um automatisch Kontaktbögen/Thumbnails zu generieren und ggf. hochzuladen.
  • Optionen für columns, rows, edgeDetection, jpegQuality, width sowie extraArgs für zusätzliche Flags.

• publish

  • (Alpha) – Veröffentlichen auf Foren, Webseiten oder JSON-Endpoint-Dienste.
  • enabled ist der globale Hauptschalter. Wenn enabled: false, publishen weder CLI noch Upper-UI.
  • publishCli steuert, ob der normale upper CLI-Lauf nach dem Upload automatisch publishen darf.
  • publishUi steuert, ob die Upper-UI-Warteschlange publishen darf.
  • Wenn publishCli oder publishUi fehlen, gilt aus Kompatibilitätsgründen weiter enabled.
  • services[].enabled bleibt der Schalter pro Ziel, z. B. für boersecx, darklight.to, data-load.me, byte.to, warezddl oder warezcx.
  • Browser-basierte XenForo-Services laufen standardmaessig ohne sichtbares Chrome-Fenster. Mit services[].headless: false kann der Browser fuer Tests oder Beobachtung eingeblendet werden.
  • Relative mappingPath-Werte werden zuerst neben der jeweiligen Upper-Instanz, dann im UI-Ordner config/mappings und zuletzt aus den eingebetteten Standard-Mappings geladen.
  • boersecx lädt seine Forum-Zuordnung aus services[].mappingPath. Kategorien können mit priority priorisiert, mit exclude gegen widersprüchliche Release-Merkmale geschützt und mit fallback: true als Standardziel ihres type markiert werden. match und exclude akzeptieren reguläre Ausdrücke ohne Beachtung der Groß-/Kleinschreibung.
  • darklight.to nutzt dasselbe Forum-Mapping unter darklightto.mapping. Für schreibbare DarkLight-Unterforen mit Pflichtpräfix setzt requirePrefix: true voraus, dass eine verschachtelte prefixes-Regel einen Präfix auswählt; ohne passenden Präfix wird kein neuer Thread erstellt.
  • data-load.me nutzt dataloadme.mapping und routet in beschreibbare Leaf-Foren wie forums/hd.8/ oder forums/hd.14/; Container-Foren werden nicht als Schreibziel verwendet. Sichtbare Sprachpraefixe in einigen Formularen sind optional und werden nicht automatisch gesetzt.
  • Services mit type: ucms posten ueber den praktisch bestaetigten Standardfluss von byte.to: Login, Formularabruf zur Uebernahme des Account-Uploaders und Multipart-Upload. Die Mapping-id ist die Seiten-Kategorie-ID; usePlainLinks: false verwendet bevorzugt Crypter-Links. Bei byte.to wird der sichtbare Upload-Titel aus dem Release-Titel gebildet und wie bei boersecx ohne Release-Punkte formatiert; Audio-Sprachen werden als byte.to-kompatible Werte wie GER, ENG, GER;ENG oder gaengige Multi-Language-Kombinationen gesendet.
  • In der Upper-UI bestimmt das auf der Upload-Edit-Seite ausgewaehlte Template den geposteten XenForo- oder uCMS-Inhalt. Bei neuen UI-Auswahlen mit leerem oder nicht lesbarem categories[].template wird ein passendes gespeichertes UI-Template vorausgewaehlt; ein lesbarer Mapping-Pfad bleibt als expliziter Default erhalten. Fuer CLI-Publishing ohne UI-Auswahl muss der Mapping-Template-Pfad weiterhin renderbar sein.
  • JSON-Endpoint-Services nutzen type: jsonEndpoint und senden die fertige Result-JSON per POST. Bestehende Ziele nutzen HTTP Basic Auth aus credentials; alternativ kann auth mit basic-auth, bearer-token, api-key oder no-auth konfiguriert werden.
  • warezddl erwartet POST /dlacp/api/upload-entry oder den Alias /dlacp/api/upload-eintrag; neue Einträge kommen als deaktivierter Entwurf zurück, bestehende Uploads können mirrors_added melden.
  • warezcx postet an https://api.warez.cx/upload/json/push; der warez.cx API-Key wird als Bearer-Token unter auth.bearerToken.token eingetragen.

Die wichtigsten Schalter:

Option	Bedeutung
publish.enabled	Globaler Publish-Hauptschalter. Muss true sein, damit irgendein Publishing läuft.
publish.publishCli	Erlaubt automatisches Publishing im normalen upper CLI-Lauf.
publish.publishUi	Erlaubt die Verarbeitung der Upper-UI-Warteschlange.
publish.services[].enabled	Aktiviert oder deaktiviert einen einzelnen Publish-Service.
publish.services[].headless	Steuert bei XenForo-Services das Chrome-Fenster: true oder fehlend laeuft verborgen, false zeigt es zur Diagnose an.

Wenn du nicht möchtest, dass der normale CLI-Lauf automatisch postet, sondern ausschließlich die Upper-UI-Warteschlange nutzen willst, setze:

publish:
  enabled: true
  publishCli: false
  publishUi: true
  services:
    - service: 'warezddl'
      type: 'jsonEndpoint'
      enabled: true
      endpointURL: 'http://localhost:8777/dlacp/api/upload-entry'
      credentials:
        username: 'USER'
        password: 'PASS'
    - service: 'darklight.to'
      enabled: true
      headless: true # false: Chrome-Fenster beim Publish sichtbar lassen
      mappingPath: 'darklightto.mapping'
      credentials:
        username: 'USER'
        password: 'PASS'
    - service: 'data-load.me'
      enabled: false
      headless: true
      mappingPath: 'dataloadme.mapping'
      credentials:
        username: 'USER'
        password: 'PASS'
    - service: 'byte.to'
      type: 'ucms'
      enabled: false # aktivieren, sobald Credentials, Mapping und Templates eingerichtet sind
      mappingPath: 'ucms-byte.mapping'
      credentials:
        username: 'USER'
        password: 'PASS'
      ucms:
        baseURL: 'https://byte.to/'
        usePlainLinks: false # false: Crypter-/Containerlinks, true: direkte Hosterlinks
    - service: 'warezcx'
      type: 'jsonEndpoint'
      enabled: true
      endpointURL: 'https://api.warez.cx/upload/json/push'
      auth:
        type: 'bearer-token'
        bearerToken:
          token: 'WAREZ_CX_API_KEY'

Ein uCMS-Mapping kann nicht entfallen: Die Seite zeigt die Kategorie-IDs zwar in ihrer Navigation, Upper muss aber aus Release-Typ und Releasenamen eine einzelne Zielkategorie auswaehlen und diese in der UI lesbar anzeigen. Bei byte.to wurden die IDs aus der oeffentlichen Navigation https://byte.to/?p=news am 25.05.2026 uebernommen. label ist nur die UI-Beschriftung; gepostet wird weiterhin die numerische id:

Bei ausschliesslicher Nutzung der Upper-UI darf template in einer Kategorie leer bleiben, sofern fuer den Inhaltstyp ein UI-Template gespeichert und beim Upload-Ziel ausgewaehlt ist. Der normale upper CLI-Publish-Ablauf benoetigt dagegen weiterhin einen gueltigen template-Pfad im Mapping.

Fuer einen beobachtbaren Testlauf eines Browser-Publishers kannst du nur das
betroffene Ziel sichtbar schalten:

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

categories:
  - type: 'movie'
    id: '93'
    label: 'Filme - HD - 1080p'
    template: '/pfad/zum/ucms-message-template.txt'
    priority: 600
    match: ['(?:^|[ ._-])1080[pi](?:$|[ ._-])']

config/mappings/ucms-byte.mapping.yml enthaelt die sichtbaren Leaf-Kategorien fuer Filme, Television, Spiele, Musik/Audio und XXX sowie konservative automatische Regeln. Ziele ohne sicheren Titel-Marker koennen in der Upper-UI manuell ausgewaehlt werden. Fuer byte.to wurden Login und authentifizierte Upload-Maske am 25.05.2026 praktisch geprueft: Der Login akzeptiert email, password und action=Login; die Standardmaske unter ?p=upload liefert den readonly Account-Uploader und erwartet einen Multipart-POST mit action=Eintragen, password als optionalem Entpack-Passwort sowie download und mirror1 bis mirror9. Fuer password wird das bereits fuer die Archivdateien geltende archive.pw verwendet. Ein echter Upload-Eintrag wurde bei der Pruefung nicht abgesendet. Das Preset bleibt deaktiviert, bis ein Benutzer seine Credentials und Templates konfiguriert.

uCMS-Konfigurationsoptionen

Die Konfiguration bildet nur den bei byte.to praktisch bestaetigten Standardablauf ab. Nicht belegte Editier- oder Flag-Ablaufe werden nicht als Konfigurationsoptionen angeboten.

Option	Bedeutung / gesendetes Verhalten
service	Eindeutiger Name des Ziels in Upper und Upper-UI. Fuer jede uCMS-Seite einen eigenen Namen verwenden, z. B. byte.to.
type: ucms	Aktiviert den generischen Formular-Publisher fuer diesen Service.
mappingPath	Mapping-Datei mit den Kategorie-IDs der konkreten Seite sowie label/Routing-Regeln. Standard-Mappings sind eingebettet; eigene Dateien neben der Instanz oder im UI-Ordner ueberschreiben den Standard.
credentials.username, credentials.password	Werden bei byte.to nur zum Login als email/password verwendet. Der Standard-Upload uebernimmt uploader aus der angemeldeten Upload-Maske und versendet keine Account-Credentials im Artikel.
baseURL	Basis-URL der Zielseite. Der Publisher verwendet die bei byte.to bestaetigten Pfade ?p=userarea&location=login und ?p=upload.
archive.pw	Optionales Entpack-Passwort der erzeugten/konfigurierten Archive; derselbe Wert wird bei uCMS als Formularfeld password gesendet und ist nicht das Member-Login-Passwort.
usePlainLinks	false sendet pro Hoster dessen ersten Crypter-/Containerlink, true dessen ersten Direktlink. Das bestaetigte byte.to-Standardformular unterstuetzt download sowie mirror1 bis mirror9 (zehn Hoster-Slots).

Ein DarkLight-Mappingziel mit Pflichtpräfix sieht beispielsweise so aus:

categories:
  - type: 'movie'
    id: 'https://darklight.to/community/forums/filme.148/'
    fallback: true
    requirePrefix: true
    prefixes:
      - id: '40' # 2160p
        priority: 400
        match:
          - '(?:^|[ ._-])2160p(?:$|[ ._-])'
      - id: '39' # 1080p
        priority: 300
        match:
          - '(?:^|[ ._-])1080p(?:$|[ ._-])'

Weitere typische Modi:

# Altes Verhalten: CLI und UI dürfen publishen
publish:
  enabled: true
  publishCli: true
  publishUi: true

# Publishing komplett aus
publish:
  enabled: false
  publishCli: true
  publishUi: true

# CLI darf publishen, Upper-UI-Queue nicht
publish:
  enabled: true
  publishCli: true
  publishUi: false

Für die Upper-UI-Warteschlange müssen zusätzlich diese Bedingungen erfüllt sein:

• publish.enabled: true
• publish.publishUi: true oder Feld weglassen, wenn das alte Verhalten gewünscht ist
• der gewünschte Service hat enabled: true
• der Upload hat in der UI ein gespeichertes Publishing-Ziel
• der Upload wurde in die Warteschlange gesetzt und liegt dort mindestens 30 Sekunden

Bei JSON-Endpoint-Services sendet die UI nach der Wartezeit die gespeicherte Upload-JSON an endpointURL. Bei Fehlern wird der Eintrag auf failed gesetzt und der Fehlertext in der Upload-Liste sowie auf der Edit-Seite angezeigt.

Hinweis zu lokalen HTTP-Endpunkten: Basic Auth über http://localhost funktioniert, Resty kann dabei aber eine Sicherheitswarnung loggen. Für echte entfernte Endpunkte sollte https:// genutzt werden.

Wichtig:
Diese Module sind für fortgeschrittene Setups gedacht.
Wenn du nicht genau weißt, was du tust, lass die Standardeinstellungen (meist enabled: false) unverändert.

---

Zusammenfassung

Um mit go-upper sicher zu starten, solltest du in upper.config.yml:

1. license eintragen,
2. workmode (meist normal) setzen,
3. in path deine Scan‑, Work‑ und Result‑Ordner eintragen,
4. mindestens einen Filehoster mit Zugangsdaten aktivieren,
5. nach Bedarf Linkcrypter und Result‑Optionen (json/txt) konfigurieren.

Alles Weitere (Backup, Bandbreite, Content‑Grabber, Add-ons) kannst du Schritt für Schritt aktivieren, sobald dein Basis‑Workflow stabil läuft.