Posts by tom-at-lp

    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

    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

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

    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

    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

    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

    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

    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

    Na Spitze - ob im Original "src" oder "srv" dortsteht kann ich leider auch nicht (aktuell) bestätigen. Die Pfade zeigen bei mir von jeher auf andere Ziele (jeweils NFS-Verzeichnisse).


    Was ich "generell" festgestellt habe: Wo Mencoder verwendet wird, geht die Umwandlung nicht. Bin aber dran mit den Optionen von Mencoder zu spielen.


    Hab mittlerweile an die 30 Aufnahmen umgewandelt und bis jetzt kein Problem festgestellt.


    lG Tom

    so - umwandeln ist fertig - allerdings offensichtlich anders als bei Dir:

    Quote

    Oct 17 20:20:29 vdr02 logger: Starte <ffmpeg -f mpeg -i /var/lib/video/%Die_Königin_der_Verdammten/2010-10-16.22.08.10-0.rec/00001.ts -cropleft 0 -cropright 0 -croptop 0 -cropbottom 0 -y -deinterlace -vcodec libxvid -s 640x480 -b 1400K -acodec libmp3lame -ar 44100 -ab 128K "/daten/video/NEU/Die_K_nigin_der_Verdammten.avi">Oct 17 20:20:30 vdr02 logger: Exit <rc:1><ffmpeg -f mpeg -i /var/lib/video/%Die_Königin_der_Verdammten/2010-10-16.22.08.10-0.rec/00001.ts -cropleft 0 -cropright 0 -croptop 0 -cropbottom 0 -y -deinterlace -vcodec libxvid -s 640x480 -b 1400K -acodec libmp3lame -ar 44100 -ab 128K "/daten/video/NEU/Die_K_nigin_der_Verdammten.avi">Oct 17 20:20:30 vdr02 logger: Erstellung von /daten/video/NEU/Die_K_nigin_der_Verdammten.avi fehlgeschlagenOct 17 20:20:30 vdr02 logger: ERROR <queue/yac_queue_1287338628.sh.run /var/lib/video/%Die_Königin_der_Verdammten/2010-10-16.22.08.10-0.rec>Oct 17 20:20:31 vdr02 logger: YACOTO Status: Konvertierung laeuftOct 17 20:20:37 vdr02 logger: vdr_status PLUG bgprocess yacoto PROCESS 1287339626 101 Error converting Die_K_nigin_der_Verdammten


    Wie sieht Deine yacoto.conf aus ? und die conf/divx_ffmpeg.conf (falls Du mit ffmpeg umwandelst).


    MEIN Problem konnte ich wie folgt identifizieren: Hab den Befehl aus dem Log rauskopiert und in in eine "echte" Kommandozeile umgewandelt (Zeit weg; Meldungen weg). Den Befehl hab ich dann direkt in der Konsole gestartet und kam zu folgendem Fehler:



    Hab mit dann so lange mit den Optionen gespielt, bis das offensichtlich zu Tage kam. Das Script "divx_ffmepg" verwendet als Parameter "-f mpeg" was im Zusammenhang mit einem .TS scheinbar ned das ware ist (warum wohl:) ). Hab den "force Mpeg" (also "-f mpeg") beim Script yac_enc_ffmpeg.sh in Zeile 22 entfernt und beide (VDR / TS) Umwandlungen nochmal gestartet. Hat bei mir geholfen....


    Eventuell hilft Dir mein Vorgehen bei Deiner Fehlersuche.... Grundsätzlich funktioniert es mit TS + VDR.
    Mit ein paar Informationen mehr von Deiner Seite kann ich ev. gerne helfen.


    Was hab ich :
    yaVDR mit Updatesstand von gestern.
    vdr-plugin-yacoto_0.3.0-8yavdr1_i386.deb
    ffmpeg_0.5.1-1ubuntu1_i386.deb

    Servus Schorschl,


    da haben wir doch was gemeinsam - auch ich hab mich an das README gehalten :)


    Was mir noch so in Erinnerung ist (ist schon 2 Wochen her), waren insbesondere folgende Passagen:


    Quote

    Daraus resultiert YAC_CONF_DIR (/etc/vdr/plugins/yacoto)
    - In der darin enthaltenen yacoto.conf die Pfade anpassen (z.B. VDR_VIDEO)
    Auch die Kommentare werden ausgewertet ! (siehe weiter unten)
    - Mit ./yac_update.sh die conf Dateien erstellen (bereits vorhandene werden nicht ueberschrieben)
    - Zum Abschluss mit ./yac_setplgconf.sh das Plugin conf fiel erstellen.


    Danach ist es bei mir als Punkt "8" im Hauptmenü aufgetaucht. Hat den vielsagenden Namen "Aufnahmen umwandeln"....


    Wegen ".TS" schau ich gerade - die bis jetzt umgewandelten waren .vdr - Ergebniss kommt in Kürze (er rechnet gerade einen anderen Film in der Queue um....)


    lG Tom

    Hallo Schorschi,


    doch doch - manuell kann man die Umwandlung starten. Mir ist nur das Menügehobse bei jedem Film zu mühsam gewesen.....
    Das Plugin hat viele Umwandlungsmöglichkeiten (lediglich die mit Mencoder haben bei mir nicht funktioniert - FFMpeg geht tadellos) und die Defaulteinstellungen liegen in einer Confdatei.


    Liste der möglichen Umwandlungsziele:
    3gp,divx,divx_ffmpeg,divx_mobile,dvd,ffmpeg,h264,ipod_ffmpeg,ipod_menc,ipod_nano,mp3,mpeg2,ogg,youtube


    getestet hab ich selber nur "divx" (der nicht ging) und "divx_ffmpeg".
    Da ich alle Filme im selben Format haben will, reicht es wenn er diese Einstellungen auf alle Filme anwendet.


    lG Tom

    Nachdem ich gezwungen war mein System auf neue Beine zu stellen, wählte ich - wegen der HD-fähigkeit - yaVDR. Zu meinem Bedauern stellte ich fest, daß es keine fertige Schnitt -> Umwandeln Lösung gibt/gab.
    Früher hatte ich - wie viele andere- mit VDRConvert umgewandelt und wer den Luxus des automatischen umwandelns mal genossen hat, will es nicht mehr hergeben.


    Zur Sache: Nachdem Yacoto als "designierter" Nachfolger gehandelt wird, hab ich diesen mal installiert und ihm beigebracht wie er automatisch nach dem Schnitt die Umwandlung startet:


    im /etc/vdr/recording-hooks/R90.custom folgendes eintragen:



    Erklärung:
    anzahl zählt wieviele "/" es im Pfad gibt
    name holt den Text vor dem letzten "/" (was normalerweise der Filmname ist)
    schlußendlich schmeiß ich noch in Zeile 3 das "%" am Anfang weg - damit passt der Name für mich.
    in der 4. Zeile gehe ich ins Yacoto-Verzeichnis und rufe yac_start.sh mit Name + Verzeichniss auf -> Fertig


    Offen gestanden : Er rechnet gerade das 1. mal um - ob es in allen Verzeichniskonstellationen passt muss ich mir selbst erst anschauen :)


    Wers brauchen kann : viel Spass damit....
    :portal1

    falls es andere interresiert :


    Ich hab mein Problem gelöst.


    Testhalber hab ich die gesamte Installation auf 'testing' (1.3.49) ausprobiert. -> the same...
    Also zurück zu 1.4.3....


    Während des herumprobierens ist mir allerdings aufgefallen, dass bei einem Aufruf von VDR in der Kommandozeile mit nur 2 Plugins die Aufnahmen inkl. normalen Ton funktionierte !!!


    Also musste es ein Plugin sein (Mist : Die ganze Arbeit umsonst :heuldoch )


    Mit dieser Liste funktioniert es mitterweile (Aufnahmen + DVD mit normalem Sound):


    trayopen
    osdpip
    sudoku
    pilot
    vompserver
    games
    spider
    image
    dvd
    recstatus
    yaepg
    autotimeredit
    mp3
    autosort
    nordlichtsepg
    tvonscreen
    sysinfo
    femon
    screenshot
    osdteletext
    timeline
    vdrcd
    vdrrip
    burn
    freecell
    solitaire
    epgsearch
    pim
    streamdev-server
    vcd
    dvdselect
    skinsoppalusikka
    remote
    skinelchi


    mehr brauch ich nicht (ausser Mplayer, aber das wird ein eigener Thread :lachen2 ) und es funkt astrein. Den einen oder anderen kleineren hab ich zwar ausprobiert, aber nicht gebraucht (z.B.: submenu - zäh...).


    Ich schätze es liegt irgendwo bei pvr oder softdevice... Vielleicht find ich´s noch ....
    Jetzt genisse ich mal den jetzigen Zustand.


    Ach ja, noch was : :respekt

    servus DonUlfo,


    yup - sowohl mit a52dec und ac3dec herumgespielt. Erst musste ich mal draufkommen das ich "-6" weglassen muss um es auf normalen 2.1-Boxen hören kann, aber dann hats tadellos geklappt.


    Parameter : yup; im /etc/default/vdr die "OPTIONS="-w 60 -a '/usr/bin/a52dec' " eingetragen und mittels "ps axf | less" überprüft - ist drinnen...
    Der Aufruf ist auch im "ps axf" ersichtlich und funktioniert....


    Mittlerweile hab ich vdr_1.4.3-1ctvdr3 drauf -> the same..
    Seltsamerweise hab ich (mittlerweile ?) im Sat1 auch keinen Ton :schiel Wenn ich auf DD-2.0 umschalte, kommt er zwar wieder (via a52dec) aber normal halt nicht... ProSieben schon .... :(


    Durch den SourceCode von dvbdevice.c hab ich mich auch schon durchgekämpft (is das ewig her, als ich noch C geschrieben hatte), aber bin nicht wirklich klüger geworden. Maximal ist die Ehrfurcht vor denjenigen gestiegen, die das noch verstehen :schleim

    Quote

    Original von donulfo


    ich hab gelesen, dass dies ein bekanntes Problem ist, und man dem aus dem Weg gehen kann in dem man das LiveTV puffert...


    Brauch ich nicht :lovevdr
    Ich brauch nur umschalten (mit der Grünen Taste) auf "stereo deutsch" und schon passt wieder alles (beim Live-TV) - DAS klappt ja auch schön...
    Nur eben nicht bei den Aufnahmen (mit "stereo deutsch" oder "deu" wie dort steht...)

    servus donulfo,


    nö - wie beschrieben unter "Verkabelung" - d.h. extern über den Line-In zur Soundkarte...
    muss ich tatsächlich innen rumschrauben ?


    PS: Nachsatz so nebenbei: Mit a52dec oder ac3dec läuft das Bild und der Ton mit der Zeit auseinander - soll heißen (im Forumterminus): Lippenunsyncron. Aber eben nicht von Anfang an , sondern die 2 entfernen sich schön langsam voneinander