Die einzige Möglichkeit ist das bei dir mit tcpdump zu überprüfen wohin die Daten geschickt werden.
ok, das habe ich gemacht. Ergebnisse siehe unten.
Moeglich waere das der Server bei dir eventuell gestartet wird bevor das Netzwerk verfügbar ist, das könntest du aber lösen in dem du den Server einfach neu startest. Sollte dies das Problem sein kannst du einfach die udev Skripte anpassen und das Start Delay dort erhöhen.
es sieht tatsachlich so aus, als wenn das Problem mit einem zu fruehen Start des mediasrv zu tun haette. Mittlerweile gelingt es mir ohne weiteres nach einem manuellen shutdown/start des mediasrv auf dem Server den Scan wieder funktionsfaehig zu machen.
Anstelle von sleep 3; /opt/bin/mediaclient --start kannst du auch /opt/bin/mediaclient --start=3 ausführen.
diesbezueglich habe ich aber das Problem, dass der 'mediasrv' trotz '--start=50' augenblicklich gestartet wird (siehe 'ps -ef'). Jetzt koennte man annehmen dass das vielleicht ok ist, weil sich das Delay in Wirklichkeit nur auf Netzwerk-Aktionen bezieht.
Aber selbst dann wenn ich in '/lib/udev/rules.d/80-mediasrv-eeti.rules' und '/etc/udev/rules.d/80-mediasrv-eeti.rules'
eintrage:
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ACTION=="add", RUN+="/opt/bin/mediaclient --start=50"
aendert das am Fehlerverhalten nichts (d.h. der scan funktioniert trotzdem nicht). Mein System braucht aus power-off uebrigens ca 30s bis zum Shell-Prompt ueber's Netz. Da sollten also 50s Start-Delay dicke ausreichen.
Erst wenn ich wie oben beschrieben
/opt/bin/mediaclient --shutdown
und dann
/opt/bin/mediaclient --start
eingebe nach dem das System schon laengst oben ist, funktioniert ploetzlich alles wie gewuenscht. D.h alle Sticks am Server werden auf den Clients gemeldet.
Der Scan funktioniert einwandfrei, irgendwo wird bei dir wohl gefiltert.
also gefiltert wird sicher nicht, wie die nachfolgenden tcpdumps zeigen.
Ist dein Server ein PC oder ein Embedded System? 32 Bit oder 64bit?
es ist ein ganz normales Intel 64bit System auf einem DN2800MT. OS ist eine debian 6.0 minimal-Installation. Ich habe das System praktisch im Originalzustand + eure aktuellsten Treiber.
Wichtig -- überall die gleiche Treiberversion verwenden, oder zumindestens eine ab Juli.
ich habe überall (Server+Client) die Version sundtek_installer_120720.2210.sh
Jetzt zu den tcpdumps. Ich habe 4 Files:
BAD_server.txt - Schlechtfall/ tcpdump vom Stick-Server
BAD_client.txt - Schlechtfall/ tcpdump vom Client
GOOD_server.txt - Gutfall/ tcpdump vom Stick-Server
GOOD_client.txt - Gutfall/ tcpdump vom Client
Der Schlechtfall ist sofort reproduzierbar wenn ich keinen manuell shutdown/start mache. Selbst '--start=50' (siehe oben) bringt nichts. Der Gutfall ist nach manuellem shutdown/start sofort reproduzierbar.
ServerIP: 192.168.146.210
ClientIP: 192.168.146.187
Wenn man die Server und Client Dumps vergleicht sieht man es wird nichts gefiltert. Alles ist auf Server und Client sichtbar.
Es werden anscheinend immer Multicasts und dann Broadcasts gemacht. Und zwar im Gut wie im Schlechtfall. Im Schlechtfall wird jedoch
mehrfach wiederholt.
ABER: im Schlechtfall werden vom Server nur die Broadcasts beantwortet. Die Multicasts bleiben ohne Antwort an den Client.
Was ich jetzt nicht verstehe: selbst im Schlechtfall liegen dem Client die Antworten (ueber Broadcast) also vor aber werden anscheinend ignoriert. Eine Anzeige ergibt ergibt zumindest schlichtweg:
- 0 IPTV server found -------------------------------------------------------
So wie es aussieht funktionieren nur die Multicasts. Aber die werden wiederum nur moeglich nach dem manuellen Workaround mit shutdown/start. Alles eine verzwickte Geschichte
Die einzige automatisierte Moeglichkeit im Moment fuer mich ist im '/etc/rc.local' meinen Workaround einzubauen.
Eine andere Idee habe ich nach den ganzen Tests erst mal nicht.
Vielleicht gibt es doch noch eine geschicktere Variante?
Einer der folgenden Fixes sollte dazu bereits ausreichen:
1. Broadcasts zum funktionieren bringen. Dann muesste man sich um die unbeantworteten Multicasts (wegen zu fruehem mediasrv-start) nicht mehr zu kuemmern.
2. die -start=XX Option zum Laufen bringen. Dann muessten die Multicasts nach bisherigem Wissen eigentlich wieder funktionieren und man muesste die Broadcasts nicht mehr fixen.
Danke schon mal im voraus. Ich kann gerne noch was testen...
- sparkie
[UPDATE]
attachments gehen hier im Forum anscheinend nicht. Mit aktuellem firefox. Ich bekomme immer
Cannot access attachments upload path!
obwohl die Attachments ganz normal ueber Browse gefunden und eingebunden werden. Access Perms stimmen natuerlich auch.
wie ich die 4 kleinen tcp-Dumps (insges. nur ca. 60kB an Daten) uebermitteln soll - keine Ahnung
[/UPDATE]
