Ein Medienlink ist noch kein Stream.

Wer einen YouTube- oder SoundCloud-Link auf dem Smartphone öffnet, sieht eine Webseite oder eine App. Ein DLNA-Player benötigt dagegen eine direkt abrufbare Mediendatei in einem Format, das er versteht. Dazwischen liegt die eigentliche Arbeit von PlayOnDLNA.

Die kurze Fassung lautet: Die Android-App löst den geteilten Link auf, wählt passende Video-, Audio- und Untertitelspuren aus, bereitet daraus eine kompatible Datei vor und stellt sie im lokalen Netzwerk bereit. Anschließend teilt sie dem Player mit, wo diese Datei liegt und dass er sie abspielen soll.

Der gesamte Weg vom Link zum Player

Geteilter Medienlink
        |
        v
NewPipe Extractor: Metadaten und direkte Stream-Adressen
        |
        v
Auswahl: Video + Audio + optional Untertitel
        |
        v
Download per HTTP Range und Aufbereitung mit FFmpeg
        |
        v
Fertige MP4-, M4A- oder MP3-Datei im App-Cache
        |
        +---------------- lokaler HTTP-Datenstrom ----------------+
        |                                                         |
        v                                                         v
PlayOnDLNA -- UPnP/AVTransport-Steuerung --> DLNA-Player lädt Datei

Das Diagramm zeigt zwei verschiedene Verbindungen zum Player. Über UPnP AVTransport steuert PlayOnDLNA die Wiedergabe. Über HTTP lädt der Player die Mediendaten direkt vom Android-Gerät. Dass eine Verbindung funktioniert, sagt deshalb noch nichts über die andere aus.

1. Aus einem Webseiten-Link werden direkte Medienquellen

Ein geteilter Link zeigt normalerweise nicht direkt auf eine MP4-Datei. Die Zielseite kann Skripte, verschiedene Qualitätsstufen, getrennte Video- und Audiospuren oder adaptive Streamingformate verwenden.

PlayOnDLNA verwendet den NewPipe Extractor, um den unterstützten Dienst zu erkennen und die verfügbaren Informationen abzurufen. Dazu gehören unter anderem Titel, Laufzeit, Vorschaubilder sowie direkte Adressen für Video, Audio und Untertitel. NewPipe spielt das Medium nicht ab und übernimmt auch nicht den eigentlichen Download; es liefert der App die Informationen, die sie für die nächsten Schritte benötigt.

Dieser Schritt erklärt, warum ein Link in einem Browser funktionieren kann, in PlayOnDLNA aber nicht: Inhalte können entfernt, regional beschränkt oder nur nach einer Anmeldung verfügbar sein. Außerdem ändern Plattformen regelmäßig ihre Webseiten und Schnittstellen. Dann muss häufig zuerst die Extraktion angepasst werden.

2. Kompatibilität ist wichtiger als die größte Zahl

Die höchste angebotene Auflösung ist nicht automatisch die beste Wahl für einen Fernseher oder Kodi. Ein Container wie MP4 sagt außerdem noch nicht, welcher Video- oder Audiocodec darin steckt.

PlayOnDLNA berücksichtigt die gewählte maximale Videoqualität und bevorzugt eine Kombination, die von vielen Renderern verstanden wird:

Video als MP4 mit H.264/AVC
Audio als M4A/MP4 mit AAC
möglichst die originale Audiospur, ansonsten eine zur Gerätesprache passende Spur
SRT-Untertitel in der Gerätesprache, mit Englisch als Rückfalloption

Ist keine bevorzugte Variante verfügbar, verwendet die App einen passenden Rückfall. Das erhöht die Chance, den Inhalt überhaupt abspielen zu können, kann bei ungewöhnlichen Codecs aber auch die Grenze eines älteren Players sichtbar machen.

3. Warum Video und Audio oft getrennt geladen werden

Viele Plattformen liefern hohe Videoqualitäten ohne Tonspur aus. Audio und Video liegen dann unter verschiedenen Adressen. Manche moderne Renderer können solche getrennten Spuren über adaptive Formate wie HLS oder DASH selbst verarbeiten. Das gehört jedoch nicht zu den Fähigkeiten, auf die sich PlayOnDLNA bei beliebigen DLNA-Playern verlassen kann. Deshalb bereitet die App eine einzelne, möglichst breit kompatible Mediendatei vor.

PlayOnDLNA lädt progressive Quellen in mehreren Bereichen parallel. Dafür ermittelt die App die Dateigröße, fordert mit HTTP-Range jeweils klar begrenzte Bytebereiche an und setzt die Teile in ihrer ursprünglichen Reihenfolge zusammen. Diese Technik beschleunigt große Downloads, setzt aber voraus, dass die Quelle Range-Anfragen korrekt unterstützt.

Je nach Liefermethode kann FFmpeg eine Audiospur auch direkt aus der entfernten Quelle lesen. Entscheidend ist das Ergebnis: Bevor das Medium als abspielbereit gilt, existiert eine vollständige lokale Ausgabedatei.

4. FFmpeg baut eine rendererfreundliche Datei

FFmpeg führt die ausgewählten Bestandteile zusammen. Dieser Vorgang heißt Muxing: Video, Audio und gegebenenfalls Untertitel werden in einen gemeinsamen Container geschrieben, ohne das kompatible H.264-Video unnötig neu zu codieren.

Eine bereits kompatible AAC-Audiospur wird ebenfalls kopiert. Eine ungeeignete Audiospur konvertiert PlayOnDLNA dagegen zu AAC. Optional können SRT-Untertitel als mov_text in die MP4-Datei eingebettet werden; die externe SRT-Datei kann zusätzlich separat bereitstehen. faststart verschiebt die für den Wiedergabestart benötigten MP4-Metadaten an den Dateianfang.

Reine Audiodateien werden als MP3 oder M4A gespeichert. Das fertige Medium, seine Metadaten, das Vorschaubild und mögliche Untertitel bilden anschließend einen Eintrag in der lokalen Bibliothek. Dadurch muss ein bereits vorbereitetes Medium beim nächsten Abspielen nicht erneut verarbeitet werden. Bibliothek und Dateien liegen im App-Cache und teilen dessen Lebenszyklus.

5. Wie PlayOnDLNA den Player findet

Die Gerätesuche läuft über SSDP, das Discovery-Protokoll von UPnP. Die App sendet eine M-SEARCH-Anfrage an die Multicast-Adresse 239.255.255.250:1900. Geräte antworten mit der Adresse ihrer XML-Gerätebeschreibung.

Aus dieser Beschreibung liest PlayOnDLNA den sichtbaren Gerätenamen und die angebotenen Dienste. Besonders wichtig ist die Control-URL des Dienstes AVTransport. Nur ein Gerät, das im lokalen Netzwerk gefunden und über diesen Dienst angesprochen werden kann, lässt sich von der App starten und steuern.

Multicast wird in Gastnetzen, VLANs oder WLANs mit aktivierter Client-Isolation häufig blockiert. In diesem Fall können Smartphone und Player beide Internetzugang haben und sich trotzdem nicht gegenseitig entdecken.

6. Das Smartphone wird zum lokalen Medienserver

Für die Wiedergabe startet PlayOnDLNA einen kleinen HTTP-Server auf einer zufällig gewählten Portnummer. Die Adresse enthält die lokale IPv4-Adresse des Android-Geräts, zum Beispiel:

http://192.168.1.42:49152/media-id/video.mp4

Zusammen mit dieser URL erzeugt die App DIDL-Lite-Metadaten. Darin stehen unter anderem Titel, Laufzeit, Medientyp, MIME-Type und protocolInfo. Diese Angaben helfen dem Renderer zu entscheiden, wie er die Ressource behandeln soll.

Der HTTP-Server unterstützt vollständige Antworten (200 OK) und Bytebereiche (206 Partial Content). Header wie Content-Length, Content-Range und Accept-Ranges erlauben dem Player, vor- oder zurückzuspringen, ohne die gesamte Datei erneut anzufordern. DLNA-spezifische Content-Features und der Transfermodus kennzeichnen die Antwort zusätzlich als Stream im lokalen Netz.

PlayOnDLNA ist damit zwar die Medienquelle für den Player, veröffentlicht aber keinen externen Cloud-Dienst. Die Datei verlässt das Smartphone nur über das lokale Netzwerk.

7. Steuerung und Datenübertragung bleiben getrennt

Zum Start sendet PlayOnDLNA zwei SOAP-Anfragen an die AVTransport-Control-URL des Players:

SetAVTransportURI übergibt die lokale HTTP-Adresse und die DIDL-Lite-Metadaten.
Play fordert die Wiedergabe mit normaler Geschwindigkeit an.

Danach verbindet sich der Player mit dem Smartphone und ruft die Datei über HTTP ab. PlayOnDLNA schiebt die Videodaten also nicht innerhalb der SOAP-Anfrage zum Fernseher. Weitere Befehle wie Pause, Stop, nächster oder vorheriger Eintrag laufen wieder über den Steuerungsweg.

Diese Trennung ist der wichtigste Schlüssel zur Fehlersuche:

Beobachtung	Wahrscheinlicher Abschnitt
Der Link wird nicht erkannt	Dienst-Erkennung oder NewPipe-Extraktion
Download oder Vorbereitung bricht ab	Quellserver, Range-Unterstützung, Speicher oder FFmpeg
Der Player erscheint nicht	SSDP, Multicast oder Netzwerktrennung
Der Player erscheint, startet aber nicht	AVTransport, Metadaten oder Formatunterstützung
Der Player reagiert auf Play, lädt aber nichts	lokale IP-Adresse, Port, Firewall oder HTTP-Erreichbarkeit
Wiedergabe startet und bricht reproduzierbar ab	Range-Verhalten, Codec-Unterstützung oder Netzwerkwechsel

Lokal bedeutet nicht offline

Der Weg vom Android-Gerät zum Player bleibt lokal. Stammt das Medium von einer Onlineplattform, benötigt PlayOnDLNA für Extraktion und Download trotzdem eine Internetverbindung. Es gibt keinen Cloud-Relay von PlayOnDLNA und keinen zusätzlichen Server, den man einrichten müsste.

Das erklärt auch die absichtliche Verwendung von unverschlüsseltem HTTP im LAN: Viele DLNA-Renderer erwarten genau diesen Transport und könnten mit einem selbst signierten HTTPS-Zertifikat nichts anfangen. Die öffentliche Medienquelle bleibt davon getrennt; der lokale Player erhält ausschließlich die Adresse des vorbereiteten Mediums auf dem Smartphone.

Ein Fehlerbericht, mit dem man arbeiten kann

App-Version:
Android-Version und Smartphone:
Player-Hersteller und -Modell:
Medienquelle und Inhaltstyp:
Gewählte Qualität und Untertiteleinstellung:
Netzwerkaufbau, Gastnetz oder VLAN:

Letzter erfolgreicher Schritt:
1. Link erkannt
2. Download abgeschlossen
3. Aufbereitung abgeschlossen
4. Player gefunden
5. Wiedergabe gestartet

Erwartetes Verhalten:
Tatsächliches Verhalten:
Reproduzierbar: immer / manchmal / einmalig

Veröffentliche keine privaten Medienlinks oder ungeprüften vollständigen Logs. Entferne sensible Angaben, ohne die für das Problem entscheidenden technischen Informationen zu verlieren.

Die Projektseite von PlayOnDLNA fasst die Funktionen zusammen. Quellcode, aktuelle Voraussetzungen und vorhandene Fehlerberichte stehen im Repository. 🌶️