Dynamite Anpassungen für S480 Firmware loading

Moin!

Gedanken dazu mache ich mir schon. Wann wird denn die Firmware geladen - beim ersten Öffnen des Frontends (d.h. ich müsste es einmal kurz öffnen und dann warten) oder schon beim Laden des Treibers (d.h. ich kriege von udev die Nachricht und warte dann erst mal, bevor es weitergeht).

Danke!

Lars

Zitat von mini73

Gedanken dazu mache ich mir schon. Wann wird denn die Firmware geladen - beim ersten Öffnen des Frontends (d.h. ich müsste es einmal kurz öffnen und dann warten) oder schon beim Laden des Treibers (d.h. ich kriege von udev die Nachricht und warte dann erst mal, bevor es weitergeht).

Das ist aber ganz eindeutig ein Fehler des Treibers, eine Lösung dafür gehört nicht nach dynamite, da sind wir uns doch hoffentlich einig. Was ich mir vorstellen könnte ist das udev dynamite signalisiert das entsprechende Device von vorne herein detached zu lassen. Über einen anderen weg muss dann das erfolgreiche Laden der Firmware getrackt werden und dann dynamite beauftragt werden das Device zu attachen.

Gerald

Moin!

Ich finde auch, dass es eigentlich im Treiber gelöst werden müsste. Aber irgendwie besteht die Welt doch immer aus Workarounds...
Kann man eigentlich nachträglich udev-Eigenschaften ändern? Muss ich mal ausprobieren. Denn wenn man ein "dynamite_attach=no" an ein Frontend hängt, dann wird dynamite es immer "missachten", auch wenn es später explizit mit "ATTD" hinzugefügt wird.
Kann man nicht ein passendes sleep irgendwo in den Treiber zwischen Firmwareload und Registrieren des Frontends einsetzen?

Und vorher muss ich erst noch dynamite und Multi-Frontend-Support auf 1.7.22 portieren.

Lars.

gda - klar ist es ein Treiberproblem - es ist aber auch ein existierendes Problem für 3-5 Geräte - aus meiner Sicht spricht nichts gegen einen Workaround, der durch eine entsprechende Udev Rule ausgelöst wird. Sollte sich die Treibersituation bessern, kann man es wieder zurücknehmen.

Zitat von steffen_b

gda - klar ist es ein Treiberproblem - es ist aber auch ein existierendes Problem für 3-5 Geräte - aus meiner Sicht spricht nichts gegen einen Workaround, der durch eine entsprechende Udev Rule ausgelöst wird. Sollte sich die Treibersituation bessern, kann man es wieder zurücknehmen.

Das habe ich doch gemeint. Udev ist die richtige Stelle um sowas zu machen, aber der Thread-Titel lautet: "Dynamite Anpassungen für S480 Firmware loading" und ich würde es nicht gut finden, wenn dynamite plötzlich Hardware erkennen würde.

Gerald

Ich würde mir vorstellen das dynamite nur per udev eine Variable access_delay=X bekommt und bei entsprechender Eigenschaft dann X Sekunden wartet.

Natürlich muss dynamite die Karte nicht erkennen, nur auf die Variable reagieren - Die Frage von Lars steht noch im Raum - ich vermute es ist kein Zugriff nötig bur ein 3s Timeout oder so - aber es wäre schade wenn ich das falsch verstehe

Moin!

Richtig, es würde nur eine udev-Variable sein, auf die dynamite reagiert. Ich muss jetzt nur noch wissen, wie dynamite reagieren soll - deshalb meine Frage.

Lars.

Moin!

Am einfachsten kannst du das testen, indem du das Teil erst mal abstöpselst, den Rechner startest, vdr beendest und dann das Ding einstöspelt.
Erscheint dann ein Laden der Firmware in den Logs passiert es auch ohne Öffnen des Frontends.
Falls dann noch nichts in den Logs steht, einfach den vdr starten, dann müsste das Laden angestoßen werden.

Für die Argumentation mit Igor:
Warum erstellt der Treiber schon die Devices, wenn sie noch nicht benutzt werden können?
Bzw. wenn sie noch nicht benutzt werden können, warum blockiert ein open nicht so lange, bis die Firmware da ist und das Device benutzt werden kann?

Ein direktes Beobachten des Ladens der Firmware ist nicht möglich (oder doch? müsste ich mal bei udev nachsehen). Ich könnte höchsten ein paar Sekunden warten (an der richtigen Stelle).

Lars.

Zitat von Torsten73

Da beim yavdr dass von dynmite übernommen wird, und es noch größere Probleme beim S3 damit gibt, macht es durchaus Sinn, dass dynamite die Firmware überwacht.

Nein, das macht überhaupt keinen Sinn, weil dynamite nur die Devices kennt, aber nicht die Hardware die sich dahinter verbirgt. Udev kennt die Hardware und legt die Devices an, da gehört das hin.

Zitat von Torsten73

Was auch immer wirklich der Grund ist, ich weiß nur, es funktioniert problemlos, wenn man eine solche Lösung einbaut (siehe MLD, da ist dieser Lösungsweg seit Monaten im Einsatz und funktioniert perfekt, aber auch kein dynamite).

Erwartest du jetzt, dass einer von uns sich MLD installiert und das reverse engineered, oder sagst du es uns einfach?

Zitat von Torsten73

Und damit das auch mit S3 geht, muß dies in dynamite erfolgen und nicht beim Start des VDR´s, da der beim Wakeup aus S3 ja gar nicht mehr neu gestartet wird.

Ich bleibe dabei, das gehört nicht nach dynamite, sondern nach udev, udev kann ja dann dynamite benutzen.

Gerald

hi jungs,

gda, so haben wir es gelöst: dvb-usb

greetz MarMic

p.s. install ist doch gar nicht nötig 1. alles im svn 2. LIVEBOOT *LOOOL*

edit://man sollte auch nicht vergessen, dass wir kein dynamite nutzen und vdr erst starten lassen, wenn das dvb init durchgelaufen ist -> erleichtert die sache natürlich gewaltig!

Zitat von MarMic

gda, so haben wir es gelöst: dvb-usb

Also nach dem Laden des Treibers 10 Sekunden warten nachdem der letzte DVB-Adapter hinzugekommen ist. Anscheinend unabhängig davon was für ein Adapter es ist. Es wird also auf das Erscheinen aller DVB-Adapter und dann noch mal 10 Sekunden gewartet. Warum nicht die unproblematischen Adapter ignorieren und nur auf die S480 warten? Ach ihr könnt auf diese Art und Weise nicht wissen welches der Adapter für die S480 ist. Sollte auf jeden Fall durch udev und dynamite zu machen sein.

Ich muss mich nochmal korrigieren, ihr wartet dort anscheinend nur auf die Adapter der S480. Erst ganz am Schluss werden die anderen USB-DVB-Treiber geladen. Ich hätte es ja andersherum gemacht, so dass die anderen Devices schon mal aktiv sind, aber ohne dynamite nützt euch das ja eh nichts.

Gerald

hi gda,

ja es wird geschaut ob eine oder n teviis im system enthalten sind und je nachdem wird auf die adapter gewartet (nur 1sekunde -> mit 10sekunden haette man einfach nur nen sleep 10 einfügen können und es haette immer geklappt). Tevii als erstes, da es ja noch andere langsame usb devices geben kann, was das testen auf adapter verfälschen würde.

greetz MarMic

Zitat von MarMic

ja es wird geschaut ob eine oder n teviis im system enthalten sind und je nachdem wird auf die adapter gewartet (nur 1sekunde -> mit 10sekunden haette man einfach nur nen sleep 10 einfügen können und es haette immer geklappt). Tevii als erstes, da es ja noch andere langsame usb devices geben kann, was das testen auf adapter verfälschen würde.

Sorry, du hast recht, ihr hört einen Sekunde nach dem Erscheinen des letzten DVB-Adapters auf. Ihr wartet nur maximal 10 Sekunden darauf, dass sie alle kommen. Ne, stimmt auch nicht, ihr wartet nur auf das Erscheinen des letzten Adapters und macht dann sofort weiter. Das soll alles sein? Nur auf das Erscheinen beider Adapter zu warten?

Gerald

Ok also geht ein fixer Wert (1s oder 2s per udev rule und ein sleep auf dynamite seite beim Zugriff) - Zugriff braucht es nicht - nur Verzögerung

(1s nach erscheinen der Devices/udev event bei MLD). Danke MarMic

Zitat von steffen_b

Ok also geht ein fixer Wert (1s oder 2s per udev rule und ein sleep auf dynamite seite beim Zugriff) - Zugriff braucht es nicht - nur Verzögerung

Zitat von steffen_b

(1s nach erscheinen der Devices/udev event bei MLD). Danke MarMic

Ne, gar keine Verzögerung, nur warten bis beide Adapter da sind.

Gerald

Ok also blockiert das zweite device wenn auf das erste zugegriffen wird ... ?

hi jungs,

es ist lange lange her seit dem einbau des workarounds. ich bin der meinung, wenn wirklich beide devices da sind also z.B. /adapter0 und /adapter1 -> dann ist die karte auch wirklich betriebsbereit. deswegen testen wir auf die anzahl der adapter (man könnte die eine sekunde auch kleiner wählen, aber naja 1sec ist ja vertrettbar).

d.h. wenn sich die anzahl der adapter um die anzahl der gefundenen tevii-ids erhöht hat -> kann man den vdr starten

greetz MarMic

Zitat von MarMic

d.h. wenn sich die anzahl der adapter um die anzahl der gefundenen tevii-ids erhöht hat -> kann man den vdr starten

Ganz sicher ist das natürlich nicht. Bis bei euch der VDR auf die Adapter zugreift, dauert es ja noch einige Sekunden. Bei uns läuft der VDR ja schon und dynamite schlägt erbarmungslos zu. Können wir nur durch Testen herausbekommen ob es reicht auf beide Adapter zu warten, oder ob wir noch ein paar Sekunden drauflegen müssen.

Gerald