FAQ
Die Karten beantworten typische Rückfragen zur Architektur, zu Quellen und zum praktischen Ablauf.
Nein. Autofetch bündelt bestehende Quellen und macht sie gemeinsam durchsuchbar und automatisierbar.
Einordnung: Autofetch ersetzt keine Quelle, sondern verbindet mehrere Quellen mit Suche, Regeln und Job-Steuerung.
Praxis: Du suchst nicht in „autofetch-Inhalten“, sondern in den von dir angebundenen Providern und Feeds.
Nein. Der Server verwaltet Suche, Regeln und Jobs. Die Ausführung übernimmt immer ein verbundener Client.
Architektur: Server und Ausführung sind bewusst getrennt.
Praxis: Auch wenn der Client auf derselben Maschine läuft, wird der Download als Job an einen Client gesendet und nicht direkt vom Server ausgeführt.
Die Query bleibt bestehen. Autofetch prüft weiter und erzeugt später einen Job, sobald ein passender Treffer auftaucht.
Vorteil: Du musst nicht selbst daran denken, die Suche später noch einmal zu starten.
Praxis: Eine vorbereitete Query kann tagelang bestehen bleiben und erst dann feuern, wenn die Quelle einen passenden Treffer liefert.
Clients können auf Windows, macOS und Linux laufen, inklusive ARM-Systemen wie Raspberry Pi.
Formfaktoren: GUI, Weboberfläche oder komplett headless sind möglich.
Praxis: Dadurch kann ein kleiner Client im Netzwerk Downloads ausführen, während du die Steuerung bequem über das Web-Interface machst.
Aktuell u. a. Mediathek, IRC/XDCC, GitHub, GitLab, RSS-Feeds und JSON-Feeds.
Prinzip: Alle Quellen werden in ein gemeinsames Such- und Jobmodell überführt.
Praxis: Du brauchst im Alltag keine komplett andere Bedienung, nur weil ein Treffer aus einer Mediathek statt aus GitHub oder IRC stammt.
Ja. Der Client kann öffentlich heruntergeladen werden, und die Nutzung startet nach Login und Pairing.
Öffentlich: Die Download-Seite ist frei zugänglich, und der Client ist als Open-Source-Projekt auf GitHub einsehbar.
Praxis: Du lädst den Client ohne Login herunter. Für Pairing, Verwaltung und Nutzung meldest du dich anschließend im Webinterface an.
