Squeezebox module - development

[oliv06]

Thread dedicated the Squeezebox module development as suggested by bugster_de who developed this module

[bugster_de]

Thanks, that is excellent !

So in here, we should collect the alignments of the developers (not the usage of the module).
- how to modify the code for new features, bugfixes etc.

[oliv06]

2 changes in SVN for 98_SB_PLAYER.pm :
- revision control string $Id$ included
- changed file so it is now using Unix EOL convention. But with "svn propset svn:eol-style native 98_SB_PLAYER.pm"  it should be read correctly on Windows too (Until now I had ^M on each end of line on my Linux machine)

[bugster_de]

EOL: that is somewhat interesteing: I'm using emacs and have set it to use CR&NL and the end of the line. I had no issues on my Windows and my Linux machine. Anyhow good you changed that

[bugster_de]

Collection of new requirements (to be continued)
- integrate triggers / events for alarms: alarm on, off, snooze
-

[oliv06]

Last changes in SVN update 5302 :
- save/recall feature implemented (saves/recalls playlist, state and playStatus)
- talk behavior updated :
   - recall will wait for end of talks
   - talks calls can be stacked in the current playlist .
   - accents handled correctly (UTF-8)
- do not filter "client disconnect/reconnect" messages
- unknownir as well as ir go into the "lastrir" reading

[oliv06]

It seems to me that according to http://www.fhemwiki.de/wiki/DevelopmentGuidelinesAV the currentMedia reading should be the URL of the current track (and not the track number which we could name currentTrackID). What do you think ?

[bugster_de]

a list of open topics, that need fixing updating
- make the availability check (via Ping) optional as an attribut. Most users have the SB Server always on, so that is not needed and seems to create a lot of problems
- finalize the talk function
- review the Alarms implementation. Seems like some are not really happy with what is provided so far
  challenge: SB Server doesn't provide any interface to read the existing alarms of a player
- double-check the currently playing function
- get something implemented, that allows to display the cover-art inside FHEM

[bugster_de]

oliv06: can you give me an overview / intro to the talkStatus concept you implemented earlier? On my side, it simply doesn't seem to work. It plays the text fine but does never go back to the last played item

sadly, to me it seems we need to distinguish depending on what the player is playing (as depending on that, the return values are different)
if it is a remote stream (internet radio), we can resume directly
if it is a local playlist, we need to identify the playlist name, the song number and the playtime in that song before going to make the player talk.
If it is a pure file (mp3) I'm not sure, how that works (we might need to save a temporary playlist?)

[oliv06]

Yes it is bugged. I rewrote it some time ago, but I am not sure it is really better.  I can send it to you if you want to test it. I will  be away for a while now so I will not be able to work on it before september.

[bugster_de]

Ich habe bei mir das Setup, dass der LMS Server und die jeweiligen Software Player auf dem Windows HTPC im Wohnzimmer laufen. Der HTPC ist nicht dauerhaft an, sondern wird nur bei Bedarf ein- und ausgeschaltet. FHEM läuft euf einem RPi. Somit wollte ich eine zuverlässige Erkennung, ob der LMS läuft oder nicht. Der im 97_SB_SERVER Modul implementierte Mechanismus ist dabei wie folgt:

1. Stufe
FHEM baut zum LMS eine Telnet Verbdinung via der FHEM Standard-Mechanismen aus der DevIO.pm auf. Wenn erfolgreich, dann geht der STATE auf "opened". Wenn nicht erfolgreich, dann geht der STATE auf "disconnected". Soweit die Theorie.
Leider sind die Mechanismen für zweistufige Module nicht sonderlich gut dokuemntiert und durch viel Trial&Error habe ich heraus gefunden, dass bei "disconnected" in regelmässigen Abständen die ReadyFn aufgerufen wird. Ergo dann in dieser Funktion der Versuch die Verbindung neu aufzubauen.
Zweites Problem: es ist oftmals so, dass selbst bei komplett ausgeschaltetem HTPC, der STATE noch sehr lange (min. 30 Min) auf "opened" stehen bleibt. Somit kann man natürlich Verstärker etc. nicht ausschalten. Wenn man den HTPC in hibernate fährt bekommt FHEM gar nicht mit, dass der HTPC aus ist und es bleibt immer auf "opened".
Sprich die Standardmechsnismen via ReadyFn sind nicht zuverlässig.

2. Stufe: Ping und RCC
um nun also festzustellen, ob der PC überhaupt an ist, pinge ich in an. Wenn da keine Antwort kommt, dann ist er wohl aus.
Desweiteren gibt es im Contrib Bereich das Modul RCC, welches sehr viele Remote Controls auf einem Windows PC via FHEM erlaubt. So meldet dieses Modul z.B. auch den aktuellen Zustand des PC (on, off, hibernate, etc.)
Mit diesem Modul und dem Ping kann man feststellen, ob der PC läuft

3. Stufe: Telnet
auch Stufe 2 ist nicht ausreichend, da sie nicht aussagt, ob der LMS läuft und ob die CLI Verbidnung fehlerfrei ist. Ich hatte z.B. folgende Effekte:
- der PC war hochgefahren aber der LMS kam wegen einem Fehler nicht hoch. Hätte eigentlich DevIO abfangen sollen, aber siehe Probleme oben
- der LMS war zwar hochgefahren aber nach eine bestimmten Laufzeit war die CLI Schnittstelle tot und hat nichts mehr gemacht
Um nun also abzufragen, ob die CLI Schnittstelle lebt und was sinnvolles tut, mache ich mir eine Eigenschaft der CLI Schnittstelle zu nutze: immer wenn man ein unbekanntes Kommando an die CLI Schnittstelle schickt, dann sendet sie das genau so zurück (echo). Sprich ich sende einfach "fhemalive" und wenn das zurück kommt, dann ist die CLI Schnittstelle wohl noch am Leben
Da die Kommunikation mit dem LMS ja asynchron ist, wird in bestimmten Abständen der fhealive gesendet und der Status auf "waiting" geändert. Wenn eine Antwort kommt, dann wird die Variable auf "received" gesetzt. Nun kommt alle paar Sekunden (einstellbar) der check, ob sich der Inhalt der Variable geändert hat. Wenn der noch auf "waiting" ist, dann haben wir wohl kein Resultat erhalten.

Um die Probleme aus 1. zu umschiffen, baue ich die Telnet Verbdindung mittels DevIo_CloseDev ab. Erschien mir das sauberste.

jetzt haben wir mal sauber erkannt, ob der LMS noch am Leben ist. Und nun kommt der Teil, wie die Verbidnung von OFF wieder auf ON geht
- wir können uns ja nicht auf den Zustand des STATE verlassen (siehe oben) also schauen wir nach Ping und RCC Status. Wenn einer der beiden auf on ist (oder verknüpft), dann ist der PC wohl wieder da. Wenn die Variable power auf "off" steht, dann ist es wohl das erste mal, dass erkannt wurde, dass der PC wieder oben ist. Also öffnet man die Telnet Verbdindung mittels DevIO_OpenDev wieder. Und hier wird ja dann die DoInit aufgerufen, die den alivecheck Mechanismus anstartet.
Somit also: die AliveCheck Funktion muß min. zweimal durchlaufen werden, um den Zustand sauber zu setzen.
Damit das schnell geht habe ich die $nexttime Variable drin, um vom ersten auf den zweiten Durchgang nicht die eingestellt Zeit warten zu müssen sondern schneller zu sein. Desweiteren ist die Reihenfolge der if-then-else Bedingungen entscheidend.


Wie gesagt: vieles davon basiert auf Trial&Error und für Hinweise und Verbesserungen bin ich natürlich dankbar.


Und wie man sieht ist der Mechanismus nicht trivial, weshalb sich meine Begesiterung den Ping auch noch in einen nebenläufigen Thread auszulagern doch in engen Grenzen hält. Das wird dann nicht einfacher und stabiler, wenn man mit zig parallelen Threads rumhantiert.

[bugster_de]

ihr scheint Recht zu haben: es gibt Situiationen, in denen sich der STATE nicht ändert. Ich hatte am Wochenende den LMS-Server PC laufen und habe von FHEM aus die Musik gesteuert. Dann habe ich am LMS-Server PC neuen treiber eingespielt und hatte dabei einen Bluescreen. Danach hat FHEM den LMS-Server erst wieder erkannt, nach dem ich am SB_SERVER ein modify ausgeführt habe. Da muß ich wohl mal schauen.