[gelöst] ds3000_firmware_ondemand: Waiting for firmware upload(2)... nach VDR-Start (PowerOn & Suspend)

  • Hallo alle,


    jetzt sitz ich nun seit 3 Tagen und such mir die Finger wund.
    Folgendes Problem : Nach dem Start von yaVDR 0.5 - egal ob nach PowerOn oder suspend - kommt "No Signal" und man sieht kein Bild. Die SinercgyS2 USB HD wird immer im "warm state" gefunden wird, unabhängig davon ob der Strom vom Receiver getrennt wurde oder nicht.


    WENN ich nun in der Konsole "restart vdr" auslöse, kommt anschliessend immer verlässlich ein Bild.
    Ich hab nun schon dutzende Beiträge über "sleep 2" hier und "sleep 5" da gefunden, aber es hilft nix....
    Im Detail:


    - sleep in /etc/init/vdr.conf vor dem "exec $DAEMON ..."
    - sleep in /etc/pm/sleep.d/20vdr_sleep mit anschliessendem "service vdr restart"
    - eintragen von modulen in /etc/yavdr/force-reload-modules.list (im pm-suspend.log wird dvb-usb-dw2102 als blockiert ausgeworfen...)
    - eintragen von "vdr" in /etc/yavdr/force-reload-services.list


    wenn ich dvb-driver --unload starte, passiert im Prinzip dass selbe wie beim Starten des Rechners: Es steht unendlich - bis ich auf einer zweiten Console "restart vdr" eingebe. Dann kann dvb-driver die Treiber entladen....


    Aber zurück zum aufwachen aus dem Suspend. in dmesg steht :



    und dort steht dmesg solange, bis ich "restart vdr" eingebe. Nach dem restart von vdr steht in dmesg weiter :


    Code
    1. [ 522.186902] init: vdr-frontend main process (4747) terminated with status 1
    2. [ 524.628145] dw2102: su3000_power_ctrl: 0, initialized 1
    3. [ 524.628147]
    4. [ 527.992047] dw2102: su3000_power_ctrl: 1, initialized 1


    Ich hab auch (einigen alten Posts folgend) verschiedene Firmware-dateien versucht. Aktuell wird die mit der md5-summe a32d17910c4f370073f9346e71d34b80 verwendet. Im Prinzip keine Änderungen dadurch.


    Meines Erachtens ist der Knackpunkt darin zu suchen, dass das initialisieren der Karte blockiert wird, weil der vdr-prozess/vdr-frontend-prozess (?) darauf zugreift. Erst wenn der sich "über die Häuser haut", kann die Karte initialisiert werden.
    Diese Erkenntnis alleine reicht leider noch nicht. Ich habe keinen Anhaltspunkt wo ich ansetzen müsste um in der Phase der Initialisierung der USB-Karte den VDR-Prozess loszuwerden. Einige beherzte Versuche bei diversen /etc/init-Scripte ein "/usr/bin/killall vdr" führten nur dazu dass er in einer Loop landete (meist logischerweise) und gar nix mehr anzeigte.... (z.b: in /etc/init/vdr.conf; /etc/init/vdr-frontend.conf; /etc/init/dvb-driver.conf).


    Hat jemand einen Tipp wo ich da ansetzen könnte um das Initialisieren zu ermöglichen ?


    lG Tom

  • Was passiert denn, wenn du über das dynamite-Plugin (ist unter yaVDR vorinstalliert, README siehe https://github.com/flensrocker/vdr-plugin-dynamite) die Karte auswirfst und anschließend wieder einbindest?
    Hast du dich mal an den udev-Attributen fürs attach-delay und und attach_delay_preopen versucht? Damit sollte die Karte genug Zeit haben die Firmware zu laden:


    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Lieber seahawk1986,


    vorerst mal danke für Deine Antwort und dem Hinweis auf Dynamite. Gesehen hab ich ihn wohl, allerdings noch nicht hinterfragt was damit zu tun ist.


    Allerdings darf ich anfügen - ich glaube nicht dass es an der Zeit an sich liegt. Er will ja auch nicht die Firmeware hochladen. Der Treiber will offensichtlich nur die Karte initialisieren.
    Was dem Treiber aber nicht gelingt, da jemand anderer (jedenfalls ein (sub-)Prozess vom VDR) den Treiber "in use" hat....


    Aber wie gesagt - ich probier´s selbstverständlich aus was passiert wen das Delay im udev angegeben wird.
    Das mit "frontend" ist jedenfalls schon mal ein guter Ansatz, denn ich seh alle Kanäle (Karte ist also da) aber kein Bild davon - ich darf am Abend berichten sobald ich wieder davor sitze....

    lG Tom

  • Allerdings darf ich anfügen - ich glaube nicht dass es an der Zeit an sich liegt. Er will ja auch nicht die Firmeware hochladen. Der Treiber will offensichtlich nur die Karte initialisieren.
    Was dem Treiber aber nicht gelingt, da jemand anderer (jedenfalls ein (sub-)Prozess vom VDR) den Treiber "in use" hat....


    Genau dafür ist soweit ich das verstanden habe ja das dynamite_attach_delay_preopen gedacht. Du schreibst ja selbst, dass ein sleep vor dem VDR-Start nicht hilft - vermutlich weil der Treiber die Firmware erst beim ersten Zugriff ("ondemand") lädt:

    [ 503.535633] ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)...
    [ 503.538052] ds3000_firmware_ondemand: Waiting for firmware upload(2)...


    Damit öffnet das dynamit-Plugin kurz das Gerät und gibt es sofort wieder frei, damit die Firmware geladen werden kann. Nach der angegebenen Verzögerung sollte das Gerät (mit zu dem Zeitpunkt dann hoffentlich geladener Firmware) wieder eingehängt werden.


    Falls das nicht klappt, schau mal hier: [yaVDR 0.5-alpha1] - Terratec Cinergy S2 und TT3600 da hat hepi noch eine alternativ-Lösung (die auf dem Aus- und wieder Einhängen des Gerätes über ein Skript basiert) aufgezeigt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • ich darf mich recht herzlich bedanken und ging Hoffnungsfroh ans Werk.... (wenn da nicht das "aber" wäre :( )
    Mit folgendem hab ich begonnen:

    Code
    1. /etc/udev/rules.d/20-cynergy-usb.rules
    2. ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend" , ENV{dynamite_attach}="yes" , ENV{dynamite_attach_delay}="10"


    im Syslog:


    in dmesg


    Am TV: Man sieht die Statusanzeige und nach 10 Sek. die Meldung "attached /dev/dvb/adapter0/frontend0"
    Ergebnis: kein Bild :(


    nun hab ich die udev-rule schrittweise (immer ein Parameter mehr) erweitert zu:

    Code
    1. ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend" , ENV{dynamite_attach}="yes" , ENV{dynamite_attach_delay}="10" , \
    2. ENV{dynamite_attach_delay_preopen}="yes", ENV{dynamite_cardindex}="0", ENV{dynamite_timeout}="5", ENV{dynamite_disable_autoidle}="yes"


    im syslog


    in dmesg:


    am TV : man sieht die Statusmeldung - nach ein paar Sekunden "attached /dev/dvb/adapter0/frontend0" - nach wenigen weiteren Sekunden "detached /dev/dvb/adapter0/frontend0"


    daraufhin habe ich den Timeout wieder rausgenommen (wegen des Detach)

    Code
    1. ACTION=="add",SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend" , ENV{dynamite_attach}="yes" , ENV{dynamite_attach_delay}="10" , \
    2. ENV{dynamite_attach_delay_preopen}="yes", ENV{dynamite_cardindex}="0", ENV{dynamite_disable_autoidle}="yes"


    was leider auch nicht den gewünschten Effekt hatte (im Sinne von "es kommt ein Bild")

    ABER
    : im dmesg steht immerhin:


    d.h. es tut sich etwas - nähmlich das Initialisieren. Aber scheinbar bekommt der VDR zu diesem Zeitpunkt nicht mit dass sich der Frontend0 (ich hoffe ich drücke mich richtig aus) geändert hat.


    Denn : so sieht es im Log aus wenn "restart vdr" auslöst:

    Code
    1. Nov 7 23:39:10 franz vdr: [9260] starting plugin: dynamite
    2. Nov 7 23:39:10 franz vdr: [9260] dynamite: startup channel is 8
    3. Nov 7 23:39:10 franz rsyslogd-2177: imuxsock begins to drop messages from pid 9260 due to rate-limiting
    4. Nov 7 23:39:14 franz vdr-sxfe[9368]: [9394] [console] read_key: read(stdin) failed: no stdin
    5. Nov 7 23:39:15 franz rsyslogd-2177: imuxsock lost 397 messages from pid 9260 due to rate-limiting
    6. Nov 7 23:39:15 franz vdr: [9260] dynamite: /dev/dvb/adapter0/frontend0 should not be attached yet
    7. Nov 7 23:39:16 vdr: last message repeated 199 times
    8. Nov 7 23:39:16 franz rsyslogd-2177: imuxsock begins to drop messages from pid 9260 due to rate-limiting


    Ergebnis: Bild und Ton.....


    Abschliessend glaube ich dass ich einen Schritt weiter bin, aber noch nicht ganz am Ende.....
    lG Tom

  • Ich darf noch eine Beobachtung mitteilen:


    Mit den vorigen Erkenntnissen (und nach einer Zigarette) hab ich die Pause (jetzt "sleep 15") vor dem "exec $DAEMON" wieder hinzugefügt (die hatte ich vorher entfernt, damit es wieder "richtig" = im Originalzustand ist).


    MIT der Pause vor dem Exec passiert folgendes:


    im dmesg


    im syslog


    am TV : Nach einigen Sekunden (theoretisch 15) kommt der Statusschirm vom VDR mit "no Signal" als Hintergrundbild und dem zuletzt eingestelltem Kanal. Nachdem die Statusanzeige sich weg blendet, kommt ganz kurz darauf die Meldung "attached /dev/dvb/adapter0/frontend0"....


    Wenn ich jetzt alles gelesene summiere, bleibt für mich übrig dass der VDR auslöst dass die Karte abgegriffen wird, dann die udev-Regel zieht ,was allerdings zu spät ist, da der VDR-Prozess schon läuft und der VDR nicht mitkriegt dass der Frontend mittlerweile initialisiert hat. Einen Kanal <rauf> und <runter> hab ich jedes mal probiert um zu sehen ob das was behebt (manchmal - früher mal - musste man das ab und zu machen um "wieder" ein Bild zu bekommen).


    Das udev erst zieht wenn VDR auf die Karte zugreifen will ist mir erst mal unlogisch, aber vielleicht hat ja jemand eine Antwort auf dieses (für mich) Rätsel 8)
    lG Tom

  • Moin!


    • Wir müssen erst einmal herausfinden, wie man die Karte ohne Start des vdr so initialisiert, damit der vdr sofort damit umgehen kann. Vielleicht klappt es mit irgend einem dvb-Tool (Paket dvb-apps oder so).
      Also vdr-Start deaktivieren und mit frischem Reboot testen, wie man den Firmwareload auslöst und abwartet, bis er fertig ist.
    • Wenn wir einen zuverlässigen Weg gefunden haben, wird der in einen Upstart-Job mit der Bedingung "on starting vdr" gepackt.


    Und dann sollte alles funktionieren... :)


    Leider kann ich bei dem Herausfinden der richtigen Initialisierung nicht helfen, da ich das Teil nicht hier habe.


    EDIT: Die Suche nach "ds3000_firmware_ondemand" liefert drei Seiten Ergebnisse. Das ist eine überschaubare Menge an Beiträgen, einfach mal durchlesen, vielleicht findest du was. Was anderes könnte ich jetzt auch nicht tun.
    Ich mache es nur, wenn du nicht lesen kannst. :)


    Lars.

  • ich danke herzlichst - bin gerade auf dem Alternativweg auf den seahawk1986 verwiesen hat.
    Allerdings ist der beschriebene Lösungsweg (aus meiner Sicht) sehr rudimentär. Jedenfalls bin ich am durchackern von den diversen Beschreibungen um diese simple Zeile in etwas "lauffähiges" zu übersetzen

    Code
    1. svdrpsend dynamite FDTD


    heißt übersetzt

    Code
    1. svdrpsend -p 6419 plug dynamite FDTD /dev/dvb/adapter0/frontend0


    für wissende zum schmunzeln - für nicht soooo wissende zum heulen ;D


    meine bisherigen Tests (!) damit waren sehr vielversprechend. Den Hinweis "detached ...." hatte ich ja schon und den Hinweis auf ein Script dass dabei ausgeführt werden kann hab ich auch schon gefunden .... 8)


    Aktuell kann es sich nur noch um Sekunden handeln bis die Hütte lauffähig wird - allerdings werden wir erst am Ende wissen wieviele Sekunden es tatsächlich waren (10 ? 100 ? 3600 ? .....) :D


    Ich danke jedenfalls für die Anteilnahme und darf weiter berichten.


    lG Tom

  • hallo alle,


    mittlerweile funktioniert es.
    Mal vorerst, denn ich muss noch ergründen was genau dazu geführt hat und wie man die Zeit noch optimal runter bringt....
    Aktuell ist:

    • die udev-Regel entfernt
    • in der /var/lib/vdr/setup.conf die Zeilen dynamite.DefaultGetTSTimeout = 10 und dynamite.GetTSTimeoutHandler = /usr/share/vdr-plugin-dynamite/kick.sh
    • der sleep 15 vor exec $DAEMON .... draußen (/etc/init/vdr.conf)
    • in der Datei /var/lib/vdr/plugins/plugin.dynamite.conf die Zeile mit --attach-hook=/usr/share/vdr-plugin-dynamite/attach-hook aktiviert

    aus welchen Grund auch immer wird nicht das kick.sh-Script aufgerufen, sondern lt. log das in der plugin.conf (/usr/share/vdr-plugin-dynamite/attach-hook)
    zumindest steht es so im Log



    Wie auch immer - momentan funktioniert es und ich werd das morgen noch ergründen - für heute sag ich mal ein beherztes "Gute Nacht Welt" und vertschüß mich :]

  • habe ähnliche Probleme mit ner Tevi 471.
    ich lasse einfach beim Systemstart der vdr "neustarten"


    in /etc/init eine restart.conf erstellen mit folgenden Einträgen:


    #VDR Restart
    description "VDR beim Systemstart restart"


    start on ((started vdr and stopped openbox-tools) or vdr-frontend-restart or resume)
    stop on stopping vdr or suspend or stopping openbox



    script
    exec restart vdr
    end script



    habe die Einträge (start on ... und stop on ... einfach aus anderen .conf Dateien kopiert.
    Das ist vieleicht nicht die eleganteste Lösung aber funktioniert bei mir.

    Easyvdr 1.0 - MSI H61M-P25 (B3) - Core i3 2120T - CineS2 v6
    yaVDR 0.4 - Zotac Synergy Ion G-E - Skystar USB HD - TT S2-3600

  • Moin!


    Die dynamite-Einträge aus der setup.conf würde ich entfernen und auch in die plugin.dynamite.conf übertragen, dann hast du die gesamte Konfiguration an einer Stelle. Könnte übersichtlicher sein.
    Der De-/Attach-Hook wird immer vor dem GetTSTimeoutHandler aufgerufen. Da ich nicht genau weiß, was die beiden bei dir tun, ist es eventuell wichtig.
    Das Log sagt übrigens, dass beide Scripte aufgerufen werden.


    Der Inhalt der beiden Scripte wäre evtl. interessant. :)


    Lars.

  • Vielleicht noch kurz zu Erklärung:


    Die Firmware wird OnDemand geladen, das heisst beim ersten Zugriff auf das Device-File (welches und wie genau ist evtl noch unklar)
    Die Firmware kann nicht geladen werden wenn das Gerät im Zugriff ist.


    Klingt schizophren ? Ja! Ist aber leider so umgesetzt worden.


    , ENV{dynamite_attach_delay}="10" \ - es wird nach ersten Zugriff (wenn er erfolgt) noch x Sekunden gewartet
    , ENV{dynamite_attach_delay_preopen}="yes" - es erfolgt ein erster Zugriff auf das Gerät


    Wie gesagt - es muss vielleicht noch geschaut werden, welcher Zugriff erfolgen muss um das Laden zu triggern.


    Der Vorteil hier wäre, wir diese udev-rule übernehmen könnten, da nur dies nur bei diesem Gerät aktiv wird - wenn es auch für andere gilt kann man hier entsprechend erweitern.

  • ich darf berichten.
    wie von mini73 vorgeschlagen hab ich die Einträge nach /etc/vdr/plugins/plugin.dynamite.conf verschoben

    Code
    1. #
    2. # Command line parameters for vdr-plugin-dynamite
    3. #
    4. # For more details see:
    5. # - /usr/share/doc/vdr-plugin-dynamite/README
    6. --attach-hook=/usr/share/vdr-plugin-dynamite/attach-hook
    7. dynamite.DefaultGetTSTimeout = 5
    8. dynamite.GetTSTimeoutHandler = /usr/share/vdr-plugin-dynamite/kick.sh


    kick.sh

    Code
    1. [....]
    2. svdrpsend -p 6419 plug dynamite FDTD $device
    3. sleep 2
    4. svdrpsend -p 6419 plug dynamite ATTD $device
    5. [....]


    attach-hook

    Code
    1. [....]
    2. # timer conflict check
    3. svdrpsend -p 6419 plug dynamite FDTD $device
    4. sleep 2
    5. svdrpsend -p 6419 plug dynamite ATTD $device
    6. [....]


    Ergebnis


    kein Aufruf von - kein Bild


    Die eine Zeile kann dynamite: device '/dev/dvb/adapter0/frontend0' not found ich mir ja noch erklären (eventuell), aber die zweite dynamite: can't attach '/dev/dvb/adapter0/frontend0' darf ich als Cool deklarieren. Warum ? In der Console geht es jedesmal (auch als User "vdr"), aber nicht aus dem Script heraus.....
    Aus meiner Sicht wird allerdings nicht das "attach-hook" aufgerufen (Override durch .config ?). Es steht zwar dynamite-attach-hook: attaching '/dev/dvb/adapter0/frontend0', aber es gibt keine "logger" Ausgaben die im Script hinterlegt sind....


    Nachdem ich es wieder zurück gebaut habe auf die letzte funktionierende, lass ich es mal so - bzw. werd ich noch kurz den Vorschlag von Killerken ausprobieren. Klingt vielversprechend....


    lG Tom

  • Ende der Geschichte : Lösung von Killerken geht astrein - vor allem bleiben die 10 Sek. erspart die der udev als Timeout hätte....
    Den Rest lass ich jedoch so, da mit dynamite (sensationell das Teil !!!) das Hotplug für dvb geht - von daher fast schon traumhaft in der Kombination der beiden Lösungen.....


    Als Abschluß darf ich mich noch bedanken bei allen die hier beigetragen haben und bei allen die im allgemeinen zu (ya)VDR beigetragen haben. :tup

  • Moin!


    Code
    1. #
    2. # Command line parameters for vdr-plugin-dynamite
    3. #
    4. # For more details see:
    5. # - /usr/share/doc/vdr-plugin-dynamite/README
    6. --attach-hook=/usr/share/vdr-plugin-dynamite/attach-hook
    7. dynamite.DefaultGetTSTimeout = 5
    8. dynamite.GetTSTimeoutHandler = /usr/share/vdr-plugin-dynamite/kick.sh


    Ok, ich hätte mich genauer ausdrücken sollen. Die Einträgen müssen natürlich "übersetzt" werden in die Kommandozeilenparameter (siehe README, Zeile 214ff)

    Code
    1. #
    2. # Command line parameters for vdr-plugin-dynamite
    3. #
    4. # For more details see:
    5. # - /usr/share/doc/vdr-plugin-dynamite/README
    6. --attach-hook=/usr/share/vdr-plugin-dynamite/attach-hook
    7. --GetTSTimeout=5
    8. --GetTSTimeoutHandler=/usr/share/vdr-plugin-dynamite/kick.sh


    Ich denke, es ist keine gute Idee, im attach-hook das Gerät wieder zu detachen und neu zu attachen - das müsste eigentlich eine Endlosschleife auslösen. Da du aber nicht das ganze Script zeigst, weiß ich nicht, was da so an Abbruchbedingungen drin steht.
    Das sollte also aus dem attach-hook raus, dafür ist der nicht geeignet. Der ist dafür da, andere Aktionen auszulösen, wenn ein Gerät hinzukommt oder entfernt wird, wie z.B. einen Timer-Konflikt-Check o.ä.


    Die Lösung von killerken sieht interessant aus, ob die Upstart-Start/Stop-Bedingungen so passen, muss man ausprobieren. Da mag es evtl. Fälle geben, wo das an einer Stelle zu einem Neustart führt, wo man eigentlich keinen wollte. Aber es kann auch alles klappen, ich weiß es nicht. :)


    Am besten wäre natürlich, wenn der Treiber nicht so anfällig wäre...


    Weiterhin viel Spaß mit deinem VDR!


    Lars.

  • hab die upstart Bedingung noch mal angepasst
    so sollte es passen


    start on started vdr and stopped openbox-tools

    Easyvdr 1.0 - MSI H61M-P25 (B3) - Core i3 2120T - CineS2 v6
    yaVDR 0.4 - Zotac Synergy Ion G-E - Skystar USB HD - TT S2-3600

  • Für die Lösung ohne dynamite, musste hier noch ein sleep 10 in das (RE-)Startscript:



    Ohne sleep kam der VDR hoch und zeigte Signalrate an, gab aber kein Bild (per vdr-sxfe) aus.


    Vielen Dank für die Lösung!

    Asus ION - Skystar HD PCI - Sundtek - yaVDR 0.6
    Zotac ION - Terratec USB-S2 - Yavdr 0.6
    Goflex Home - Debian Wheezy mit VDR, ISC-DHCP, TFTPD-HPA, NFS, SAMBA ...