Nach dem die F1-WebSite (NextThree) ein neues Design bekommen hat, war der MediaBrowser als nächstes dran. Als im Heimnetz plex installiert war, fiel der Unterschied im Design noch deutlicher auf, und auch die UX fiel ab - war halt "selbstgemacht".
Die GrundIdee des MediaBrowsers ist simpel: alle Mediendateien liegen geordnet im Dateisystem, eine Jakarta-EE-Webanwendung auf Apache Tomcat stellt sie im Browser dar, Benutzerverwaltung, Passwörter und das ganze in der Cloud. Dabei blieb es. Nur das Design sollte sich ändern.
Mit dem N3 Theme gab es bereits ein brauchbares Design, und das Redesign des MediaBrowsers hat dann noch ein paar Anleihen für neue Features bei plex genommen.
Ein solches neues Feature ist die Startseite im N3-Theme — vier horizontale Scroll-Regale für zuletzt hinzugefügte Fotos, Filme, Musik und Videos.
Was der MediaBrowser kann
Fotobibliothek
Organisation in Ordner, Jahres- oder Event-basierte Galerieansicht, Thumbnails wg. Performance, Lightbox, Diashow, Upload direkt aus dem Browser.
🎬 Filmbibliothek
Alphabetisches Poster-Grid, Suchfunktion, TMDB-Metadaten (Cast, Regie, Bewertung), alternativ Info aus Wikipedia, Video-Overlay ohne Seitenwechsel.
🎵 Musikbibliothek
Interpreten-Kacheln mit Album-Cover aus ID3-Tags, Albumsicht per Interpret, Suchfunktion, Album-Player mit Trackliste im Browser.
📹 Videobibliothek
Heimvideos, Konzerte und Urlaubsschnipsel — analog zur Fotobibliothek nach Jahr und Event. Stillpicture, Informationen aus den mp4 Dateien.
Wie es angefangen hat
Die ersten Versionen des MediaBrowsers waren einfache JSP-Seiten — ein paar Servlets, die Dateilisten aus dem Filesystem lasen und in einem HTML-Grid ausgaben. Simples einheitliches Design, aber es lief. Und es wuchs.
Über die Jahre kam der Audioplayer hinzu, dann die Videobibliothek, dann Login-Schutz mit Tomcat FORM-Authentifizierung, dann Upload. W3.CSS hat dabei gute Dienste geleistet: einfach und unkompliziert.
Der Wendepunkt kam im Frühjahr 2026. Das N3-Theme — das im vorigen Blog-Eintrag für das F1-Projekt beschrieben ist — war der Ausgangspunkt für eine vollständige Migration. Alle Seiten einheitlich, eine Sidebar, ein Dark Theme, ein Grey Mode. Und gleichzeitig ein paar neue Features.
Die Filmbibliothek — TMDB und ffprobe
Die Filmbibliothek existierte funktional schon in einer ersten Version. Hier wollte ich neben dem N3 Look ein „Plex- Feature“: lokale MP4-Dateien kombiniert mit Metadaten aus der TMDB API — Poster-Bild, Beschreibung, Besetzung, Regie, Bewertung — alles ohne Abo, mit einem kostenlosen API-Schlüssel.
Dazu kommt ffprobe (aus dem ffmpeg-Paket): ein Kommandozeilenwerkzeug, das in Sekunden Laufzeit, Codec und Auflösung einer MP4-Datei ausliest — ohne die Datei zu öffnen. Der MediaBrowser ruft ffprobe beim ersten Aufruf einer Filmdetailseite auf und cached das Ergebnis dauerhaft. So erscheinen technische Details wie "2:14:33 · H.264 · 1920×1080" neben dem TMDB-Poster, ohne dass man je manuell Metadaten pflegen müsste.
Serien bekommen eine eigene Detailseite: aufklappbare Staffeln, Episodenlisten mit asynchron nachgeladenen Laufzeiten — nur das, was der Nutzer gerade aufklappt, wird berechnet.
Die Musikbibliothek — ID3-Tags als Datenquelle
Die Altversion der Musikbibliothek war technisch schon vollständig, die MP3-Dateien tragen ihre Album-Cover im ID3v2-Tag. Die Bibliothek liest diese Tags zur Laufzeit aus — Titel, Interpret, Album, und das Cover-Bild als JPEG-Blob.
Die Interpreten-Übersicht liest für jeden Künstler das erste gefundene MP3 und extrahiert dessen Cover. Das läuft beim ersten Aufruf durch einen Servlet-Cache, danach aus dem Speicher. Kein manuelles Pflegen, keine externe Datenbank — die Metadaten kommen aus der Musiksammlung selbst. Das Desgn wurde im N3 Look neu aufgelegt und der Player orientierte sich an iTunes.
Self-contained WAR
Eine weitere Umstellung: alle CSS-Dateien, Webfonts, Icons und das Favicon sind Teil der WAR-Datei — nicht mehr auf dem Server separat abgelegt. Das bedeutet: ./mvnw clean package baut alles in eine einzige deploybare Datei. Auf dem Produktionsserver genügt es, die WAR in Tomcats webapps/ zu legen.
Die einzige externe Konfiguration ist eine kleine XML-Datei (MediaBrowser.xml) in Tomcats Konfigurationsverzeichnis — sie enthält den Pfad zur Mediensammlung und den TMDB API-Schlüssel. Diese Datei ist bewusst nicht im Git-Repository, damit Credentials nicht versehentlich committet werden.
Technische Dokumentation
Zum MediaBrowser gibt es eine eigenständige HTML-Dokumentation — entstanden parallel zur N3-Migration, als der Überblick zu behalten anfing, Arbeit zu kosten. Sie deckt Installation, JSP-Architektur, Login/Logout/Timeout, Thumbnailing & Caching, TMDB-Integration und Umgebungskonfiguration ab.
- MediaBrowser Dokumentation Über MediaBrowser — Geschichte, Features,
- Screenshots Installation & Setup — Schritt für Schritt: Tomcat, WAR,
- Medienverzeichnisse JSP Namenskonzept — Architektur, Rollen, Datenfluss Login,
- Logout & Timeout — FORM-Auth, Session, Inaktivitäts-Timeout
- Thumbnailing & Caching — ThumbnailServlet, Disk-Cache, Cache-Strategie
- TMDB Integration — API-Schlüssel, Poster, Cast, Caching
- Umgebungskonfiguration — MediaBrowser.xml, ROOT-Pfad, Tomcat-Setup
Claude Code — diesmal mehr als Assistent
Beim N3-Redesign des F1-Projekts, das ich im vorigen Blog-Eintrag beschrieben habe, war Claude Code ein leistungsfähiger Entwicklungspartner: es hat migriert, refaktoriert, aufgeräumt. Aber ich habe das sehr kleinteilig und interaktiv gemacht.
Bei der Neuversion vom MediaBrowser bin ich hier etwas weiter gegangen und habe versucht in Zielen vorzugeben, „was“ das Ergebnis sein soll. Das „Wie“ - TMDB-Calls, HikariCP Connection Pool, ffprobe-Integration, Thumbnail-Servlet, dreistufiger Cache: das war Claude Code.
Meine Aufgabe war: Anforderungen formulieren, Konzepte entscheiden, visuelles Feedback geben und testen. Welche Features soll die Filmbibliothek haben? Wie soll die Serien-Detailseite aussehen? Passt der Abstand zwischen Poster und Cast-Liste? Ist die Sidebar im Grey Mode gut lesbar? Das sind Entscheidungen, die kein Werkzeug übernehmen kann — und die den Unterschied zwischen einer lauffähigen und einer brauchbaren Anwendung ausmachen.
Was sich dabei verändert hat: die Schwelle für Dinge, die man "mal eben macht", ist dramatisch gesunken. Eine vollständige Installationsanleitung schreiben? Früher ein Nachmittag, wenn man es überhaupt angegangen wäre. Jetzt: ein Gespräch. Alle JSP-Dateinamen nach einem einheitlichen Schema umbenennen und jede Referenz in allen Dateien aktualisieren? Früher ein riskantes Shell-Skript oder gar nicht. Jetzt: ein Auftrag und ein Review. Die gesamte HTML-Entwicklerdokumentation — sieben Seiten, vollständig im N3-Stil mit Grey-Mode-Toggle: Claude Code macht es einfach.
Das ändert nichts daran, dass man den Code lesen muss. Wirklich lesen. Jede Datei, die Claude Code schreibt, habe ich gelesen — nicht als Kontrolle, sondern um zu verstehen, was in der eigenen Anwendung passiert. Der Code ist erst dann wirklich meiner, wenn ich ihn kenne.