Posts by TomG

    Hi Hannes!


    Ich hatte schon vor ein paar Wochen eine entsprechend korrigierte Version des Init-Scripts an Peter und Tobias geschickt. Ist aber leider bisher nicht in die aktuelle Version eingeflossen.


    Quote

    1. finde ich immer nett, wenn bei Konfigurationsdateien, die automatisch erstellt werden und nicht veraendert werden sollen (weil eh ueberschrieben wird) dies auch in einem Kommentar am Anfang vermerkt wird. (Betrifft auch reccmds).


    Der Vorschlag gefällt mir. Würde einiges klarer machen. Und eventuell die Zahl der Fragen danach hier im Forum verringern.


    Tom

    Hi Stephan!


    Dein Ansatz ist so ziemlich der gleiche wie bei mir. Folgende Unterschiede sehe ich:

    • Bei dir wird schon vor Erreichen der Marke gesprungen.
    • Es wird nicht verhindert, dass nach Setzen oder Anspringen einer Marke gleich zur nächsten gesprungen wird.
    • Dein Parameter FuzzyJump ist bei mir nicht über das Setup einstellbar. Ich sehe auch keinen Sinn darin.
      Die Größe des Parameters habe ich so bestimmt: In der Dokumentation steht, dass ProcessKey zumindest ungefähr einmal pro Sekunde aufgerufen wird. Zur Sicherheit habe ich den Wert noch verdreifacht.
      Den Parameter zu klein zu wählen, macht keinen Sinn, denn dann springt er wieder nur zufällig. Und wenn man das Problem mit dem Weiterspringen beim Setzen oder Anspringen einer Marke gelöst hat (siehe oben), dann ist es auch kein Problem, den Wert etwas großzügiger zu bemessen.
    • Der Test, ob Anfangsmarke oder Endmarke, kann einfacher über die Indexnummer erfolgen (wie bei EditTest - Taste "8").


    Ich will dich aber jetzt nicht entmutigen. Als Einstieg in die VDR-Quellen finde ich das Programmieren so eines kleinen Patches sehr sinnvoll.


    Quote

    habe zwar nicht den JumpPlay Patch eingesetzt (wg Komplettpatch-E)


    In den Komplett-Patch wird er wohl demnächst eingebaut.


    Viele Grüße, Tom

    Hi Torsten!


    Quote

    Original von Torsten/WarEagle
    Hast du den irgendwo auf einer HP liegen? Wenn nicht würde ich den bei mir einfach austauschen bzw. einen Link auf diesen Thread als aktuelle Version draufpacken.


    Eine extra Web-Seite für den kleinen Patch wollte ich nicht einrichten. Ich denke, in deiner Patch-Sammlung ist er gut aufgehoben, wenn du ihn übernehmen willst.


    Tom

    Hi Stephan!


    Quote

    Schnittmarken sollen eben auch bei NICHT sichtbarem Fortschritt übersprungen werden.


    Genau das macht der überarbeitete JumpPlay-Patch.


    Quote

    Könnte mir jemand die Stelle (Methode reciht) nennen, wo ich eingreifen muss ?
    Es ist doch sicher im vdr.c irgendwo....


    Nicht in vdr.c, sondern in menu.c: cReplayControl::ProcessKey
    Aber die Sache ist nicht ganz so einfach, da man verhindern muss, dass nach Setzen oder Anspringen einer Marke gleich zur nächsten gesprungen wird.


    Tom

    Hi Pit!


    Auch wenn wir beide die einzigen zu sein scheinen, die JumpPlay gut finden ;(, habe ich nochmal ein paar Kleinigkeiten verbessert:
    [list=1]
    [*]Im Play&Jump-Modus habe ich das Beenden des Abspielens an der letzten Marke in Ordnung gebracht:
    menu.c cReplayControl::ProcessKey

    [*]Die Anzeige der Position erfolgt normalerweise mit Minute und Sekunde ohne Frames. Nur beim Positionieren und Anspringen von Marken wird die genaue Position inklusive Frames angezeigt. Das klappt in einigen Fällen nicht richtig (auch schon im ungepatchten vdr-1.2.6).
    Zum Beispiel wenn man vor der ersten Marke mit "7" zurückspringen will, dann wird die Aufnahme weiter abgespielt, aber mit eingeblendeten Frames. Und beim Setzen von Marken im Pause-Modus werden die Frames nicht angezeigt.
    menu.c cReplayControl::MarkToggle

    und cReplayControl::MarkJump

    [/list=1]
    In Zusammenhang mit der Frames-Anzeige ist mir noch ein Bug aufgefallen, der aber nur mit Elchi und ImprovedOSD auftritt. Springt man eine Marke an und drückt dann z.B. auf Play, dann wird unten links kurz ein Rechteck eingeblendet.
    Folgende Änderung in cReplayControl::ProcessKey von menu.c behebt diesen Bug:

    Code
    }
       if (DoShowMode)
          ShowMode();
    -  if (DisplayedFrames && !displayFrames)
    -     Interface->Fill(0, 2, 11, 1, clrBackground);
       return osContinue;
     }

    Diese Änderung ist nicht mit in der diff-Datei, da der Bug nur mit Elchi und ImprovedOSD auftritt.


    Tom

    Hi

    Aktuelle Version: vdr-jumpplay-0.3-1.2.6.diff.gz:
    http://www.vdrportal.de/board/attachment.php?attachmentid=1821&sid=


    Vor allem in Zusammenhang mit den automatisch von noad gesetzten Schnittmarken, die in vielen Fällen sehr gut sind (Great job, theNoad!), ist es einfach komfortabel, dass der Film beim Sprung zur nächsten Marke nach der Werbung gleich weiter läuft (Jump&Play). Noch komfortabler ist die zweite Funktion des Patches, beim Abspielen die Werbung einfach zu überspringen, ohne dass man irgendeine Taste drücken muss (Play&Jump).


    Leider hat der bisherige JumpPlay-Patch von http://vdr.sjur.de/ eine Reihe von Problemen, die teilweise auch schon hier im Forum angesprochen wurden:

    • Das Löschen einer Schnittmarke wird nicht abgespeichert.
    • Beim Sprung zur nächsten Schnittmarke wird die Geschwindigkeit beibehalten (selbst beim schnellen Rücklauf).
    • Überspringen des Films statt der Werbung.
    • Überspringen der Werbung klappt nicht immer.
    • Nach manuellem Sprung zur Schnittmarke springt man manchmal gleich eine Schnittmarke weiter.
    • Überspringen ist nur aktiv, wenn die Fortschrittsanzeige sichtbar ist.


    Der überarbeitete Patch behebt diese Probleme. Er beruht auf einem ungepatchten vdr-1.2.6. Die Anwendung nach Elchi oder AutoPID bedarf manueller Nacharbeit (aber alles überschaubar).


    Dass das Überspringen der Werbung nur bei sichtbarer Fortschrittsanzeige funktionierte, war evtl. genau so vorgesehen. Denn um die Schnittmarken vor dem Schneiden zu kontrollieren, wird man die Fortschrittsanzeige sowieso an haben. Aber wenn man sich eine Sendung nur einmal ansehen will, ohne sie erst zu schneiden, dann ist es unschön, die Fortschrittsanzeige immer im Bild haben zu müssen, damit die Werbepausen übersprungen werden.


    Um den alten Modus zu erhalten habe ich die Einstellmöglichkeiten für Play&Jump erweitert: nein / ja / nur bei Anzeige. Vielleicht sagt ihr mal eure Meinung dazu, ob der Modus "nur bei Anzeige" nicht ganz wegfallen kann.


    Ich hoffe, dass der Patch in seiner neuen Form mehr Leute von seiner Nützlichkeit überzeugt.
    Tom


    Nochmal überarbeiteter Patch: vdr-jumpplay-0.3-1.2.6.diff.gz (siehe unten):
    http://www.vdrportal.de/board/attachment.php?attachmentid=1821&sid=

    Quote

    Original von DVD-Master
    die einzige änderung die ich im /etc/init.d/vdr durchgeführt habe ist das ich in diesem script auch hdparm starte.


    Daran kann es eigentlich nicht liegen.


    Versuch doch mal folgendes:

    • vdr stoppen: /etc/init.d/vdr stop
    • commands.conf löschen: rm /etc/vdr/commands.conf
    • vdr wieder starten: /etc/init.d/vdr start


    Wenn der Effekt weiterhin auftritt, musst du mal nachsehen, welche Dateien mit dem Muster command.*.conf bzw. commands.*.conf (geht ein bisschen durcheinander, wie Methusalixx schon geschrieben hat) in /etc/vdr vorhanden sind. Aus diesen setzt das Init-Script beim Starten von vdr die commands.conf zusammen.


    Darum musst du auch eigene Kommandos in eine extra Datei schreiben, die nach dem obigen Muster benannt ist (zur Not 2 Dateien anlegen: command.xxx.conf und commands.xxx.conf, bzw. 1 Datei und ein Link).


    BTW: Zum Aufruf von hdparm gibt es bei Debian ein Paket hwtools. In dessen Init-Script muss man nach der Installation den hdparm-Aufruf eintragen (ist auskommentiert vorbereitet).


    Tom

    Quote

    kennt wer dieses problem?


    Nein, das Problem kenne ich nicht. Ich habe aber eine Idee, was die Ursache sein könnte. Oder eigentlich zwei.


    Meine erste Idee waren Zugriffsrechte. Aber nach ein paar Tests würde ich das eher ausschließen.


    Meine zweite Idee ist, dass die Variable "CMDS_FILE" im Init-Script geändert ist. Hast du an /etc/init.d/vdr etwas geändert bzw. in /etc/default/vdr eine Definition für "CMDS_FILE" eingefügt?


    Tom

    Hi


    Ausprobiert habe ich transfron auch und fand die Ergebnisse eigentlich sehr gut. Mit den Stolpersteinen wie Leerzeichen im Dateinamen und nicht gefundenem Zielverzeichnis kann man recht gut umgehen, wenn man es weiß.


    Besonders die Qualität der OGM-Konvertierung hat mich überzeugt. Weiß jemand, wie es mit der Verbreitung dieses Formats aussieht? Kann man OGM-Dateien auf jedem beliebigen (Windows-)PC abspielen?


    Schön wäre natürlich so ein Komfort wie beim Vdrrip-Plugin, dass man die Dateigröße vorgibt und die Bitrate automatisch ausgerechnet wird.


    Was mich aber am meisten an Transfron gestört hat, ist das Verhalten, wenn VDR neu startet, während eine Konvertierung läuft. Der Neustart blieb bei mir dann immer hängen, weil das von Transfron gestartete Konvertierungsprogramm verhinderte, dass die Treiber entladen und wieder neu geladen werden konnten.


    Es ist ja prinzipiell gut, dass die Konvertierung weiterläuft, aber dann sollten die Programme so gestartet werden, dass die Treiber-Handles (die sie sicher gar nicht brauchen) geschlossen werden.


    Tom

    Hi Olaf,


    Schön, dass es jetzt funktioniert. :]


    Leider findet sich der Tipp mit den falschen Einträgen in /etc/modules in einigen Anleitungen, hier im Forum und im Internet. Ich frage mich nur, ob die anderen, die sich danach richten (oder gar selbst geschrieben haben), nicht die gleichen Probleme haben müssten? ?(


    Quote

    Ausserdem musste ich noch evdev in die modules eintragen.


    Bei mir wird das Modul evdev nicht geladen. Ich denke, das hängt vom Kartentyp ab. Bei der Nexus-Karte wird es wohl für Remote benötigt.


    Gruß
    Tom

    Hallo Olaf


    Quote

    Welche Befehle muss ich nun wohin schreiben ???? Wenn ich z.B. eine Datei Namens "/etc/modutils/dvb-2.4.23" erstelle, woher weiss der Debian, daß es sie gibt ? ?(


    Erstmal gar nicht. Aber wenn man

    Code
    update-modules

    aufruft (hatte ich vorhin falsch geschrieben), durchsucht es das Verzeichnis /etc/modutils/ und stellt aus allem, was darin zu finden ist, eine neue moduls.conf zusammen. Das ist dann auch an Hand der Kommentare in /etc/moduls.conf zu erkennen.


    Der Inhalt der Datei /etc/modutils/dvb-2.4.23 sieht bei mir so aus:

    Code
    probeall /dev/dvb dvb-ttpci
    alias char-major-250 dvb
    alias dvb dvb-ttpci
    below dvb-ttpci stv0299


    Statt "stv0299" (für die TT 1.5) mußt du je nach DVB-Karte das entsprechende Modul eintragen (alps_bsrv2 alps_tdmb7 alps_tdlb7 grundig_29504-401 grundig_29504-491 ves1820). Die Zuordnung zwischen Modulen und DVB-Karten habe ich nicht im Kopf.


    Man kann auch mehere Module angeben (für mehrere Karten verschiedenen Typs):

    Code
    probeall /dev/dvb dvb-ttpci
    alias char-major-250 dvb
    alias dvb dvb-ttpci
    below dvb-ttpci stv0299 grundig_29504-491


    Oder man gibt gleich alle in Frage kommenden Module an, wie es im DVB-Paket vorgeschlagen wird:

    Code
    probeall /dev/dvb dvb-ttpci
    alias char-major-250 dvb
    alias dvb dvb-ttpci
    below dvb-ttpci alps_bsrv2 alps_tdmb7 alps_tdlb7
    add below dvb-ttpci grundig_29504-401 grundig_29504-491
    add below dvb-ttpci stv0299 ves1820


    Dann werden zwar immer alle Treiber-Module geladen, aber sie erkennen selbst, ob ihre Hardware da ist und sie aktiv werden müssen. Die inaktiven Module stören nicht weiter.


    Ach ja, und für deine /etc/modules müsste dann:

    Code
    usb-ohci
    input
    # usbkbd
    # keybdev
    8139too

    ausreichen.


    Gruß,
    Tom

    Hi



    In /etc/modules stehen nur Modulnamen, keine probeall- oder alias-Anweisungen:


    Code
    # /etc/modules: kernel modules to load at boot time.
    #
    # This file should contain the names of kernel modules that are
    # to be loaded at boot time, one per line.  Comments begin with


    So wie beschrieben, wird zwar der Grundig-Treiber beim Systemstart geladen, aber nicht bei einem Neustart von vdr entladen und neu geladen. Und wenn der Grundig-Treiber das Problem war, warum vdr sich beendet hat, hilft nur noch ein Systemstart.


    Damit das Entladen und Neuladen der Treiber in runvdr klappt, muss die Abhängigkeit vom Modul dvb-ttpci in /etc/modules.conf definiert sein. Und da bei Debian die modules.conf dynamisch mit update-modules erzeugt wird aus Dateien in /etc/modutils/, gehören die entsprechenden Anweisungen in eine Datei in diesem Verzeichnis, z.B. /etc/modutils/dvb-2.4.23.


    Code
    probeall /dev/dvb dvb-ttpci
    alias /dev/dvb/* /dev/dvb
    alias char-major-250 dvb-ttpci
    add below dvb-ttpci grundig_29504-491


    Man kann auch die Datei modules.conf aus linux-dvb.2003-11-08.tar.bz2 als Vorlage nehmen, so wie es das dvb-Paket der ct-Distribution macht.


    Gruß,
    Tom

    Hi


    Quote

    Original von Fledermaus
    Bei den addons sind vorne dreistellige Nummern wenn man diese ändert
    werden diese entsprechend neu im Menü angeordnet.


    ?( Bin ich der einzige, der das nicht versteht?


    Welche dreistelligen Nummern meinst du? In welcher Datei?


    Oder meinst du vielleicht die externen Kommandos in der commands.conf.


    Es geht hier aber um Plugins. Und die Diskussion ergibt auch nur einen Sinn für die ct-Distribution oder darauf aufbauende, weil dort die Plugins automatisch eingebunden werden.


    Tom

    Hi


    Mich hat das neue Design ziemlich verwirrt. Vor allem, weil die Umstellung mit meinen ersten Anpassungen des Profils zusammenfiel. Ich dachte erst, ich hätte etwas verkonfiguriert.


    Die Namensgebung des alten Style als "Blau" ist vielleicht auch etwas unglücklich. Für mich sieht der neue Style "blauer" aus.


    Ansonsten würde ich es begrüßen, wenn auf der Portal-Seite der eigentliche Inhalt (die jetzige mittlere Spalte) mehr Platz bekommen würde, z.B. indem alle anderen Kästen in nur einer Spalte links oder rechts zusammengefasst werden - wie es hier auch schon vorgeschlagen wurde. Dann müsste man auch bei kleinerer Bildschirmauflösung bzw. Fenstergröße nicht so viel hin- und herscrollen.


    Tom

    Quote

    Ich glaube das die *vdr Datein im Unterverzeichnis nicht gefunden werden.


    Zugriffsrechte? Startest du vdr als root oder als normaler User?


    Und steht in der Log-Datei keine Fehlermeldung?


    Wie gesagt, bei mir hat es - nach Beseitigung der Schwierigkeiten mit Zielverzeichnis und Leerzeichen - letztendlich funktioniert. Ich habe aber nur die Varianten XVID und OGM probiert. In den anderen Teilen könnten noch weitere Fehler sein. Das Plugin scheint mir noch nicht ganz ausgereift zu sein!?


    Eine Fehlerquelle können natürlich auch noch fehlende externe Programme sein.


    Quote

    Habe ein Gehäuse Marke Eigenbau, kann die Festplatte einfach entnehmen, beim Combi reinstecken, mit Knoppix starten, Laufwerke freigeben dass darauf geschrieben werden kann, und einfach die vdr Datein auf eine Win-Partition rüberziehen.


    Dauert bei 3,5 Giga ca 30 min, und dann unter Win umwandeln .


    Windows? 8o :rolleyes: -- Na gut, das ist natürlich auch 'ne Lösung. Leider etwas umständlicher als ein Plugin.


    Viel Erfolg,
    Tom


    PS: Es gibt auch noch das Vdrrip-Plugin und vdrconvert.

    Hi, Markus,


    Quote

    Kannst du nem Linux Neuling denn die Kommandozeile zum Patchen posten ?
    Kenne mich mit den Diffs leider noch nicht aus.


    Diff-Datei runterladen z.B. ins Verzeichnis /tmp und dann:

    Code
    cd /etc/init.d/
    patch < /tmp/vdr.init.order.diff

    Muss als root ausgeführt werden, sonst hat man keine Schreibrechte.
    Ich hänge am besten auch noch mein komplettes Init-Script als (gezippte) Datei an, falls es mit dem Patchen nicht klappt. Auspacken mit:

    Code
    gunzip vdr.gz

    Darin sind noch ein paar andere Kleinigkeiten gegenüber der ct-Version geändert. Die einzige wesentliche Änderung ist aber, dass zur Zusammenstellung der commands.conf nicht mehr nach Dateien mit dem Muster "command.*.conf", sondern "commands.*.conf" gesucht wird. So funktioniert auch die Einbindung der Kommandos des Pakets vdr-addon-vdrconvert. Damit dann das Shutdown-Kommando nicht verschwindet muss jetzt aber command.shutdownvdr.conf umbenannt werden in commands.shutdownvdr.conf.


    Quote

    PS. Das ist doch was für Alle. Können wir Tobi das nicht in die Multipatch Version Aufnehmen lassen ?


    Hab ich nichts dagegen. Sonst hätte ich's hier nicht veröffentlicht. ;)
    Tom

    Hi, Fledermaus

    Quote

    Kannst du einen Auszug einer LOG-Datei hier reinstellen.


    Okay, aber ich weiß nicht, ob es viel hilft, denn bei der DIVX-Konvertierung werden teilweise andere Programme aufgerufen, als bei SVCD.


    Geht es denn immer noch nicht?
    Was gibt es jetzt noch für ein Problem?
    Tom

    Na, immerhin kommen wir dem Ziel näher.


    Quote

    executing: transcode -i temp_source// -y mpeg2enc="-a 2 -b 2500 -n p -S 800 -B 224",mp2enc -Q 5,5 -V -Z 480x576 -F 4 -E 44100 -b 224 -o /video/hj/transcodes/@Tigerenten Club Der Club zum Mitmachen.svcd -q 0
    ---------------------------------------------
    execution failed: No such file or directory


    Eine SVCD habe ich zwar noch nicht erstellt, aber bei DIVX gab es ähnliche Probleme. Sie ließen sich umgehen, wenn man den Zieldateinamen im Menü so ändert, dass keine Leerzeichen mehr vorkommen.


    Leider enthält die Vorgabe immer Leerzeichen statt der Unterstriche (evtl. erst in neueren VDR-Versionen?) und die Aufrufe der externen Tools (transcode, mp2enc usw.) quoten die Dateinamen nicht durchgehend.


    Aber mit der expliziten Anpassung des Zieldateinamens im Menü hat es bei mir dann funktioniert.


    Quote

    Auf der Eben wo die Ordnder video+avi+system usw angelegt sind
    kann ich transcodes nicht anlegen vermutlich kein Zugriffsrecht.


    Auch nicht, wenn du als root eingeloggt bist?
    Tom

    Quote

    Original von MrDASYLab
    Habt ihr ne idee wie man die reihenfolge der plugins im menu ( taste M ) beeinflussen kann ?
    Ich benutze die ct distri.: im script /etc/init.d/vdr wird nach den plusins gesucht und die liste dann irgendwie zusammen gebastelt. Aber die reihenfolge ist nicht beeinflussbar.


    Das hat mich auch schon immer gestört. Aber sonst ist die automatische Plugin-Einbindung des ct-VDR ja sehr komfortabel. Also habe ich mich heute rangemacht und das Init-Script (/etc/init.d/vdr) so angepasst, dass es die Reihenfolge der Plugins aus einer neuen Konfigurationsdatei "order.conf" ausliest, die im Plugins-Verzeichnis liegen muss (also in /etc/vdr/plugins).


    Die Datei enthält je einen Plugin-Namen pro Zeile, also z.B.

    Code
    calendar
    timeline
    mp3
    mplayer
    vdrrip


    Die Plugins erscheinen in dieser Reihenfolge im Menü, danach kommen dann alle nicht eingetragenen Plugins. Nicht installierte Plugins werden ignoriert, so muss man die Datei nicht bei jeder Installation oder Deinstallation eines Plugins anpassen.


    Meine Änderungen am Init-Script hänge ich als Diff-Datei an.
    Tom

    Das Verzeichnis transcodes (nicht transcodecs!) liegt nicht in /video, sondern parallel dazu (".." bedeutet. übergeordnetes Verzeichnis).


    Es ist also normalerweise /transcodes, nur wenn /video ein Link ist, muss man aufpassen, dann liegt es im selben Verzeichnis wie das Ziel des Links. Wenn z.B. /video ein Link auf /mnt/hda4/video ist, dann ist /video/../transcodes das Verzeichnis /mnt/hda4/transcodes.


    Zum Anpassen des Zielverzeichnisses im Menü muss man in der Destination-Zeile die Taste "Cursor nach rechts" drücken.