Hallo zusammen,
ich verwende das FHEM MPD Modul in Verbindung mit mehreren Owntone Server Instanzen (Version 28.5). Seit längerem beobachte ich Probleme beim Sync zwischen FHEM und Homebridge.
Nach längerem Suchen habe ich dafür das
MPD Plugin als Ursache identifiziert.
Getriggert vom Event "
changed: database OK", kommend vom Owntone Server, reagiert der FHEM MPD mit einer Flut an "
playlistinfo", welche der Owntone Server wieder mit einem "
OK" bestätigt wird.
Das führ dazu, dass der Owntone Prozess und der FHEM Process jeweils auf ca. ~98% Last gehen.
Das Event "
changed: database OK" entsteht, wenn ich auf Owntone Server ein "Update Library" mache, oder ein neues Album hochlade.
Anbei ein TCPDUMP (zipped) in dem das ganze gut zu sehen ist. In nicht ganz 30s werden 125.000 Pakete generiert.
- Owntone MPD: 127.0.0.1:50490
- FHEM Instanz: 127.0.0.1:6601
Beruhigen lässt sich das FHEM MPD Modul mit folgendem Kommando:
set DAAPD resetVielleicht kann sich das ja einer der Entwickler mal ansehen.
Vielen Dank und Lieben Gruß
Oliver
Hi.
Weiß nicht, ob das auch in dem Fall hilft, aber evtl. magst du die Version aus https://forum.fhem.de/index.php/topic,18517.msg1225687.html#msg1225687 mal testen, ob die das Problem auch hat?
Die sollte zumindest länger Blockaden vermeiden, wenn irgendwas unerwartetes kommt oder die Gegenstelle viel länger braucht wie erwartet...
Gerade getestet. Leider gleiches Verhalten. Trotzdem Danke für den Versuch. :)
Danke.
Magst du dann das hier noch testen?
leider auch noch nicht.
ich habe gesehn, dass da ein Linefeed in Dump ist (0x0A). Also so:
changed: database
OK
hab mich am code versucht in zeile 1285 mit:
elsif ($_ eq "database\nOK"){
hat leider auch nicht geklappt.
M.E. dann nur "database".
leider auch nicht. ich bau da morgen mal ein paar debug ausgaben ein. trotzdem schnmal vielen dank!
OK. Vielleicht dazu eine Idee: Das Modul geht jetzt von einem bestimmten Satz an möglichen Infos aus, die da kommen können. Vermutlich bist du "zu neu", und es kommt was, was das Modul nicht kennt. Wir könnten daher auch umgekehrt vorgehen: Alles, was das Modul (noch) nicht kennt, kommt ins Log (und/oder ein Reading?) und wird ansonsten ignoriert?
ich habe nun ein paar logging ausgaben eingebaut, und festgestellt, dass nicht das "database" ankommt, sondern ein "update". Ich habe dann deinen code auf update geändert. Es fehlte dann noch ein "step 1", weil der dann bei den OKs in "step 0 " unendlich loopt.
hier meine änderung bei zeile 1285:
elsif ($_ eq "update"){
print $sock "idle\n";
$step=1;
}
Zitat von: Beta-User am 09 Dezember 2022, 07:05:15
OK. Vielleicht dazu eine Idee: Das Modul geht jetzt von einem bestimmten Satz an möglichen Infos aus, die da kommen können. Vermutlich bist du "zu neu", und es kommt was, was das Modul nicht kennt. Wir könnten daher auch umgekehrt vorgehen: Alles, was das Modul (noch) nicht kennt, kommt ins Log (und/oder ein Reading?) und wird ansonsten ignoriert?
ja den Ansatz finde ich nicht schlecht. Aktuell führen unbekannte nachrichten dazu, dass der Step nicht gesetzt wird. und bei step=0 sendet er dann unedlich ein "playlistinfo".
else #if ($_ eq "OK")
{
print $sock "idle\n" if($step) ;
print $sock "playlistinfo\n" if(!$step) ;
$step=2 if ($step==1);
} # OK
Das hier sollte es tun. Kannst/magst du testen?
elsif ($_ !~ m{\Aplayer|playlist|mixer|options|update\z}x){
print $sock "idle\n";
$step=1;
readingsSingleUpdate($hash,'last_error',$_,1);
}
elsif ($_ eq 'update'){ #might be extended for other new message types w/o further action to FHEM
print $sock "idle\n";
$step=1;
}
else #if ($_ eq "OK")
sorry bin jetz erste dazu gekommen das zu testen. das geht soweit! vielen dank!
aber das 'update' ist nun zwei mal drin. Zeile 1285 und 1290. war/ist das so gedacht?
vielen dank!
vg
Oliver
Danke für's testen, habe das jetzt so eingecheckt.
Das mit der vermeintlichen "Doppelung" ist übrigens korrekt, es ist einmal "was anders als" und das andere mal "gleich" ;) .