DIY Multiroom Projekt

drdownload · 04 Januar 2017, 21:18:06

Hi, ich habe jetzt meine Arch VM aufgegeben und eine Debian Jessie VM für den Musik Server gemacht. Funktioniert jetzt mit 7 Zonen problemlos. Das einzige das mir in Kombi mit mopidy auffällt, dass mopidy nach dem Druck auf Pause oft noch viele Sekunden nachspielt (das könnte ja noch der fifo sein) aber da auch fhem dann einige Sekunden hängt vermute ich eher ein mopidy Lock Up. Hat das Problem sonst jemand?

unimatrix · 09 Januar 2017, 10:01:03

Hallo,

bin zurück aus dem Urlaub und werd jetzt wieder loslegen. Bei mir ist die FIFO Pause ca. 1-2 Sekunden.

Warum hängt dann FHEM? Nutzt du jetzt das Snapcast Modul oder das MPD Modul oder beides?

Problem mit dem Snapcast Modul ist dass im Moment ja einiges an der Schnittstelle bei Snapcast gedreht wird, das aber noch nicht fertig ist.

Mopidy habe ich noch keinem Dauertest unterzogen aber ich habe Beobachtungen wo die einzelnen Instanzen mal auf 100% CPU Last gehen und dann langsam reagieren.

unimatrix · 09 Januar 2017, 17:47:40

Zitat von: LeoSum am 19 Dezember 2016, 23:24:34
Mir ist aufgefallen dass dein Modul die readings nicht updated, nachdem ein setbefehl rausgeschickt wird.

Ich habe das jetzt dadurch gelöst, dass ich am ende der Snapcast_set Methode in Zeile 135 noch ein "Snapcast_GetStatus($hash);" hinzugefügt habe.

Hallo, kann ich nicht reproduzieren. Das Modul hält eine offene Verbindung zum Snapcast Server und sollte eig. alle Readings updaten, die auch vom Server upgedated werden. Das betrifft ja gerade auch solche Updates, die von einem anderen Client, z.B. vom Android Client aus, angetriggert werden. Wenn ich bei mir im Android Client z.B. Mute und UnMute dann sehe ich das sofort in den Readings.

Ein Extra GetStatus wollte ich eigentlich vermeiden. Kannst du das Problem genauer beschreiben?

unimatrix · 09 Januar 2017, 17:50:51

Zitat von: LeoSum am 19 Dezember 2016, 23:12:30

In deinen Beispielen haben sich aber kleine Fehler eingeschlichen. das set command muss immer "set <servername> <attribut> <clientname> <wert>" lauten. du hast teilweise attibut und clientname vertauscht. Das musste ich erstmal rausfinden

meinst du in der Commandref oder hier im Forum? Commandref habe ich gerade nochmal durchgeschaut und scheint zu stimmen, aber vll. bin ich da als Autor blind

Zitat von: LeoSum am 19 Dezember 2016, 23:12:30
Meinst du es würde Sinn machen ein command wie "volstepup" und "volstepdown" zu definieren?

Das ist direkt im Modul geplant

unimatrix · 09 Januar 2017, 19:09:47

Zitat von: drdownload am 04 Januar 2017, 21:18:06
Hi, ich habe jetzt meine Arch VM aufgegeben und eine Debian Jessie VM für den Musik Server gemacht. Funktioniert jetzt mit 7 Zonen problemlos. Das einzige das mir in Kombi mit mopidy auffällt, dass mopidy nach dem Druck auf Pause oft noch viele Sekunden nachspielt (das könnte ja noch der fifo sein) aber da auch fhem dann einige Sekunden hängt vermute ich eher ein mopidy Lock Up. Hat das Problem sonst jemand?

Kann ich reproduzieren. Ist IMHO ein Problem mit dem MPD Modul. Dem muss ich auf den Grund gehen sonst ist das ja unbenutzbar.

drdownload · 09 Januar 2017, 19:22:35

Das Problem ist wohl die Kombi aus mopidy filesink und snapcast. Wenn ich einfach auf eine alsasink abspiele läuft mopidy.

Das mpd Modul lockup kommt auch nur vor wenn ich versuche in mopidy zu stoppen etc.

CPU Last ist unter Debian jetzt kein problem mehr ca 5% pro transcoding instanz

drdownload · 09 Januar 2017, 19:23:52

Der blocking call von Mpd Modul ist aber auch so grausig

unimatrix · 09 Januar 2017, 20:15:36

aus meiner Sicht braucht man da gar keinen Blocking Call....uff...das sieht nach Arbeit aus die ich mir gar nicht antun wollte...

drdownload · 09 Januar 2017, 20:20:13

Ich hab mich Mal kurz gespielt, wenn ich die Fifos von snapcast anlegen lasse und dann mopidy die ownership gebe bin ich immerhin auf 2s lagging unten

edit: pff leider doch nicht, verstehe ich nicht, manchmal geht es sofort, manachmal hängt es 2-3 min. bevor es stoppt (und in der Zeit ist auch FHEM blockiert)

egal ob spotify, stream oder lokal.

unimatrix · 09 Januar 2017, 20:38:13

ok das habe ich schon immer so gemacht, wahrscheinlich durch Zufall.

MPD mal angeschaut. Da wird immer wieder die Verbindung zum MPD Server in einem eigenen Prozess aufgebaut. Mir ist noch nicht klar wieso. Ich unterstelle mal dass da ein guter Grund hinterstand. IMHO koennte man einfach die Verbindung auflassen so wie ich das mit dem SC Modul auch mache und dann gibts auch keine Blocking Calls, keine Timeouts, oder sonst irgendetwas.

Bei mir ist es jetzt leider so dass FHEM für immer einfriert wenn ich ein MPD Modul definiere und dann per Android Native Mopidy Client etwas tue.

drdownload · 09 Januar 2017, 21:01:26

Ja, das Verhalten kenne ich.

unimatrix · 09 Januar 2017, 21:18:55

du kennst es oder ist es bei dir auch immer so bzw. nur manchmal? ich versuche, dem auf den Grund zu gehen. danke

unimatrix · 09 Januar 2017, 21:37:12

nach attr mpd player mopidy tritt das problem nicht mehr auf. na toll.

unimatrix · 09 Januar 2017, 22:07:56

Zitat von: LeoSum am 19 Dezember 2016, 23:12:30
Meinst du es würde Sinn machen ein command wie "volstepup" und "volstepdown" zu definieren?

Ist implementiert und auf dem GIT.

Beispiel: set snap myclient volume -12
..also einfach ein + oder - davor setzen.

Werde bei Bedarf noch ein Attribut fuer eine dort festlegbare Stepweite anlegen.

unimatrix · 10 Januar 2017, 08:55:40

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

Das sieht interessant aus in Richtung Visualisierung, das System ist ja das gleiche wie bei uns. Auch hier hört ein kanal woanders mit. Nur mal als Hinweis.

Ich poste ab jetzt alle Dinge, die direkt mit Snapcast zu tun haben, nur noch in den Snapcast Thread. Heute kommt noch ein Update.