Dynamite Anpassungen für S480 Firmware loading

    Moin!


    Ach, das ist ein Dual-Tuner-Gerät und erst dann benutzbar, wenn alle Adapter da sind? Hm, spannender Treiber...


    Interessant wäre aber trotzdem noch, ob das Laden des Treibers das Laden der Firmware auslöst oder es erst durch das Öffnen des Frontends passiert (wie bei anderen Geräten).
    Ich vermute jetzt aber einfach mal, dass der Treiber schon vor dem ersten Öffnen die Firmware lädt.


    Ein passender Lock im Treiber sollte aber trotzdem eingebaut werden, anstatt es auf alle Applikationen abzuwälzen, die das Teil benutzen wollen.


    Ich werde mit dem neuen Wissen noch mal drüber schlafen. Denkbar wäre eine "linked to"-udev-Variable oder so, die dafür sorgt, dass dynamite erst aktiv wird, wenn beide "verknüpften" Frontends da sind.


    Lars.

    Naja einige Sekunden sind das nicht gerade bei mir. Dank der SSD und Core i sind das kaum messbare Werte, allenfalls 1-2s. Im Log zu sehen anhand des Zeitpunkts. Deshalb benötigt der yavdr mit der S480 auf so lange bis zum ersten TV Bild. Die Kanal nicht verfügbar Info ist schon lange da bevor die Devices von Dynamite eingehangen werden. Das sind gut 10s !
    Liegt aber auch an der schnellen Hardware.


    Schaut mal hier auf der lahmen Atom Kiste die messages (yavdr 0.3 Lucid mit testing alter Stand, nach wakeup aus S3 mit Pauli Patch):



    dazu passend die syslog:


    Man kann also eindeutig sehen, dass ab der Meldung " dvb-usb: TeVii S660 USB successfully initialized and connected" der VDR erst geladen wird und dazwischen liegen rund 3s die die Karte benötigt um fertig zu sein.
    Theoretisch reicht es für nur S480 Lösungen diese Meldung auszuwerten.
    Was ich nicht verstehe ist, warum ich nur adapter 1 frontend 0 im log finde, ich hätte dort auch noch frontend 1 erwartet.
    Hier ist es aber noch ein System ohne dynamite das gleiche mit dynamite liefere ich Euch noch nach, wenn gewünscht. Der Rechner ist bereits nicht mehr in meinen Händen ;)

    Proxmox VE, Tyan Xeon Server, OMV, MLD-Server 5.1
    MLD 5.1 64bit: Asus AT5iont-t, ION2, 4GB Ram, SSHD 2,5" 1Tb, HEX TFX 300W 82+, Cine S2 V6.2 , 38W max.
    Yavdr 0.5:     Zotac D2550ITXS-A-E mit GT610 OB, TT S2-4100 PCI-e ,Joujye NU-0568I-B
    Yavdr 0.5:     Sandy Bridge G840, Tests und Energieverbrauch , CoHaus CIR, Cine S2 V6.2
    MLD 5.1 Beebox N3150    , DVBSky S960 und 1Tb WD Blue

    Zitat von mini73

    Ich werde mit dem neuen Wissen noch mal drüber schlafen. Denkbar wäre eine "linked to"-udev-Variable oder so, die dafür sorgt, dass dynamite erst aktiv wird, wenn beide "verknüpften" Frontends da sind.


    Wenn das reicht, was ja bis jetzt nur eine Vermutung ist. Vielleicht baust du ja einen Aufruf für eine Art Callback-Skript ein ;)


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Moin!


    Ich interpretiere das Log so, dass die Firmware erst dann geladen wird, wenn das Frontend geöffnet wird, weil der vdr um 12:49:57 startet und das Laden der Firmware erst um 12:49:59 passiert. Außerdem steht da was von "on demand".
    Es scheint also nicht das Laden der Firmware ein Problem zu sein, sondern dass auf den ersten Adapter zugegriffen wird, bevor der zweite da ist. Denn dynamite reagiert auf die udev-Meldung, dass ein Frontend erstellt wurde, und erstellt dann gleich ein cDvbDevice-Objekt, so dass der vdr das Frontend öffnet. Und da ca. eine Sekunde zwischen dem Registrieren der beiden Frontends liegt, fällt das sicherlich in diesen Zeitraum.


    Ein Callback-Script wäre auch denkbar, das ließe sich auch über udev steuern. Ein Callback-Script an das erste Frontend hängen, das wird dann von dynamite aufgerufen und wartet auf das Ende des Scripts. Das Script kriegt das Frontend als Parameter und ermittelt daraus, auf welches andere Frontend es warten soll und tut es. In diesem Moment bekommt dynamite aber die udev-Nachricht über das zweite Frontend und überholt sich da also selbst - sowas kann auch immer interessant sein.


    Spontan würde ich sagen, dass ein Sleep innerhalb von dynamite nach Empfang einer udev-Nachricht vielleicht die kleinste und einfachste Lösung wäre, obwohl ich eine "ereignis-gesteuerte" Lösung vorziehen würde.
    Ein Auswerten der Log-Dateien kommt auf keinen Fall in Frage, das wird dynamite nie machen. Das ist auch zu "hackish", denn die Log-Meldungen können sich jederzeit ändern und dann klappt das alles wieder nicht.


    Und wieder was zum drüber schlafen. ;)


    Lars.

    Bei meiner TeVii S660 und der baugleichen Cinergy S2 USB HD gibt es übrigens dasselbe Problem.
    Der Workaround sollte imho also nicht nur für die TeVii S480 sondern auch für die TeVii S660 und die Cinergy S2 USB HD funktionieren.


    Wenn Ihr Logs braucht, sagt Bescheid, was ihr genau braucht.
    Ich hab hier eine ziemlich komplexe Konfiguration mit drei verschiedenen USB-Devices.

    VDR: ASRock ION 330-HT, yaVDR 0.5.0a TT-connect S2-3650 CI (DVB-S2 an USB, CI ungetestet), TeVii S660 (DVB-S2 an USB), Cinergy S2 USB HD (DVB-S2 an USB), HDMI mit Ton an 42"-LCD, MCE-Fernbedienung auch zum Einschalten (beim ASRock ION 330HT mitgeliefert)
    VDR im Ruhestand: Xeatre 6100 pro mit easyVDR 0.6.0 mit VDR 1.4.7 (FF, Budget)
    sonstige PVR: uralte Erfahrungen mit Topfield PVR 4000 und früher Grundig SeleXX (verschrottet)

    Moin!


    Bei der Lösung, die ich anstrebe, wirst du selbst dafür verantwortlich sein, diesen Workaround zu aktivieren, indem du eine passende udev-Regel erstellst und eine bestimmte Variable mit einem bestimmten Wert an das richtige Frontend hängst, das dann von dynamite ausgewertet wird.


    Wo liegt der Unterschied zwischen einer S660 und S480? Ist die S660 eine "halbe" S480 in einem USB-Gehäuse?
    Wie macht sich da das Problem bemerkbar? Denn die S480 ist ein Dual-Tuner, bei dem auf die komplette Initialisierung aller Adapter gewartet werden muss (anscheinend).
    Muss bei der S660 auch einfach nur ein bisschen gewartet werden, nachdem der Treiber geladen wurde?


    Ist also vermutlich ein etwas anderes Problem, aber trotzdem interessant, falls man es in einem Rutsch lösen kann.


    Lars.

    hallo mini73,


    so wie ich das mal gelesen habe ist die s480 eine anbindung zweier s660-usb über pcie.


    also nichts anderes als 2x s660 mit ner pcie bridge (falls das so richtig heisst)


    greetz MarMic

    SZVDR HD: Intel e5300@1,2ghz - Gigabyte GA-EP41-UD3L - 2GB ddr2 800 - Gainward G210 512mb - Silverstone LC16MR - Tevii s480 - Astra 19,2 - MLDHD-5.4 testing


    WZVDR HD: Intel g1610@1,6ghz - Intel DH61BE - Scythe Big Shuriken 2 - 4GB ddr3 1333 - Asus GT610 1024mb - Chieftec Hi-Fi HM-02 - Tevii s480 - Astra 19,2 - MLDHD-5.4 testing

    Moin!


    Ok, dann macht das "dvb-usb" im Log auch wieder Sinn. ;)


    Trotzdem bleibt die Frage, wie sich das Problem bei einer S660 manifestiert, da es ja nur ein Adapter und nicht zwei sind.


    CouchPotato: Logs ähnlich wie die von Torsten73 im 23. Post wären gut.


    Lars.

    Zitat von mini73

    Trotzdem bleibt die Frage, wie sich das Problem bei einer S660 manifestiert, da es ja nur ein Adapter und nicht zwei sind.


    Das habe ich zuerst auch gedacht, aber er hat ja 2 davon:

    Zitat

    Bei meiner TeVii S660 und der baugleichen Cinergy S2 USB HD


    Mein Verdacht ist aktuell, dass der Treiber einfach das falsche Gerät zuerst mit der Firmware befüllt. Es wird auf das 1. Gerät zugegriffen, der Firmware-Upload startet, aber leider ins falsche Gerät. Nach erfolgreichem Upload in Gerät 2 gibt der Treiber sein OK für Gerät 1 und es kracht beim Zugriff drauf.


    Wäre doch eine Erklärung, oder?


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    kernel:
    http://pastebin.com/NJP24sGb


    syslog:
    http://pastebin.com/qD1rTyCc


    LG
    Ralph

    VDR: ASRock ION 330-HT, yaVDR 0.5.0a TT-connect S2-3650 CI (DVB-S2 an USB, CI ungetestet), TeVii S660 (DVB-S2 an USB), Cinergy S2 USB HD (DVB-S2 an USB), HDMI mit Ton an 42"-LCD, MCE-Fernbedienung auch zum Einschalten (beim ASRock ION 330HT mitgeliefert)
    VDR im Ruhestand: Xeatre 6100 pro mit easyVDR 0.6.0 mit VDR 1.4.7 (FF, Budget)
    sonstige PVR: uralte Erfahrungen mit Topfield PVR 4000 und früher Grundig SeleXX (verschrottet)


    exakt so ist es. Betrifft möglicherweise alle Devices die auf die ds3000 aufbaut. Da gibt es noch andere so weit ich weiß.

    Proxmox VE, Tyan Xeon Server, OMV, MLD-Server 5.1
    MLD 5.1 64bit: Asus AT5iont-t, ION2, 4GB Ram, SSHD 2,5" 1Tb, HEX TFX 300W 82+, Cine S2 V6.2 , 38W max.
    Yavdr 0.5:     Zotac D2550ITXS-A-E mit GT610 OB, TT S2-4100 PCI-e ,Joujye NU-0568I-B
    Yavdr 0.5:     Sandy Bridge G840, Tests und Energieverbrauch , CoHaus CIR, Cine S2 V6.2
    MLD 5.1 Beebox N3150    , DVBSky S960 und 1Tb WD Blue

    Zitat von gda

    Mein Verdacht ist aktuell, dass der Treiber einfach das falsche Gerät zuerst mit der Firmware befüllt. Es wird auf das 1. Gerät zugegriffen, der Firmware-Upload startet, aber leider ins falsche Gerät. Nach erfolgreichem Upload in Gerät 2 gibt der Treiber sein OK für Gerät 1 und es kracht beim Zugriff drauf.
    Wäre doch eine Erklärung, oder?
    Gerald


    Nope, zumindest bei mir nicht. Der Fehler des zu späten bzw. gar nicht ladens tritt auch auf, wenn nur eins der DS3000-Geräte dran ist.
    Und das schon seit yaVDR 0.1. Damals hab ich es mit einem 10 sec.-Sleep beim Startup gelöst.


    Hier ist die TeVii gar nicht hochgekommen:
    http://pastebin.com/21Hw0R9V

    VDR: ASRock ION 330-HT, yaVDR 0.5.0a TT-connect S2-3650 CI (DVB-S2 an USB, CI ungetestet), TeVii S660 (DVB-S2 an USB), Cinergy S2 USB HD (DVB-S2 an USB), HDMI mit Ton an 42"-LCD, MCE-Fernbedienung auch zum Einschalten (beim ASRock ION 330HT mitgeliefert)
    VDR im Ruhestand: Xeatre 6100 pro mit easyVDR 0.6.0 mit VDR 1.4.7 (FF, Budget)
    sonstige PVR: uralte Erfahrungen mit Topfield PVR 4000 und früher Grundig SeleXX (verschrottet)

    Zitat von CouchPotato

    Der Fehler des zu späten bzw. gar nicht ladens tritt auch auf, wenn nur eins der DS3000-Geräte dran ist.
    Und das schon seit yaVDR 0.1. Damals hab ich es mit einem 10 sec.-Sleep beim Startup gelöst.


    Na, ja, dann ist es ja eindeutig ein anderes Problem bei dir.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    hi jungs,


    da wir nun einen neuen user mit problemen hatten -> haben wir die thematik noch einmal aufgegriffen und untersucht. wir nutzen kein udev sondern mdev und das muessen wir ausführen um xorg bediengeräte bereitzustellen (führt nun zu weit...)


    jedenfalls ist mir aufggefallen, dass die tevii sich als id 481/482 meldet BIS ein mdev -s angestoßen wird -> erst dann ändert sie ihre id zu 660! bei mir war diese zwar immer 660, weil ich vorher einen mdev -s wegen xorg ausgelöst hatte. Bei dem neuen user war dvb-usb VOR xorg soweit und ist nie in die if schleife gegangen weil es keien 660er gefunden hat.


    claus hat dann das script so abgeändert vllt hilft euch das weiter -> wenn nicht vergesst es einfach :P



    damit tut die karte nun bei jedem tester, den wir haben :P


    greetz MarMic


    p.s. dank geht natürlich an claus!

    SZVDR HD: Intel e5300@1,2ghz - Gigabyte GA-EP41-UD3L - 2GB ddr2 800 - Gainward G210 512mb - Silverstone LC16MR - Tevii s480 - Astra 19,2 - MLDHD-5.4 testing


    WZVDR HD: Intel g1610@1,6ghz - Intel DH61BE - Scythe Big Shuriken 2 - 4GB ddr3 1333 - Asus GT610 1024mb - Chieftec Hi-Fi HM-02 - Tevii s480 - Astra 19,2 - MLDHD-5.4 testing

    Moin!


    Ja, stimmt, dass sich die Id ändert, hatten wir auch schon mal bemerkt - nämlich bei der Installation, wo wir dann anhand bestimmter Ids das richtige Treiberpaket installieren.


    Ich werde aber vermutlich einfach nur ein "sleep" einbauen, dass man per udev-Attribut aktivieren kann. Alles andere ist zu abhängig von bestimmten Dingen, die ich gar nicht wissen will... :)


    Lars.

    Moin!


    Im unstable-vdr-PPA gibt's nun ein dynamite-Plugin (>= 0.0.8i), dass das udev-Attribut "dynamite_attach_delay" auswertet. Mit einer passenden udev-Regel lässt sich nun der Zugriff des vdr auf das Frontend entsprechend verzögern.


    Lars.

    Hallo,


    Hänge mich auch mal mit rein.
    Schön das weiter dran gearbeitet wird die zickige USB-Box(en) zum Laufen zu kriegen.


    Bin leider nicht so er udev-Experte, wie also sollte so eine Regal aussehen?



    Danke und MFG SVen


    /edit


    hier mal das Log wenn ich die Terratec dazu stecke:



    Allerdings liefert die Terratec kein Signal:


    Code
    Dec 17 22:10:29 hdvdr vdr: [3436] switching to channel 8
Dec 17 22:10:30 hdvdr vdr: [3909] receiver on device 3 thread started (pid=3436, tid=3909)
Dec 17 22:10:30 hdvdr vdr: [3910] TS buffer on device 3 thread started (pid=3436, tid=3910)
Dec 17 22:10:30 hdvdr vdr: [3908] osdteletext-receiver thread ended (pid=3436, tid=3908)
Dec 17 22:10:30 hdvdr vdr: [3436] buffer stats: 0 (0%) used


    Erst wenn VDR nochmals neu gestartet wird, wie schon gehabt geht sie erst...


    edit/

    Moin!


    Um eine passende udev-Regel erstellen zu können, braucht man die Ausgabe von (Adapter-Nr entsprechend anpassen)

    Code
    udevadm info --query=all --name=/dev/dvb/adapter2/frontend0


    und

    Code
    udevadm info --query=all --name=/dev/dvb/adapter2/frontend0 --attribute-walk


    Die Variable muss an das Frontend gehängt werden, es wird also ähnlich aussehen wie

    Code
    ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", (hier fehlt was zur Identifikation), ENV{dynamite_attach_delay}="10"


    Bei PCI-Karten bietet sich meistens KERNELS des Parent-Device zur Identifikation an (ist sozusagen die Id des PCI-Slots), das funktioniert allerdings nicht bei z.B. den Cine-Karten mit ngene bzw. ddbridge, weil da verschiedene Frontends am selben PCI-Slot hängen.
    Bei USB-Geräten hat man z.B. eine Vendor-Id und manchmal sogar eine Seriennummer. Aber das erzählt uns dann die Ausgabe von udevadm.


    Lars.

    Hi, mini73


    Danke für deine Antwort, also ich habe mal die udev-Regel aus der Readme genommen und mal unverändert eine Regel erstellt und raus gekommen ist:



    und dmesg zeigt:



    Schon mal Super, aber kann nicht getunt werden: Kanal nicht verfügbar! Hab ich was falsch gemacht? Bin echt nicht so bewandert in der Materie, hab bitte Nachsicht!


    Danke und MFG SVen


    /edit


    Ich bin zu blöd ich weis nicht was ich hier rein Schreiben soll "(hier fehlt was zur Identifikation)", mal geht die Box beim Hochfahren mal wieder nicht...


    edit/

    Moin!


    Kein Problem, ich gebe seid über 20 Jahren immer wieder Nachhilfe in Mathe, ich habe eine Menge Nachsicht... :)


    Die einzige Variable, die dich eigentlich interessiert, ist "dynamite_attach_delay". Die anderen kannst du aus deiner udev-Regel entfernen, die brauchst du nicht.


    Und wenn du jetzt noch die Ausgabe von

    Code
    udevadm info --query=all --name=/dev/dvb/adapter2/frontend0 --attribute-walk


    postest, können wir den Teil, der zur Identifikation benötigt wird, auch noch ableiten.


    Lars.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden