98_DLNARenderer.pm (UPnP) (zuvor 98_DLNAClient.pm)

[KölnSolar]

Naja, upnptester findet 2 devices:

Code Auswählen Erweitern

Description: AVM Audiobruecke
DeviceType: urn:schemas-upnp-org:device:aura:1
FriendlyName: AVM Audiobruecke
Manufacturer: AVM Berlin
ManufacturerUrl: http://www.avm.de/
ModelName: FRITZ!WLAN Repeater N/G
ModelNumber: 0.9.4
ModelURL: http://www.avm.de/
PresentationUrl: http://fritz.repeater/
UDN: uuid:22617c0d-cb0f-4fb9-a31f-4711

Description: FRITZ!WLAN Repeater N/G 68.04.88
DeviceType: urn:schemas-avm-de:device:configd:1
FriendlyName: FRITZ!WLAN Repeater N/G
Manufacturer: AVM Berlin
ManufacturerUrl: http://www.avm.de/
ModelName: FRITZ!WLAN Repeater N/G
ModelNumber: avm
ModelURL: http://www.avm.de/
PresentationUrl: http://fritz.repeater/
UDN: uuid:297bf8b4-0cd9-11df-bb1b-4712


Kein device mit den beiden für DLNA notwendigen services wie bei Dir

xxxx.xx.xx xx:xx:xx 5: ControlPoint: Accepted Search-Response: "LOCATION: http://192.168.155.100:49200/MediaRendererDevDesc.xml
SERVER: FRITZ!WLAN Repeater N/G UPnP/1.0 AVM FRITZ!WLAN Repeater N/G 68.04.88
CACHE-CONTROL: max-age=1800
EXT:
ST: urn:schemas-upnp-org:device:MediaRenderer:1
USN: uuid:fa095ecc-e13e-40e7-8e6c-9CC7A60FA3AE::urn:schemas-upnp-org:device:MediaRenderer:1

"
2018.04.27 20:00:18 4: DLNARenderer: deviceAdded, AVM FRITZ!MediaRenderer
2018.04.27 20:00:18 5: DLNARenderer: AVTransport: urn:schemas-upnp-org:service:AVTransport:1 found. OK.
2018.04.27 20:00:18 5: DLNARenderer: AVTransport: urn:schemas-upnp-org:service:AVTransport:1 found. OK.
2018.04.27 20:00:18 5: DLNARenderer: RenderingControl: urn:schemas-upnp-org:service:RenderingControl:1 found. OK.
2018.04.27 20:00:18 5: DLNARenderer: RenderingControl: urn:schemas-upnp-org:service:RenderingControl:1 found. OK.

Bei mir scheint also irgendeine Option nicht gesetzt 

Edit: Ahhhhh, unter Audio und 3.analog/digital ein Häkchen und nun spuckt der upnptester das device aus:

Code Auswählen Erweitern

Description: FRITZ!MediaRenderer
DeviceType: urn:schemas-upnp-org:device:MediaRenderer:1
FriendlyName: AVM FRITZ!MediaRenderer
Manufacturer: AVM Berlin
ManufacturerUrl: http://www.avm.de/
ModelName: FRITZ!WLAN Repeater N/G
ModelNumber: avm
ModelURL: http://fritz.repeater/
PresentationUrl: http://fritz.repeater/
SerialNumber: 10
UDN: uuid:fa095ecc-e13e-40e7-4713


Mal gucken, was das so ausspuckt....

[KölnSolar]

Neue Erkenntnisse zum 30s-/60s-freeze: Der freeze entsteht auch, wenn man ein gar nicht vorhandenes file vom FHEM-Server aufruft.
also:
freeze:
- http://fhem-ip:8083/falscherPfad/irgendwas.jpg
- http://fhem-ip:8083/fhem/rss/rssvorhanden.jpg
- http://fhem-ip:8084/fhem/rss/rssnichtvorhanden.jpg
kein freeze:
- jeder Pfad ungleich FHEM-WebServer. Egal ob existent oder nicht. 

Hier mal das freezemonlog bei http://fhem-ip:8084/fhem/41.mp4

Code Auswählen Erweitern


[Freezemon] freezedetect: possible freeze starting at 16:27:29, delay is 60.444 possibly caused by: tmr-BlockingKill(N/A)
2018.04.28 16:27:28.300 4: WEB_FHEM-IP_49976 POST /fhem?cmd.setDLNA_4844f7aa62ab%3Dset%20DLNA_4844f7aa62ab%20stream%20http%3A%2F%2FFHEM-IP%3A8084%2Ffhem%2F41.mp4&XHR=1&fwcsrf=csrf_120982151928161&fw_id=572; BUFLEN:0
2018.04.28 16:27:28.303 5: Cmd: >set DLNA_4844f7aa62ab stream http://FHEM-IP:8084/fhem/41.mp4<
2018.04.28 16:27:28.321 4: BlockingCall (DLNARenderer_generateDidlLiteBlocking): created child (25650), uses telnetPort to connect back
2018.04.28 16:27:28.397 5: End notify loop for DLNA_4844f7aa62ab
2018.04.28 16:27:28.402 4: WEB: /fhem?cmd.setDLNA_4844f7aa62ab%3Dset%20DLNA_4844f7aa62ab%20stream%20http%3A%2F%2FFHEM-IP%3A8084%2Ffhem%2F41.mp4&XHR=1&fwcsrf=csrf_120982151928161&fw_id=572 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2018.04.28 16:27:28.441 4: Connection accepted from WEBPhone_FHEM-IP_56814
2018.04.28 16:27:28.452 4: WEBPhone_FHEM-IP_56814 GET /fhem/41.mp4; BUFLEN:0
2018.04.28 16:27:28.497 4: WEBPhone: /fhem/41.mp4 / RL:3411 / text/html; charset=UTF-8 /  /
2018.04.28 16:27:28.620 4: Connection closed for WEBPhone_FHEM-IP_56814: EOF
2018.04.28 16:27:28.637 4: Connection accepted from telnetPort_127.0.0.1_48136
2018.04.28 16:27:28.658 5: Cmd: >{BlockingStart('60')}<
2018.04.28 16:27:28.663 5: Cmd: >{DLNARenderer_generateDidlLiteBlockingFinished('DLNA_4844f7aa62ab|http://FHEM-IP:8084/fhem/41.mp4|')}<
2018.04.28 16:27:28.666 2: DLNARenderer: AVTransport: urn:schemas-upnp-org:service:AVTransport:1 found. OK.
--- log skips    60.537 secs.
2018.04.28 16:28:29.202 5: DLNARenderer: Service UPnP::ControlPoint::Service=HASH(0x341a940), upnpServiceCtrlProxy UPnP::ControlPoint::ControlProxy=HASH(0x3a6e908)
2018.04.28 16:28:29.203 5: DLNARenderer: AVTransport, SetAVTransportURI(0,http://FHEM-IP:8084/fhem/41.mp4,) succeed. return: UPnP::ControlPoint::ActionResult=HASH(0x22e6478)
2018.04.28 16:28:29.207 2: DLNARenderer: AVTransport: urn:schemas-upnp-org:service:AVTransport:1 found. OK.
2018.04.28 16:28:29.421 5: DLNARenderer: Service UPnP::ControlPoint::Service=HASH(0x341a940), upnpServiceCtrlProxy UPnP::ControlPoint::ControlProxy=HASH(0x362b460)
2018.04.28 16:28:29.421 5: DLNARenderer: AVTransport, Play(0,1) succeed. return: UPnP::ControlPoint::ActionResult=HASH(0x39e7d90)
2018.04.28 16:28:29.440 5: End notify loop for DLNA_4844f7aa62ab
2018.04.28 16:28:29.445 5: [Freezemon] freezedetect: ----------- Starting Freeze handling at 2018.04.28 16:28:29.444 ---------------------


und bei http://fhem-ip:8083/fhem/rss/mycallrss.jpg

Code Auswählen Erweitern


[Freezemon] freezedetect: possible freeze starting at 16:40:59, delay is 59.828 possibly caused by: no bad guy found :-(
2018.04.28 16:40:58.019 4: Connection accepted from telnetPort_127.0.0.1_48330
2018.04.28 16:40:58.038 5: Cmd: >{BlockingStart('88')}<
2018.04.28 16:40:58.043 5: Cmd: >{DLNARenderer_generateDidlLiteBlockingFinished('DLNA_4844f7aa62ab|http://FHEM-IP:8083/fhem/rss/mycallrss.jpg|')}<
2018.04.28 16:40:58.053 2: DLNARenderer: AVTransport: urn:schemas-upnp-org:service:AVTransport:1 found. OK.
--- log skips    60.533 secs.
2018.04.28 16:41:58.586 5: DLNARenderer: Service UPnP::ControlPoint::Service=HASH(0x341a940), upnpServiceCtrlProxy UPnP::ControlPoint::ControlProxy=HASH(0x3a9f0a8)
2018.04.28 16:41:58.586 5: DLNARenderer: AVTransport, SetAVTransportURI(0,http://FHEM-IP:8083/fhem/rss/mycallrss.jpg,) succeed. return: UPnP::ControlPoint::ActionResult=HASH(0x3aa3188)
2018.04.28 16:41:58.590 2: DLNARenderer: AVTransport: urn:schemas-upnp-org:service:AVTransport:1 found. OK.
2018.04.28 16:41:58.804 5: DLNARenderer: Service UPnP::ControlPoint::Service=HASH(0x341a940), upnpServiceCtrlProxy UPnP::ControlPoint::ControlProxy=HASH(0x3a92520)
2018.04.28 16:41:58.805 5: DLNARenderer: AVTransport, Play(0,1) succeed. return: UPnP::ControlPoint::ActionResult=HASH(0x39eeb68)
2018.04.28 16:41:58.824 5: End notify loop for DLNA_4844f7aa62ab


Ich denke, dass das kein Samsung-spezifisches Problem ist, sondern ein generelles des DLNARenderers. Kann das jemand bestätigen ?
Was behindert sich da ?

[KölnSolar]

Ich hab dann mal den Status abgefragt, damit nicht mehr die irreführende Meldung"...succeed" sondern die vom device gelieferte Fehlerbeschreibung kommt. So z.B. für den fritz.repeater von Fhemotto:

2018.04.28 23:47:37 3: DLNARenderer: Error! UPnP-Fault-Fields: Code: "s:Client", String: "UPnPError", Actor: "-", Detail: "{UPnPError => {errorDescription => 'XML error', errorCode => 502}}"

@willibutz: Hilft zumindest mal zu sehen, was der Sony meckert...
Grüße Markus
PS: ....abgekupfert aus reinerleins SONOS 

[willibutz]

Hallo Markus,
danke dir, werde ich probieren, bin jetzt aber erst mal 1 Woche im Urlaub 

LG willibutz

[MichaelT]

Hallo Markus,

habe das Modul mal getestet. Version wird mit 2.07Patch angezeigt - aber leider kein attr "envPrefix".

Code Auswählen Erweitern

dlnadevices: unknown attribute envPrefix. Type 'attr dlnadevices ?' for a detailed list.

Hast Du eine Idee, was das sein könnte?

Gruß
Michael

[KölnSolar]

Hallo Michael,
Du findest es nur im "Master" device.
Grüße Markus

[MichaelT]

Hallo Markus,

dlnadevices ist das masterdevice!

Ich glaube, es fehlt im Modul Zeile 174 der envPrefix in der Liste.

Code Auswählen Erweitern

$hash->{AttrList}  = "ignoredIPs usedonlyIPs envPrefix ".$readingFnAttributes;

EDIT:
Scheint erstmal unauffällig zu funktionieren. Ich habe hier einige peaq-Munets. Am TV probiere ich es noch.

Danke für deine Zeit
Gruß Michael

[KölnSolar]

Hallo Reiner,
ich hoffe Du liest noch mit.
Wie fhemotto hab ich auch einen FritzRepeater n/g. Device wird erkannt, aber keine actions möglich: 502 xml Fehler. Also hab ich gedebugged. Schuld sind wieder die namespaces  Mir ist dann der mir überflüssig erscheinende namespace

Code Auswählen Erweitern

xmlns:namesp1="u"
aufgefallen. Erzeugt wird er beim Controlproxy-Aufruf durch... ->ns("u"). Flink auskommentiert und die actions funktionieren für den Repeater u. auch meinen Samsung.

Code Auswählen Erweitern


<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<s:Body>
<SetAVTransportURI xmlns="urn:schemas-upnp-org:service:AVTransport:1">
<InstanceID xsi:type="xsd:int">0</InstanceID>
<CurrentURI xsi:type="xsd:string">x</CurrentURI><CurrentURIMetaData xsi:type="xsd:string" />
</SetAVTransportURI>
</s:Body>
</s:Envelope>

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<s:Body>
<Play xmlns="urn:schemas-upnp-org:service:AVTransport:1">
<InstanceID xsi:type="xsd:int">0</InstanceID>
<Speed xsi:type="xsd:string">1</Speed>
</Play>
</s:Body><
/s:Envelope>

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<s:Body>
<SetVolume xmlns="urn:schemas-upnp-org:service:RenderingControl:1">
<InstanceID xsi:type="xsd:int">0</InstanceID>
<Channel xsi:type="xsd:string">Master</Channel>
<DesiredVolume xsi:type="xsd:int">12</DesiredVolume>
</SetVolume>
</s:Body>
</s:Envelope>


Außerdem ist mir aufgefallen, dass die Prüfung auf bereits benutzte namespaces in SOAP::Lite nicht zu funktionieren scheint. Es werden immer neue namespaces namspxy mit jeder action generiert. Ohne die Option ->ns("u") passiert das nicht, weil keine namespaces generiert werden.

Und nun die Frage: Kannst Du das so übernehmen oder brauchen andere devices diesen namespace ? 
Grüße Markus

[Reinerlein]

Hi Markus,

damit klappt leider die Kommunikation mit den Sonos-Playern nicht mehr richtig.
Ich vermute, da ich einiges selber per regulärem Ausdruck parse, dass damit dann irgendwelche Tags nicht mehr passen...

Kannst du mal probieren, ob es mit einem Leerstring geht?
Oder mal ein prefix mit angeben (zweiter, optionaler Parameter)...

Irgendwas müssen wir jetzt noch finden, sonst muss ich halt ein If drumherum basteln. Das würd ich aber gerne vermeiden

Grüße
Reiner

[KölnSolar]

Hi Reiner,
space oder leer

Code Auswählen Erweitern

<?xml version="1.0" encoding="UTF-8"?><s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:namesp1=" " xmlns:namesp2="urn:schemas-upnp-org:service:AVTransport:1" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><s:Body><namesp2:SetAVTransportURI><InstanceID xsi:type="xsd:int">0</InstanceID><CurrentURI xsi:type="xsd:string">x</CurrentURI><CurrentURIMetaData xsi:type="xsd:string" /></namesp2:SetAVTransportURI></s:Body></s:Envelope>

und prefix "u"

Code Auswählen Erweitern

<?xml version="1.0" encoding="UTF-8"?><s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:namesp1="urn:schemas-upnp-org:service:AVTransport:1" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:u="u" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><s:Body><namesp1:SetAVTransportURI><InstanceID xsi:type="xsd:int">0</InstanceID><CurrentURI xsi:type="xsd:string">x</CurrentURI><CurrentURIMetaData xsi:type="xsd:string" /></namesp1:SetAVTransportURI></s:Body></s:Envelope>
funktionieren leider nicht.

sonst muss ich halt ein If drumherum basteln. Das würd ich aber gerne vermeiden

If hieße ja auch wieder ein Attribut. Den Repeater haben aber sicherlich nicht viele. Und die wenigen können ja ggfs. meinen "Workaround" nutzen. Nur, wenn andere devices ähnlich reagieren ? 
Grüße Markus

[Reinerlein]

Hi Markus,

naja, Workaround hieße ja eine Codeänderung durch den Anwender, die beim nächsten Update weg wäre, oder eben eine Updateverhinderung durch exclude_from_update, was dann u.U. in der Zukunft zu einer alten Version führen würde.

Ich denke, mit einem optionalen Parameter, der dann wieder als Attribut am DLNARenderer gesetzt werden kann, sollte das dann schon gehen... sofern das mit den zeitversetzten Attributen mal produktiv drin ist

Ich überlege mir nur gerade, was in dem Parameter eigentlich stehen muss.
Sinnvollerweise muss man etwas eintragen können, was dann auch verwendet wird, und einen "Sonderstring", der für "weglassen des ->ns() Zusatzes" steht, vielleicht "<none>" oder so...
Und gar nicht angeben macht dann den bisherigen Zustand mit "->ns('u')".
Damit bleiben wir Abwärtskompatibel, und können alles andere zulassen und ermöglichen...

Ich baue mal

Grüße
Reiner

[KölnSolar]

Hallo Reiner,

naja, Workaround hieße ja eine Codeänderung durch den Anwender, die beim nächsten Update weg wäre, oder eben eine Updateverhinderung durch exclude_from_update, was dann u.U. in der Zukunft zu einer alten Version führen würde.

genau so dachte ich

Ich denke, mit einem optionalen Parameter, der dann wieder als Attribut am DLNARenderer gesetzt werden kann, sollte das dann schon gehen... sofern das mit den zeitversetzten Attributen mal produktiv drin ist

Ich hab halt so ein bißchen Sorge, dass bei dem "tollen" "Standard" immer wieder neue Sonderlocken erforderlich werden. Also alles immer unübersichtlicher. Aber Du bist der maintainer  u. mit Deinem SONOS-Modul der Hauptnutzer. (Und Dominik für den DLNARenderer. Wäre ja schön, wenn der sich auch mal wieder zu Wort melden würde.  ) Gibt es noch weitere Module, die die "FHEM-UPnP-Lib" einsetzen ?

Sinnvollerweise muss man etwas eintragen können, was dann auch verwendet wird, und einen "Sonderstring", der für "weglassen des ->ns() Zusatzes" steht, vielleicht "<none>" oder so...
Und gar nicht angeben macht dann den bisherigen Zustand mit "->ns('u')".
Damit bleiben wir Abwärtskompatibel, und können alles andere zulassen und ermöglichen...

Wie wäre es mit default_ns = y/n[default] ? Das ist ja genau das, was bei weglassen von "->ns('u')" durchlaufen wird.
Und im DLNA_Renderer könnten wir es vielleicht sogar mit default=y einbauen ? Mein Bauchgefühl sagt mir, dass damit alle devices klar kommen. 

Btw, hast Du eine Idee, was den 30Sek.-freeze auslöst, wenn man versucht einen stream mit URI des FHEMWEB-Servers zu senden ? Kannst Du mit dem SONOS-Modul auch eine URI eines nicht Mediaservers versuchen zu streamen und hast dann das selbe Problem ?

Kurz zum Verständnis:
Ich habe das STV-Modul so umgebaut, dass man sich Bildschirmnachrichten als Bild/Audio/Video auf dem STV per DLNARenderer(aktuell noch mit DLNAClient)rendern kann. Grundsätzlich sollte dafür ein Mediaserver eingesetzt werden. Die interessanteste Anwendung ist aber dabei das Medium dynamisch zu generieren, also z.B. bei einem eingehenden Anruf Infos wie Name, Tel. einzubauen. Das wiederum hab ich aus früheren Zeiten mit dem RSS-Modul gemacht und mir ein jpeg dynamisch erzeugt. Dieses als URI(http://FHEM_IP:FHEMWEB_Port/fhem/rss/mycallrss.jpg) angegeben funktioniert perfekt mit dem DLNAClient. Und frag mich nicht, warum das überhaupt funktionioniert, da FHEMWEB ja kein Media-Server ist.  Der DLNARenderer friert aber genau 30 Sek ein  Es beißt sich also irgendetwas mit FHEM. Da ich zwischenzeitlich herausgefunden habe, dass es auch passiert, wenn man z.B. die unsinnige URI http://FHEM_IP:FHEMWEB_Port/fhem/nichtvorhandenes.jpg streamed, lässt sich das RSS-Modul als Ursache ausschließen und ich kann es mir nur so erklären:
- in den Tiefen des UPnP wird 30 Sek. blockierend auf eine Antwort des TV gewartet(evtl. auch STV-spezifisch, dass von dort nach 30 Sek. vergeblichen Wartens auf den vermeintlichen Mediaserver erst eine response geschickt wird  ) Gegen diese Theorie spricht eigentlich, dass ein Aufruf eines nicht vorhandenen streams vom Media-Server nicht blockierend ist.
- (eher eine vage Spekulation) FHEMWEB u. DLNA blockieren sich gegenseitig. Nur wo genau und warum ?
Grüße Markus

[Reinerlein]

Hi Markus,

kurz zu deinem Problem:
Ich würde sagen, dass du da einen Dead-Lock vorliegen hast.

Dein DLNARenderer (oder -Client) wartet auf die Antwort deines STV. Der STV aber wiederrum kann die Antwort erst erzeugen, wenn er weiß, ob er den Stream bekommen kann oder nicht.
Wenn der Stream jetzt von FHEM geliefert werden soll, klemmt es, da FHEM ja noch mit dem DLNA-Aufruf beschäftigt ist (er wartet ja auf die Antwort).
Eine Art der Auflösung eines solchen Deadlocks erlebst du ja durch den erfolgten Timeout

Das ist der Grund, warum ich einen eigenen SubProzess für die Kommunikation mit den Sonos-Playern gebaut habe, der läuft dann autark gegenüber Fhem, und damit gibt es auch einen solchen Deadlock nicht.

Das kannst du nur umgehen, wenn du deinen DLNA-Aufruf z.B. über die NonBlocking-Mechanik in Fhem, aufrufst:
- NonBlocking baut spontan einen neuen Thread, führt dort deine Aufgabe aus, und verbindet sich vor dem Töten (oder besser: ausleben lassen) des Threads mit Fhem, um das Ergebnis dieses Aufrufs zu übertragen.
- Währenddessen ist Fhem frei, und kann deine FhemWeb-Anfrage (indirekt durch den STV) verarbeiten
- Dein STV erhält sofort eine Meldung, und nicht erst nach seinem eigenen Timeout, weil Fhem jetzt auch sofort reagieren kann
- Das Ergebnis deines DLNA-Aufrufs landet asynchron in deinem Reading (oder wo auch immer)

Grüße
Reiner

[KölnSolar]

Hallo Reiner,
ja, so denke ich ist es. Wäre ja auch gar nicht soooo dramatisch, wenn es bei tatsächlich nicht vorhandenen streams auftreten würde. Die hat man ja eher nie. Sprich, der freeze ist quasi Symptom aber nicht Ursache.
Ich erinnere mich wieder schwach, dass der STV im konkreten Fall mit einem "HEAD" anstatt "POST" antwortet. Dafür hatte Rudi uns extra ein Global-Attribut spendiert. Ich debugge mal tiefer, auch wenn ich glaube, dass mir das nicht wirklich weiterhilft, weil eine "Korrektur" dann ja in einem Perl-Modul außerhalb von FHEM stattfinden müsste.
Grüße Markus

[willibutz]

Ich hab dann mal den Status abgefragt, damit nicht mehr die irreführende Meldung"...succeed" sondern die vom device gelieferte Fehlerbeschreibung kommt. So z.B. für den fritz.repeater von Fhemotto:@willibutz: Hilft zumindest mal zu sehen, was der Sony meckert...

Hallo Markus,
habe mal deine angepasste  Version von 98_DLNARenderer.pm installiert und dann folgendes Log bekommen:

Code Auswählen Erweitern


Datum         Zeit Stufe Nachrichten
2018-05-07 19:56:17 Notice : DLNA_104fa8052a77 stream: http://translate.google.com/translate_tts?tl=en&client=tw-ob&q=Hallo
2018-05-07 19:56:17 Error : 3: DLNARenderer: Error! UPnP-Fault-Fields: Code: s:Client"
2018-05-07 19:56:17 Debug : 5: DLNARenderer: AVTransport: urn:schemas-upnp-org:service:AVTransport:1 found. OK.
2018-05-07 19:56:17 Error : 3: DLNARenderer: Error! UPnP-Fault-Fields: Code: s:Client"
2018-05-07 19:56:16 Debug : 5: DLNARenderer: AVTransport: urn:schemas-upnp-org:service:AVTransport:1 found. OK.
2018-05-07 19:56:16 Notice : DLNA_104fa8052a77 stream http://translate.google.com/translate_tts?tl=en&client=tw-ob&q=Hallo
2018-05-07 18:20:26 Notice : DLNA_104fa8052a77 stream: http://translate.google.com/translate_tts?tl=en&client=tw-ob&q=Hallo
2018-05-07 18:20:26 Debug : 5: DLNARenderer: AVTransport, Play(0,1) succeed.
2018-05-07 18:20:26 Debug : 5: DLNARenderer: AVTransport: urn:schemas-upnp-org:service:AVTransport:1 found. OK.
2018-05-07 18:20:26 Debug : 5: DLNARenderer: AVTransport, SetAVTransportURI(0,http://translate.google.com/translate_tts?tl=en&client=tw-ob&q=Hallo,<DIDL-Lite xmlns=urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" xmlns:sec="http://www.sec.co.kr/"><item id="-1" parentID="parent" restricted="1"><upnp:class>object.item.audioItem.musicTrack</upnp:class><dc:title>http://translate.google.com/translate_tts?tl=en&amp
2018-05-07 18:20:25 Debug : 5: DLNARenderer: AVTransport: urn:schemas-upnp-org:service:AVTransport:1 found. OK.
2018-05-07 18:20:25 Notice : DLNA_104fa8052a77 stream http://translate.google.com/translate_tts?tl=en&client=tw-ob&q=Hallo
2018-05-07 18:19:50 Warning : 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at /usr/local/FHEM/share/fhem/FHEM/98_DLNARenderer.pm line 318.
2018-05-07 18:10:55 Notice : DLNA_104fa8052a77 multiRoomSupport: 0
2018-05-07 18:10:55 Info    : 4: DLNARenderer: SessionManagement unknown for DLNA_104fa8052a77.
2018-05-07 18:10:55 Notice : DLNA_104fa8052a77 online
2018-05-07 18:10:55 Notice : DLNA_104fa8052a77 presence: online
2018-05-07 18:10:55 Info : 4: DLNARenderer: SpeakerManagement unknown for DLNA_104fa8052a77.
2018-05-07 18:10:55 Warning : 1: PERL WARNING: Subscription request failed with error: 400 Bad Request at /usr/local/FHEM/share/fhem/FHEM/98_DLNARenderer.pm line 1360.
2018-05-07 18:10:55 Debug : 5: DLNARenderer: RenderingControl: urn:schemas-upnp-org:service:RenderingControl:1 found. OK.
2018-05-07 18:10:55 Debug : 5: DLNARenderer: RenderingControl: urn:schemas-upnp-org:service:RenderingControl:1 found. OK.
2018-05-07 18:10:55 Warning : 1: PERL WARNING: Subscription request failed with error: 400 Bad Request at /usr/local/FHEM/share/fhem/FHEM/98_DLNARenderer.pm line 1356.
2018-05-07 18:10:55 Debug : 5: DLNARenderer: AVTransport: urn:schemas-upnp-org:service:AVTransport:1 found. OK.
2018-05-07 18:10:55 Debug : 5: DLNARenderer: AVTransport: urn:schemas-upnp-org:service:AVTransport:1 found. OK.
2018-05-07 18:10:55 Notice : DLNA_104fa8052a77 manufacturer: Sony Corporation
2018-05-07 18:10:55 Notice : DLNA_104fa8052a77 manufacturerURL: http://www.sony.net/
2018-05-07 18:10:55 Notice : DLNA_104fa8052a77 modelNumber: BAR-2015
2018-05-07 18:10:55 Notice : DLNA_104fa8052a77 modelName: HT-XT3
2018-05-07 18:10:55 Notice : DLNA_104fa8052a77 manufacturer: Sony Corporation
2018-05-07 18:10:55 Notice : DLNA_104fa8052a77 friendlyName: BRAVIABOX


hilft das schon weiter oder brauchst du noch mehr Infos?

LG willibutz