Habe mich gerade gefragt, ob der DLNA-Zugriff für ESPuino noch interessant sein könnte, als ich auf diese Lib hier gestoßen bin: GitHub - yellobyte/SoapESP32: Scan local network for DLNA media servers, browse their content and download files. For ESP32 devices..
Habe bisher noch nix dazu getestet.
Was meint ihr?
Hy,
das klingt interessant.
Mehr funktionen sind irgendwie immer cool. Jedoch weiß ich nicht, ob ich dies mehr als einmal im Monat verwenden werde.
Ich kann den Aufwand nicht abschätzen - ich bin ein bisschen hin und her gerissen…neue Funktionen immer gern aber es wird auch Sommer.
Danke für deinen unermüdlichen Einsatz 
Wie hättest du dir das vorgestellt? Browsing über das Webinterface und dann Download auf die SD-Karte? Oder on-demand streaming? Es geht ja letztlich bei dem Projekt um die RFID-Steuerung. Vielleicht wenn die Karte selbst einen Titel enthält und man diese folglich für mehrere ESPuinos verwenden kann?
Ich finde die Funktion nicht so wichtig für das ESPuino Projekt. Wäre vermutlich für die gleichen Zielgruppe die auch MQTT verwendet, und das sind ja glaube ich nicht so viele.
Um ehrlich zu sein, hatte ich mir noch gar keine Gedanken gemacht. Möglicherweise ist das auch unverhältnismäßig viel Arbeit, so dass ich es nicht realisiere. Wollte hier einfach mal hören, was Andere dazu meinen.
Ich denke das ist ein sehr spannendes Feature wenn man nicht so auf redundante Datenhaltung steht. Gleichzeitig geht natürlich der Vorteil der Portabilität verloren, weil lokales Streaming natürlich auch lokal begrenzt ist.
Ich würde es sicher nutzen, glaube aber dass der Aufwand ggf. etwas hoch ist.
Ich habe zwar keine Ahnung, wie hoch der Aufwand wäre, aber ich würde die Möglichkeit begrüßen.
Ich halte es inzwischen für keine gute Idee mehr:
a) Das wird kaum jmd. brauchen.
b) Das wird so gut wie niemand testen.
c) Es braucht wieder zusätzlichen Speicher. In der Richtung ist ESPuino eh schon „hinreichend fett“, so dass wir ohne PSRAM gar nicht mehr auskommen.
Die Lösung mit dem PHP-File wäre lightweight. Ich denke was wir eigentlich bräuchten (@tueddy oder geht das schon und ich hab’s vergessen!?), ist, dass der Playmode LOCAL_M3U nicht nur lokale m3u-Files lesen kann, sondern auch m3u-Files von entfernten Servern. Bisweilen (sofern ich mich nicht irre) reichen wir m3u-Files von Webservern einfach an die Audiolib durch und die pickt dann eben den ersten Eintrag raus.
Ansonsten gibt’s aktuell einen PR, der auf ein Feature zurückgeht, welches Files nachlädt, sofern sie lokal nicht zu finden sind. Allerdings wird dafür auf RFID-Karten was geschrieben und das lehne ich jetzt und auch in Zukunft ab. Würde man das umsetzen wollen, so müsste man die GUI erweitern und neben einem File-Link auch noch einen Web-Link als Fallback angeben. NVS-Lese- und Schreibroutinen müssten angepasst werden.
Wie auch immer: Allen Lösungen gemein ist, dass sie einen Webserverdienst benötigen. Wer so etwas betreiben kann, der ist jedoch normalerweise auch in der Lage, das Filesystem eines ESPuinos per FTPfs in sein Linux-System zu mounten und darauf ein rsync zu machen. So kann man Dinge halt auch synchronisieren, obgleich ich zugeben muss, dass ich das noch nicht getestet habe.
Weil ich das Thema gerade auch in einer PN hatte, hier nochmal meine Gedanken zu dem Thema:
Mein use case für ist das ich mehrere ESPuinos betreue, die sich in unterschiedlichen Haushalten befinden, die RFID Tags aber durchaus zwischen den Kindern getauscht werden.
Um den Content zu Syncronisieren müsste ich mich da aufwändig mit VPN, etc. zu den einzelnen ESPuinos verbinden. Das ist nicht wirklich praktikabel. Ein wichtiges Kriterium für mich ist, das die Zuordnung der RFID UIDs zu den Audiodaten auf einem zentralen Server erfolgen soll.
Um das mit DLNA umzusetzen fallen mir zwei Varianten ein:
ESPuino such alle bzw. einen eingestellten DLNA Digital Media Server (DMS) nach einer Bestimmten Datei ab (z.B. im Ordner /ESPuino/$UID.m3u). Das dürfte mit allen DMS Implementierungen kompatibel sein. Man brächte aber wieder irgend eine extra Software, die die Dateien auf dem DMS entsprechend erstellt (manuell wäre mir zu fehleranfällig/aufwändig).
Alternativ könnte man einen Search Request an den/die DMS schicken, der z.B. nach einem bestimmten Kriterium (z.B. rfid:uid==$UID oder dc:title=="ESPuino-$UID.m3u") sucht. Das würde die Implementierung/Arbeit auf Seiten des ESPuino einfacher machen, aber viele einfache DMS unterstützen keine Suche (von speziellen Such Kriterien mal ganz abgesehen). Bei einer Fritz Box würde ich z.B. nicht erwarten das dort eine Suche Unterstützt wird. Man bräuchte entsprechend wieder einen richtigen DMS der das kann.
Im klassischen Use-Case erfolgt das ganze Discovery via Multicast, Server und Client müssen entsprechend im selben Subnetz sein. Eine Limitierung auf das selbe Subnetz wäre für mich ein KO-Kriterium. Eine manuelle Spezifikation und entsprechende direkte unicast Kommunikation mit einem externen Server sollte aber möglich sein (Relevant für meinen use case).
Mein größtes Problem mit DLNA ist aber, dass das ganze Protokoll auf SOAP/XML basiert. XML parsen/erzeugen ist so ziemmlich das schlimmste was man einen CPU/Speicher limitierten Gerät antuen kann 
Entsprechend bin ich auch eher ein Freund von einfachen HTTP REST calls.
Was ich Interessanter fände, wäre die Implementierung eines DLNA Digital Media Renderer (DMR). Damit mann via DLNA z.B. eine Datei vom Handy auf einen ESPuino Streamen kann (Anstelle von Bluetooth). Streamen von z.B. Amazon Music übers Handy auf einen ESPuino würde aber vermutlich damit auch nicht gehen. Entsprechend auch wieder nur ein sehr spezieller use case.
Mit DLNA
DLNA nutzt für die Kommunikation SOAP/XML. Das zu parsen/erzeugen ist nicht besonderes Speicher freundlich. Es wäre mit entsprechenden massiven Overhead verbunden, das möchte ich den ESPuinos aktuell nicht antun.
Die fritz box Implementiert soweit ich weis nur einen dummen media server der quasi