[mmh] iTunes

[no sleep]

Hier nun das versprochene Beispiel:

Du möchtest den Repeat und Shuffle-Status an eine beliebige IP gesendet bekommen:

a) Commandserver: Einen Commandserver (im Unterordner "addons") z.B. mit Namen itunes_info.csv anlegen der definiert, wohin die Information gesendet wird:

[CONFIG];
SERVERIP;192.168.1.200
SERVERPORT;6000
SERVERMODE;ASCII
SERVERTIMEOUT;0
SERVERPROTOCOL;UDP

[COMMANDS];
REPEAT;<ITUNES>GETREPEAT=\#|OK</ITUNES>
SHUFFLE;<ITUNES>GETSHUFFLE=\#|OK</ITUNES>

Mit dieser .csv erweitert man den Befehlssatz um eine neue Klasse und 2 Befehle:
Klasse: <ITUNES_INFO> (weil die .csv itunes_info.csv genannt wurde)
Befehle: <REPEAT=...> und <SHUFFLE=....>
Ruft man in mmh den Befehl
<ITUNES_INFO><REPEAT=ALL></ITUNES_INFO>
auf, wird die Sequenz
<ITUNES>GETREPEAT=ALL|OK</ITUNES>
an die IP 192.168.1.200 Port 6000 per UDP gesendet.
SERVERIP und SERVERPORT müssen natürlich entsprechend angepasst werden.
Die Syntax habe ich so gewählt, damit die mmh-Syntax nicht gebrochen wird und die Parser-Regel auf dem Zielrechner nicht verändert werden muß.

b) Eventserver: Die Information automatisch aus dem mmh-Ausgangskanal auswerten und die passenden Commandserver-Befehle selbständig aufrufen:
Im events-Unterordner eine .csv mit beliebigem Namen anlegen, z.B. itunes_events.csv:

[CONFIG];
TRIGGERIP;INTERNAL
TRIGGERPORT;OUT
TRIGGERMODE;ASCII

[TRIGGERS];
GETREPEAT=\*|;<ITUNES_INFO><REPEAT=\#></ITUNES_INFO>;ONCHANGE
GETSHUFFLE=\*|;<ITUNES_INFO><SHUFFLE=\#></ITUNES_INFO>;ONCHANGE

Den CONFIG-Teil habe ich im vorherigen Beispiel bereits beschrieben. Im TRIGGERS-Abschnitt wird auf die Antwort der iTunes-Befehle GETREPEAT und GETSHUFFLE geprüft und bei einem erfolgreichen Test die in der obigen Commandserver csv neu definierten Befehle mit dem ausgelesenen Argument aufgerufen. Der Wert "ONCHANGE" sorgt dafür, daß das Event nur ausgelöst wird, wenn sich das Argument verändert hat.
Zusammengefasst: Wenn im Ausgangskanal von mmh GETREPEAT oder GETSHUFFLE auftauchen, werden diese über den Commandserver versendet, sobald sich der Rückgabewert der Befehle ändert.

c) Die ITUNES-Befehle GETREPEAT und GETSHUFFLE-Befehle automatisch aufrufen lassen:
Im misc-Unterordner eine timer.csv anlegen:

[CONFIG];
ACTIVE;YES
DEBUG;NO

[TIMERS];
ITUNES_DATA;INTERVAL;1;<ITUNES><GETREPEAT><GETSHUFFLE></ITUNES>

Dies erzeugt einen Intervalltimer mit dem namen ITUNES_DATA, der im 1-Sekunden-Takt die beiden Befehle ausführt.

Da bei diesem Timer der Zusatz ";AUTOSTART" fehlt, startet man den Timer manuell, wenn man die Info über die iTunes-Stati benötigt:
<TIMER><START=ITUNES_DATA></TIMER>
Möchte man das Automatische Versenden der Stati abschalten, stoppt man den Timer:
<TIMER><STOP=ITUNES_DATA></TIMER>

[Günther]

Hallo Sascha, Mike.... das mit dem Timer würde ich auch bevorzugen.... muss mir erst den Eventserver bei Mike bestellen... aber für ein Beispiel wäre ich dir sehr Dankbar......

LG
Günther

Ich mache das auch über den Timer... diesen aber dynamisch. D.h. Der Timer ist aktiv, wenn iTunes "played" ...

LG

[no sleep]

Hallo Günther,

nein, das ist nicht angedacht, aus mehreren Gründen:
Der Shuffle- und Repeat-Status ist Playlisten-bezogen, d.h. um eine eindeutige Aussage zu treffen, müsste man auch noch den Namen der Playliste auswerfen.
Hier stellt sich dann die Frage, wo man die Grenze zieht:
Der Nächste möchte vielleicht auch noch sekündlich die Playtime des aktuellen Titels im Broadcast haben, usw.
Nicht zuletzt erzeugt alles, was wir über den Broadcast senden, Mac-intern eine geringe, aber auch permanente Prozesslast. Wenn man diese Methodik übertreibt, bremst man sich irgendwann (unnötigerweise) das System aus.

Zur Lösung Deiner Anwendung gibt es mehrere Lösungsmöglichkeiten:
a) Du benutzt einen Titelwechsel (der ja über den Broadcast gesendet wird) als Event zum Abfragen der Stati. Damit wäre die Anzeige zwar nicht immer synchron, aber dennnoch "zeitnah". Diese Lösung erzeugt die geringste Last.
b) Du nutzt einen Timer, der in einem einstellbaren Intervall die Stati abfragt und lässt Dir den Status mit einer Kombination aus Event- und Commandserver an eine beliebige IP senden. Falls Dich dieser Weg interessiert, kann ich diese Lösung gerne hier posten.

[Günther]

Shuffle- und Repeat-Status werden übrigens grundsätzlich nicht über den Broadcast gesendet.[/QUOTE]

Hallo Sasha.
Das ist schade... dann muss man dies wiedereinmal zyklisch auslesen...
Ist hier auch nichts angedacht für kommende Versionen dass das im BC gesendet wird?


LG
Günther

[no sleep]

Hallo Günther,

Du hast Recht - die GET-/SETREPEAT Befehle funktionieren mit dem aktuellen iTunes nicht, hier hat Apple etwas geändert. Die Änderung ist jedoch bereits in mmh eingepflegt und mit der nächsten Version verfügbar.

Shuffle- und Repeat-Status werden übrigens grundsätzlich nicht über den Broadcast gesendet.

[Günther]

Jups... ich habs nochmals getesten....

LG
Günther

Im Leben nicht !!!

Ist Bestandteil unseres mremote Profils bzw. dem nachgebautem Remote...

Aber ich checke dies noch mal.

Danke für's Feedback.

[Günther]

möglicher BUG????????

Hallo zusammen. Ist jemanden aufgefallen dass wenn man <ITUNES><SETREPEAT=ALL></ITUNES> zum mmh schickt dass effektiv in den ITunes nicht passiert. D.h. dass der Wiederholmodus nicht gesetzt wird. Man erhält zwar die Antwort <ITUNES>SETREPEAT=|OK</ITUNES>
Aber diese Antwort erhält man auch wenn man einen beliebigen String schickt.....
Liest man den Zustand dann mit <ITUNES><GETREPEAT></ITUNES> erhält man als Antwort den letzten Zustand des Wiedergabemodus.
<ITUNES>GETREPEAT=OFF|OK</ITUNES>

Auch ist mir aufgefallen dass bei Änderung des Wiedergabemodus und der zufälligen Wiedergabe SHUFFLE am mmh in den ITunes keine Änderung im BC gemeldet werden....

[Dundi]

Schade Günther....das habe ich nicht in meiner Installation.

[Günther]

Hallo Dundi... Wenn du mit Elvis (der Firma IT-GmbH) arbeitest könnte man darüber reden.....

Grüße Günther

[Dundi]

Ja super Günther...

dann gibt es ja dann ein Musterprojekt von dir.

[Günther]

Ok dann lassen wir uns überraschen.. ich glaube ich habe schon eine Idee wie ich das in die Visu einbaue... mal schauen

[no sleep]

Vermeiden lässt sich das nur, wenn man direkt über die ID geht.
Der Befehl GETIDTITLE liefert zu einer gegeben ID den Titel, GETIDARTIST den Interpreten und GETIDALBUM das Album. Mit diesen Befehlen kann man sich dann seine Visu füllen, sofern man die ID hat.
Wenn man die ID nicht hat, wird es u.U. mehrdeutig, was bei einer gezielten Titelauswahl nicht mehr akzeptabel ist.
Sinnvoll wäre daher ein Befehl wie z.B. GETALLPLAYLISTIDS oder so ähnlich, der dann eine Liste aller in der Playlist vorhandenen ID's auswirft. Ich denke, sowas in der Art werden wir einbauen.

[Günther]

Hallo Sasha.
Den Befehl den ich meine um alle Titel einer Playlist in der Visu anzuzeigen wäre der wie GETALLPLAYLISTS halt nur zB. GETALLTITLEFROMPLAYLISTS.
Somit könnte man alle Titel der gewälten Playlist in der Visu anzeigen.
Um einen bestimmten Titel zu starten bräuchte man dann logisch die ID. Das wäre dann ein zweiter Schritt...
Und das wäre ja nicht das Problem. Beim markieren des Titels lässt man sich über GETIDTITLE die ID des Titels geben und bei Betätigung eines Button schickt man dann die erhaltene ID zum mmh. Das Problem mit gleichen Titel würde hier auch bestehen aber ich glaube das lässt sich so nicht vermeiden.......

Grüße
Günther