So richten Sie Jellyfin nach dem Wechsel zu einem neuen Netzwerk neu ein

Eva Wong ist die technische Redakteurin und begeisterte Tüftlerin bei ZimaSpace. Als lebenslanger Geek mit einer Leidenschaft für Homelabs und Open-Source-Softwarehat sie sich darauf spezialisiert, komplexe technische Konzepte in verständliche, praxisnahe Anleitungenzu übersetzen. Eva ist überzeugt, dass Self-Hosting Spaß machen sollte und nicht einschüchternd sein darf. Mit ihren Tutorials hilft sie der Community dabei, Hardware-Setups zu durchschauen, vom Bau des ersten NAS bis zum sicheren Umgang mit Docker-Containern.

Baue Jellyfin nach einem Netzwerkwechsel neu auf, indem du zuerst den lokalen Dienstpfad wiederherstellst und anschließend Speichereinbindungen, Identität, DNS und Fernzugriff als separate Prüfpunkte validierst.

Ein neuer Router, ein neues Subnetz, VLAN oder eine neue DNS-Domain kann eine intakte Jellyfin-Datenbank fehlerhaft erscheinen lassen, weil Clients, Einbindungen und Reverse-Proxys nicht mehr denselben Pfad nutzen. Bewahre die alten Netzwerkinformationen und eine Kopie der Anwendungsdaten auf. Ziel ist ein klar definierter Pfad vom Client über den Dienst bis zu den Medien, mit einer klaren Abbruchgrenze für den Fall, dass das Netzwerk selbst die Fehlerquelle ist und nicht Jellyfin.

Notiere den alten Pfad, bevor du etwas änderst

Notiere die Serveradresse, den Hostnamen, das Subnetz, das Gateway, den DNS-Namen, die eingebundenen Medienpfade, das Reverse-Proxy-Ziel, den Zertifikatsnamen sowie alle Firewall- oder Portweiterleitungsregeln. Unterscheide zwischen lokalem und externem Streaming. Falls der alte Host noch verfügbar ist, exportiere die Jellyfin-Konfiguration und liste die Benutzer und Bibliotheken auf, bevor du neue Adressen vergibst.

Damit wird die Grundlage für den Neuaufbau geschaffen: Ein Benutzer erreicht den Dienst, der Dienst erreicht seine Datenbank und Medien, und Backups erreichen ihr Ziel. Richte nicht zuerst einen öffentlichen Port oder eine neue Proxy-Regel ein.

Stelle den lokalen Dienst unter einer stabilen Adresse wieder her

Richte für den Server eine DHCP-Reservierung oder eine statische Adresse ein und bestätige anschließend, dass die Jellyfin-Weboberfläche im selben LAN erreichbar ist. Überprüfe die Bind-Adresse des Dienstes und die Host-Firewall und teste einen lokalen Client, bevor du den DNS änderst. Wenn die App startet, aber die Bibliotheken leer sind, halte an und überprüfe den Speicherpfad, anstatt die Datenbank neu aufzubauen.

Jellyfins Migrationsanleitung betont, dass interne Daten pfadabhängig sind und die Containerpfade mit den gespeicherten Speicherorten der Medien übereinstimmen müssen (pfadabhängige Migrationsanleitung). Behandle eine Pfadabweichung als Topologiefehler, nicht als Metadatenfehler.

Einbindungen und Berechtigungen vor DNS wiederherstellen

Binde die Medien- und Sicherungsvolumes unter stabilen Pfaden ein und teste anschließend den Lesezugriff mit dem Jellyfin-Dienstkonto. Prüfe eine Datei pro Bibliothek und einen Schreibvorgang im Anwendungsdatenverzeichnis. Speichere Cache und heruntergeladene Coverbilder auf wiederherstellbarem Speicher, während Benutzermedien, Datenbank und Sicherungen auf geschützten Speicherbereichen bleiben.

Der Vorgang ist BESTANDEN, wenn ein Neustart die Einbindungen wiederherstellt, bevor Jellyfin startet, und ein Bibliotheksscan keine Warnungen zu fehlenden Dateien ausgibt. Wenn die Einbindung von einer interaktiven Anmeldung abhängt, korrigiere die Startreihenfolge, bevor du fortfährst.

Single board computer zimaboard2

Identität, DNS und Remotezugriff in dieser Reihenfolge wiederherstellen

Sobald die lokale Wiedergabe funktioniert, stelle den Hostnamen und den internen DNS-Eintrag wieder her. Teste einen Client mit dem Namen statt der IP-Adresse und prüfe anschließend den Reverse-Proxy oder das VPN von außerhalb des Heimnetzwerks. Halte Authentifizierung und Autorisierung getrennt vom Routing: Ein Anmeldefehler ist kein Beleg dafür, dass die neue Portweiterleitung falsch ist.

Starte einen Direct Play und eine Transkodierung mit der tatsächlichen Client-Auswahl. Notiere den beobachteten Endpunkt, den Wiedergabemodus und die Fehlerstelle. Ein Community-Migrationsfall eignet sich zum Vergleich von Pfad- und Netzwerkannahmen, aber verallgemeinere weder die Hardware noch die Routereinstellungen (Migrationsfallstudie).

Rollback und Erweiterungen klar festlegen

Bewahre den alten DNS-Eintrag, die Konfigurationssicherung und die bisherigen Netzwerkn notizen auf, bis lokale Wiedergabe, Benutzerzugriff, Remote-Routing und Wiederherstellung erfolgreich getestet wurden. Erweitere nur, indem du einen dedizierten Pfad hinzufügst - etwa ein separates VLAN für die Verwaltung oder eine zweite Netzwerkschnittstelle -, wenn der gemeinsam genutzte Pfad an Leistung verliert. Brich den Neuaufbau ab, wenn der Server keine stabile Adresse, dauerhafte Einbindungen oder einen getesteten Wiederherstellungsweg erhält; keine noch so umfangreiche Neukonfiguration der Clients behebt diese fehlenden Grundlagen.

NAS- und Servereinrichtung

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.