Unknown module DLNARenderer

[MarkusAutomaticus]

Hallo zusammen,

Habe gerade folgendes versucht:

Code Auswählen Erweitern

define dlnadevices DLNARenderer

Und obiges Ergebnis bekommen.
Woran kann das liegen?
Fehlt vielleicht eine library?

Gruß
Markus

[mw77]

Ist die Datei 98_DLNARenderer.pm denn auf deinem System vorhanden?
Update gemacht heute, das Modul wurde ja gestern erst eingecheckt.

[MarkusAutomaticus]

Hallo und Danke für den Hinweis,

ich habe gerade ein Update gemacht, allerdings ist der Ergebnis oberflächlich betrachtet nur marginal anders:

Code Auswählen Erweitern

Cannot load module DLNARenderer

Schaut man ins Log:

Code Auswählen Erweitern

2016.07.20 09:00:38 1: reload: Error:Modul 98_DLNARenderer deactivated:
Attempt to reload UPnP/ControlPoint.pm aborted.
Compilation failed in require at ./FHEM/98_DLNARenderer.pm line 131.
BEGIN failed--compilation aborted at ./FHEM/98_DLNARenderer.pm line 131.

2016.07.20 09:00:38 0: Attempt to reload UPnP/ControlPoint.pm aborted.
Compilation failed in require at ./FHEM/98_DLNARenderer.pm line 131.
BEGIN failed--compilation aborted at ./FHEM/98_DLNARenderer.pm line 131.

Scheint ihm irgendwas in Zeile 131 sauer aufzustoßen?!

Gruß
Markus

[marvin78]

Zugegeben ist die Doku in dem Fall hier ziemlich mies!

Aber eine Suche nach DLNARenderer bringt doch sehr schnell das richtige Ergebnis. In diesem Thread steht, was man braucht:

https://forum.fhem.de/index.php/topic,39706.0.html

[betateilchen]

Naja, die Fehlermeldung ist aber doch schon ziemlich eindeutig und besagt, dass das Modul UPnP::ControlPoint nicht geladen werden kann - vermutlich, weil es nicht installiert ist.

[marvin78]

Das stimmt.

Ich erwarte trotzdem, dass in der Doku (sprich commandref) zu erkennen ist, welche Perl Module (nicht Standard) installiert sein müssen, damit das Modul funktioniert. Im Fall von tatsächlich mit FHEM verbreiteten Modulen sollte man nicht erst im Forum danach suchen müssen (auch wenn das dann natürlich der 2. Schritt sein sollte).

[betateilchen]

Ich erwarte trotzdem,

Und ich als Entwickler erwarte, dass ein Anwender eine Fehlermeldung lesen kann und versucht, zu verstehen, was sie ihm sagen will. Dazu bedarf es weder einer commandref noch eines Forums.

Ich erwarte trotzdem, dass in der Doku (sprich commandref) zu erkennen ist,

Meines Erachtens eine völlig falsche Erwartungshaltung. Bei meinen Modulen steht sehr wohl in der commandref, was die Voraussetzungen sind. Das liest aber keine Sau. Beweis: unzählige Threads im Forum mit ähnlichem Inhalt wie diesem hier.

Es sind nicht immer nur die Entwickler in die Verantwortung zu nehmen!

[marvin78]

Dass Voraussetzungen dafür, dass ein Modul überhaupt definiert werden kann, in der Doku stehen, ist keine zu hohe Erwartung. Wir erzählen den Usern immer, dass sie in die Doku schauen sollen (auch du tust das) und Fehlermeldungen richtig lesen sollen. Dafür sollte die Doku jedoch auch vollständig sein und die Voraussetzungen für die erfolgreiche Definition gehören dazu (Edit: und wenn es nur dafür da ist, dass man dem User sagen kann: schau in die Doku - da steht, was du benötigst).

Dass die User die Doku sowieso nicht lesen ist keine gute Begründung dafür, das Weglassen solcher Infos vollständig ok ist. Im Gegenteil bestärkt sowas die User noch darin, dass Doku lesen quatsch ist und man lieber 10 mal im Forum fragt.

Ich bin im Grunde deiner Meinung, was das Lesen angeht und ich bin ganz sicher niemand, der immer "nur" die Entwickler in die Pflicht nimmt (ganz im Gegenteil - aber das weißt du ja auch), bin aber trotzdem der Meinung, dass die Doku die nötigen Infos enthalten sollte, wenn wir schon darauf hinweisen, dass sie gelesen werden soll. Das ist bei den allermeisten Modulen der Fall. Das heißt aber nicht, dass man Negativbeiepiele nicht auch mal herausheben darf.

Das Modul ist noch neu. Die Infos werden sicher noch ergänzt.

[krikan]

@MarkusAutomaticus

Markus, bekommst Du das Modul so ans laufen?

Die notwendigen zusätzlich zu installierenden Module findest Du im von Marvin78 verlinkten Thread.

Mich wundert das "UPnP/ControlPoint.pm" angemahnt wird. Die gehört eigentlich seit längerem zum Standardlieferung von update und liegt bei Dir unter fhem/FHEM/lib/UPnP/ControlPoint.pm.

Gruß, Christian

[betateilchen]

Das Modul ist noch neu. Die Infos werden sicher noch ergänzt.

Davon gehe ich auch aus. Und ich gebe Dir grundsätzlich recht, dass diese Information in der commandref stehen sollte. Aber eine Doku ist noch lange nicht "ziemlich mies" nur weil ein Entwickler vergessen hat, das reinzuschreiben. Auf seinem System ist die Voraussetzung ja gegeben, sonst hätte er das Modul nicht schreiben können. Deshalb gerät so ein zusätzlich benötigtes Modul schnell mal in Vergessenheit. Als Entwickler merkt man das selbst meist erst dann, wenn man sein eigenes Modul auf einer zweiten Plattform in Betrieb nimmt. Deshalb sind bei mir Entwicklungs- und Produktivsystem strikt getrennt.

[marvin78]

Ist hier nicht der Fall, da es ja im verlinkten Forenthread explizit erwähnt wird.

Du hast aber recht: "ziemlich Mies" ist falsch. Das gebe ich zu. Ich korrigiere auf unvollständig.

[MarkusAutomaticus]

Sorry,

ich wollte hier keinen Streit vom Zaun brechen.

Vorneweg: Nein es tut noch nicht und die besagte Lib liegt bei mir unter opt/fhem/FHEM/lib/UPnP/ControlPoint.pm ist vom 29.06.2016 und ist 42,77kb groß.
Ich habe kontrolliert, ob die Voraussetzungen, die am Anfang des Threads erwähnt sind:

Code Auswählen Erweitern

Voraussetzung:
SOAP::Lite => sudo apt-get install libsoap-lite-perl
LWP::Simple => sudo apt-get install libwww-perl
XML::Simple => sudo apt-get install libxml-parser-lite-perl


erfüllt sind und halte mein FHEM durch tägliche Updates auf dem neuesten Stand.

Mit nunmehr 23 Jahren Berufserfahrung als Softwareentwickler ist mir der Spagat zwischen der Entwicklersicht, am liebsten so schnell wie möglich tolle neue Features einzubauen und dem Anspruch der Anwender benutzerfreundliche, fehlerfreie Software haben zu wollen, gut bekannt.

Man darf bei dieser Anspruchhaltung aber nicht außer Acht lassen, dass bei einem OpenSource-Projekt wie FHEM viele Entwickler ehrenamtlich und voller Engagement in ihrer oftmals knapp kalkulierten Freizeit spannende Dinge für sich und andere entwickeln.

Da darf die Messlatte sicherlich nicht so hoch liegen, wie bei einem Produkt, dass Lizenzgebühren im 5stelligen Eurobereich einfordert.

Trotzdem liegt es im Interesse jedes Entwicklers saubere und gute Arbeit abzuliefern und diese auch zu dokumentieren.
Zum einen, weil man stolz darauf sein kann, wenn es viele verwenden und natürlich ist auch der Supportaufwand viel geringer,
wenn man auf Benutzerfreundlichkeit, guter Doku und einer geringen Anzahl von bugs hingearbeitet hat.

Gruß
Markus

[betateilchen]

Da darf die Messlatte sicherlich so hoch liegen, wie bei einem Produkt, dass Lizenzgebühren im 5stelligen Eurobereich einfordert.

Welch ein arroganter Bullshit ist das denn 

Das ist mit Verlaub eine völlig überzogene, um nicht zu sagen arrogante Erwartung!
Es sind nicht alle Anwender Software-Ingenieure,

Die Fehlermeldung, die perl ausgibt, bedarf keines Informatikstudiums, um sie zu verstehen.

Und als Softwareentwickler (seit 1978) kann ich meine Erwartungshaltung gegenüber Anwendern inzwischen recht gut einschätzen. Es ist für viele Anwender einfach bequemer, die Entwickler zu beschimpfen, anstatt die eigene Denkmaschine in Betrieb zu setzen. Und das ist (leider) nicht nur bei Open Source Projekten so.

[krikan]

Vorneweg: Nein es tut noch nicht und die besagte Lib liegt bei mir unter opt/fhem/FHEM/lib/UPnP/ControlPoint.pm ist vom 29.06.2016 und ist 42,77kb groß.

Mmh. Bin kein Perl-Entwickler, aber vermute, dass der Pfad zur ControlPoint.pm nicht gefunden wird und Dein Problem nicht mit fehlenden anderen Modulen zusammenhängt. In der 98_DLNARenderer.pm ist ein anderer (fester?) Pfad hinterlegt. Eventuell muss dort etwas geändert/angepast werden. Wenn ich zu Hause wäre, würde ich mir dazu die Modulzeile 129 vornehmen.
Ansonsten bitte auf Perlentwickler bzw. den Modulentwickler dominik warten.
___
Zum Thema commandref-Doku: Man kann den Modulentwickler doch einfach bitten, die Modul-Voraussetzung in der commandref mit aufzunehmen. Er hat das sicherlich einfach nur vergessen. Was soll es!?

@dominik: Könntest Du bitte die vorausgesetzten Fremdmodule für 98_DLNARenderer.pm in die commandref-Doku mit aufnehmen, so wie Du es auch bei Deinem anderen Modul BOSEST getan hast. Vielen Dank!

[MarkusAutomaticus]

Welch ein arroganter Bullshit ist das denn 

Och betateilchen, ich habe mein Posting mit dem "arrogant" doch gelöscht 

[betateilchen]

Mmh. Bin kein Perl-Entwickler, aber vermute, dass der Pfad zur ControlPoint.pm nicht gefunden wird und Dein Problem nicht mit fehlenden anderen Modulen zusammenhängt.

Die Verzeichnisse, in denen perl nach Modulen sucht, haben nicht sonderlich viel mit fhem zu tun, sondern sind systemweit definiert.

Ich würde einfach das fehlende perl Paket auf Betriebssystemebene nachinstallieren, bei debian basierten Systemen z.B. mit

Code Auswählen Erweitern

apt-get -y install libnet-upnp-perl

Im schlimmsten Fall geht das auch per cpan, aber die meisten debian Distributionen haben ein passendes Paket bereit.

[krikan]

Danke, betateilchen.

Hatte damit gerechnet, dass ein Nachinstallieren des Perl-Paketes libnet-upnp-perl nicht zur Nutzung der mWn verbesserten ControlPoint.pm aus FHEM/ib durch DLNARenderer führt. Die Version aus FHEM/lib soll zumindest laut Kommentar im Modul verwendet werden.

[dominik]

Hallo,

schöner Austausch hier zu meinem Modul 

Ich habe extra die ControlPoint.pm aus FHEM verwendet und dazu nutze ich den gleichen Code wie in der SONOS Library - man muss ja das Rad nicht 2x erfinden. Kommt der Fehler bei euch allen?

Übrigens, wer die CommandRef schlecht findet, darf diese gerne ergänzen:
https://forum.fhem.de/index.php/topic,39706.msg465208.html#msg465208
Hier habe ich extra noch nach Unterstützung gefragt, also gerne dazu beitragen statt zu jammern

Gruß,
Dominik

[MarkusAutomaticus]

Hallo zusammen,

es mag ja nicht der reinen Lehre entsprechen, aber das was betateilchen vorgeschlagen hat, hat geholfen.
Gerade konnte ich in ansehnlicher Lautstärke SWR3 auf meinem Pioneer VSX-921 AV-Receiver bewundern

Gruß
Markus

[krikan]

Hallo Dominik!

kann das Problem/Fehler nicht nachvollziehen.

Um DLNARenderer auf meinem Raspi mit Jessie, Perl 5.20.2, ans laufen zu bekommen, musste ich neben den im verlinkten Thread genannten Perl-Paketen

Code Auswählen Erweitern

SOAP::Lite => sudo apt-get install libsoap-lite-perl
LWP::Simple => sudo apt-get install libwww-perl
XML::Simple => sudo apt-get install libxml-parser-lite-perl

noch "libxml-simple-perl" installieren. Ansonsten kam die Fehlermeldung

Code Auswählen Erweitern

016.07.20 21:41:52.916 1: reload: Error:Modul 98_DLNARenderer deactivated:
Can't locate XML/Simple.pm in @INC (you may need to install the XML::Simple module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at ./FHEM/98_DLNARenderer.pm line 117.
BEGIN failed--compilation aborted at ./FHEM/98_DLNARenderer.pm line 117.

XML::Simple war also wohl nicht in libxml-parser-lite-perl enthalten.

libnet-upnp-perl oder das Modul per cpan hatte ich nicht installiert und musste ich nicht installieren.
(Im Fazit führt also das obige Nachinstallieren von libnet-upnp-perl zur Nutzung der falschen ControlPoint.pm?)

Keine Ahnung, ob die Angaben nützen!? Infos aus der Problemsituation, wo nicht auf die Version aus FHEM/lib zugegriffen werden kann, wären vermutlich sinnvoller.

Wenn es Dir hilft, kann ich Dir einen Patch für die commandref mit Angabe der vorausgesetzten Perl-Module liefern, würde derzeit aber die Perl-Pakete angesichts meiner beschriebenen Problematik nicht nennen.

Gruß, Christian

[dominik]

Hallo zusammen,

danke für den commandref Patch Christian. Habe diesen soeben eingecheckt.

Gruß,
Dominik