LBS(Sammlung) Squeeze

[wintermute]

irgendwas passt da nicht .... wusstest Du, dass 1 x 2.5 = 10 ist ... ;-) ... ?

Nein, das ist mir neu
Aaaaber: E8/E9 sind keine Schritte, sondern erhoehen/erniedrigen die Laustaerke um die Schrittweite wenn eine "1" anliegt... eine "2" geht vermutlich auch, fuehrt aber zum selben Ergebnis. Die Schrittweite muss (AFAIK) ein Integer sein, der LMS arbeitet intern mit einer Lautstaerke von 0-100, jeweils in ganzzahligen Schritten. Ich hab keine Ahnung was passiert wenn man da nen Float uebergibt (also zB 2.5), aber ich mir zumindest relativ sicher, dass nicht das gewuenschte Resultat bei rumkommt
Also: E19 ein ganzzahliger Wert zwischen 0 und 100 (wobei 0 und 100 vermutlich nicht ganz so viel Sinn ergeben ) und E8 und E9 sind keine Zaehler.

Was die Traegheit angeht: ich hab noch immer keine Visu und kann das daher noch immer nicht direkt testen
Sind deine Player gesynced? Generell pollt der Baustein nicht am LMS, der LMS meldet den Status-Wechsel an den Baustein. Also ist entweder der LMS langsam, oder irgendwas in Edomi. Was passiert denn, wenn Du fuer den Server-LBS das Debugging aktivierst? Siehst Du dann im tracelog die Status-Meldungen sofort oder kommen die da auch schon verzoegert an?

[MIT]

Hi Michael,

irgendwas passt da nicht .... wusstest Du, dass 1 x 2.5 = 10 ist ... ;-) ... ?
>> Ziel sollte sein: 10er Schritte beim verringern bzw. erhöhen der Lautstärke. Dazu habe ich E19 des SqueezeCommand 0.5 auf 2.5 und die Schritte an E8 bzw. E9 auf 1 gesetzt. Die 10er Schritte habe ich nun. Aber wieso? Vor dem Update auf 0.5 war ebenfalls eine kuriose Berechnung für das Ergebnis notwendig: 1 x 0.5 = 10
... nur zur Info: Es funzt ja... alllerdings komisch, oder?

Noch etwas: Generell ist mein Status in der Visu sehr träge; d.h. ich sehe bei manchen Elementen die Änderung erst nach 5-20 Sek.; gerade nach dem ersten aktivieren des Projekts. Wenn dann der Statuswechsel einmal erfolgt ist, funktioniert es relativ zeitnah (im von gaert öfter schon mal angesprochenen Rahmen von ca 3 Sek). Ich dachte, dass diese Problem nicht mehr auftauchen müsste, nach dem Wechsel in den EXEC -Bereich.

[wintermute]

Jaja... 200 puls

Es sind jetz uebrigens die drei wichtigen LBS in neuen Versionen vorhanden:
19000200 (Server) @0.6
19000201 (Client) @0.4
19000202 (Kommando) @0.5

Bedeutende Aenderungen waeren:
-Unterstuetzung der Sleep-Funktionalitaet
-Unterstuetzung von dynamischen bzw SQL-Playlisten
-Der Client-LBS zeigt jetzt bei verbubbelten Playern schonmal den jeweiligen Master der Sync-Gruppe an (bzw alle verbubbelten Slaves). Wie ich von da aus weiter mache, weiss ich allerdings noch nicht so genau

viel Spass :: Michael

[MIT]

ZITAT: "Hier ist n Knopp ... da steht ON/OFF ... soll ich da ma draufdrücken .... ;-) .... => Es läuft .... es läuft .... ich werd verrückt ... es läuft!!!" /QUELLE: gerade unbekannt ;-)
(Fehler war: eine fehlende Verbindung zum Server. Der Server hat also die KommandoKO vom Client von mir nicht bekommen. Tze .... )

[MIT]

Hier noch ein aktuellerer TraceLOG::

2016-04-01 16:48:21	613832	EXEC	25582	LBS19000200(13): Using named pipe '/tmp/EDOMI_LBS19000200.command.pipe'	Ok
2016-04-01 16:48:21	614239	EXEC	25582	LBS19000200(13): daemon started	Ok
2016-04-01 16:48:21	616095	EXEC	25582	LBS19000200(13): Sending 'listen 1'	Ok
2016-04-01 16:48:21	722666	EXEC	25582	LBS19000200(13): RECV: listen 1	Ok
2016-04-01 16:48:21	723077	EXEC	25582	LBS19000200(13): Sending 'players'	Ok
2016-04-01 16:48:21	828192	EXEC	25582	LBS19000200(13): RECV: players count:2	Ok
2016-04-01 16:48:21	829174	EXEC	25582	LBS19000200(13): Sending 'players 0 1'	Ok
2016-04-01 16:48:21	938360	EXEC	25582	LBS19000200(13): RECV: players 0 1 count:2 playerindex:0 playerid:00:1e:06:10:1d:e1 uuid: ip:192.168.0.110:41812 name:Wohnzimmer model:squeezelite isplayer:1 displaytype:none canpoweroff:1 connected:1	Ok
2016-04-01 16:48:21	938878	EXEC	25582	LBS19000200(13): Sending '00:1e:06:10:1d:e1 status - 1 subscribe:0 tags:aAcCdDefgiIjJKlLNoOqrstTuxy'	Ok
2016-04-01 16:48:22	063110	EXEC	25582	LBS19000200(13): RECV: 00:1e:06:10:1d:e1 status - 1 subscribe:0 tags:aAcCdDefgiIjJKlLNoOqrstTuxy player_name:Wohnzimmer player_connected:1 player_ip:192.168.0.110:41812 power:0 signalstrength:0 mode:stop remote:1 current_title:Rockland Radio (Frankfurt am Main) time:0 rate:1 sync_master:00:1e:06:10:1d:e1 sync_slaves:b8:27:eb:a1:be:f0 mixer volume:50 playlist repeat:2 playlist shuffle:0 playlist modeff seq_no:0 playlist_cur_index:0 playlist_timestamp:1459513824.11793 playlist_tracks:1 digital_volume_control:1 remoteMeta:HASH(0x43e2900) playlist index:0 id:-68555256 title:Rockland Radio (Frankfurt am Main) coverid:-68555256 duration:0 coverart:0 artwork_urllugins/TuneIn/html/images/icon.png type:Radio bitrate:0 url:http://opml.radiotime.com/Tune.ashx?...b3&filter=s:~R remote:1 year:0	Ok
2016-04-01 16:48:22	066123	EXEC	25582	LBS19000200(13): Sending 'players 1 2'	Ok
2016-04-01 16:48:22	174320	EXEC	25582	LBS19000200(13): RECV: players 1 2 count:2 playerindex:1 playerid:b8:27:eb:a1:be:f0 uuid: ip:192.168.0.114:45770 name:Esszimmer model:squeezelite isplayer:1 displaytype:none canpoweroff:1 connected:1	Ok
2016-04-01 16:48:22	174721	EXEC	25582	LBS19000200(13): Sending 'b8:27:eb:a1:be:f0 status - 1 subscribe:0 tags:aAcCdDefgiIjJKlLNoOqrstTuxy'	Ok
2016-04-01 16:48:22	297480	EXEC	25582	LBS19000200(13): RECV: b8:27:eb:a1:be:f0 status - 1 subscribe:0 tags:aAcCdDefgiIjJKlLNoOqrstTuxy player_name:Esszimmer player_connected:1 player_ip:192.168.0.114:45770 power:0 signalstrength:0 mode:stop remote:1 current_title:Rockland Radio (Frankfurt am Main) time:0 rate:1 sync_master:00:1e:06:10:1d:e1 sync_slaves:b8:27:eb:a1:be:f0 mixer volume:38 playlist repeat:2 playlist shuffle:0 playlist modeff seq_no:0 playlist_cur_index:0 playlist_timestamp:1459513824.11793 playlist_tracks:1 digital_volume_control:1 remoteMeta:HASH(0x41825f0) playlist index:0 id:-68555256 title:Rockland Radio (Frankfurt am Main) coverid:-68555256 duration:0 coverart:0 artwork_urllugins/TuneIn/html/images/icon.png type:Radio bitrate:0 url:http://opml.radiotime.com/Tune.ashx?...b3&filter=s:~R remote:1 year:0	Ok
2016-04-01 16:48:22	300324	EXEC	25582	LBS19000200(13): Sending 'version ?'	Ok
2016-04-01 16:48:22	405550	EXEC	25582	LBS19000200(13): RECV: version 7.9.0	Ok
2016-04-01 16:48:22	406464	EXEC	25582	LBS19000200(13): Verbunden mit LMS an 192.168.0.110:9090, Version 7.9.0, 2 Player verbunden

[MIT]

hi hi ... ;-) ... kein Problem.
Es ist so:
Der LMS ist ein Einplatinenrechner, der den Dienst unter der IP .110 als Server bereitstellt UND aber auch einen Dienst als Client anbietet. Somit habe ich ihn nicht nur als Server, sondern auch als Zone Wohnzimmer. Die IP .114 ist ein RaspPi, der einfach als weiterer Client für die Zone Esszimmer zuständig ist. Er sitzt im Arbeitszimmer im Netzwerkschrank. Dort sind auch die Verstärker für die jeweiligen Zonen, die einfach via Aktor zugeschaltet werden.
Ich MUSS aber auch noch in meine CFG was fehlerhaft haben, da nun ffg. Situation besteht:
- Die 00.00.00.... habe ich raus bekommen (einfach in der LMS-Software den Client zurück setzten)
- beide IPs - sprich Clients - sind nun laut TRACE am Server connected.
- Trotzdem lässt es den Server kalt, wenn ich ihm via edomi-Testvisu z. Bsp. den Befehl STOP oder PLAY gebe. Die Statusänderung erkenne ich in der Live-Preview im Logikeditor, aber ich höre nichts bei PLAY oder er spielt weiter bei STOP

Achso: Test via Internetradio-Stream

[wintermute]

Ist das nun "dramatisch" ?

Mehr oder minder... ja.
Einige der Squeeze Bausteine benutzen die 00:00:00:00:00:00 als Broadcast Adresse, also wenn man das als PlayerID angibt, dann werden die zugehoerigen Befehle an alle Player geschickt (gedacht fuer zB "alle aus" oder sowas). Also auch wenn die Reconnects jetzt weg sind, die Nuller-ID wird ueber kurz oder lang zu Problemen fuehren

Was ich aber auch nicht verstehe: gemaess deiner Logs hast Du zwei Player mit unterschiedlicher IP (.114 und .110, wobei die .110 auch dein LMS ist?), die aber den gleichen Namen (Wohnzimmer) aber unterschiedliche playerIDs haben. Ich bin i-wie total verwirrt grad

[MIT]

Vermutlich zu früh gefreut:

Denn die MAX 00...00 ist immer noch "irgendwie" da:

TraceLog nach einer Aktivierung:

2016-04-01 14:59:58	840037	EXEC	9430	LBS19000200(13): Using named pipe '/tmp/EDOMI_LBS19000200.command.pipe'	Ok
2016-04-01 14:59:58	840459	EXEC	9430	LBS19000200(13): daemon started	Ok
2016-04-01 14:59:58	842894	EXEC	9430	LBS19000200(13): Sending 'listen 1'	Ok
2016-04-01 14:59:58	950054	EXEC	9430	LBS19000200(13): RECV: listen 1	Ok
2016-04-01 14:59:58	950433	EXEC	9430	LBS19000200(13): Sending 'players'	Ok
2016-04-01 14:59:59	055497	EXEC	9430	LBS19000200(13): RECV: players count:2	Ok
2016-04-01 14:59:59	056973	EXEC	9430	LBS19000200(13): Sending 'players 0 1'	Ok
2016-04-01 14:59:59	165842	EXEC	9430	LBS19000200(13): RECV: players 0 1 count:2 playerindex:0 playerid:00:1e:06:10:1d:e1 uuid: ip:192.168.0.110:41812 name:Wohnzimmer model:squeezelite isplayer:1 displaytype:none canpoweroff:1 connected:1	Ok
2016-04-01 14:59:59	166330	EXEC	9430	LBS19000200(13): Sending '00:1e:06:10:1d:e1 status - 1 subscribe:0 tags:aAcCdDefgiIjJKlLNoOqrstTuxy'	Ok
2016-04-01 14:59:59	291929	EXEC	9430	LBS19000200(13): RECV: 00:1e:06:10:1d:e1 status - 1 subscribe:0 tags:aAcCdDefgiIjJKlLNoOqrstTuxy player_name:Wohnzimmer player_connected:1 player_ip:192.168.0.110:41812 power:0 signalstrength:0 mode:stop remote:1 current_title:Rockland Radio (Frankfurt am Main) time:0 rate:1 mixer volume:50 playlist repeat:2 playlist shuffle:0 playlist modeff seq_no:0 playlist_cur_index:0 playlist_timestamp:1459513824.11793 playlist_tracks:1 digital_volume_control:1 remoteMeta:HASH(0x4313c10) playlist index:0 id:-68555256 title:Rockland Radio (Frankfurt am Main) coverid:-68555256 duration:0 coverart:0 artwork_urllugins/TuneIn/html/images/icon.png type:Radio bitrate:0 url:http://opml.radiotime.com/Tune.ashx?...b3&filter=s:~R remote:1 year:0	Ok
2016-04-01 14:59:59	294897	EXEC	9430	LBS19000200(13): Sending 'players 1 2'	Ok
2016-04-01 14:59:59	402218	EXEC	9430	LBS19000200(13): RECV: players 1 2 count:2 playerindex:1 playerid:00:00:00:00:00:00 uuid: ip:192.168.0.114:45769 name:Wohnzimmer model:squeezelite isplayer:1 displaytype:none canpoweroff:1 connected:1	Ok
2016-04-01 14:59:59	402616	EXEC	9430	LBS19000200(13): Sending '00:00:00:00:00:00 status - 1 subscribe:0 tags:aAcCdDefgiIjJKlLNoOqrstTuxy'	Ok
2016-04-01 14:59:59	523036	EXEC	9430	LBS19000200(13): RECV: 00:00:00:00:00:00 status - 1 subscribe:0 tags:aAcCdDefgiIjJKlLNoOqrstTuxy player_name:Wohnzimmer player_connected:1 player_ip:192.168.0.114:45769 power:1 signalstrength:0 mode:stop remote:1 current_title:FFH Die 80er (Deutschland) time:0 rate:1 mixer volume:50 playlist repeat:0 playlist shuffle:0 playlist modeff seq_no:0 playlist_cur_index:0 playlist_timestamp:1459513824.16189 playlist_tracks:1 digital_volume_control:1 remoteMeta:HASH(0x43148e8) playlist index:0 id:-68582296 title:FFH Die 80er (Deutschland) coverid:-68582296 duration:0 coverart:0 artwork_urllugins/TuneIn/html/images/icon.png type:Radio bitrate:0 url:http://opml.radiotime.com/Tune.ashx?...99a0e9df15ad32 remote:1 year:0	Ok
2016-04-01 14:59:59	525861	EXEC	9430	LBS19000200(13): Sending 'version ?'	Ok
2016-04-01 14:59:59	631031	EXEC	9430	LBS19000200(13): RECV: version 7.9.0	Ok
2016-04-01 14:59:59	631961	EXEC	9430	LBS19000200(13): Verbunden mit LMS an 192.168.0.110:9090, Version 7.9.0, 2 Player verbunden

Ist das nun "dramatisch" ?
Denn beim StatusKO erscheint der "Kram" wieder ...

[wintermute]

Screenshot anbei.

Aber der Trigger steht auf 0... die Ausgaenge sind auch alle leer - laeuft der Baustein vllt garnicht? Das wuerde das "ruhige" Log erklaeren
Dank meines so geschickt eingebauten Bugs kannst Du die Reconnects am Players-Ausgang (A5) des Server-LBS zaehlen lassen. Aber Vorsicht, das Feature ist der aktuellen 0.6er Version leider weggefallen

[MIT]

Super... danke!
Und in Max2Play kann die MAC direkt unter "WLAN & LAN" in Max2Play - anhand des Logs unten - ausgelesen und eingetragen werden (=> für denjenigen hier, der Max2Play ebenfalls nutzt). Ich habe sicherheitshalber die MAC in der "server.prefs"-Datei unter /var/lib/squeezeboxserver/prefs ebenfalls geändert. Denn der Server ist ja auch Client ... )
=> Diese Änderungen führten nun dazu, dass es bei mir "still" im TraceLog und ErrorLog geworden ist ... sprich: es sieht erstmal sauber aus. Also: Auch das ständige connecten ist nun weg! => Screenshot anbei.

[wintermute]

Danke, André!

BTW: ich hab grad mal die Version 0.6 vom Server Baustein hochgeladen. Die wichtigste Aenderungen betreffen wohl die Vorbereitung fuer "sleep" und "synchronize", der Rest ist mehr intern...
Die restlichen Updates folgen dann spaeter.

[jonofe]

Ich hatte das auch schon mehrfach, dass squeezelite leere MAC Adressen liefert.

Man kann das in

/etc/default/squeezelite

fest einstellen. Dazu dann die MAC Adresse, die

ifconfig eth0

liefert bei SB_EXTRA_ARGS eintragen:

SB_EXTRA_ARGS="-a 80 -m xx:xx:xx:xx:xx:xx"

Danach lief es bei mir immer problemlos.

[wintermute]

Das mit der ID 00:00:00:00:00:00 für den Server kam mir ebenfalls komisch vor. Ich muss nun mal suchen, wo ich das genau ändern kann. Ich vermute mal, dass diese PlayerID zur Identifizierung des Servers für die Clients dient und diese automatisch ausgelesen wird, oder? Woher sollte der Server denn sonst die ID kennen? Zur Anmeldung beim LMS wird diese ID in der URL [192.168.0.110:9000/settings/index.html?player=00:00:00:00:00:00] ebenfalls übertragen. Die MAC-Adresse des Clients habe ich ja definiert.
Dieser mehrmalige Versuch die Verbindung aufzubauen könnte ggf. durch diese eindeutige ID gestoppt werden? - Melde mich wieder. Erstmal: DANKE!

Wie gesagt, Squeezelite kenn ich nicht, da weiss ich leider nicht wo man das einstellen kann. Bei einem Hardware-Player ist die ID immer die MAC, nimmt man SqueezePlay auf nem Rechner ebenfalls. Beim picoreplayer weiss ich grad ausm Kopf nicht ob man die konfigurieren kann oder obs da auch (automatisch) die MAC ist. Ob der LMS den Player nu anhand seiner MAC identifiziert oder ob der Player dem LMS seine PlayerID mitgibt weiss ich auch nicht
Aber ja, die dient zur Identifizierung und der LMS kennt die automatisch "irgendwoher".

Zu den Reconnects: ob die vom Player oder vom LMS initiiert werden kann das tracelog vom LBS nicht sagen, da muesstest Du in die LMS oder Player-Logfiles schauen. Jedenfalls erzeugt jeder Reconnect eine Meldung vom LMS an den Baustein und der Baustein erfragt dann wieder den Status des Players beim LMS und alles wird dreimal durch Edomi und die Datenbank gezogen - das muesste man schon deutlich in der Auslastung erkennen koennen (aufm Edomi). Es koennte durchaus sein, dass der LMS den Player wegen seiner "komischen" ID rauswirft, koennte aber auch ein Problem am Player sein.

Jedenfalls ist mein Baustein erstmal nicht schuld

PS: ich seh grad - am Client-LBS hast du ja auch ne "korrekte" playerID angegeben - die passt halt nur nicht mit dem zusammen, was SqueezeLite schickt...

[MIT]

Das mit der ID 00:00:00:00:00:00 für den Server kam mir ebenfalls komisch vor. Ich muss nun mal suchen, wo ich das genau ändern kann. Ich vermute mal, dass diese PlayerID zur Identifizierung des Servers für die Clients dient und diese automatisch ausgelesen wird, oder? Woher sollte der Server denn sonst die ID kennen? Zur Anmeldung beim LMS wird diese ID in der URL [192.168.0.110:9000/settings/index.html?player=00:00:00:00:00:00] ebenfalls übertragen. Die MAC-Adresse des Clients habe ich ja definiert.
Dieser mehrmalige Versuch die Verbindung aufzubauen könnte ggf. durch diese eindeutige ID gestoppt werden? - Melde mich wieder. Erstmal: DANKE!

[wintermute]

Uhm... nein, hatte ich uebersehen, danke.

Es liegt an Deinem Player (erstmal... wieso der Player-Count hochzaehlt <s>muss ich nochmal naeher rausfinden</s>hab ich grad rausgefunden):

2016-04-01 11:54:34    607186    EXEC    19028    LBS19000200(13): client 00:00:00:00:00:00 reconnected    Ok
...
2016-04-01 11:54:34    715131    EXEC    19028    LBS19000200(13): RECV: 00:00:00:00:00:00 client reconnect    Ok
2016-04-01 11:54:34    715383    EXEC    19028    LBS19000200(13): client 00:00:00:00:00:00 reconnected    Ok
...
2016-04-01 11:54:34    825093    EXEC    19028    LBS19000200(13): RECV: 00:00:00:00:00:00 client reconnect    Ok
2016-04-01 11:54:34    825335    EXEC    19028    LBS19000200(13): client 00:00:00:00:00:00 reconnected    Ok
...
2016-04-01 11:54:34    934274    EXEC    19028    LBS19000200(13): RECV: 00:00:00:00:00:00 client reconnect    Ok
2016-04-01 11:54:34    934529    EXEC    19028    LBS19000200(13): client 00:00:00:00:00:00 reconnected    Ok

Laut Log hat Dein Player
a-tens) eine (mindestens mal fuer den LBS, vermutlich aber auch fuers LMS) ungueltige PlayerID (00:00:00:00:00:00), kannst Du die im Squeezelite aendern (ich kenne dein Client selber nicht)? Falls das dann tatsaechlich auch die MAC Deines Players ist, solltest Du die unbedingt aendern, denn das wird nicht lange eindeutig bleiben Was Du da reinschreibst ist eigentlich egal, aber die 00...00 wird LMS-intern als Broadcast Indicator genutzt, das koennte den LMS verwirren.

b-tens) ein weiteres Problem, denn er verbindet sich mehrmals pro Sekunde zum LMS - was fuer nen irren Overhead am LMS und demzufolge auch in Edomi sorgt

Wenns irgend geht bitte die Sachen erstmal bereinigen.

gruesse :: Michael