Sorry, @seahawk, dass ich so spät reagiere, aber ich kriege keine EMail Notification.
Soweit ich sehe, hat sich alles erledigt... Und ich sitze in Deutschland. Code ist viel einfacher geworden, weil relative Zeit sich nicht um Zeitzonen kümmern muß.
Sorry, @seahawk, dass ich so spät reagiere, aber ich kriege keine EMail Notification.
Soweit ich sehe, hat sich alles erledigt... Und ich sitze in Deutschland. Code ist viel einfacher geworden, weil relative Zeit sich nicht um Zeitzonen kümmern muß.
Echt super, es flutscht jetzt: keinen Versatz mehr, und auch der Kanalwechsel ist wieder "flüssig".
Ich habe noch folgende Fehlermeldungen nach jedem Kanalwechsel, aber sie scheinen keinen großen Einfluss zu haben:
Feb 02 19:38:59 hdvdr.home vdr[1087]: audio/alsa: start delay 336ms
Feb 02 19:38:59 hdvdr.home vdr[1087]: video/vaapi: can't destroy postproc context!
Feb 02 19:38:59 hdvdr.home vdr[1087]: video/vaapi: can't destroy config!
Feb 02 19:39:01 hdvdr.home vdr[1087]: video/vaapi: synced after 56 frames
Also, vielen vielen Dank!
Wen muss ich bestechen, dass es über YaVDR zu mir kommt?
Just as a side remark, for my own project, we gave up on generating HTML pages from troff, and switched to creating pages in Asciidoc (or Markdown), then converting to either troff or HTML (or PDF, or...). Asciidoc is easier to write than troff, GitHub understands it (I didn't try in their Wiki though), and the result looks nicer. The same is true for Markdown, but I prefer Asciidoc, it's standardized and more powerful, there aren't x variations like Markdown.
See https://github.com/rdiff-backu…/docs/rdiff-backup.1.adoc and https://docs.asciidoctor.org/a…r/latest/manpage-backend/
You are right, I've fixed it at https://github.com/yavdr/yavdr-ansible/pull/29 for seahawk1986 to review and merge.
Much appreciated!
Ja, ich bestätige, die Liste von AMD-Karten mit h265-Support ist schon sehr übersichtlich: https://geizhals.de/?cat=gra16…encode%2Fdecode%7E653_AMD (echt netter Trick, das mit Geizhals) und keine mit passiver Kühlung, nur "semi-passiv". Allerdings habe ich festgestellt, dass ich zwei andere wichtigere Einschränkungen habe: ein Slot-Höhe und HDMI Output. Damit gibt es kaum noch Auswahl. Na gut, ich bin mir noch nicht sicher, ob ich wirklich ein Grafikkarten-Problem habe, oder was Anderes... *seufz*
Thanks, very good catch. I'll try to see if I can add something to the Ansible code of YaVDR but someone is too busy to merge my Pull Requests
I didn't want to attach a 643MB file to this portal, I've uploaded to my site at https://lavarde<dot>eu/<dot>vdrportal/sample.tgz. The snippet has a lot of spoken text, it makes it easy to see the discrepancy with the lips moving
Also, what I forgot to mention: the switching from one channel to the next has become much more sluggish: it can take a few seconds until the new channel appears, whereas the sound has already switched but the old channel's video is still to be seen, kind of in slow motion.
This all hasn't improved the WAF of my beloved VDR
Seit einiger Zeit stottern manche Kanäle und es gibt ein Verzug zwischen Ton und Bild, vor allem mit ZDF neo, aber auch mit ZDF, und wahrscheinlich andere, aber nicht ARD oder ONE).
Im angehängten Log habe ich zu zdf_neo gewechselt, dann weg davon zu ONE (der Verzug bleibt manchmal), dann zu ARTE und zurück zu ONE (der Verzug ist dann auf jeden Fall weg). Das Stottern und der Verzug bleiben auch bei Aufnahmen, so weit ich beurteilen kann, immer an der gleichen Stelle bei einer bestimmten Aufnahme. journalctl_b.txt.gz
Am Anfang dachte ich, dass es an der WIedergabe (d.h. Grafikkarte oder so, ich wollte schon eine Neue kaufen), aber jetzt habe ich Zweifel, weiß aber auch nicht, wie ich das Problem untersuchen soll. Ich habe schon den ganzen Computer gesäubert und in Augenschein genommen, an einer Überhitzung oder so sollte es nicht liegen.
Ich habe leider zu lange gewartet, deshalb weiß ich nicht mehr wie lange (die Logs gehen bis zum 19. Dezember zurück) das Problem besteht aber ich tippe auf Anfang Dezember, ziemlich plötzlich. Ich habe einen bestimmten Update zu dem Zeitpunkt aber ich weiss es einfach nicht. history.log.1.gz
Ich bin ziemlich am Ende meiner Ideen, was ich ausprobieren könnte....
Ohne den Thread kappern zu wollen, ich habe sehr ähnliche Anforderungen, und hoffe, dass ich meine alternde Hardware mit einer Grafikkarte auffrischen kann. Ich habe in diesem Thread schon viele Impulse bekommen, allerdings wollte ich NVidia aus Open-Source-Prinzipien vermeiden, gibt es auch AMD-Alternativen? h265 encode/decode, bezahlbar, leise bzw. passiv-gekühlt, gibt's das bei AMD auch? Oder soll ich meine Prinzipien lieber über Board werfen? Falls es relevant ist, YaVDR 0.7.
Ah, sorry, you wrote it already but I understood that it was impacting "only" eventlircd. Happy new year, thanks for all your help in 2021!
So, I've found the time to work further on this. I've excluded the keyboard part of the remote from eventlircd with:
$ cat /etc/udev/rules.d/95-wireless_remote.rules
# Telink Wireless Receiver
ACTION=="add|remove", SUBSYSTEM=="input", KERNEL=="event*", \
ENV{ID_VENDOR_ID}=="248a", ENV{ID_MODEL_ID}=="8367", \
ENV{ID_INPUT_KEYBOARD}!="1", \
ENV{eventlircd_enable}="true", \
ENV{eventlircd_evmap}="03_$env{ID_VENDOR_ID}_$env{ID_MODEL_ID}.evmap", \
ENV{ID_INPUT.tags}="eventlircd"
After a reboot, the input device isn't managed by eventlircd anymore (I can evtest it without complaint).
I was able to remap "KEY_F2" (as shown by evtest) to Yellow by adding the line XKeySym.Yellow F2 to /etc/vdr/remote.conf respectively "KEY_COMPOSE" to Menu by adding "XKeySym.Menu Menu" (don't ask me why but xev showed Menu), but the letters (KEY_A etc) still can't be used in text fields (but in Firefox). I tried to put something iike the following but it didn't help:
Am I missing something obvious?
Yep, i added echo "YAVDR called as $0 with $*" before the case-statement in the script and I get only in journalctl | grep YAVDR the pre-message: systemd-sleep[2307]: YAVDR called as /usr/lib/systemd/system-sleep/yavdr with pre hibernate, meaning the script really doesn't seem to be called on wake-up.
I haven't noticed anything wrong but I'm wondering if everything is correct: /lib/systemd/system-sleep/yavdr has been generated and it looks fine to me:
case $1 in
pre)
[...]
echo "unload dvb drivers"
[...]
;;
post)
[...]
echo "restore dvb drivers"
[...]
but
So that I have the strong impression that the script isn't called when waking up. Is this normal?
I have defined vdr_shutdown_command: "/usr/bin/systemctl hibernate" but according to systemd-suspend.service(8) it shouldn't make a difference.
I did push a workaround as PR: https://github.com/yavdr/yavdr-ansible/pull/27 in case someone has the same issue.
Es ist fast eine ganze Stunde, wegen Sommerzeit + Drift...
Ich weiß von den Nachteilen von LOCAL-Zeit, aber ich muss es haben (die Zeit im BIOS muss lokal sein, sonst wird's kompliziert mit dem Aufwachen, lange Story). Ich vermute also, es ist systemd-timesyncd, das entschieden hat, dass hwclock.service im LOCAL-mode maskiert werden muss, und sich nicht "unmaskieren" lässt. Mist, ich hasse, solche Entwicklerentscheidungen, die ich nicht beeinflussen kann. OK, ich muss schauen, wie ich das umgehe. Zumindest läuft es jetzt wieder, mit der HW-Zeit manuell angeglichen.
Es betrifft beide ziemlich gleich, Fernsehen und Radio. Den Output von journalctl habe ich angehängt: einmal vor dem Neustarten von VDR, einmal danach, zum Vergleich. Eine Sache habe ich festgestellt: die Zeit springt um eine Stunde zurück. Könnte es daran liegen? Die Zeitumstellung könnte der Grund sein und würde zum (gefühlten) Zeitpunkt des Erstauftretens passen.
Hallo,
es hat eine Zeit lang funktioniert aber seit ein paar Wochen (nach einem `apt update/upgrade`?) scheint VDR das Neustarten nicht gut zu bekommen: nach dem Reboot (es scheint egal, ob mit Schlafen oder einfach Reboot) funktioniert's eine kleine Weile und dann gehen Video und Ton weg. Ungefähr zur gleichen Zeit kommen solche Nachrichten (vor allem die `video mit 0/ms v-buf` Zeilen).
Dec 19 09:55:01 hdvdr.home vdr[1301]: video: --:--:--.--- +0 0 0/\ms 0+0 v-buf
Dec 19 09:55:01 hdvdr.home vdr[1301]: [1301] [softhddev]No hw driver or OpenGL Osd disabled - use soft OSD
Dec 19 09:55:02 hdvdr.home vdr[1301]: [1301] switching to channel 613 S19.2E-1-1094-9181 (NOSTALGIE)
Dec 19 09:56:01 hdvdr.home vdr[1301]: video: --:--:--.--- +0 0 0/\ms 0+0 v-buf
Ein einfacher Neustart von vdr (z.B. `systemctl restart vdr`) löst das Problem bis zum nächsten Reboot... Leider habe ich zu lange gewartet, um mich darum zu kümmern, und darum weiß ich nicht genau, was der Grund für diese Verhaltensänderung sein könnte. Hat jemand eine Idee?
Um das Thema abzuschließen: die Lösung bestand darin `/etc/pulse/default.pa` nach `~vdr/.config/pulse/default.pa` zu kopieren und folgende Zeilen hinzuzufügen:
set-card-profile alsa_card.pci-0000_00_1b.0 off
load-module module-alsa-sink device=front:0 sink_name=analogOut sink_properties=device.description=AnalogOut
load-module module-alsa-sink device=iec958:0 sink_name=digitalOut sink_properties=device.description=digitalOut
load-module module-alsa-sink device=hdmi:0,1 sink_name=hdmiOut sink_properties=device.description=HdmiOut
load-module module-combine-sink sink_name=combinedOut slaves=digitalOut,analogOut,hdmiOut
set-default-sink combinedOut
digitalOut habe ich nicht zum fliegen gebracht, aber analogOut und hdmiOut tun, das reicht mir erstmal. Und analog tat lange nicht, weil ich den Stecker falsch eingesteckt hatte... Na ja, so kann man sich auch die Zeit vertreiben. Danke für die Hilfe!