fhempy: dlna_dmr

[MichaelT]

Morgen,

in dlna-dmr.py Zeile 170 ist ein Fehler.

str / int

habe bei mir in async_set_volume_level(int(params["volume"]) / 100) geändert.
Nun werden auch die restlichen Reading aktualisiert

Danke

[dominik]

Ah, super, danke für die Info. Wird beim nächsten Update behoben.

[KölnSolar]

Hi Dominik,

dlna_dmr kann also "nur" die services RenderingControl u. AVTransport ?

Bitte beachte, dass die speziellen MUNET Commands für Multizone nicht im neuen Modul unterstützt werden, das kann aktuell nur reines DLNA. MUNET nutzt nämlich CaskeId welches auf DLNA basiert.

Weil ich gerade den DLNARenderer "entzerre".
<OT>Spitzfindig ist das nicht DLNA, sondern upnp, oder ?
Genauso wie der DLNARenderer eigentlich ein DLNA-Controller ist ?

Was meinst Du ? Lass Dich gerne im verlinkten Thread aus.  <OT>

Grüße Markus

[dominik]

Hi Dominik,

dlna_dmr kann also "nur" die services RenderingControl u. AVTransport ?Weil ich gerade den DLNARenderer "entzerre".
<OT>Spitzfindig ist das nicht DLNA, sondern upnp, oder ?
Genauso wie der DLNARenderer eigentlich ein DLNA-Controller ist ?

Was meinst Du ? Lass Dich gerne im verlinkten Thread aus.  <OT>

Grüße Markus

dlna_dmr kann nur mit den Service Type MediaRenderer umgehen und dort RenderingControl und AVTransport. Korrekt. Ich nutze dazu die async_upnp_client Library (https://pypi.org/project/async-upnp-client/).

Mein Wissenstand ist, dass DLNA der Standard ist, der auch für MediaRenderer oft benutzt wird. Mit UPnP könnte man viel mehr machen (wie z.B. bei MUNET Multizone). Das neue Modul heißt dlna_dmr, da es via DLNA die Digital Media Renderer unterstützt. FHEM selbst wäre somit DMC (Digital Media Controller). So hätte ich das auch hier verstanden: https://de.wikipedia.org/wiki/Digital_Living_Network_Alliance#DLNA-Zertifizierung

Aber generell ist das DLNA/UPnP aus meiner Sicht ein ziemlicher "Mischmasch" und meistens schlecht implementiert von den Herstellern