Motrix Turbo v2: Download-Kern ohne Oberfläche und MDXP als Protokoll
Motrix ist ein voll ausgestatteter Download-Manager mit übersichtlicher Oberfläche, der HTTP, FTP, BitTorrent und Magnet-Links unter Windows, macOS und Linux verarbeitet.
Auf einen Blick
- Was ist das?
- agalwood/Motrix baut seinen Download-Manager in v2 mit Electron, React und TypeScript neu, trennt den Kern von der Oberfläche und bedient Kommandozeile sowie Browser über MDXP. Der Text ordnet Beta-Stand, CLI, Plugin-Sandbox und Abgrenzung zu v1 ein.
- Für wen ist es gedacht?
- Motrix Turbo v2 lohnt sich für alle, die Downloads an mehreren Stellen brauchen, also eine Desktop-App am Arbeitsplatz und einen Kopfbetrieb auf dem NAS, und die Steuerung über @motrix/cli in Skripte einbinden wollen. Wer ein einzelnes Gerät mit fertiger Oberfläche und deutscher Sprache bedient, bleibt bei Motrix v1, denn v2 ist Beta, bietet nur vereinfachtes Chinesisch und Englisch und warnt selbst vor der unvalidierten Übernahme von v1-Daten.
- Darf ich es kommerziell nutzen?
- Erst prüfen. Die Lizenz dieses Repositorys ordnen wir nicht automatisch ein; lesen Sie vor jeder kommerziellen Nutzung die LICENSE-Datei.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich JavaScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Motrix Turbo v2: Kern ohne Oberfläche, MDXP als Protokoll
Motrix beschreibt sich in der Einleitung als moderner, voll ausgestatteter Download-Manager, der einfach zu bedienen bleibt. Die Repository-Metadaten weisen JavaScript als Hauptsprache aus, die Lizenz ist MIT, als Standardzweig dient master, und die Projektseite liegt unter motrix.app.
Die aktuelle Linie heißt Motrix Turbo und ist Motrix v2. Laut README wurde sie von Grund auf neu gebaut, mit Electron, React und TypeScript, bei erhaltenem Bedienkonzept der ersten Version. Die wichtigste architektonische Aussage steht gleich danach: Der Download-Kern ist unabhängig von der Oberfläche. Browser-Erweiterungen und Kommandozeilenwerkzeuge sprechen die Anwendung über MDXP an, ein offenes Protokoll auf Basis von JSON-RPC 2.0, ausgeschrieben Motrix Download eXchange Protocol. Erweiterungen laufen in isolierten Sandboxes.
Diese Trennung ist mehr als ein Implementierungsdetail. Sie erlaubt es, denselben Kern unter einer grafischen Oberfläche und ohne jede Oberfläche zu betreiben, und sie macht die Kommunikationsschnittstelle zum eigentlichen Produkt.
Beta-Stand von v2.0.0-beta.28 und die Warnung zur v1-Datenübernahme
Der Stand ist ausdrücklich eine Beta. Das README bittet, nach dem Durchlaufen der verbleibenden Freigabeschritte v2.0.0-beta.28 von der Releases-Seite zu laden und vor der Installation die Anmerkungen unter docs/release-notes/2.0.0-beta.28.md zu lesen. Veröffentlicht wurde diese Fassung am 28. August 2026, v2.0.0-beta.27 einen Tag zuvor und v2.0.0-beta.26 am 25. August 2026. Ein Abstand von ein bis drei Tagen zwischen Vorabversionen sagt mehr über das Tempo als über die Reife.
Deutlicher wird das Projekt bei der Datenübernahme. Vor dem Testen sollen vorhandene Motrix-Daten und Downloads gesichert werden. Die Migration von Motrix-v1-Daten ist laut README noch nicht validiert, und es wird ausdrücklich davor gewarnt, die einzige Kopie der v1-Daten mit dieser Beta zu verwenden. Empfohlen wird ein paralleler Test mit getrenntem Betriebssystemkonto, einem zweiten Rechner oder einem eigenen Docker-Datenverzeichnis.
Das ist die klarste Aussage im gesamten Dokument, und sie begrenzt den Einsatzkreis der Beta erheblich. Wer keine zweite Kopie seiner Sammlung anlegen kann, sollte die Finger von dieser Fassung lassen.
Funktionsliste: Tracker-Liste, SQLite-Sitzungen und Geschwindigkeitsprofile
Die Funktionsliste deckt das Übliche ab und geht an zwei Stellen darüber hinaus. BitTorrent läuft mit Auswahl einzelner Dateien innerhalb eines Torrents, Magnet-Links werden unterstützt. Die Verwaltung der Tracker-Liste ist eingebaut, aktualisiert sich selbst und prüft die Gesundheit der Einträge. Für Router gibt es UPnP und NAT-PMP, für die Bandbreite Obergrenzen in mehreren Geschwindigkeitsprofilen.
Sitzungen liegen in SQLite und werden nach einem Neustart wiederhergestellt. Bei einem Download-Manager ist das der Unterschied zwischen einem verlorenen und einem fortgesetzten Tag. Das Dashboard lässt sich mit Transferstatistiken, laufender Aktivität und Aufgabenkacheln anpassen. Hinzu kommen Systembenachrichtigungen samt eigenem Benachrichtigungszentrum in der Anwendung, ein System-Tray mit Autostart sowie die Behandlung von motrix:// und magnet: Links und die Zuordnung von .torrent Dateien.
Eine Grenze steht in derselben Liste: Die Oberfläche gibt es in vereinfachtem Chinesisch und Englisch, weitere Sprachen sind geplant. Wer Deutsch braucht, muss warten, und ein Termin dafür ist nicht angegeben.
Zwei Betriebsarten: Desktop-App und Headless-Server mit Weboberfläche
Aus demselben Kern entstehen zwei Betriebsarten. Die Desktop-App läuft unter macOS, Windows und Linux. Der Headless-Server kommt ohne Desktop-Umgebung aus, entweder direkt auf Node.js oder im Container, und bringt eine Weboberfläche für NAS-Geräte und Heimserver mit. Für die Kopplung entfernter Kommandozeilen- und Agenten-Clients nutzt er eine Gerätecode-Paarbildung.
Diese Zweiteilung ist der eigentliche Fortschritt gegenüber einem reinen Desktop-Downloader. Ein NAS kann die Downloads übernehmen, während die Steuerung vom Arbeitsplatzrechner aus erfolgt. Die Weboberfläche ist dabei kein Beiwerk, sondern auf einem Gerät ohne Bildschirm der einzige Zugang.
Zur Installation der Desktop-App verweist das README auf motrix.app und die Auswahl des passenden Pakets für das eigene Betriebssystem. Die für Mac-Nutzer empfohlene Variante ist im erfassten Text abgeschnitten, und eine Paketmanager-Alternative wird im README-Auszug nicht genannt. Wer v2 im Container ausprobieren will, findet im README nur den Hinweis auf Docker, aber kein fertiges Kommando.
@motrix/cli: motrix add, motrix watch --stats und motrix pair
Die Kommandozeile ist ein eigenständiges Paket. Installiert wird sie mit npm install -g @motrix/cli, laut README wird Node.js 22 oder neuer verlangt. Der Client erkennt eine lokal laufende Desktop-Anwendung selbstständig und kann sich mit entfernten Instanzen koppeln.
Die im README gezeigten Befehle sind kurz: motrix add https://example.com/file.iso --save-dir ~/Downloads legt einen Download an, motrix list zeigt die Liste, motrix watch --stats gibt den laufenden Fortschritt als NDJSON aus, und motrix pair --name my-nas koppelt mit einer entfernten oder headless Instanz. Der NDJSON-Strom ist der Punkt, an dem sich Motrix für Skripte eignet, weil sich der Fortschritt zeilenweise weiterverarbeiten lässt, statt eine Ausgabe zu zerlegen.
Wer Automatisierung plant, sollte die Node.js-Vorgabe im Blick behalten. Auf älteren Servern ist Node.js 22 nicht überall vorhanden, und das README nennt keine Abwärtsgrenze.
Plugin-SDK, QuickJS-Sandbox und motrix-plugin.json
Für Erweiterungen gibt es ein eigenes SDK mit vier npm-Paketen: @motrix/plugin-manifest-schema, @motrix/plugin-api, @motrix/plugin-cli und create-motrix-plugin. Der Arbeitsablauf im README besteht aus sechs Schritten: pnpm create motrix-plugin my-plugin, danach cd my-plugin && pnpm install, dann pnpm dev für einen Watch-Bau mit gestartetem Motrix, pnpm exec motrix-plugin validate zur Prüfung der Datei motrix-plugin.json, pnpm run pack für ein Paket unter dist/<id>-<version>.moext und pnpm exec motrix-plugin lint zur Kontrolle des fertigen Bündels.
Die Sandbox ist der interessantere Teil. Erweiterungen werden als einzelnes ES2020-Modul gebündelt und laufen in QuickJS ohne Node.js-Schnittstellen und ohne direkten Datei- oder Netzwerkzugriff. Aktivierungsereignisse, benötigte Fähigkeiten und auf Adressen beschränkte Host-Rechte werden in motrix-plugin.json deklariert, und Motrix zeigt diese Anfragen vor der Freigabe an.
Die Standardvorlage beginnt mit einem URL-Auflöser am Ereignis beforeCreate. Wer stattdessen eine Benachrichtigung nach Abschluss möchte, übergibt post-action hinter dem Projektnamen. Verfügbare Ereignisse sind beforeCreate, beforeFinalize, afterComplete und onError, der Zugriff auf die Laufzeit erfolgt über das virtuelle Modul motrix:plugin-api.
Abgrenzung zu Motrix v1 mit Aria2 und die MIT-Lizenz
Als Alternative bleibt Motrix v1, die stabile Linie. Sie folgt nach der bisherigen Projektdokumentation einem anderen Aufbau mit Electron, Vue und Aria2 als Download-Kern und kennt keine MDXP-Schnittstelle, keinen Plugin-Marktplatz und keinen Kopfbetrieb. Wer eine verlässliche Desktop-Anwendung braucht und die eigenen v1-Daten nicht riskieren will, fährt mit v1 besser, zumal die Migration nach v2 ausdrücklich noch nicht validiert ist. Umgekehrt bietet v2 alles, was dort fehlt.
Zur Einordnung der Erweiterungen: Die drei mitgelieferten Pakete tragen die Namen Filename Template für das Umbenennen nach Vorlage vor dem Speichern, Page Scraper für das Extrahieren direkter Dateilinks aus HTML-Seiten und URL Resolver als Grundlage für seitenbezogene Medienauflösung. Sie werden als signierte .moext-Pakete verteilt, und die Bestandsliste erscheint als öffentliche JSON-Datei unter dl.motrix.app/registry/plugins.json.
Das Repository steht unter MIT. Für die Nutzung heißt das: Nutzen, Kopieren, Verändern und Verteilen sind erlaubt, Gewährleistung und Haftung sind ausgeschlossen. Bei einer Beta, die selbst vor Datenverlust warnt, ist dieser Ausschluss keine Formalie, sondern die Bedingung, unter der man sie einsetzt.
Redaktionelles Fazit
Motrix Turbo v2 lohnt sich für alle, die Downloads an mehreren Stellen brauchen, also eine Desktop-App am Arbeitsplatz und einen Kopfbetrieb auf dem NAS, und die Steuerung über @motrix/cli in Skripte einbinden wollen. Wer ein einzelnes Gerät mit fertiger Oberfläche und deutscher Sprache bedient, bleibt bei Motrix v1, denn v2 ist Beta, bietet nur vereinfachtes Chinesisch und Englisch und warnt selbst vor der unvalidierten Übernahme von v1-Daten. Der erste Schritt ist deshalb keine Installation, sondern eine Kopie der vorhandenen Motrix-Daten und ein paralleler Test mit eigenem Docker-Datenverzeichnis.
Community-Notizen