LBS(Sammlung) Squeeze

[MIT]

Nach einer erneuten Aktivierung in edomi habe ich keine Fehlermeldungen mehr ...
Habe nun probiert, ob der Player sich einschalten lässt (via einer Testvisu).
Es kommt auf jeden Fall eine 1 an ... sieht irgendwie "gesünder" aus. Und das Hochzählen des "Players" ist auch weg.
Kannst Du dir den Screenshot mal anschauen?

EDIT: Nun habe ich deinen Rat befolgt und das DEBUG auf TRUE gesetzt. Danach habe ich die LBS aktualisiert und edomi neu aktiviert und ... schwupps ... ist der o.g. Fehler wieder da ... :-(
> Das Tracelog ist anbei

[wintermute]

Von Seiten der Konfig sieht das alles soweit erstmal gut aus...
Hast Du den letzten Screenshot vllt nochmal mit aktualisierten Live-Werten?

[MIT]

Biddö :-)

[wintermute]

Da ist noch immer was falsch... Der Ausgang "Players" sollte nicht im vierstelligen Bereich liegen, das ist naemlich die Anzahl an momentan angemeldeten Playern
Kannst Du das bitte mit dem DEBUG nochmal probieren?

[MIT]

Hast Du meinen tracelog (s.o. => #181) gesehen? Oder brauchst Du das aktueller; sprich: was genau soll ich dann machen (Start in Visu drücken o.ä.?) ?

[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

[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]

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

[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]

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.

[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]

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]

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]

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]

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