12299 Squeeze Baustein

[Albert]

Hallo Holger,

das Abfragen der Musiksammlung ging doch schon immer recht gut... mit unparsed. Ich mach das in meinem Projekt. Ist mir im Prinzip egal, ob ich unparsed oder xml zerpflücke - die Auswertung ist anders.

Ich verstehe scheinbar dein Bestreben noch nicht...
Brauche wohl mehr Input...
Wo siehst Du die Vorteile wenn Musiksammlung geparsed wird? Ich werte unparsed mit einem Logikbaustein aus.

Gruß

Josef

[Albert]

Hallo Holger,

ich habe heute die aktuelle Version 1.06 getestet.
Das "abschlaten" der Musiksammlung und somit das senden von Albums, Genres, Titles usw. auf unparsed funktioniert leider nicht.

Laut Doku muss die Auswertung der Musiksammlung aktiviert werden.
Bei mir ist diese nicht aktiviert.

Ich verwende auf E2
"lang=de*port=9090*unparsed=True*sendcoverurl=Fals e*delimiter=;"

Mache ich etwas falsch? Oder ist da noch ein Fehler drin?

Gruß, Josef

[NilsS]

funzt das mit dem True/False ? besser wäre 1/0 denn es wird lediglich type int überprüft.

        ##
        ## Configuration von String lesen
        ##
        def setConfig(self,newconfig):
            if not newconfig:
                return
            for option in newconfig.split('*'):
                try:
                    key , val = option.split("=",1)
                    ## Wert in Integer wandeln
                    val = type(self.__config[key])(val)
                    ## Wenn gültig dann setzen sonst KeyError 
                    self.__config[key] = val
                except KeyError:
                    pass
                    ###DEBUG###print "Konfig fehlgeschlagen: "+option
                except ValueError:
                    pass
                    ###DEBUG###print "Konfig wrong Value: "+option
            ###DEBUG###print "Konfig: "+repr(self.__config)

hier ist die setConfig aus der aktuelle FritzCallMon wo der Type anderst umgesetzt wird. Ich würde aber trotzdem zu

lang=de*port=9090*unparsed=1*sendcoverurl=0*delimiter=;

raten, da True/False CaseSensitiv sind.

[eckerho1]

Hallo Holger,

ich habe heute die aktuelle Version 1.06 getestet.
Das "abschlaten" der Musiksammlung und somit das senden von Albums, Genres, Titles usw. auf unparsed funktioniert leider nicht.

Laut Doku muss die Auswertung der Musiksammlung aktiviert werden.
Bei mir ist diese nicht aktiviert.

Ich verwende auf E2
"lang=de*port=9090*unparsed=True*sendcoverurl=Fals e*delimiter=;"

Mache ich etwas falsch? Oder ist da noch ein Fehler drin?

Gruß, Josef

Hallo Josef

unparsed=True*parseMusiksammlung=False

Gruss, Holger

[eckerho1]

Ich würde aber trotzdem zu

lang=de*port=9090*unparsed=1*sendcoverurl=0*delimiter=;

raten, da True/False CaseSensitiv sind.

Hallo Nils

Einverstanden, aber schwierig jetzt noch zu änderm da alle Anwender dieses Bausteins jetzt schon True/False verwenden.

Gruss, Holger

[eckerho1]

Ich verstehe scheinbar dein Bestreben noch nicht...
Brauche wohl mehr Input...
Wo siehst Du die Vorteile wenn Musiksammlung geparsed wird? Ich werte unparsed mit einem Logikbaustein aus.

Gruß

Josef

Hallo Josef

Mir ging es darum die verschiedenen Anfragen bez Musiksammlung zu einer für alle passenden zusammenzufassen.

Scheinbar ist das aber nicht wirklich ein Bedürfnis. Dan können wir es auch so lassen wie es jetzt ist.

Gruss, Holger

[marko]

Hallo eckerho1,
ich finde es toll, dass du das Abfragen der Musiksamsung eingebaut hast.
Ich kann zur Zeit leider nicht so häufig an meiner SB Lösung weiterarbeiten.
(Leider scheitere ich schon an Problemen wie das Pipe Symbol in Kommunikationsobjekte oder Eingänge von Logikbausteinen zu bekommen)

Für die Erweiterung des Bausteins finde ich eine Kompatibilität mit der HSSlim-Lösung gut (wie sie von Albert vorgeschlagen).

@Albert vielleicht kannst du die Logik die du verwendest ja online stellen, dann könnten alle in einer Richtung arbeiten.

Gruß Marko

[Albert]

@Albert vielleicht kannst du die Logik die du verwendest ja online stellen, dann könnten alle in einer Richtung arbeiten.

Gruß Marko

Hallo marko,

meine Lösung ist auch noch in der Entstehungsphase. Die kann man noch lange (mangels Zeit) nicht auf die "Menschheit" loslassen. Manches wird bereits von Bausteinen erledigt, anderes mit Logik (müsste aber noch in die Bausteine)...

Ich versuche HS-Slim-Konzept im Kern nachzubauen, aber nicht zu kopieren, da mir manches nicht ins Konzept passt (z.B. nur 5 Zeilen bei Abfrage der Musiksammlung und die Playeransteuerung hat mir zuwenig Funktionen)...

Gruß, Josef

[marko]

Hallo Albert,
ich bin deiner Meinung, deswegen hatte ich eine Steuerung über webabfragen angefangen die leider viel zu komplex wurde.
Ich finde deswegen den Baustein von eckerho1 so gut. Ein Extraprogramm wie HSSLIM kommt bei mir nur zu Testzwecken zum Einsatz.
Gruß Marko

[tbi]

Automaten

Hallo Josef, Nils und Holger, ...

@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.

Ich habe das schon damals gelesen, aber ich lasse so ein Konzept immer ein bißchen in mir arbeiten

und da ist mir klar geworden, was wir hier eigentlich machen:

1. Der HS ist hier ein Marionettenspieler, der X+1 Marionetten ( X Player + 1 Server) spielt.

Damit der Marionettespieler immer die richtigen Bewegungen macht, muß er sich die Zustände der einzelnen Marionetten merken.

Warum redet der Kerl nun von Puppen ?

Weil das in der SW-Technik ein bekanntes Problem der Automatentheorie ist. Hier verwendet man ein Zustandsmodel.

Also man kann hier sich hier mächtig mit Formeln ausstoben, aber das lassen wir mal für die Mathematiker.

Wichtig ist eigentlich, dass wir es hier mit einer anderen Art von Programmablauf zu tun haben. Es ist kein sequenzielles Programm, wie z.B. ein "Hello World" Program. Oder ein reines Ereignis orientierten Program, wie z.B. ein Windows Programm, was immer auf Maus clicks wartet.

Nein, hier ist es ein Automat wie z.B. ein Kaugummiautomat.

Und der hat Zustände in denen er sich befindet und Transitionen also definiert Zustandsübergänge durch Ereignisse ausgelöst (da ist unserer Code).

Also nochmal zum Kaugummiautomaten. In der Regel steht er an der Ecke und wartet, das ein Kind vorbeikommt.

Zustand: Wartet auf Geld .

Das Ereignis ist dann, wenn die Schule zu Ende ist und ein Kind dann einen EURO reinsteckt. Darauf muß der Automat reagieren (die Transition beginnt):
Also: => Freigabe des Drehgriffs

neuer Zustand: Drehgriff bereit zum Drehen.
....
Hier wartet der Automat wieder.
....
Ereignis: Kind dreht den Griff

Transition: Transport des Kaugummies aus dem Automaten;
Kind nimmt den Kaugummi

neuer Zustand: Geht wieder in den Wartezustand. Warte auf Geld

Und warum erzähle ich das nun ??

Weil wir genau in solch eine Problemstellung kommen, wenn wir zu Beispiel eine Ansage "Waschmaschine Fertig" auf Player 5 durchsagen lassen wollen:

Ereignis: Ansage Spielen auf Player 5

Transition: CLI: Player 5 "Zustand holen" zusammenbauen
CLI: über Squeeze_Baustein raus schicken

neuer Zustand: Player 5: "Auf Zustand Antwort warten".
....
....
Ereignis: Antwort für Player 5 wurde empfangen.

Transition: Prüfen in welchem Zustand ist Player 5;
=> Sichern des empfangenen Status;
Zusammenbauen CLI: Ansage "WAMA Fertig"
CLI: über Squeeze_Baustein raus schicken

neuer Zustand: Player 5: Ansage wird gespielt.
...
Ereignis: Ansage Player 5 fertig

Transition: CLI "Alten Zustand herstellen" zusammenbauen.
CLI: über Squeeze_Baustein raus schicken

Neu Zustand: Der Player 5 macht wieder das, was er vor der
Ansage gemacht hat.
....

So das war jetzt mal nur für einen Player gedacht. Ja, Josef, für der Server gibt es bestimmt auch Zustände. Odrrr ?

Also was ist sagen will: In die Bausteine, die Josef vorgeschlagen hat: "Playerbaustein" und "Serverbaustein" sollten von Anfang an die Zustände dabei sein. Welche ? Die man braucht eben. Können ja später noch welche dazu kommen. Aber wir sollten das Konzept von Anfang an so aufsetzten.
Oder ?

Gruß Tbi

[tbi]

Also noch mal etwas verfeinert:

Am Anfang des "Playerbaustein" und des "Serverbausteins" muß dann der Zustand (eine Integer Variable ?) geprüft werden und daran in der weiteren Logik verzweigt werden.

Am Ende der Transition (also bevor der Playerbaustein verlassen wird) muß der neu Zustand (Integerwert) dann wieder in der Zustandsvariable gespeichert werden.

Das ist eigentlich alles was dazu muß. Zu dem was Alert(Josef) schon oben beschrieben hat.

Damit hat man dann die Möglichkeit mit den Playern oder dem Server Dinge zu machen, die eben mehrere CLI Befehle benötigen.

Sonst gibt das bestimmt ein wilden Spagetti code

Gruß Tbi

[ThorstenGehrig]

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

Hi
zum Thema durchsagen hab ich mal ein bisschen "rumgespielt".
Was funktioniert:
<player_id> playlist save tmp_playlist
<player_id> playlist play <durchsage>.mp3
<player_id> playlist play tmp_playlist

Wobei: es muss ein Playlist-Verzeichniss angegeben sein (da wird die Playlist tmp_playlist abgespeichert) und <durchsage>.mp3 muss auffindbar im Pfad sein (bei mir im "Musik-Root")
Problem 1: die Playlist wird immer wieder vom 1. Lied an abgespielt - bei mir kein Problem wenn dort nur ein Radiostream läuft (bei mir meistens der Fall)(
Problem 2: der letzte Befehl darf erst gestartet werden wenn das <durchsage>.mp3 abgespielt ist.

Problem 2 könnte man umgehen indem man die tmp_playlist ergänzt und die durchsage-mp3 an erste stelle setzt...
In summe leider noch nicht rund. Hat jemand zu dem Thema Durchsagen ideen?

Gruß
Thorsten

[marlan99]

Hat jemand zu dem Thema Durchsagen ideen?

Gruß
Thorsten

Ich bin auch noch am rumspielen in dieser Sache. Wenn ein Baustein dies übernehmen könnte wäre das klar besser.

Nebst der Abspieldauer der Durchsage und anschliessendem einlesen der gespeicherten playlist, muss man auch die Situation berücksichtigen, wenn die SB nicht läuft (kein Sender und kein Musikstück abgespielt wird).

Da habe ich bei mir noch teilweise komische effekte die ich mir noch nicht erklären kann.

Gruss
Marcel

FB_Addon_TelNo{ height:15px !important; white-space: nowrap !important; background-color: #0ff0ff;}

[eckerho1]

Hallo Thorsten und Marcel

Ja, genau so hab ich mir das vorgestellt

Ihr sagt mir welche Befehle geschickt werden sollen und ich baue diese in den Baustein ein.

Warte jetzt aber noch bis ihr für die Probleme auch noch ne Lösung habt.
Einverstanden?

Gruss, Holger

[ThorstenGehrig]

Hallo,
ich schreib nochmal meine bisherigen erfahrungen zu den Durchsagen zusammen.
Was geht:
Eine Durchsage NACH dem aktuell laufenden Track(= "niemals" bei Radio-Sendungen)

Bad_unten playlist insert file:///storage/Musik/durchsage.mp3

Besser: playlist abspeichern - durchsage abspielen - playlist weiterspielen

Bad_unten playlist save tmp_playlist
Bad_unten playlist play file:///storage/Musik/durchsage.mp3
Bad_unten playlist resume tmp_playlist

Problem dabei: die Länge der Durchsage müsste bekannt sein...

Außerdem unschön: der aktuelle Track wird neu abgespielt.
Das ist hiermit zu verhindern:

Bad_unten time ? 
Antwort: <unparsed>00:04:20:28:22:fa time 13.347</unparsed>

Die Antwort kann man nun direkt nach "playlist resume" schicken (ohne <unparsed> und </unparsed>) und schon wird zur passenden stelle gesprungen.

Zusammengefasst:

<player> time ? 
=> Antwort speichern: <unparsed>00:04:20:28:22:fa time 13.347</unparsed>
<player> playlist save tmp_playlist
<player> playlist play file:///storage/Musik/durchsage.mp3
==Wartezeit entsprechend Durchsagedauer==
<player> playlist resume tmp_playlist
=> gespeicherte Antwort senden

Hat jemand eine Idee wie man die länge der <durchsage> auslesen kann?

Gruß
Thorsten

Nachtrag: mit "playlist preview" lässt sich noch eine Zeile sparen:

<player> time ? 
=> Antwort speichern: <unparsed>00:04:20:28:22:fa time 13.347</unparsed>
<player> playlist preview url:file:///storage/Musik/playlists/Durchsage.m3u
==Wartezeit entsprechend Durchsagedauer==
<player> playlist preview cmd:stop
=> gespeicherte Antwort senden

Leider spring er nicht zur ursprünglichen Playlist zurück wenn die Durchsage fertig ist - das Problem bleibt also weiterhin bestehen...