[Snapcast] - support Thread ab 2022

Begonnen von Beta-User, 28 Juni 2022, 13:50:12

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

wie ihr vielleicht mitbekommen habt, bin ich grade am Rumexperimentieren mit dem Thema, wie der Sound von einem MPD denn eigentlich am "geschicktesten" und flexibelsten auf die Ausgänge eines Yamaha-Receivers geschickt werden kann.

Dabei bin ich über die Module Snapcast und OpenMultiroom von @unimatrix "gestolpert", der aber leider seit langem nicht mehr hier im Forum aktiv gewesen zu sein scheint. Da Snapcast jetzt "anfängt zu zucken", habe ich mich in Absprache mit Rudi daher als ersten Schritt mal als MAINTAINER für Snapcast eingetragen, das erste update von mir kam heute morgen. Das war noch "ungefährlich" und bringt erst mal die commandref auf den "id"-Standard, so dass die Beschreibungen zu Attributen etc. dann direkt unter dem Eingabefeld eingeblendet werden.

Irgendwelche Kenntnisse im Modul dürft ihr (noch) nicht erwarten, wobei das in der Bedienung/Konfiguration auf der FHEM-Seite erst mal nicht wirklich schwierig ausschaut. "Spaßiger" finde ich die Konfiguration auf der FHEM=Snapcast-Server-Seite iVm. pulseaudio. Aber da lichtet sich so langsam aber sicher der Nebel...

Es wäre klasse, wenn sich wenigstens einer derjenigen auch als Tester zur Verfügung stellen würde, die das heute im Einsatz haben, dann würde ich die jeweilige Entwickler-Version ggf. vorab hier im Forum platzieren. Sonst müßte ich darauf ausweichen, das nach eigenen Tests dann eben direkt ins svn zu schubsen. Wer an derartigen Tests nicht teilnehmen will, sollte daher ggf. vorsichtshalber das Modul vom update ausnehmen (ggf. erst nach dem heutigen update).

Wer Fragen oder Anregungen hat, möge diese bitte hier platzieren und/oder für "spezielle Themen" auf separate Threads ausweichen, wer die Pflege stattdessen lieber selbst (statt meiner oder ergänzend) übernehmen möchte, darf sich selbstredend melden.

Weitere Pläne und Gedanken:
- Die kommende Version wird dann eine gewisse PBP-Konformität herstellen, anschließend wird es voraussichtlich gepackaged.
- Falls es im Ausgangsthread irgendwelche (noch) offenen Punkte gegeben haben sollte, könnt ihr das gerne hier platzieren, ich schau dann, ob da was zu machen ist...
- Mittelfristig würde ich mir gerne OpenMultiroom ansehen und die direkte Steuerung der jeweiligen Verstärkerhardware noch mit da reinknödeln. Macht irgendwie m.E. nicht allzuviel Sinn, die Lautstärke softwaremäßig zu ändern, wenn man das (bei vernünftigen Ausgangspegeln aus der Software) auch in Hardware haben kann...

Soviel erst mal für's erste,

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

Beta-User

#1
So,

dann hier also mal eine erste Version für mutige Tester, und dazu gleich eine erste Fassung des erweiterten OpenMultiroom-Moduls :) .

Bitte sichert eure aktuell vorhandene(n) Fassung(en) (Module sind typischerweise zu finden in /opt/fhem/FHEM), bevor ihr euch ans Testen macht. Am einfachsten eine Kopie machen und die halt z.B. mit der Endung .svn oder .old versehen.

Danach die hier angehängten Dateien in das Verzeichnis packen, und die Rechte anpassen (anzuzeigen mit ls -l; chown ist euer Freund, Soll ist typischerweise fhem:dialout) und dann FHEM neu starten (bei einem simplen reload hagelt es vermutlich eine Reihe Warnings wegen der nun fehlenden Prototypen).

Die Änderungen an Snapcast sind eher unter der Haube zu finden, funktional hoffe ich, dass alles noch funktioniert wie gewohnt:
- diverse Attribute werden nicht mehr zwangsweise vergeben/angelegt
- PBP meckert nur noch auf Level 3, mal sehen was davon noch auf einfachem Weg wegzubekommen ist (Falls jemand wissen will, was das bedeutet: Die file nach http://perlcritic.com/ hochladen, Level anpassen und 'Analzye ...' drücken)...
- Verboselevel von manchen Log3-Anweisungen

Es würde mich ausgesprochen freuen, wenn die Bestätigung auch von dem einen oder anderen der bisherigen Nutzern käme, dass alles erst mal weiter funktioniert wie gewohnt und keine "seltsamen Einträge" im Log zu finden sind. Dann würde ich das vollends "aufhübschen" und dann einchecken.

OpenMultiroom
Ist eine Art Erweiterung zum Snapcast-Modul, das es erlaubt, auch den (jeweils aktuell) dahinterliegenden Medienplayer zu steuern (derzeit beschränkt auf MPD, es sollte aber möglich sein, das auf "alles" auszuweiten, das "typische Medienplayer-Kommandos" versteht (z.B. auch Instanzen des Spotify-Moduls?). Weiter bringt es die Möglichkeit mit, Fernbedienungs-Codes (auch als Tastenfolgen) auszuwerten und dann als Kommando an den Player zu schicken
Da oft/meistens (?) eine Koppelung zwischen einer Snapcast-Instanz und einem Verstärker bestehen wird, der ggf. gesondert angesteuert werden müßte, dachte ich mir, es sei den Versuch wert, einen solchen (samt optionaler Angabe eines "inputs") auch noch zu integrieren.

Auch hier ist die Zahl der notwendigen/zwangsweisen Attribute erst mal gesunken, sinnvollerweise müßten wohl "mr" und "soundMapping" gesetzt werden (siehe Wiki), wer die Verstärker-Option testen will, gibt dann noch in "amplifier" den Namen des Verstärkers an, wer den input-Kanal mit Schalten will, setzt den - getrennt durch einen Doppelpunkt - dahinter (funktioniert derzeit ggf. nur bei Wechsel des streams).

Habe das mehr oder weniger (eher letzteres) kurz angetestet und bin mal gespannt, ob das allg. Interesse findet...

Viel Spaß jedenfalls beim Testen und Danke vorab!

Gruß Beta-User

EDIT: Per Perltidy aufgehübschte Fassungen, funktional unverändert.
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

rcmcronny

Hallo,

habe beide mal eingespielt. OpenMultiroom nutz ich aktuell aber nicht. Snapcast sieht erstmal gut aus, keine offensichtlichen Fehler. Mal gucken wie es sich die Tage verhält.

(Und hier auch abonniert :) )

Ronny

Beta-User

Zitat von: rcmcronny am 04 Juli 2022, 14:25:28
Snapcast sieht erstmal gut aus, keine offensichtlichen Fehler. Mal gucken wie es sich die Tage verhält.
:) Dann bin ich erst mal beruhigt und warte, ob du noch irgendwas an Auffälligkeiten oder komischen Log-Einträgen findest (es sollten bei verbose=3 weniger geworden sein).

Hatte schon vermutet, dass die Ankündigung untergegangen war, aber irgendwie ist es m.E. auch nicht geschickt, die alten Support-Threads dann endlos weiterzuführen, wenn ein Maintainer-Wechsel stattgefunden hat.

Zitat
OpenMultiroom nutz ich aktuell aber nicht.
Das ist auch kein "Muss", den Punkt hätte ich vielleicht deutlicher klarstellen können?

Hier trotzdem etwas OT der Hinweis, falls jemand da mit einsteigen will und z.B. auch die TTS-Ausgaben mit reinmischen:
@pldemon hat ein paar patches für Text2Speech geliefert, mit denen man z.B. gleich das Ausgabegerät mit angeben kann (die wurden ins svn übernommen). Er nutzt das u.A. auch dazu, gleich einen Player anzusteuern, der das per raop-sinks verteilt, siehe https://forum.fhem.de/index.php/topic,119278.msg1137044.html#msg1137044, aber die {options}-Methode sollte man z.B. auch dazu verwenden können, die vielen Text2Speech-Instanzen aus der OpenMultiroom-Darstellung im Wiki abzulösen...
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

rcmcronny

Hi,

bisher paßt alles bei mir weiterhin.

Ne OpenMultiroom schau ich mir mal an, war klar für mich das es optional ist. War eine reine Info, das mein Feedback nur für snapcast.pm gilt :)

Ronny

chicco

Hallo Beta-User,

ich nutze das Modul seit 3 Monaten weil ich in meiner neuen Wohnung den Sound zwischen Küche und Wohnzimmer aufteilen muss. In der alten Wohnung war alles zentral in der Wohnküche.
Ich habe dann auch einen Fehler gefunden und habe den lokal bei mir gefixt. Jetzt wollte ich den Fix im alten Snapcast-Thread posten... und siehe da, du hast das Modul übernommen.

Fehlerbeschreibung:
Wenn man in der Snapcast-Android-App die Lautstärke von einer Gruppe ändert, crasht fhem.
Dann kommt ein Array von json-Strings (ein String für jeden Client in der Gruppe) im Modul an und wenn das dann decoded werden soll, kommt kein Hash dabei raus -> Fehlermeldung:
Not a HASH reference at ./FHEM/96_Snapcast.pm line 243

Ich nehme an, du willst den Fix in deine Version einbauen.
Was brauchst du von mir?
Meine geänderte Snapcast.pm?
Oder ein diff?

Deine Version habe ich noch nicht getestet. Will ich dann gerne machen, aber vielleicht ist es sinnvoller das zu tun wenn mein Fix eingebaut ist.

Und wenn das Modul jetzt wieder einen Maintainer hat, will ich doch gleich mal einen Feature-Request in die Runde werfen: Gruppensteuerung
Habe selbst schon mit dem Gedanken gespielt das anzugehen, aber noch nicht die Zeit gehabt so tief in das Modul einzusteigen  :-\

Gruß
chicco

Beta-User

#6
Moin,

dann mal willkommen an Bord!

Hatte gestern mittag noch eine Aktualisierung ins svn geschubst, bei der sieht die Zeile zumindest anders aus (jetzt: #233) - der Stand war der hier im Form vorab gepostete :) .

Also bitte einfach deine Version sicherheitshalber wegspeichern und ein normales update machen.

Hier gleich die nächste Iteration: gepackaged (sonst keine neue Funktionalität, kann aber sein, dass das eine oder andere Warning gefixt ist).
Da dabei (leider) auch was schief gehen kann, würde ich empfehlen, das vorab mal auf einen Testsystem auszutesten...

Die laufen bei mit auch auf dem Hauptsystem, aber ich bin leider noch etwas mit meiner neuen Hardware beschäftigt, da kommt via Snapcast im Moment leider nur "choppy sound" raus (geht 2x durch Pulseaudio).

Mit Gruppensteuerung habe ich mich daher noch nicht intensiver auseinandergesetzt, aber vielleicht schilderst du mal, was du genau erreichen willst und schaust dir auch OpenMultiroom man an - ich bin mir nämlich nicht sicher, ob das nicht bereits (indirekt) einige features enthält, die in diese Richtung gehen...
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

#7
Zitat von: chicco am 09 Juli 2022, 20:00:43
Dann kommt ein Array von json-Strings (ein String für jeden Client in der Gruppe) im Modul an und wenn das dann decoded werden soll, kommt kein Hash dabei raus -> Fehlermeldung:
Not a HASH reference at ./FHEM/96_Snapcast.pm line 243

[...]
Was brauchst du von mir?
Meine geänderte Snapcast.pm?
Oder ein diff?
Nochmal zur Sicherheit: Was macht dein Fix? Verhindert er "nur" den crash? (dann sollte meine Variante schon reichen.) Oder wird das Array nacheinander ausgewertet?

Wenn letzteres: Bitte einfach anheften, was du "einfach" zur Verfügung stellen kannst, diff -u wäre super (gg. die svn-Version, die die Basis war (bitte auf jeden Fall mit nennen)). Ansonsten geht auch die Vollversion :) .

EDIT: Formatierung war irgendwie kaputt.
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

chicco

Hi,

ich habe das Array zerlegt und bin den Rest der Funktion dann in einer Schleife durch das Array gelaufen.
Wobei das mit der Schleife wahrscheinlich unnötig ist, denn wenn ich das richtig in Erinnerung habe, steigt die Funktion im ersten Schleifendurchlauf immer irgendwo mit einem "return ..." aus und der Rest der Schleife ist hinfällig. Das war dann aber egal weil auch immer ein Snapcast_getStatus() ausgelöst wird und dadurch alle Clients aktualisiert werden.

Ich hänge dir einfach mal meine beiden Snapcast-files an, einmal die originale und die von mir veränderte. Dazu ein diff -uw

Bei der Gruppensteuerung dachte ich an sowas wie
set SnapServer mute {groupname/groupid} true/false
oder
set SnapServer volume {groupname/groupid} xy

OpenMultiroom hatte ich damals bei der Snapcast-Einrichtung nur kurz angeschaut. Vielleicht schau ich das nochmal genauer an...

Gruß
chicco

Beta-User

OK, Danke!

Mein "Zwischenfix" war leider nicht ausreichend, um das Gruppenproblem zu umschiffen, ergänzter Code ist in Vorbereitung, muss aber erst getestet werden. Im Moment habe ich aber Zweifel, ob der bereits ausreicht, alle "batch"-Fälle sauber zu verarbeiten (zum Ganzen vgl. https://www.jsonrpc.org/specification#batch)

*Augenreib* - es ist wirklich verwunderlich, dass sich all die Jahre keiner wegen dieses Themas gemeldet hatte, oder übersehe ich was?!?



Bzgl. Gruppensteuerung bin ich am Sondieren, wie man das am Geschicktesten angeht. Das mit dem "Gruppenvolume" scheint gar nicht auf direkten Weg vorgesehen zu sein (siehe den Hinweis auf "batch" bei https://github.com/badaix/snapcast/blob/master/doc/json_rpc_api/control.md#requests-and-notifications) und auch danach bei "Requests" findet sich kein Gruppen-volume-set in dieser Doku...
Muss man wohl über eine Schleife erledigen, mal sehen :) .
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

chicco

#10
Das mit dem json-batch habe ich gelesen, aber nicht ganz verstanden - kann es also nicht ganz beurteilen ob mein Fix alle batch-Fälle sauber verarbeitet.
Als ich den Fehler gefunden habe war ich auch verwundert, dass das noch niemand gemeldet hat - das Snapcast-Modul gibts ja immerhin schon ein paar Jahre...

Bzgl. Gruppenvolume habe ich mal geforscht wie das in Snapdroid und Snapweb gelöst ist.
Einmal hab ich das hier gefunden (bin mir aber nicht sicher ob das jetzt zu Snapdroid gehört):
https://github.com/badaix/snapcast/blob/master/control/setVolume.py
Da ist auf jeden Fall eine Schleife durch die Clients einer Gruppe und für jeden Client wird volume einzeln gesetzt.

Bei Snapweb hab ich das hier gefunden:
https://github.com/badaix/snapweb/blob/master/page/snapcontrol.ts
Da gibts Funktionen getGroupVolume() und setGroupVolume().
Bei get kann man sehen, dass die GroupVolume ein Mittelwert der einzelnen Clientvolumes ist.
Bei set ist auch wieder eine Schleife durch die einzelnen Clients und die einzelnen Clientvolumes werden prozentual relativ verändert.

An der Schleife führt wohl kein Weg vorbei...

Beta-User

#11
Puh,

(hoffentlich) ein gewisser Fortschritt...

Anbei vorab eine Aktualisierung. Die gute Nachricht:
FHEM scheint nicht mehr zu crashen, wenn man irgendwelche Gruppenaktionen an der Snapdroid-App ausführt. Allzu intensiv habe ich aber noch nicht getestet.

Die schlechten Nachrichten:
- Der Code ist aus vielerlei Gründen* ziemlich umgebaut;
- ich habe keine Ahnung, ob jetzt alles noch funktioniert wie vorher;
- Der Umbau ist noch nicht abgeschlossen**...

Tendiere aber wegen der crash-Prävention dazu, gleich den großen Schnitt zu machen und diese Version zeitnah einzuchecken, falls euch oder mir nicht noch was Schlimmes auffällt (was nicht direkt auch behoben werden könnte).

Zitat von: chicco am 13 Juli 2022, 00:03:13
Das mit dem json-batch habe ich gelesen, aber nicht ganz verstanden - kann es also nicht ganz beurteilen ob mein Fix alle batch-Fälle sauber verarbeitet.
Ganz verstanden habe ich das vermutlich auch noch nicht, denn das, was jetzt an vermeintlichen batch-volume-Anweisungen rausgeht, scheint nicht den Erwartungen des Snapcast-Servers zu entsprechen (**erster Punkt für Nacharbeit), obwohl keine direkte Rückmeldung zu kommen scheint (dafür aber eine auf Anweisungen von der App aus, die ausgeführt werden?)

Was dein Code macht, habe ich dann nicht im Detail untersucht, sondern einfach erst mal eine Vorrangbehandlung für decodierte*** Arrays reingebastelt. Ich bezweifle aber, dass die alle Fälle erfasst, und habe halt mal (inhaltlich nicht weiter im Detail auf Funktionalität geprüft) reingenommen, was ich "einfangen" konnte (=> ** Teil II)

Zitat
Als ich den Fehler gefunden habe war ich auch verwundert, dass das noch niemand gemeldet hat - das Snapcast-Modul gibts ja immerhin schon ein paar Jahre...
Die Verwunderung bleibt nicht an der Stelle stehen: Das Modul ist (bzw. *war) ausschließlich (?) auf IP-V4-Clients zugeschnitten, "id" war erst am Horizont angedeutet, und irgendwie bin ich auch nicht sicher, ob das Rückwärtsmatching mit mehreren Clients auf einer IP-Adresse je funktioniert hat. Jedenfalls hagelte es beim FHEM-Start eine Reihe von "mag ich nicht"-Meldungen wegen der Reading-Namen.

*Na jedenfalls beabsichtige ich, das ganze konsequent auf "id"-Bezüge umzustellen, so dass auch IP-V6-Clients korrekt adressiert werden.

ZitatBzgl. Gruppenvolume
Dazu habe ich jetzt mal eine Schleife + batch-Kommando gebaut, es funktioniert nur aus irgendwelchen Gründen noch nicht. Das versendete JSON selbst sieht für meine Augen ok aus.
Eine mögliche Ursache könnte sein, dass man alle clients aufführen muss, die in der Gruppe sind. Das klappt u.A. deswegen noch nicht, weil die Schleife bisher nur clients erfaßt, die es auch als FHEM-Devices gibt. (* die volume-Werte sind aber am Server-Device da, so dass der Bezugspunkt halt ggf. einfach geändert werden muss/kann).

***apropos JSON: das ist jetzt auch von decode_json/encode_json weg auf die "nicht-Zeichensatz-konvertierende" Variante. Scheint zumindest nicht schlechter zu funktionieren.

=> wie ihr seht, ist noch einiges zu tun, aber ein paar große weitere Schritte sind gemacht :) .
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 14 Juli 2022, 13:22:52
Tendiere aber wegen der crash-Prävention dazu, gleich den großen Schnitt zu machen und diese Version zeitnah einzuchecken, falls euch oder mir nicht noch was Schlimmes auffällt (was nicht direkt auch behoben werden könnte).
done.

Habe gg. der Version von gestern noch eine etwas veränderte Gruppen-funktion versucht, leider (bisher) auch erfolglos...

Falls jemand eine Idee hat: her damit... Werde mir als nächstes jedenfalls nochmal die internen Referenzierungen vornehmen, aber das ist dann alles nicht mehr ganz so dringlich.
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

So, die erste Gruppenfunktion funktioniert jetzt - man kann im "Zentralgerät" das volume der Gruppen setzen. Für absolute Kommandos wird eine virtuelle Lautstärke ermittelt und die als Referenz verwendet.

Ansonsten wundert mich etwas, dass es hier so still ist? Keine Probleme oder im Urlaub?!?

("Keine Probleme" interessiert mich auch, da waren doch einige größere Umstellungen drin und ich stochere bei manchem noch im Nebel...)
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

rcmcronny

Moin,

hast Du es schon eingecheckt und kommt es mit dem Update oder muss man getrennt runterladen ?
Ich versuche das extra runterladen auf ein notwendiges Maß zu reduzieren und update dafür öfters (jeden Früh mache ich ein Check und lasse mir die Infos zukommen, da sehe ich dann ob es sinnvoll ist bzw was ich erwarten kann :D)

Für Snapcast mach ich aber eine Ausnahme, wenn es nötig ist :)

Achja, ansonsten rennt alles und ich bastel da eher im Herbst wieder rum wenn das Wetter schlechter wird. Aktuell ist eher genießen wie es läuft und nix ändern ,was was kaputt macht und man dann das Wetter nicht genießen kann :D

Ronny