12299 Squeeze Baustein

[eckerho1]

Hier noch schnell die Version in der man die Musiksammlung ein- und ausschalten kann.

parseMusiksammlung:True oder False, gleich wie mit unparsed.

Doku folgt dann morgen.

Gruss, Holger

[NilsS]

sieht schon gut aus, aber warum legst du die __config auf feste Variablen im __init__ wenn du das machst, und nicht direkt if self.__config['paresMusiksamlung'] machst, dann kannst du den config zur Laufzeit nicht mehr ändern.

[eckerho1]

Hallo Nils

warum legst du die __config auf feste Variablen im __init__ wenn du das machst, und nicht direkt if self.__config['paresMusiksamlung'] machst.

Weil ich das schon immer so mache
Das ist ein uraltes Stück Code der wohn noch aus dem Fritzbox-CallMon stammt.

Mach ich in hier im Code für alle Variablen die übergeben werden so.
Könnte ich aber mal anpassen.


Wenn wir schon beim Thema Optimierung sind.
Bin mir nie sicher was den HS weniger belastet.

A) jede Variable in jedem Baustein selbst ermitteln. Für die Zeit z.B. überall time.localtime() einbauen.

oder

B) Einmal eine Baustein in die Logik der die Zeit leifert, die Zeit dann auf ein iKO z.B. Uhrzeit und dieses iKO dann an die Eingänge der weiteren Bausteine hängen.

Momentan mache ich meistens B).

Was ist deine Meinung dazu?

Gruss, Holger

[MatthiasS]

Ich erinnere mich dunkel, dass es in einem Fall A mit reichlich Zeitberechnungen zu Performance-Problemen kam. Ich bin auch für B.

[NilsS]

Also time.localtime() egal wie oft innerhalb eines ByteCode Bausteins ist sicherlich schneller als wenn eine Logik von extern getriggert wird und somit quasi das eval aller Bedingungsformeln, dann das eval der Formelzeile und das eval der darin enthaltenen ByteCode Formel.

Ein Timer hingegen sollte wiederverwendet werden, da sonst mehrere Timer parallel laufen und natürlich dann nacheinander abgearbeitet werden.

Viele Bausteine die einen Refresh Eingang haben, können wenn sie entsprechen programmiert sind auch sonst mit einer 0 getriggert werden, dass löst dann zwar die Bedingung die oft EC[1] or OC[1] heißt aus, die 0 in der Timerformel erstellt jedoch keinen neuen Timer.

Sinnvoll ist bei Mehrfachverwendung von Funktionen jedoch schon das time.localtime dann erst auf ltime legen und dann z.B. year=ltime[0]
man kann das aber auch gleich in einem machen.

year,month,day = time.localtime()[0:3]

[eckerho1]

Hallo Nils

dann bleiben wir doch mal bei diesem Beispiel.

Es ist also sinnvoll die Stunde aus dem Uhrenbaustein 9039 zu beziehen.
Aber der Bustein wäre schneller wenn er sich nur einmal die Zeit holt, die in einen Speicher schreibt und nur noch den Speicher auswertet.

Schnell:

5012|9039|0|""|"__import__('time').localtime()"|""|0|0|7|0 # Tag
5012|9039|0|""|"SN[7][2]"|""|1|0|1|0 # Tag
5012|9039|0|""|"SN[7][1]"|""|2|0|2|0 # Monat
5012|9039|0|""|"SN[7][0]"|""|3|0|3|0 # Jahr
5012|9039|0|""|"SN[7][3]"|""|4|0|4|0 # Stunde
5012|9039|0|""|"SN[7][4]"|""|5|0|5|0 # Minute
5012|9039|0|""|"SN[7][5]"|""|6|0|6|0 # Sekunde
5012|9039|0|""|"SN[7][6]"|""|7|0|0|0 # Wotag (0-6)
5012|9039|0|""|"SN[7][7]"|""|8|0|0|0 # Jatag (0-355)

Langsam:

5012|9039|0|""|"__import__('time').localtime()[2]"|""|1|0|1|0 # Tag
5012|9039|0|""|"__import__('time').localtime()[1]"|""|2|0|2|0 # Monat
5012|9039|0|""|"__import__('time').localtime()[0]"|""|3|0|3|0 # Jahr
5012|9039|0|""|"__import__('time').localtime()[3]"|""|4|0|4|0 # Stunde
5012|9039|0|""|"__import__('time').localtime()[4]"|""|5|0|5|0 # Minute
5012|9039|0|""|"__import__('time').localtime()[5]"|""|6|0|6|0 # Sekunde
5012|9039|0|""|"__import__('time').localtime()[6]"|""|7|0|0|0 # Wotag (0-6)
5012|9039|0|""|"__import__('time').localtime()[7]"|""|8|0|0|0 # Jatag (0-355)

Hab ich das richtig verstanden?

Gruss, Holger

[NilsS]

in diesem Falle wäre das sicher Irrelevant, da beide Versionen durch ihre 3 eval je Zeile zu 27 evals je Aufruf sehr unperformant wären.

In diesen Fällen wäre es sicher uninteressant.

Man kann sich auch bei anderen Dingen da Gedanken machen .... aber ob es bei den Datenmengen was ausmacht ?

PythonSpeed/PerformanceTips - PythonInfo Wiki

[eckerho1]

Man kann sich auch bei anderen Dingen da Gedanken machen .... aber ob es bei den Datenmengen was ausmacht ?

PythonSpeed/PerformanceTips - PythonInfo Wiki

Aber sind ein paar interessante Beispiele drin die ich mir beherzigen werde.

Danke für den Link.

Gruss, Holger

[NilsS]

Ja ich sollte davon auch mal manche beherzigen

[Albert]

Hallo Holger und Nils,

da schaut mal ein paar Tage nicht rein, dann ist umgesetzt, was man sich vorstellt - Musiksammlung EIN/AUS...

Danke für Euere Arbeit.

@TBI
@Holger

Es ist wirklich an der Zeit an einem Konzept zu arbeiten.
Ich würde gerne meine Erfahrungen einbringen.
Als Anregung für ein Konzept könnte ich mir folgendes vorstellen.

1) Der überarbeitete Squeezebaustein soll abwärtskompatibel sein. Das kann man durch Parameter realisieren.
2) Grundsätzlich gibt es zwei Arten von CLI Befehlen / CLI Antworten - Befehle / Antworten mit PlayerID und welche ohne PlayerID. Befehle mit PlayerID könnten von einem "PlayerBaustein" bearbeitet werden - je PlayerID ein Playerbaustein. Befehle ohne PlayerID werden von einem "SqueezeServerBaustein" bearbeitet.
3) Die Kommunikation mit dem SqueezeServer erfolgt über den SqueezeBaustein welcher die PlayerID auswertet und den Befehlsstring in XML (PlayerID>xx:xx:...:xx< Befehlsstring>...<) verpackt. Die PlayerID 00:00:00:00:00:00 könnte dann als vitruelle PlayerID / Codierung für den Squeezeserver verwendet werden.
4) Die Auswertungen der Befehlsstrings erfolgt dann in den "PlayerBausteinen" bzw. im "SqueezeServerBaustein".
5) In den "PlayerBausteinen" bzw. im "SqueezeServerBaustein" werden auch die CLI-Befehle für Abfragen usw. generiert. Welche Funktionen hier umgesetzt werden, ist noch zu definieren.

Haltet Ihr diese Vorgehensweise für sinnvoll? Wenn Ja, würde ich meine Gedanken weiter verfeinern.

Gruß
Josef

[eckerho1]

Hallo Alfred

Ich hab mir das so vorgestellt.

Kommunikation mit SqueezeServer mit CLI Kommandos geht wie gewohnt über den 12299er Baustein.
Da da fest eine IP Verbindung aufgebaut und aufrecht erhalten wird macht es auch keinen Sinn mehrere Bausteine auf den Server los zu lassen.

Die Auswertung erfolgt dann entwerder innerhalb dieses Bausteins oder es werden die im <unparsed> Tag enthaltenen Infos von einem weiteren Baustein übernommen und von diesem ausgewertet.

Was ich von euch brauche sind die CLI Befehle, die erwartete Antwort von Server und die gewünschte Auswertung.
Wie wichtig es ist den genaue Ablauf zu definieren sehen wir ja da dran, dass die für Marko eingebaute Abfrage bei dir schon für Probleme gesorgt hat.

Haltet Ihr diese Vorgehensweise für sinnvoll? Wenn Ja, würde ich meine Gedanken weiter verfeinern.

Ja, bitte mach das.

Gruss, Holger

[ThorstenGehrig]

Hi Holger,
nur mal allgemein gefragt:
besteht eine realistische chance das eine "durchsage"-Funktion mittelfristig in den Baustein wandert?

Von der Funktion her ist das ja "einfach":
Alter zustand Speichern (Power 0/1, Playlist)
Abspielen definierte MP3-Datei mit definierter Lautstärke
Wiederherstellen des gespeicherten Zustands

Bevor ich jetzt anfange mir was eigenes um den Baustein drum rum zu basteln...

Danke & Gruß
Thorsten

[eckerho1]

Hallo Thorsten

Also von alleine nicht....

Aber wenn du mir genau beschreibst was du sendest und was dann passieren soll, dann stehen die Chancen nicht schlecht.

Gruss, Holger

[Albert]

Hallo Holger,

wie versprochen, habe ich über das Konzept weiter nachgedacht.

Pro Player wird ein "SqueezePlayerControl-Baustein" (Neu)verwendet.
Response wird mit Daten aus einem modifizierten 12299_Squeezebausten belegt.
Der 12299_Squeezebaustein übernimmt die Kommunikation mit dem SqueezeBoxServer. Wertet aber nicht aus (durchreichen der Rohdaten "fullunparsed"), die Auswertung machen die "SqueezePlayerControl-Bausteine" (Neu) bzw. der "SqueezboxServer-Baustein" (Neu).
Response ungleich der parametrisierten PlayerID xx:xx:xxxx:xx:xx führt zu einem Abbruch der Auswertung im Baustein (Daten nicht für den Baustein bestimmt).
Response mit richtiger PlayerID wird ausgewertet. Auswertungen ähnlich wie im 12299_SqueezeBaustein + neue Funktionen.
Response mit richtiger PlayerID und nicht ausgewerteten Daten wird als unparsed ausgegeben - für weitere Funktionen....
Alles was nicht Playerspezifisch ist, wird in einem sogenannten SqueezboxServer-Baustein behandelt (in Planung).
Befehel für die einzelnen Funktionen müssen noch festgelegt werden.

Ansteuerung der Player
PlayerID xx:xx:xx:xx:xx:xx
Response vom Squeezbaustein
Power on/off
sleep 0..xxxx
Play Play/Pause
Stop Stop
seek track time 0:30
skip Next Track / Previous Track
Shuffle on/off
Repeat off/single/all
Volume aboslut 0..100 relativ -100..+100
Volume relativ -10/+10
SynchronisationPlayer xx:xx:xx:xx:xx:xx
Load Genre Genre ID
Load Artist ArtistID
Load Album AlbumID
Load Track TrackID
Clear Playlist Playliste löschen
Load Playlist Playliste laden
Save Playlist Playliste speichern
Playlist Name speichern
Durchsage-URL akt. Durchsage
Durchsage Volume aboslut 0..100 relativ -100..+100

Rückmeldung der Player
Power on/off
PlayerName String
sleep 0..xxxx
Status Play, Pause, Stop
Shuffle on/off
Repeat off/single/all
Volume absolut 0...100
SynchronPlayer xx:xx:xx:xx:xx:xx (Liste)
Titel
Interpret
Album
Playlist Name
Track in Playlist Nummer in Playlist
Playlist Tracks Anzahl in Playlist
Restspielzeit akt. Track
Gesamtspielzeit akt. Track
Playlist Titel, Interpret, Album (Liste)
Cover-URL akt. Track
unparsed für nichtausgewertete Daten

Mit Sicherheit noch ausbaufähig. Für Input wäre ich dankbar.

Gruß

Josef

[eckerho1]

Hallo Josef

Sehe ich das richtig. Du möchtest einen Baustein mit x Ausgängen, jeder mit einer eigenen Bedeutung, z.B. Power, Volume...
Und dann für jeden Player einen solchen Baustein einsetzen?

Das kannst du ja jetzt schon haben wenn du das xml so auseinandernimmst wir du es möchtest.

Und das gleiche dann auch zum senden?

Mir geht es ausschliesslich um eine Erweiterung für die Musiksamlung die dann jeder wieder für sich so anpassen kann wie er möchte.

Gruss, Holger