Posts by MichaelB

  • werden die Gentoo ebuilds noch gepflegt?

    Quote from Zoolook

    ich weiß nicht was Jörg mittlerweile noch so gemacht hat, aber ich habe schon mal für den Eigenbedarf paar Ebuilds inklusive vdr-2.4.0 (ohne die ganzen Patches nachzuziehen) aktualisiert, auch auf github. Bin auch nicht besonders weit gekommen mit Plugins, weil ich mich bis jetzt nur um solche gekümmert habe, die sich im headless-Betrieb eignen, und auch an manchen von denen wäre noch Einiges zu tun. Meine Ebuilds und die Eclass auf die sie bauen verwenden argsdir-Konfigurationsdateien, und ich selber habe sie nur noch unter systemd getestet, nicht mehr unter OpenRC, aber ich gehe davon aus daß sie da auch funktionieren, kannst mal probieren...

    So, mittlerweile habe ich mal ausprobiert ;)


    Diese ganzen Softhddevice-Varianten sind wieder mal nur murks. Schade, dass sich die VDR-Community nicht ausnahmsweise mal auf ein repo einigen und zusammenarbeiten kann... es fehlt offenbar immer der BDFL.

    Aber deine headless-ebuilds tun mit kodi leia - wollte ich immer schon mal ausprobieren, schön mit VDPAU, ffmpeg 4.1 und nvidia 415.25 - zusammen ganz prima. Vielen Dank für die Arbeit! :thumbup:

    VG michaelb

  • werden die Gentoo ebuilds noch gepflegt?

    Ich nutze schon ewig gentoo für alle Kisten hier und denke nicht daran umzusteigen.

    #gentoo-vdr ist auch seit Monaten tot. CvH hat recht - zzam hatte sich schon ewig nicht mehr um die vdr-skripte und ebuilds gekümmert und hdbrummy hat alleine offenbar keine Lust mehr gehabt. Das ein oder andere ebuild kam von Dritten, aber richtigen maintainer-Nachwuchs gab es nie.

    Also umsteigen auf handgebauten vanilla-vdr.

    VG michaelb

  • [vdr-devel & softhddevice] Wiedergabe fremder Aufnahmen will nicht?

    Fehler beim download? Ich denke nicht. Hab zur Abwechslung statt ncftp auch mal lftp genommen. Gleiches Ergebnis, Grössen passen, md5-Summen sind ja leider nicht dabei.


    VG michaelb

  • [vdr-devel & softhddevice] Wiedergabe fremder Aufnahmen will nicht?

    Hola,

    ich habe zwei Aufnahmen (Cloud Atlas und Der Pathologe 1/3) von sigis ftp gezogen, mittlerweile auch mehrfach. Die Aufnahmen sollten in Ordnung sein, da reported wird, dass sie sich problemlos abspielen lassen.

    Nur bei mir wollen die nicht - Ton läuft, aber die Bild-Wiedergabe "stottert". Ich bekomme nur ein "hüpfendes" Standbild des aktuellen Live-TV. Laufenlassen, ein bisschen in der Aufnahme springen, egal, der Ton macht die Aktion mit, beim Bild bleibts beim hüpfen.

    Im Log sieht das dann so aus wie im anhängenden Abschnitt, nach dem Start der Wiedergabe nur noch jede Menge

    Code
    vdr: video/vdpau: decoder rendering failed: An invalid handle value was provided.

    .

    Ich hab gerade vor einigen Wochen eine Runderneuerung meines VDR abgeschlossen, Pentium G630, Asus GT730 mit nvidia-Treibern 340.24, Gentoo, vdr-testing 2.1.6, softhddevice aktuell aus dem git.
    Der läuft ansonsten perfekt. Eigene Aufnahmen, egal ob SD oder HD, aktuell im .ts-Format oder uralt noch von 2006 (vdr 1.2?), spielt er problemlos ab.

    Ist das ein bekanntes Phänomen? Schon mal jemand gehabt?

    --
    azrael ~ # equery -q uses vdr
    -alternatechannel
    -bidi
    -binaryskip
    -debug
    -graphtft
    +html
    -jumpingseconds
    -jumpplay
    -mainmenuhooks
    -menuorg
    -menuselection
    -naludump
    -permashift
    -pinplugin
    -resumereset
    -ttxtsubs
    -vanilla
    +wareagleicon
    -yaepg

    azrael ~ # equery -q uses vdr-softhddevice
    +alsa
    +debug
    -opengl
    -oss
    +vaapi
    +vdpau
    -xscreensaver

    VG michaelb

  • [solved] neuer TV -> TV erkennt kein Signal an HDMI nach 2. mal anschalten

    Just for the record...
    nach Aus-/Einschalten von Denon-AVR und Panasonic-TV wollte der NVidia X-Treiber meines VDRs auch partout kein Bild mehr ausgeben. Alle Komponenten sind via HDMI verkabelt, VDR->AVR->TV. Nur Neustart des X-Servers bzw. Reboot brachte Abhilfe. Die (hoffentlich) finale Lösung war, neben allen anderen Tricks mit ausgelesener EDID, etc., hotplugging für die NVidia über die Option "UseHotplugEvents" abzuschalten.

    Die entsprechende Sektion meiner xorg.conf:

    VG Michael

  • ERROR: Ausschalten unmöglich - Option '-s' fehlt!

    Hallo Tinitus,

    die Kommandozeile vom vdr sollte eigentlich ungefähr so aussehen

    Code
    /usr/bin/vdr -u vdr --watchdog=60 --epgfile=/var/vdr/epg.data --log=3 --video=/var/vdr/video0 --lirc --record=/usr/share/vdr/bin/vdrrecord-gate.sh --shutdown=/usr/share/vdr/bin/vdrshutdown-gate.sh --plugin=...

    Bei Dir fehlt wohl das --shutdown (kurz: -s). Schau doch mal in /etc/conf.d/vdr.shutdown, ist shutdown vielleicht gar nicht aktiviert? So sollte es aussehen, damit er auch runterfährt:

    Code
    # With this switch you can completely disable shutdown.
# If set to no all settings in this file are disabled.
#   allowed values: yes no
#   default: no
SHUTDOWN_ACTIVE="yes"

    Grüsse aus Pb.

  • lirc mit Silverstone ML02MX

    Quote

    Original von batesman
    also zum Compilierfehler...
    Das lirc_imon.c das dabei war hat auch die Version1.58 aber 1802 Zeilen.
    Ich hab gerade ein "cvs update" durchgeführt und es waren immer noch 1802 Zeilen.
    Nur so als Denkaufgabe ;)

    Denken ist blöd, wir schauen einfach im repository nach... ?(

    http://lirc.cvs.sourceforge.net/viewvc/lirc/li…n.c?view=markup
    ...
    1669 module_init(imon_init);
    1670 module_exit(imon_exit);
    1671
    1672 #if !defined(KERNEL_2_5)
    1673 EXPORT_NO_SYMBOLS;
    1674 #endif

    Hm?

    Perfekt, alles super, genau so muss das aktuell aussehen. Das Problem mit der Empfindlichkeit löst eine neue Funktion im CVS-Treiber sehr elegant, damit beschleunigt der Cursor sogar, je länger man drückt...ich würde sagen, entweder den Fehler mit dem cvs-checkout suchen oder abwarten bis die 0.8.5pre2 oder final da ist und du bist fertig! :tup

    Grüsse aus Pb.

  • lirc mit Silverstone ML02MX

    Hi batesman,

    du willst ja Sachen....
    Ich selbst betreibe den VDR pur und brauch keinen Maus-Ersatz. Im ersten imon-pad patch für die alten (nicht-hid) imon-devices war das drin, aber, um mich mal selbst zu zitieren "The mouse device was completely useless for me and created only unnecessary kernel dependencies, so I've removed the mouse input device support". :) Den könnte man wieder einbauen, allerdings gäbe es dann noch mehr Probleme mit den verschiedenen Devices. Für die imon hid-devices muss man den kernel erst davon überzeugen, dass sie keine hid-devices sind, nur um dann hid im lirc-Treiber zu emulieren? Nenene, klingt nicht sinnvoll. lircmd ist 'ne krücke, das könnte das Pad mit nativem Support viel besser. Wenn du ganz wagemutig bist, kannst du ja mal versuchen, die alten Patches von SiliconFiend wieder zu beleben... http://venky.ws/forums/viewtopic.php?f=2&t=60&start=90&st=0&sk=t&sd=a

    Grüsse aus Pb.

  • lirc mit Silverstone ML02MX

    Hallo batesman,

    soll heissen jetzt geht eigentlich alles? Das ist ja schon mal fein.

    Das x-fache senden des gleichen (bzw. eigentlich leicht variierender) Codes durch das Pad ist völlig richtig, das muss so sein. Der alte pad2keys-patch und eine neue Funktionalität in der CVS-Version sorgen nur dafür das die Codes schön und ordentlich generiert werden, damit der cursor nicht hüpft...

    Der Compiler-Fehler ist übrigens wirklich fasziniernd - die aktuelle Version von lirc_imon.c ist die 1.58, die hat hier überhaupt nur 1674 Zeilen, wie kommst du dann in Zeile 1793 an einen Fehler? Was hast du da ausgecheckt? Oder hast du die versucht zu patchen? Na egal... :D

    Grüsse aus Pb.

  • lirc mit Silverstone ML02MX

    Hallo batesman,

    auskennt? Naja, es gibt ungefähr drölfzig verschiedene imon-Varianten, mit teilweise doppelt und dreifach verwendeten USB-IDs für unterschiedliche Geräte ... ich habe zufällig Eines davon :) Das gute alte vfd, mit nur einem device. Von daher hab ich auch nur einen lircd laufen, und kann dir nicht sagen, ob und wie zwei Konfigs zu verheiraten sind. Für sowas gibts die lirc Mailing-Liste.

    Die Mouse/Keyboard-Taste, das Pad und die beiden Mouse-Tasten lass erstmal außen vor, die sind ganz speziell und kommen später... erstmal versuchen, die normale Funktionalität der anderen Tasten zuverlässig hinzubekommen.

    Ich sitze gerade nicht vor meinen linux-Kisten, kann also nicht genauer schauen, aber ich rate mal, dass der Fehler beim Kompilieren eher an der Kernel-Version hängt. Welche verwendest du?

    Grüsse.