Jump to content

UPnP Problem


grauix

Recommended Posts

Hallo,

ich habe bei dem Media Server UPnP aktiviert. Ich wollte nun auf meine Fire TV box streamen. Dafür habe ich auf der Fire TV box den VLC Player installiert. Der Player findet zwar den Media Server aber keinerlei Inhalte. Im Webinterface vom Media Server werden aber unter "Medien" alle bereitgestellten Datein (sind alles mpg-Dateinen) angezeigt.

Ich verwende parallel noch TVersity, das funktioniert problemlos. Habt ihr eine Idee woran das liegen kann?

Link to comment

Kann die Fire TV box eventuell nicht mit MPEG2 umgehen?

Der DMS Transcodiert bei UPnP nicht. Aber manche anderen UPnP Server machen das wenn der Client nicht mit dem Format umgehen kann.

Link to comment
vor 4 Stunden schrieb Tjod:

Der DMS Transcodiert bei UPnP nicht.

 

..aber er benennt alle Endungen um in ein Format von dem er der Ansicht ist das der Client es verstünde.

Meistens eben oder im Zweifelsfalle .mpg

Man kann ihn anweisen eine andere Endung zu senden, das ist aber ziemlich kompliziert, da müsst ich mich erst wieder "draufschaffen".

Hat aber nur Sinn wenn gaanz sicher das andere Endung die Lösung wäre.

 

Diese Erfahrungen sammelte ich hier*.

Leider bringt der neue DMS auch in diesem UPnP Falle keinerlei Besserung, gleich langsam, UHD hakelt oft.

Link to comment

 

14 hours ago, grauix said:

Dafür habe ich auf der Fire TV box den VLC Player installiert. Der Player findet zwar den Media Server aber keinerlei Inhalte. Im Webinterface vom Media Server werden aber unter "Medien" alle bereitgestellten Datein (sind alles mpg-Dateinen) angezeigt.

 

Die Medien-Seite des DMS Webinterface spiegelt zwar das UPnP-Angebot wieder. Der DMS greift dafür aber intern direkt  auf die Strukturen zu, nicht via UPnP. Der ist doch nicht blöd :). Früher war der RS in der Hinsicht sein eigener Client, d.h. er hat sich selbst über Netzwerk-Funktionen bzw. localhost versorgt. Das habe ich dann abgeschafft.

 

Während der VLC unter Windows alles anzeigt (sogar in mehrfacher Ausfertigung, siehe unten) und ich auf alles zugreifen kann, verhält er sich hier auf einem Fire Tablet ähnlich wie beschrieben. Es gibt zwei Einträge "DVBViewer Media Server". Beim ersten komme ich in den Videos-Ordner, aber danach ist Schluss. Z.B. Videos -> Alben kriege ich nicht geöffnet.

 

Der zweite Eintrag für den DVBViewer Media Server liefert mir direkt (also ohne Unterordner) die DMS-Senderliste, und die Einträge funktionieren auch.

 

Keine Ahnung, was sich die Android-VLC-Version bei ihrem UPnP-Handling denkt. Es kommt mir ziemlich unausgereift vor. Der Android-VLC ist ja noch im Beta-Stadium, oder?

 

Wie auch immer: Danach habe ich BubbleUPnP auf dem Fire HD6 installiert. Damit werden die UPnP-Strukturen des DMS sauber abgebildet, und man kann sich einen Player aussuchen, der die Wiedergabe übernimmt, also auch den VLC, der auf diese Weise kein Problem mit MPG-Dateien hat.

 

14 hours ago, Tjod said:

Der DMS Transcodiert bei UPnP nicht.

 

Suche mal in die uPnPProfilesV2.xml nach "transcode". Dort findest du z.B. unter <LiveExtensions>

<Ext name=".mp2">
  <MediaFormat mime-type="video/x-mp3" special="" alias=".mp3" transcode="-1" hassize="0" allaudio="0" bufsize="0">*</MediaFormat>
  <MediaFormat mime-type="video/mpeg" special="" alias=".mp3" transcode="-1" hassize="0" allaudio="0" bufsize="0">*</MediaFormat>
  <MediaFormat mime-type="video/mp2" special="" alias="" transcode="0" hassize="0" allaudio="0" bufsize="0">*</MediaFormat>
</Ext>

Wenn es sich um einen Radiosender mit MP2 Audio handelt, bietet der DMS ihn in drei Varianten an. Zwei davon mit unterschiedlichem Mime Type beinhalten Transkodierung nach MP3. Der Client kann sich eine aussuchen. Der DVBViewer (Wiedergabe -> UPnP Server) nimmt die erstbeste Möglichkeit. Der VLC nimmt unter Windows alle drei, d.h. zeigt den Sender dreimal an.

 

9 hours ago, craig_s said:

.aber er benennt alle Endungen um in ein Format von dem er der Ansicht ist das der Client es verstünde.

 

Der Mime Type im HTTP Response Header dürfte auch Gewicht haben. Aber es hängt letztendlich vom Client ab, was er wie auswertet.

 

9 hours ago, craig_s said:

Leider bringt der neue DMS auch in diesem UPnP Falle keinerlei Besserung, gleich langsam, UHD hakelt oft.

 

Grundsätzlich funktioniert UPnP mit den bei mir verfügbaren Clients abgesehen vom Android-VLC gut (DVBViewer, Kodi, Windows-VLC, BubbleUPnP, in Grenzen Windows Media Player). UPnP-fähige Fernsehapparate oder sonstigen neumodischen Consumer-Kram habe ich nicht. Der Fall wird gerade bearbeitet. Ansonsten lasse ich meine Finger vom UPnP-Code und auch der uPnPProfilesV2.xml, da ich nicht weiß, aus welchen Erfahrungen heraus das entstanden ist und was Lars sich dabei gedacht hat. Die Gefahr ist mir zu groß, dass bei Änderungen alles mögliche landauf und landab umfällt. Oder anders gesagt, ich greife da nur ein, soweit ich es selbst testen kann oder es einen engagierten/qualifizierten Tester wie Basic.Master gibt (der selbst programmiert) und ich die Auswirkungen überschauen kann.

 

Link to comment
Quote

Danach habe ich BubbleUPnP auf dem Fire HD6 installiert. Damit werden die UPnP-Strukturen des DMS sauber abgebildet, und man kann sich einen Player aussuchen, der die Wiedergabe übernimmt, also auch den VLC, der auf diese Weise kein Problem mit MPG-Dateien hat.

Stellt sich die Frage, warum das nicht auch mit DVBViewer_eigenen_Mitteln geht.

Link to comment

UPnP/DLNA ist nun mal ein ziemlich aufwändiges Protokoll. Zum Durchsteigen muß das einer schon lange studiert haben.

 

Ich konnte auf der uPnPProfilesV2.xml zwar nach zahlreichen Versuchen die mime-types ändern, das brachte mich aber kein Stück weiter.

Bubble zeigt das Live-TV in der Hälfte Zeit zu laden geht, frag sie doch nach dem Code.. :whistle:

 

Der eigentliche Hemmschuh liegt meiner Erfahrung nach weiter vorne, wenn man es so sieht:

- eine Datei auf der Festplatte ist per UPnP in 3-7 sec geladen, mpeg2, H-264, UHD egal

- DVBViewer lädt einen Sender in 1-3 sec, mpeg2, H-264, UHD egal

 

Jetzt einfach dazwischen die Brücke bauen!

Receiver handeln UPnP so: "Der Receiver gaukelt dem Client beim UPnP streaming einfach vor das es sich beim Live-TV um eine gewöhnliche Datei handelt die praktisch kein Ende hat". -> Wichtig - aber eben doch ein Ende!

 

Eine Datei ohne Ende (weil sie gerade geschrieben wird) kann per UPnP nicht übertragen werden, leider!

Also müßte auch der neue DMS das können: Explorer überlisten das dieser denkt bzw. behauptet die Datei hätte irgendwann ein Ende. So wird das dann ins UPnP eingespeist, Fall gelöst.

Link to comment

@grauix. Da hier gerade "Experten" dein Thema für eine Grundsatzdiskussion über UPnP benutzen, die für dein Problem nicht relevant ist: Hier steht eine mögliche Lösung (bevor sie untergeht). Auf weiteres werde ich hier erst mal nicht mehr eingehen.

Link to comment

Naja, für mich ist eigentlich die Ausgangslage schon unzureichend beschrieben ;)

 

Quote

ich habe bei dem Media Server UPnP aktiviert. Ich wollte nun auf meine Fire TV box streamen.

Ja wie denn? Der DMS ist Media Server, so viel ist klar. Die Fire TV Box aber anscheinend nicht der Client, denn das ist die auf der Box installierte App wie z.B. Kodi oder hier anscheinend der VLC Player. Ich sehe bei mir das auch2x als Fire TV und als Kodi. Wer oder was ist UPnP Controller?

 

Ich habe schon immer Bubble UPnP empfohlen :D

Link to comment

Noch mal ganz zurück zum Anfang:

 

On 21.4.2017 at 7:57 PM, grauix said:

Der Player findet zwar den Media Server aber keinerlei Inhalte. Im Webinterface vom Media Server werden aber unter "Medien" alle bereitgestellten Datein (sind alles mpg-Dateinen) angezeigt.

 

Ich weiß jetzt, warum der Android-VLC nicht mit den vom DMS gelieferten UPnP-Strukturen klarkommt. Die Erklärung findet sich hier:

 

Quote

Beim Debuggen stellt sich (wie vermutet) heraus, dass die Implementierung in dem Gerät ein Problem mit der Raute "#" als Bestandteil der Object-ID hat: Alles hinter der Raute in der Object ID wird verworfen

 

Den Link hatte ich schon weiter oben angegeben Kurz gesagt mag der Android-VLC ebenso wie das TechniSat DigitRadio 500 das vom DMS verwendete Trennzeichen '#' nicht. Ich vermute, dass es irgendeine UPnP-Programmbibliothek mit dieser Eigenart gibt, die gerne hier und da verwendet wird.

 

Nach den Vorüberlegungen und Vorarbeiten in letzter Zeit ließ sich nun relativ schnell ein Versuchsaufbau realisieren, der das Trennzeichen im DMS-UPnP-XML-Output durch ein '$' ersetzt und beim UPnP-XML-Input wieder zurück durch ein '#'. Damit lassen sich alle DMS-UPnP-Inhalte direkt im Android-VLC ohne BubbleUPnP abrufen.

 

Im nächsten DMS-Release wird die Möglichkeit zumindest als Tweak zur Verfügung stehen. Generell ändern möchte ich das Trennzeichen nicht, da unbekannt ist, welche UPnP-Clients welche Trennzeichen nicht mögen. Das müsste erst allerorten überprüft werden.

 

Nichtsdestotrotz hat der Android-VLC bei der Wiedergabe der Inhalte Schwächen aufzuweisen. MPG-Wiedergabe geht gut, auch Springen. Aber mit Remote TS-Dateien funktioniert Springen nicht, weil der VLC die Länge nicht erkennt. Und das liegt sicherlich nicht am DMS. Der VLC kann nämlich auch direkt (also ohne DMS) auf Mediadateien in Windows-Freigaben zugreifen. Und da hat er mit TS-Dateien das gleiche Problem.

 

Insofern könnte man erwägen, den VLC durch BubbleUPnP plus einen nicht UPnP-fähigen Player wie den MXPlayer zu ersetzen, der mit Remote TS-Dateien besser zurechtkommt.

 

Link to comment

Nächstes Problem: Der Android-VLC zeigt keine UPnP-Radiosender an. Die DMS-Strukturen für Radio sind zwar komplett vorhanden, aber leer.

 

Wie ein kurzer Versuch zeigt, liegt es an den hier zitierten Einträgen in der uPnPProfilesV2.xml. Es kam mir schon immer reichlich schräg vor, für Radiosender einen Video Mime Type anzugeben. Wenn ich Video durch Audio ersetze, weiß der Android-VLC, was Sache ist und zeigt die Radiosender an.

 

Allerdings stellt sich auch hier wieder die Frage: Warum hat Lars das so gemacht? Ein Versehen ist es vermutlich nicht. Es muss Clients gegeben haben, die das erforderten.

Link to comment

Auf jeden Fall hat es die gegeben mit Betonung auf hat. Wärend meiner 'Pfuscherei' fiel mir auf das doch recht viel sehr veraltet ist. Die Geräte gibts kaum noch.

Beispiel, obwohl mein TV ein "Samsung UE" ist wurde er scheints nicht richtig erkannt: der "Samsung UE" Bereich unten hatte keinerlei Einfluss aufs Streaming, ich konnte ihn ändern, ergänzen, versümmeln oder ganz weglassen nichts änderte sich. Später habe ich der Übersichtlichkeit halber die uPnPProfilesV2.xml sogar stark gekürzt und den gesamten </profile> 'Geräte' Teil rausgenommen d.h. mit dem Default Profile von .png endete die xml:

 

...
<Ext name=".png">
          <MediaFormat mime-type="image/png" special="" maxWidth="160" maxHeight="160">PNG_TN</MediaFormat>
          <MediaFormat mime-type="image/png" special="" maxWidth="4096" maxHeight="4096">PNG_LRG</MediaFormat>
        </Ext>
      </PhotoExtensions>
    </profile>
  </profiles>

 

Durch Änderung des Default Profile von .ts konnte ich RS andere mime-types an den Samsung schicken lassen, der TV verstand sogar einiges mehr als mpg als Video extention, das brachte aber leider keine Besserung. Ich hatte sogar mit einem Tool den kompletten MediaFormat string aus meinem TV ausgelesen den er bei ts (alias mpg) erwartet, der unterschied sich von dem in der xml, brachte auch nichts.

 

Fazit: Am Ende wunderte ich mich doch wieviel man in der xml umstellen kann und nichts passiert.

Trotzdem nicht zur allgemeinen Nacharmung empfohlen.. ;)

Link to comment

Was der DMS aus der uPnPProfilesV2.xml verwendet, hängt vom User Agent ab. Den sieht man nur im svcdebug.log, wenn im Webinterface Konfiguration -> UPnP -> UPnP Debug Logging eingeschaltet ist - die Einstellung hat nicht über das Stoppen des DMS hinaus Bestand, weil dabei sehr viel gelogged wird!

 

Danach muss man im Log nach "UPnP post" suchen. Für den Android-VLC erhalte ich zum Beispiel:

 

TPNPWebserver        UPnP post        Linux/3.10.61-g52cf9a0, UPnP/1.0, Portable SDK for UPnP devices/1.6.19

 

Für den Samsung UE lautet die Angabe in der uPnPProfilesV2.xml <UserAgent>.*SEC_HHP.*</UserAgent>. Ich vermute, dass die Sternchen wie bei Dateimasken für eine beliebige Zeichenfolge stehen. Da die Angabe beim Vergleich mit dem User Agent aus dem HTTP Request Header als regulärer Ausdruck verwendet wird, müsste man die genaue Wirkung erst mal recherchieren - ich kenne mich damit nicht ausreichend aus.

 

Die Angelegenheit ist ziemlich verwirrend, da der DMS zusätzlich bestimmte Client-Typen hardgecodet (also nicht auf Basis der uPnPProfilesV2.xml ) unterscheidet. Wenn z.B. im User Agent String die Sub-Strings 'DLNADOC/1.50' oder 'SEC_HHP' vorkommen, wird als Typ upnpSamsung1 notiert, und das steht auch im Log direkt unter dem User Agent als

 

TPNPWebserver        getclienttype    upnpSamsung1

 

Das hat dann Auswirkungen darauf, wie XML-Antworten an Clients formuliert werden. Soweit ich sehen kann, beeinflusst der Samsung-Typ nur die Angabe von Vorschaubildchen-URLs.

 

Die uPnPProfilesV2.xml bestimmt dagegen eher, mit welchen Formatangaben Medieninhalte übermittelt werden, ob sie transkodiert werden sollen und sowas.

 

Was Lars sich da ausgedacht hat, ist also ein ergiebiger Forschungsbereich, der noch Generationen von Historikern beschäftigen wird :)

 

Link to comment
vor 3 Stunden schrieb Griga:

Für den Samsung UE lautet die Angabe in der uPnPProfilesV2.xml <UserAgent>.*SEC_HHP.*</UserAgent>. Ich vermute, dass die Sternchen wie bei Dateimasken für eine beliebige Zeichenfolge stehen.

 

merkwürdig der . hinter HHP. Weil im user agent steht immer HHP_

Habe ich aber schonmal ohne den Punkt versucht, brachte nichts.

 

In der Tat, bei mir heisst es genau das:

TPNPWebserver        UPnP post        DLNADOC/1.50 SEC_HHP_[TV] UE55JU6850/1.0 UPnP/1.0
TPNPWebserver        getclienttype    upnpSamsung1

 

im Anhang 2 svcdebug.log's die ich kurz gehalten habe:

Also DMS gestartet, UPnP Logging eingeschaltet,

im TV per Input-Menü erst den Server gewählt dann auf 'SES UHD Demo' Kanal (brauchte 2-4 Anläufe bis er lief)

ca. 1 min laufen lassen, Menü-Exit, DMS stoppen

 

beim "DMS" log war DMS der Server (langsam beim Kanal-Switchen)

beim "DMS-Bubble" war der Bubble DMS [proxy] der Server (mehr als doppelt so schnell)

 

Ich glaube aber nicht wirklich das da der komplette Dialog zw. Bubble und Samsung geloggt wurde?

Anhaltspunkte: beim (bei den) jeweils letzten (untersten im Log)

- TUPnPAnnounce        HandleMessage    Send alive...

wird gestreamt bzw. nach Fehlermeldung erneuter Versuch von mir.

 

interessant evl. die lange Antwort die auf:

- TPNPWebserver        Client:          Windows10/10.0 UPnP/1.0 BubbleUPnPServer/0.9-update23
- TPNPWebserver        Requested:       \description.xml
- TPNPWebserver        Answer:         ... -> hier

kommt.

 

svcdebug - DMS.zip

 

 

vor 3 Stunden schrieb Griga:

Was Lars sich da ausgedacht hat, ist also ein ergiebiger Forschungsbereich, der noch Generationen von Historikern beschäftigen wird :)

 

Ich glaube nicht das es viel Sinn macht so viel in der Vergangenheit rumzuwühlen.

In einem solchen Kaos-Fall hat es sich eher bewährt Positives zu sammeln und damit das Kaos nach und nach aufzufüllen.

 

Ein Positive ist Bubble's Beschleunigung, das andere wäre ein alternativer Weg - das schnelle Laden von Datei oder emulierter Datei, siehe

http://www.DVBViewer.tv/forum/topic/59724-upnp-problem/?do=findComment&comment=461469

 

Edited by craig_s
Link to comment

p.s.

..habe mir schon überlegt ob Bubbles Proxy Server sich dem Client als 'virtuelle Festplatte' präsentiert, dagegen spricht aber das die Fehlermeldung "..Format wird momentan nicht unterstützt" auch bei Bubble kommt.

 

Bei Dateiwiedergabe mimen alle Server (auch MS, DivX, UMS) ebenfalls .mpg aber die Meldung kommt nie!

Nur beim Versuch Live-TV zu streamen (ohne Ende..).

 

Ich weiß, es verlockt jetzt enorm sich hinzusetzen und in aller Ruhe auf mögliche Verbesserungen eines möglichen UPnP/2.0 zu warten ;)

Könnte aber ewig dauern...

Link to comment
vor einer Stunde schrieb craig_s:

 

merkwürdig der . hinter HHP. Weil im user agent steht immer HHP_

Habe ich aber schonmal ohne den Punkt versucht, brachte nichts.

 

 

In einem regulären Ausdruck (RegEx) steht der Punkt nicht für einen tatsächlichen Punkt sondern als Platzhalter für ein beliebiges Zeichen, der Stern für eine beliebig häufige Wiederholung des Zeichens davor (auch Null, also keine). Die Folge ".*" ist also ein beliebiger String beliebiger Länge oder auch "Nichts". Konkret heißt " .*SEC_HHP.* " also, erst irgendwas oder nichts, dann SEC_HPP und dann wieder irgendwas oder nichts. Das passt auf jeden String in dem "SEC_HPP" vorkommt.

Edited by HaraldL
Link to comment

..hab ich mal anders gelernt. Punkt steht Punkt. zB. *.txt sucht nach allen Texten. *.* sucht nach allen Dateien mit einem Punkt.

 

'Platzhalter für ein einzelnes beliebiges Zeichen' war schon immer das Fragezeichen. -> ?

 

Aber achtung, OT hier. Gleich wandern wir auf den Kompost.. ;)

Link to comment

Windows nutzt da in der Suche oder Kommandozeile keine Reguläreren Ausdrücke.

 

Auch wenn es im englische the cat richtig ist passt the Katze im deutschen sicher nicht ;)

Man muss immer auf den Zusammenhang achten.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...