Beiträge von wolf_rambatz

    Moin zusammen,
    in der Hoffnung, niemanden von Euch damit zu nerven, folgende Anfrage:
    Mein VDR von 2003 (!) (Standalone-System auf der Basis des damaligen c't-Bauvorschlags) funktioniert zwar immer noch (es gab in der ganzen Zeit lediglich ein Festplattenupgrade), ruckelt aber ordentlich beim Abspielen von Aufnahmen (außerdem natürlich keine HD-Qualität möglich, da eine damals erworbene FF-Karte von Hauppauge eingebaut ist).
    Jetzt möchte ich mir ein aktuelles System zusammenstellen, habe mich aber in den letzten Jahren nicht mehr wirklich um das Thema VDR gekümmert (außer immer schön Tobis Pakete upzudaten).
    Bitte empfehlt mir Eure Wunsch-Hardware, die folgende Eigenschaften haben soll:

    • DVB-T(2?) und DVB-C-Empfang, HD-Qualität (mehr wird nicht benötigt) -> dafür wichtig: welche Karten bzw. Sticks empfehlt für diese Zwecke empfehlt Ihr mir!
    • Ausgabe über HDMI
    • Aufnehmen und Abspielen (also wieder Standalone-System)
    • Leise, am besten ohne Lüfter
    • Wakeup-Funktion für die Aufnahmen

    Viele Grüße


    Wolf

    Zitat

    Denk bitte auch dran, dass DVB-T und DVB-C nicht gleichzeitig möglich sind. Du musst Dich vor dem vdr-Start entscheiden, welche Empfangsart Du haben willst.


    Wieso? Habe ich bis 2008 mit einer Nova-T und einer FF-DVB-C-Karte immer so gemacht (mir halt die benötigten Kanäle in die channels.conf geschrieben).


    Gruß


    Wolf


    Hallo marpiet, hatte ich auch erst so. Standard muss aber nach wie vor iso-8859-15 sein.


    Gruß,


    Wolf

    Hallo Tobi,


    laufen dann für ein Weilchen vdr und vdrdevel mit 1.5.x-Versionen parallel (wie das seinerzeit mit 1.3.x der Fall war)? Hast Du entsprechende Absprachen mit Tom?!


    Außerdem wäre natürlich interessant, die wichtigsten Änderungen von 1.5.x gegenüber 1.4.x vor allem im Bereich der Konfiguration zu dokumentieren (lade zwar immer fleißig vdrdevel, habe mich aber kaum damit beschäftigt)


    Gruß,


    Wolf

    Hi notwhy,

    Zitat

    Original von notwhy
    Dank vieler bastelei und motivation die letzten Tage kann ich sagen:
    wenn mit xinit -e vdr-sxfe -f xvdr:tcp://localhost ein Bild auf dem Monitor ist, dann ist auch über vdradmi ein bild zu sehen.
    Da ich aber sonst noch null ahnung von linux habe eine Frage an dich.
    Ich habe ein System mit 2 Buget und ein System mit einer TTFF, wenn ich dein PS richtig interpretiere sollte es möglich sein über tcp die TTFF als Ausgabedevice für mein Budgetsystem zu nutzen ?


    Danke für die Info: damit sollten sich die meisten 'vdradmin-Fernseher-Probleme' erledigt haben.
    Zu Deiner Frage:
    Ja, das ist möglich: als einfachste Lösung nimmst Du einfach den Rechner mit der TTFF als Streamdev-Client für den Rechner mit den beiden Budget-Karten (als Streamdev-Server).
    Es gäbe auch die Möglichkeit, die Ausgabe des X-Clients von dem Rechner mit den beiden Budget-Karten (mit laufendem xine-Plugin) auf den Rechner mit der TTFF umzulenken. Damit hättest Du aber einigen Konfigurationsaufwand und: ob der sich lohnt z. B. aus Sicht der Performance weiß ich nicht.


    Gruß,


    Wolf

    Soweit mir bekannt, setzt der 'Fernseher' in vdradmin eine Full-Featured-Karte voraus. Mit dem xine-Plugin wirst Du wohl nichts werden X(
    Gruß,


    Wolf


    PS: Davon abgesehen, hing das ganze noch damit zusammen, dass der 'Fernseher' das Bild vom eigentlich überholten Device /dev/video0 abgreift. Man muss also irgendwie hinbekommen, die mpeg2-Ausgabe zu diesem Device zu erklären. Bei einer FF-Karte musste ich dazu nur mit einem Skript das Original /dev/video0 löschen und dann einen symbolischen Link mit diesem Namen auf das entsprechende Device setzen. Aber ohne FF-Karte, ... ?

    Schön, dass dieses Problem auch hier jemand mitbekommt ;)


    Nachdem meine Recherchen bis jetzt nur ergeben hatten, dass auch viele andere Debian-Nutzer nach dem Umstieg auf Etch das gleiche Problem haben (ohne es gelöst zu haben), bin ich zu LILO zurückgekehrt.


    Irgendwie hat sich der Mechanismus von grub geändert: grub verwendet jetzt eine Datei "default" in /boot/grub. In meinem Fall kann da aber stehen, was will (sowohl mit grub-set-default als auch manuell probiert); grub (re)bootet immer den Kernel, der in der Liste zuerst steht. Ich gebe aber zu, dass ich den Mechanismus nicht 100%ig verstanden habe.


    So wie es im offiziellen Manual beschrieben wird, klappt es jedenfalls nicht. Bin gespannt, ob sich hier eine nachvollziehbare Lösung ergibt.


    Gruß,


    Wolf

    Ich finde, epgsearch funktioniert perfekt!


    Hast Du http://vdr-portal.de/board/thread.php?threadid=56918 gelesen?


    Zu Deinem Problem fällt mir nur ein: Australien ist ein sehr 'unscharfer' Suchbegriff. Wenn Du diesen verwendest, dann solltest Du diesen nur für den Titel verwenden, und den Suchmodus 'ein Wort' oder 'exakt' nehmen.


    Manuelles Löschen von Timern, die epgsearch erzeugt hat, bringt natürlich nichts, also möglichst klare Suchen bzw. Autotimer formulieren.


    Wenn Dir das alles nicht liegt: *noch* würde es ja auch mit den alten Autotimern gehen; die hast Du aber genau wie ich vermutlich in der Config deaktiviert; jetzt tauchen diese in der Config nicht mehr auf.
    Irgend jemand weiß bestimmt, was in der vdradmin.conf eingefügt werden muss, damit die alten Autotimer wieder aktiviert werden?!


    Gruß


    Wolf

    Kann mich bcr nur anschließen:


    Einprügeln auf den ctvdr ist unfair: immerhin bekommen auch Linux-Unerfahrene ein Videorecorder-Paket, das von den Grundfunktionen her in den allermeisten Fällen läuft.
    Natürlich wird die Sache schnell zur Bastelkiste, aber das ist ja auch intendiert. Wer es dann wirklich wissen will, stellt sowieso auf Tobis Repository um und liest hier eifrig mit ... und emanzipiert sich auf diese Weise ja auch schnell von dem ursprünglichen ctvdr.


    Für mich (seit 2003 ctvdr-User) der entscheidende Vorteil gegenüber anderen Distributionen/Lösungen:

    • Upgraden ist denkbar einfach, vor allem durch den unermüdlichen Einsatz von Tobi, TomG und anderen ... die Kompilierungs- und Konfigurations-Orgien, die man ohne Distribution z. B. bei der Verwendung eines Standard-Linux wie SuSE eingeht, können entfallen ...
    • Im Vergleich zu anderen Distris wie Linvdr werden recht viele Plugins und Addons mitgeliefert ...
    • Die von der ct bzw. Peter Siering gelieferten Kernel sind klasse und lindern so den Ärger, der sich bei dem einen oder anderen nicht ganz zu Ende gedachten ergibt ...


    Gruß,


    Wolf

    Hallo,


    nachdem uns Tobi mit vdr-Version 4.3/DMH-Archive-Patch und dem erneuerten Burn-Plugin beglückt hat (vielen Dank insbesondere an ihn und an den Burn-Plugin-Weiterentwickler Lord J.), macht die Benutzung des Burn-Plugins jetzt richtig Spaß ud die Ergebnisse sind auch super (u. a. dank der gelungenen Integration projectX).


    Besonders interessant sind für mich aber die Vorteile, die die neuen DMH-Archiv-DVDs bringen sollen. Allerdings fehlen mir Doku (und eigene Ideen): was mache ich nach dem Erstellen der DVD genau d. h. was darf/soll gelöscht werden (vermutlich die 0xx.vdr-Dateien und ...), und wie mache ich das ganze Couch-Potato-kompatibel d. h. integriere es in die commands.conf oder reccommands.conf.


    Gruß,


    Wolf

    Hi,


    seitdem ich vdrdevel 1.3.36 habe, habe ich einige Problem mit vdrconvert:


    Zunächst mal fuhr der vdr nicht mehr herunter (wurde hier ja behandelt -> Fehler im Shutdown-Hook von vdrconvert), dann startete keines der Konvertierungsskripte mehr (gleichlautender Fehler in der status.sh).


    Nachdem ich Änderungen gemäß den hier geposteten Empfehlungen vorgenommen habe (ps -aef durch ps -ae ersetzt), startet vdr2dvd.sh (nach dem Drücken von "konvertierung starten") aber immer noch nicht; manchmal dann allerdings dirtekt nach einem restart von vdrdevel.


    Hat jemand eine Peilung, was da los sein könnte bzw. wie die Sache wieder zum normalen Laufen gebracht wird. Um es gleich vorweg zu nehmen:
    Ja, ich benutze auch das Burn-Plugin und finde es auch sehr gelungen, v. a. von der Bedieneroberfläche her, aber mir fehlt ein Feature: das Verwenden von Screenshots aus dem jeweiligen Film als Hintergrundbilder - vielleicht kommt das ja noch, Sascha ;)


    Grüße,


    Wolf

    Hi,


    evtl. muss /dev/nvram erst einmal erzeugt werden - bei mir fehlt dieses device jedenfalls nach jedem reboot (MSI Hermes).
    Also mal ausprobieren, on /dev/nvram existiert ...
    Wenn nicht, wird eine Datei, nennen wir sie mal create_dev_nvram, im Verzeichnis /etc/init.d erzeugt. Inhalt:



    Danach mit chmod 755 /etc/init.d/create_dev_nvram ausführbar machen und mit update-rc.d create_dev_nvram defaults "scharf schalten".


    Sonst war das Specialshutdown noch in /etc/defaults/vdrdevel zu ändern:


    Code
    ...
    SHUTDOWNCMD="etc/init.d/vdrdevel stop; sleep 1; echo y|grub-reboot 2 --no-floppy"
    ...


    Vosricht mit der 2: diese muss der Nummerierung in Deiner menu.lst entsprechen (also dem dritten Eintrag, da von 0 aus gezählt wird).


    Mehr fällt mir auch nicht ein bzw. den Rest hat ggsm beschrieben. Viel Erfolg!


    Wolf

    Hi,


    Gelöst aber nur in Bezug auf den mplayer (immerhin ;) )
    Für das grab-Kommando von vdr und die Anwendungen desselben ('Fernseher'/vdradmin, screenshot-Plugin, Screenshots von vdrconvert) ändert sich erst einmal nichts, da der vdr einige wichtige Funktionen nur auf dem ersten Video-Device /dev/video0 vorhält. Umstecken hilft aber nichts: der Kernel registriert von sich aus erst die Budget- und danach die FF-Karte.


    Deshalb habe ich einen Trick verwendet (ctvdr):


    Device /dev/video0 verschieben:


    Code
    mv /dev/video0 /dev/video0.not_in_use


    Device /dev/video1 verlinken auf /dev/video0


    Code
    ln -s /dev/video1 /dev/video0


    Das ganze muss bei jedem Systemstart passieren also in einer Datei im Verzeichnis /etc/init.d/ stehen. Dafür kann z. B. das dort vorhandene skeleton verwendet, unter einem neuen Namen gespeichert und mit dem Programm update-rc.d verlinkt werden.


    Grüße,


    Wolf