Modul für MPD

Begonnen von roedert, 08 Januar 2014, 12:17:21

Vorheriges Thema - Nächstes Thema

Beta-User

@JensS:
Grundsätzlich fände ich es gut, wenn man die Aufrufe "relativ einfach" in ein Block-eval kapseln könnte.

Ungetestet wäre ich dann statt
while (<$sock>)  # MPD rede mit mir , egal was ;)
{ last if $_ ; } # end of output.

auf das hier gekommen  (statt "die" sollte es Carp::carp auch tun):
if ( !eval {
        $SIG{ALRM} = sub {Carp::carp 'timeout';};
        alarm(1);
        while (<$sock>)     # MPD rede mit mir , egal was ;)
            { last if $_ ; } # end of output.
        alarm(0);
        1; }
    ) {
        return $@ if $@;
    }


Die IO::Select/can_read()-Methode hatte unimatrix hier schon mal vorgeschlagen:
Zitat von: unimatrix am 13 Januar 2017, 16:45:54
Ggf gibts auch eine schnellere Lösung mit IO::Select und can_read(), was man dann aufruft, um zu checken ob da was kommt. So würde man zumindest in den Timeout laufen. Das schaue ich mir gerne selbst an sobald ich die Gelegenheit habe.

@Wzut: Du bist so verdächtig still...
Habe mal versucht, den Thread hier durchzuflözen, habe aber keine Anhaltspunkte gefunden, dass die Vorschläge irgendwie obsolet geworden wären. Aber falls die aktuellen Vorschläge schon mal verworfen worden waren - bitte einfach "halt" rufen!

Was vielleicht noch wissenswert ist:
- meine MPD-Version ist 0.23.5 (=reguläre Ubuntu 22.04 LTS-Version, "richtiger" MPD mit perlre-Unterstützung)
- läuft auf einem anderen Rechner
- das mit den separaten Commands für die Erneuerung/Ergänzung der aktuellen playlist hat sich erledigt, aber (bzgl. der Steuerung mit RHASSPY) wichtig wäre, dass mpdCMD erhalten bleibt (damit kann man super filter-Anweisungen raushauen...)




Liest hier eigentlich auch jemand mit, der OpenMultiroom im Einsatz hat?
Soweit erkennbar, ist @unimatrix nicht mehr aktiv, und das Modul aus https://forum.fhem.de/index.php/topic,65785.msg569918.html#msg569918 wurde nie ins FHEM-svn eingecheckt (scheint aber Probleme zu machen?). Prinzipiell finde ich das interessant, würde aber gerne meine "beiden" Hauptausgabegeräte irgendwie direkt beliefern (ein YAMAHA-Receiver mit 2 Zonen, der derzeit v.a. über HDMI von dem Rechner aus mit Sound versorgt wird, auf dem der MPD läuft).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: Beta-User am 21 Juni 2022, 13:16:12
Ungetestet
Jetzt: Getestet, keine neuen Probleme (bei meinem an sich stressfreien System).
Anbei daher aktualisierter patch samt Vollversion, falls jemand mittesten will...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

Zitat@Wzut: Du bist so verdächtig still...
sorry, aber ich bin erst ab 3. Juli wieder zu Hause mit guter Verbindung
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Zitat von: Wzut am 22 Juni 2022, 20:08:51
sorry, aber ich bin erst ab 3. Juli wieder zu Hause mit guter Verbindung
Kein Grund, dich zu entschuldigen!
Genieße die Zeit!!!

Wollte nur sicherstellen, dass wir hier nicht in eine Richtung laufen, die unerwünscht ist oder bereits "abgehakt"...

Zitat von: Beta-User am 21 Juni 2022, 13:16:12
Liest hier eigentlich auch jemand mit, der OpenMultiroom im Einsatz hat?
Würde mich weiter interessieren, habe zu meinen spezifischen Anforderungen/Vorstellungen auch mal einen Thread (Lost in options - Yamaha, DLNA und MPD: Wie zusammenpuzzeln?) aufgemacht und würde mich freuen, wenn mir jemand den Weg weisen könnte. Ansonsten wäre grade die Idee, erst mal zuversuchen, ob die Yamaha-Zonen nicht am einfachsten mit pulseaudio-module-raop (Airtunes-Schnittstelle) eingebunden werden könnten. Bin aber totaler Noob mit dem Thema...

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: Wzut am 22 Juni 2022, 20:08:51
sorry, aber ich bin erst ab 3. Juli wieder zu Hause mit guter Verbindung
Hattest du schon Gelegenheit, mal drüberzuschauen?
Der Kreis der Tester hat sich zwar nicht wesentlich vergrößert, aber jedenfalls bei mir gab es keine nennenswerten Probleme bisher.

(OT: es gibt irgendwo auch noch einen offenen Punkt bzgl. readingsWatcher-commandref :) ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

enno

Zitat von: Beta-User am 22 Juni 2022, 08:13:01
Jetzt: Getestet, keine neuen Probleme (bei meinem an sich stressfreien System).
Anbei daher aktualisierter patch samt Vollversion, falls jemand mittesten will...

Ich arbeite auch noch mit der Version von Beta-User. Kann ich das normale Update wieder aktivieren?  8)

Gruss
Enno
Einfacher FHEM Anwender auf Intel®NUC

JensS

Zitat von: Wzut am 22 Juni 2022, 20:08:51
sorry, aber ich bin erst ab 3. Juli wieder zu Hause mit guter Verbindung

@Wzut
Siehst du eine Möglichkeit, den Fehler von plötzlich ausbleibenden MPD-Paketen, im MPD-Modul abzufangen? Wäre schön, wenn das ginge.

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Beta-User

@Wzut - falls du das noch nicht gesehen hattest:

Es gab Probleme mit (vermutlich) sehr neuen/modifizierten Versionen von mpd, Lösungsvorschlag (incl. bisheriger Vorschläge) wäre hier zu finden:
https://forum.fhem.de/index.php/topic,130801.msg1250282.html#msg1250282
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

sorry aber ich kann da leider nicht mehr mitreden da ich nun schon eine ganze Weile keinen MPD mehr in Betrieb habe.
D.h. wenn du (Bata-User) dich da richtig einbringen möchtest kannst du gerne das Modul übernehmen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Puh, war eigentlich nicht meine Intention - habe schon zu viele "Waisen", die eigentlich einen Maintainer bräuchten, der versteht, wie die Dinge funktionieren ::) ...

Das mit dem "nebenläufigen Prozess" habe ich vermutlich noch nicht komplett durchschaut.

Vorschlag: Ich trage mich mal als Co-Maintainer ein und checke die Änderungen bei Gelegenheit ein. Falls (!) es Probleme geben sollte, ist jedenfalls klar, wer's verbockt hat und reparieren sollte :o ...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wernieman

Würde Dir ja normalerweise gerne dabei helfen, nur bin ich definitiv kein Entwickler .... jedenfalls hat das mein beruflicher Werdegang mehr als ein mal gezeigt ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Beta-User

Zitat von: Wernieman am 04 Januar 2023, 20:22:30
Würde Dir ja normalerweise gerne dabei helfen, nur bin ich definitiv kein Entwickler .... jedenfalls hat das mein beruflicher Werdegang mehr als ein mal gezeigt ...
Na ja, immerhin kannst du zwischen "Entwickler" und was anderem unterscheiden...

Ich bin definitiv auch kein wirklicher Entwickler ;D , aber bestehenden Code halbwegs ordentlich verwalten und ggf. bei Problemen anpassen, das geht grade eben so...

(Falls irgendwo Probleme bekannt werden, kommt es eh' nicht darauf an, wer die Ursache(n) dafür findet, sondern eher, dass die (zeitnah und "ordentlich") gefixt werden).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

Nun macht euch beide mal nicht kleiner als ihr seid :) Ich als gelernter Schlosser habe/hatte auch mit Software beruflich nichts am Hut und mache es seit über 40 Jahren auch nur als Hobby.

Zitat von: Beta-User am 04 Januar 2023, 19:43:31
Vorschlag: Ich trage mich mal als Co-Maintainer ein und checke die Änderungen bei Gelegenheit ein.
Das klingt doch schon mal sehr gut, mach das erstein mal so.
Langfristig könnte man das Modul auch nach contrib verschieben, da müsste ich aber nochmal bei einem svn Guru nachhaken wie das genau geht (bei meinem Letzten Versuch mit einem anderen Modul war das dann doppelt)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Zitat von: Wzut am 05 Januar 2023, 09:46:20
Das klingt doch schon mal sehr gut, mach das erstein mal so.
Done!

Zitat
Langfristig könnte man das Modul auch nach contrib verschieben, da müsste ich aber nochmal bei einem svn Guru nachhaken wie das genau geht (bei meinem Letzten Versuch mit einem anderen Modul war das dann doppelt)
Für contrib sehe ich im Moment keine Veranlassung, das Modul wird ja von einigen genutzt, und contrib wäre nur umständlicher, was updates etc. angeht.

Das "verschieben" geht übrigens in der Tat nicht direkt, das ist immer "neu anlegen und am alten Ort löschen".
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files