Squeezebox Modul - erste Version

[RoBra81]

Also, die Musik läuft durch. Der LMS läuft auf einer Synology Diskstation, FHEM läuft auf einem Cubietruck und der Player ist ein RPI mit piCorePlayer - alles mit Netzwerkkabeln verbunden. Ich habe noch einen zweiten Player, bei dem das nicht passiert - der Unterschied ist, dass dieser noch nicht auf den piCorePlayer umgezogen ist...

Ich werde heute Nachmittag nochmal die alte SD-Karte reinschieben, wo es noch nicht der piCoreplayer sondern Squeezelite auf raspbian war und mal sehen, ob es dann noch immer auftritt.

Ronny

PS: den Effekt habe ich übrigens auch bei Stop -> auch da wechselt er immer zwischen stopped und pause...

[bugster_de]

wie gesagt: ich muß mir den Code der Module auch nochmal genau ansehen. Es gab neulich ein paar Patches von anderen Usern, die ich übernommen habe.

Welche Modul Version bei FHEM hast Du im Einsatz? Sind das schon die neuen Module, die ich diese Woche eingecheckt habe?

[RoBra81]

Habe mir wegen des Phänomens die aktuellste Version gezogen

[karl0123]

Ehrlich gesagt, wäre es besser, du gegst 2-3 Versionen zurück. Die aktuelle ist zu fehlerhaft.

[Future]

also das mit dem Alarmen wäre zwar schön, ist aber jetzt kein muss bzw wenns später kommt 

zum anderen Thema:
bei mir läuft dem LMS auf dem CubieTruck mit einer 500 GB HD. Sammlung besteht aus kanpp 900 Alben und knapp 15.000 Musikstücken.
nebeibei laufen noch 2 Squeezelight player, 1x Analog und 1x Digital. wäre das nicht noch genug laufen fhem, nagios3, Owncloud und ein Postfix Server..... 
und das ganze läuft relativ problemlos und die last ist auch nicht über normal 

[RoBra81]

Ehrlich gesagt, wäre es besser, du gegst 2-3 Versionen zurück. Die aktuelle ist zu fehlerhaft.

Ich hatte vorher eine ziemlich alte Version mit der es auch nicht ging und hatte von dem Problem abgesehen, bisher keine Probleme mit der neuen.

Ich werde heute Nachmittag nochmal die alte SD-Karte reinschieben, wo es noch nicht der piCoreplayer sondern Squeezelite auf raspbian war und mal sehen, ob es dann noch immer auftritt.

Es tritt auch mit der anderen Version des Players auf...

[MarcoE]

Hallo,
ich habe gerade die neueste Version von Server und Player eingespielt.
Nun habe ich folgendes Problem (was zuvor problemlos funktionierte): ich schalte meine Squeezebox mit der IR-Fernbedienung ein woraufhin sich (bisher) der Status im FHEM auf on änderte und per ampl die Lautsprecher eingeschaltet wurden. (Bzw. beim Ausschalten eben ausgeschaltet)

Nun passiert dies erst bei Aufruf von statusRequest auf den Player, wobei auch dabei nur ampl geschaltet wird aber der STATE sich nicht ändert.
Muss ich da noch etwas anders parametrisieren (im Vergleich zu vorher)?

Nachtrag: heute morgen haben sich die Lautsprecher ein- bzw. ausgeschaltet, aber mit einer Zeitverzögerung von geschätzt 2-4 Minuten. Beim Ausschalten kann ich ja damit leben- aber einschalten war schneller besser
Danke und Gruß,
Marco

[bugster_de]

Hallo Leute,

mittlerweile kann ich bei mir zu Hause das ganze Verhalten mit On/Off sowie die beschriebenen Verstärker On/off ebenfalls nachvollziehen bzw. es tritt bei mir auch auf. Was ich allerdings nicht nachvollziehen kann ist der Grund hierfür. In der gesamten Kommunikation mit dem LMS Server tritt keinerlei Hinweis auf irgendein Kommando auf, welches diesen Effekt erzeugt. Ich bin da nun leider etwas ratlos, wo ich suchen soll. Aber ich bleibe dran.

[ChrisD]

Hallo bugster_de,

Beim Testen der neuen Version ist mir aufgefallen dass beim Neustart von FHEM die Fehlermeldung 'Error messages while initializing FHEM: configfile: SB: unknown attribute httpport. Type 'attr SB ?' for a detailed list.' im Log auftaucht. Diese kommt daher dass das Attribut 'httpport' in $hash->{AttrList} fehlt. Ich habe die Zeile

Code Auswählen Erweitern

    $hash->{AttrList} .= "maxcmdstack ";
geändert in

Code Auswählen Erweitern

    $hash->{AttrList} .= "maxcmdstack httpport ";
wodurch die Meldung verschwindet.

Wie mehrfach geschrieben gibt es mit der neuen Version 'Kommunikationsprobleme'. Diese kommen daher dass nach einem Start des Modules die Funktion SB_SERVER_LMS_Status nicht aufgerufen wird die für die Initialisierung der Kommunikation nötig ist. In den älteren Versionen des Moduls wurde der Inhalt von SB_SERVER_LMS_Status direkt in SB_SERVER_DoInit abgeschickt.

Es reicht aber nicht SB_SERVER_LMS_Status in SB_SERVER_DoInit aufzurufen da dadurch eine Schleife in SB_SERVER_ParseCmds entsteht:
- SB_SERVER_LMS_Status sendet u.a. ein 'pref authorize ?'
- die Antwort wird in SB_SERVER_ParseCmds ausgewertet und führt zu einem erneuten Aufruf von SB_SERVER_LMS_Status

Mir ist nicht ganz klar wieso SB_SERVER_LMS_Status in SB_SERVER_ParseCmds aufgerufen wird. Ich habe die Aufrufe deaktiviert und in SB_SERVER_DoInit

Code Auswählen Erweitern

    InternalTimer( gettimeofday() + 2 ,
   "SB_SERVER_LMS_Status",
   $hash,
   0 );hinzugefügt. Seitdem werden die Ereignisse vom LMS wieder übertragen.

In SB_SERVER_DoInit wird SB_SERVER_Broadcast aufgerufen was dazu führt dass eine ganze Reihe von Befehlen von den SB_Player-Modulen geschrieben werden. Da der Server zu dem Zeitpunkt noch nicht als 'on' erkannt ist, landen diese Befehle in der Queue. Nach dem Ausführen des 1. SB_SERVER_Alive wird in SB_SERVER_Read festgestellt dass die Queue Befehle enthält und es wird versucht diese zu schicken. Es wird aber nur der 1. Befehl geschickt und anschließend die Queue gelöscht. Um alle zwischengespeicherten Befehle zu verschicken habe ich in SB_SERVER_CMDStackPop die Zeile

Code Auswählen Erweitern

    if ( $n <= $SB_SERVER_CmdStack{$name}{first_n} ) {
in

Code Auswählen Erweitern

    if ( $n <= $SB_SERVER_CmdStack{$name}{last_n} ) {geändert werden. Dadurch werden alle Befehle in der Queue abgeschickt.

Grüße,

ChrisD

[MarcoE]

Hi ChrisD,
ich habe gerade mal deine Änderungen eingespielt- definitiv besser. Jetzt habe ich nur noch ein Problem:
bei mir sind es zwei Squeezeboxen (einmal Squeeze Radio und einmal touch). Die beiden sind synchronisiert. Sprich schalte ich die eine an geht die andere mit an und bei aus selbiges.
Nur: bei fhem ändert sich nur der STATE der Box die ich eingeschaltet habe. Sprich schalte ich den SqueezeRadio ein bleibt laut FHEM die Touch aus (obwohl sie läuft- durch die Synchronisation) und natürlich bleiben auch die Lautsprecher aus...
Sende ich nun an die Touch einen "get StatusRequest" ändert sich der Status auf den richtigen Wert.

Hast Du dafür auch eine Idee?

Danke und Gruß,
Marco

[bugster_de]

@ChrisD: Danke für die ausfürhliche Beschreibung. Wenn ich den Post gestern abend noch gesehen hätte, dann hätte ich mir das Debuggen sparen können. Um 0:30h hatte die Themen dann soweit eingekreist und zumindest bei mir mal gefixed. Der beschriebene Effekt tritt aber nur auf, wenn man kein Alive-Checking des LMS macht. Der Loop des Server Status tritt auch dann nur auf, wenn der LMS nicht passwort geschützt ist.

Root-Cause der ganzen Sache sind alle möglichen bug-Fixes, die hier oder über anderen Wegen bei mir aufgeschlagen sind und die ich in gutem Glauben in das Modul integriert habe. Ich habe gestern abend das ganze Zeug erstmal vollständig aus dem Code entsorgt, da ich es, ehrlich gesagt, leid bin, den Support zu liefern, um dann festzustellen, dass der Bug von jemand anderem eingeführt wurde. Meine private Email läuft so langsam auch voll.

Wie auch immer:
ich komme zu dem Schluß, dass der ganze Mechnismus zur Prüfung, ob der LMS Server eingeschaltet ist vermutlich zu komplex ist. Sprich ich baue das wieder aus und das 97_SB_SERVER verlässt sich dann komplett auf "opened" bzw. "disconnected".
Desweiteren habe ich bei mir den LMS V7.8.1 drauf. Sobald man das Kommando "listen 1" schickt, sendet der alle Sekunde den kompletten LMS Server Status. Bin mir jetzt noch nicht sicher, ob das ein Bug im LMS ist, oder eine Option. Da muß aich nochmal schauen. Zumal die Zustände der Player in den Messages unterschiedlich sind, was zu dauerndem Ein/Aus des verstärkers führt.

[ChrisD]

Hallo,

@bugster_de: Ich habe nur die Punkte beschrieben die für mich relevant waren, das Debuggen hättest du trotzdem machen müssen da ich nicht alle Code-Pfade überprüft habe (z.B. mit Login). Bei meinen Tests war das Alive-Checking übrigens aktiv, das Alive war auch das Einzige was alle 2 Minuten zwischen FHEM und LMS passierte (mangels listen 1). Somit tritt der beschriebene Effekt auch bei aktivem Alive-Checking auf.

@Marco: In 98_SB_PLAYER ist kein Code vorhanden der das Ein-/Ausschalten der synchronisierten Geräte behandelt. Wenn du ein Gerät direkt einschaltest schickt der LMS die Meldung 'power 1' an FHEM. FHEM setzt dann die Readings 'state' und 'power' auf 'on'. Für die synchronisierten Geräte wird dagegen vom LMS 'prefset server power 1' geschickt. Dies wird aber im Moment verworfen wodurch sich der Status der Geräte nicht ändert. Du kannst versuchen in 98_SB_PLAYER hinter den Zeilen

Code Auswählen Erweitern


    } elsif( $args[ 1 ] eq "volume" ) {
SB_SERVER_UpdateVolumeReadings( $hash, $args[ 2 ], true );
(in v6932 sind dies die Zeilen 771 und 772) dies:

Code Auswählen Erweitern

    } elsif( $args[ 1 ] eq "power" ) {
                if( $args[ 2 ] eq "1" ) {
                        readingsBulkUpdate( $hash, "state", "on" );
                        readingsBulkUpdate( $hash, "power", "on" );
                        SB_PLAYER_Amplifier( $hash );
                } elsif( $args[ 2 ] eq "0" ) {
                        readingsBulkUpdate( $hash, "presence", "absent" );
                        readingsBulkUpdate( $hash, "state", "off" );
                        readingsBulkUpdate( $hash, "power", "off" );
                        SB_PLAYER_Amplifier( $hash );
                }
            }
einzufügen. Nach einem reload 98_SB_PLAYER sollte der Status aller Geräte die zusammen ein- und ausgeschaltet werden aktualisiert werden.

Grüße,

ChrisD

[bugster_de]

Hallo Leute,

so, ich habe mal was gemacht. Achtung: das ist Beta !

- das dauernde Ein/Aus des Verstärkers is gefixt
- der von ChrisD beschriebene Effekt ist gefixt
- ich habe das Auslesen der im Player gesetzten Alarme implementiert. Man erhält nun für jeden Alarm ein Reading (ALARM__xyz). In diesem Reading wird die Uhrzeit, die Wochentage, enabled, repeat, Lautstärke sowie das abzuspielende Stück angezeigt wird

Was noch nicht geht:
- wenn man einen Alarm auf dem Player löscht, dann wird das entsprechende Reading noch nicht gelöscht
- ab und zu gehen die Player auf "off" obwohl sie an sind. Mit einem statusRequest kommt aber der Status wieder

[ChrisD]

Hallo bugster_de,

Ich habe die neue Version getestet und dabei ist mir aufgefallen dass der Fehler in SB_SERVER_CMDStackPop nicht behoben wurde. Dadurch wird weiterhin nur der 1. Befehl der Queue abgearbeitet und alle anderen werden gelöscht.

Die Schleife in SB_SERVER_Alive die dazu führt dass nach einem fehlgeschlagenen AliveCheck im Block

Code Auswählen Erweitern

if( $hash->{ALIVECHECK} eq "waiting" )die Verbindung per DevIo_CloseDev geschlossen wird und anschließend nie wieder geöffnet wird ist auch noch enthalten. Ich habe meinen Fix aus Beitrag 335 wieder integriert und damit wird die Verbindung wieder korrekt aufgebaut.

Wenn mehrere Player miteinander synchronisiert sind wird der aktuell gespielte Titel und Interpret nur beim Master aktualisiert. Damit bei den anderen Geräten die Daten aktualisiert werden habe ich in SB_PLAYER_Parse hinter

Code Auswählen Erweitern

    # the song has changed, but we are easy and just ask the player
    IOWrite( $hash, "$hash->{PLAYERMAC} artist ?\n" );
    IOWrite( $hash, "$hash->{PLAYERMAC} album ?\n" );
    IOWrite( $hash, "$hash->{PLAYERMAC} title ?\n" );
    SB_PLAYER_CoverArt( $hash );(Zeilen 530-534 in der Beta aus letztem Post) dies

Code Auswählen Erweitern

        if ($hash->{PLAYERMAC} eq $hash->{SYNCMASTER}) {
            if (defined($hash->{SYNCGROUP}) && ($hash->{SYNCGROUP} ne '?')) {
                my @pl=split(",",$hash->{SYNCGROUP});
                foreach (@pl) {
                    IOWrite( $hash, "$_ artist ?\n" );
                    IOWrite( $hash, "$_ album ?\n" );
                    IOWrite( $hash, "$_ title ?\n" );
                }
            }
        }hinzugefügt.

Grüße,

ChrisD

[MarcoE]

Hallo,
super, daß sich in dem (für mich tollen!) Modul noch soviel bewegt! Danke!
Ich habe gerade die beta und die Änderungen von ChrisD eingebaut. Ob ich die Änderungen an den richtigen Stellen gemacht habe bezweifle ich etwas...
Nach dem Einschalten der Boxen per Webinterface des Mediaservers ändert sich leider der Zustand im FHEM erst nach statusRequest.
Ebenso scheint bei den letzten Änderungen im Player im amplifier der "trigger" wieder unter den Tisch gefallen zu sein wodurch sich die Verstärker wieder nicht einschalten (zumindest bei mir).
Daher ist der aktuelle Zustand nicht so wirklich gut da scheint mir der Zustand von github+ChrisD Änderungen etwas besser gewesen zu sein.

Viele Grüße,
Marco