Auch mit passender 60Hz Einstellung im Softhddevice
Das ist kontraproduktiv, da ja alle TV-Sendungen hier in DE mit 50Hz gesendet werden.
Also zuerst immer 1080p50 oder 2160p50 einstellen. Wobei ich zu Anfang es nur mit FullHD, also 1080p50 probieren würde.
Also ich habe ALSA (kein Pulseaudio) für Audio und bei mir ist der Ton einwandfrei über das HDMI-Kabel in DD+ über meinen Denon AVR-X4500H.
Für LiveTV ist für mich der VDR ebenfalls unschlagbar 
und deshalb frustriert mich ja auch die schlechte Treiberentwicklung von NVIDIA für Linux. 
Die Chinaboxen sind übrigens besser als Ihr Ruf, wenn man das Android nicht benutzt, sondern Libreelec bzw. Coreelec einsetzt. Und man sollte nicht gerade das billigste Teil nehmen. Die von mir erwähnte ODROID-N2-Box kommt übrigens aus Korea, nicht aus China! 
Sobald diese in DE erhältlich ist, werde ich mir eine kaufen und dann schaun wir mal.
Jetzt ist es genug OffTopic und hoffen wir mal, dass NVIDIA die Linux-Treiberentwicklung doch nochmal etwas forciert.
Denn vielleicht schon zur IFA Berlin im Herbst diesen Jahres oder Anfang nächsten Jahres werden vielleicht auch das ZDF und ARTE einen UHD-Testsender starten. Und dann wäre es doch super, wenn wir bis dahin ein vernünftiges system hätten, mit dem wir diese Sendungen auch in bester Qualität sehen könnten.
Paul
Man sollte das in einem getrennten thread diskutieren.
Ja, da hast Du recht.
Ich wollte nur meinen Frust mit NVIDIA und deren vernachlässigte Entwicklung für Linux-Treiber loswerden!
habe ich alles richtig eingestellt, liegt aber m.M. nach an den Beschränkungen des Nvidia-Treibers und ist mir nur früher mit meinem kleinen 47"-LCD-TV nicht aufgefallen!
Nach dem ich nun fast 1 Jahr eine GT1030 nutze bin ich immer weniger von NVIDIA überzeugt und tendiere inzwischen dazu eine der neueren Amlogic-Boxen zu nutzen, weil diese auf die Wiedergabe von FullHD/4K/UHD incl. HDR optimiert sind und dabei einen sehr geringen Energieverbrauch von 3...5W haben.
Meine Kritikpunkte an NVIDIA:
Somit ist eine wirklich gute Wiedergabe von FullHD und auch UHD nur bedingt möglich und dies fällt vor allem auf, je größer der TV ist. Bei TVs < 55" wird das vermutlich kaum stören. Aber ich habe einen 65" an der Wand hängen bei einem Sitzabstand von knapp 3m und da sieht man die Bildfehler schon sehr deutlich.
Aktuellt nutze ich zum rumspielen und Testen eine "ältere" Alfawise H96pro+ mit einem Amlogic SOC S912 und diese Box hat schon ein wesentlich besseres Bild bei UHD als es die GT1030 schafft. Die Box kann problemlos bei 4K/UHD eine Farbtiefe von 10bit (4K, 60Hz) oder sogar 12bit (4K/30Hz) am HDMI-Ausgang liefern, und beherrscht auch die automatische Umschaltung der Bildauflösung und Farbtiefe.
Bei Amlogic ist die Entwicklung inzwischen schon viel weiter und es gibt neuere SOCs, welche endlich auch entsprechende native Treiber für Linux haben.
Wobei vor allem die neueste ODROID-N2 mit dem Amlogic SOC S922X sehr gut sein soll. Aktuell gibt es die noch nicht in DE zu kaufen, aber ich denke es dauert nicht mehr lange und diese Box wird auch bei POLLIN gelistet sein. Für diese Box gibt es bereits erste Entwickler-Software für CoreElec und auch Ubuntu soll schon darauf laufen. Die Box kann problemlos 4K/UHD mit HDR, HLG usw. wiedergeben und das bei einem Energieverbrauch von 3...5W. Wer etwas dazu mehr lesen will:
hardkernel.com - ODROID-N2 with 2/4GByte RAM
Da auf der ODROID-N2-Box auch Ubuntu laufen soll (dazu gibt es bereits ein Unterforum im Odroid-N2-Forum) wäre das vielleicht auch etwas wo man probieren könnte darauf direkt den VDR laufen zu lassen.
Leider sind hier meine Linux-Kenntnisse zu gering um so etwas selbst zu stemmen.
Momentan nutze ich deshalb Coreelec mit Kodi und dem vdr-vnsi-Plugin was auch schon sehr gut klappt.
Das sieht schon nach NEC aus - es kann immer nur ein Kernel-Decoder aktiv sein ...
Sicher?
Also ich habe hier bei meiner Chinabox auch "serial_ir" laufen und kann das mit 2 unterschiedlichen FBs bedienen, eine mit "nec"-Protokoll und eine mit "rc-5"-Protokoll.
Dazu musste ich damals nur beide Protokolle aktivieren (ist jetzt nur aus dem Gedächtnis, der Befehl kann auch etwas anders sein):
ir-keytable -p nec,rc-5 -t
Mit ir-keytable kann man dann nachschauen, welche Protokolle aktiviert sind. das sieht dann bei mir z.B. so aus:
Bei "Enabled protocols: rc-5 nec" sind hier die beiden benutzbaren Protokolle aufgeführt.
In der zugehörigen /etc/rc_keymaps/remote-config müssen dann beide Protokolle in der 1. Zeile stehen:
# table remote-config, type: rc-5,nec
Und dazu werden dann beide ermittelten Keycodes für die einzelnen FB-Tasten in diese Datei eingetragen.
Hier mal nur als Beispiel zuerst der rc-5-Code und dann der nec-Code, wie das in meinem Fall aussieht:
Da das aber keine normale Funktion, sondern ein Umschalten zwischen 2 Modi ist, habe ich das dann so gemacht, damit sich das etwas abgrenzt.
Man kann aber natürlich, wie bei jeder anderen Beschriftung, das in den po-Dateien ändern.
Aha, das hatte ich mir auch fast schon so gedacht.
Ist jetzt ja kein funktionales Problem, sondern nur etwas Kosmetik!
Danke aber für den Patch, denn diese Idee ist wirklich genial und sollte direkt in den VDR aufgenommen werden. 
Paul
Nachtrag:
Für "AUFNAHMEN" hätte ich besser "Zurück" oder "Back" genommen!
Denn die Funktion ist ja, dass man den Undelete-Bereich wieder verlässt. Oder leige ich da falsch?
Ich hab gleich mal den neuen VDR eingespielt und den Undelet-Patch ausprobiert.
Funktioniert einwandfrei! Löschen sowie auch das Wiederherstellen!
Was mir hier allerdings nicht gefällt, sind die Bezeichnungen für die Farbtaste "Rot", welche in Großbuchstaben angezeigt werden!
Das sind die Bezeichnungen: UNDELETE und AUFNAHMEN
Diese sind, wie es ausschaut, im Patch so definiert und müssten vermutlich also auch da angepasst werden.
Ich würde hier die "normale" Schreibweise bevorzugen, also Undelete und Aufnahmen, da auch die anderen Farbtasten in dieser "normalen" schreibweise angezeigt werden.
Stimmt, wenn ich das extrecmenu-Plugin deaktiviere, dann geht das auch so, wie von Dir beschrieben über das interne VDR-Aufzeichnungsmenü.
Aber wenn das "nur" am extrecmenu-Plugin liegt, dann bin ich scheinbar der einzigste, der das Plugin noch einsetzt! 
Schade, denn ich finde das Plugin doch etwas komfortabler als das interne VDR-Aufzeichnungsmenü.
Ich habe einen Bug im yavdr-ansible festgestellt, der beim Verschieben von Aufzeichnungen über das OSD-Aufzeichnungsmenü auftritt.
Dieser Fehler tritt nur beim Verschieben von Aufzeichnungen auf, die noch ein Unterverzeichnis mit z.B. einem Episodentitel haben.
Wenn ich solch eine Aufzeichnung verschieben will, dann bleibt der VDR einfach hängen und das letzte OSD bleibt stehen, Bild und Ton laufen weiter, aber der VDR ist unbedienbar. Das ist unabhängig vom OSD selbst, denn auch beim "klassischen VDR OSD" passiert das. Hier hilft nur noch ein "reboot"!
Verschiebe ich dagegen eine "normale" Aufzeichnung ohne Unterverzeichnis/Episodentitel, dann klappt das problemlos, wie erwartet.
Um das nochmals zu verdeutlichen habe ich 2 Auszüge aus dem syslog gemacht.
1. Verschieben einer Aufzeichnung ohne Unterverzeichnis:
2. Verschieben einer Aufzeichnung mit einem Unterverzeichnis/Episodentitel:
Mehr Einträge gibt es im syslog hier nicht mehr!
Da der VDR sich nicht mehr bedienen lässt muss ich über die Konsole den VDR rebooten.
Nach dem Reboot ist dann die Aufzeichnung allerdings korrekt verschoben, d.h. die Aktion wird prinzipiell ausgeführt, aber irgendwo bleibt der VDR komplett hängen.
Paul
Wie seahawk1986
schon sagt, Du hast hier einige dateinamen unterschiedlich geschrieben!
Einmal schreibst Du rc-one4all-7960 und dann wieder rc-one4all_7960.
Du solltest also nochmals genau kontrollieren, was Du in der /etc/rc_keymaps.cfg drin stehen hast!
Das Problem ist eher, dass die Keytable (oder das Protokoll) nicht auf den Empfänger anwendet wird.
Siehe meine Hinweise zum Laden der keytable im Beitrag #15 in diesem Thread!
Außerdem gibt es bereits eine Diskussion zu dem Thema im "yavdr-ansible"-Thread, wo genau beschrieben ist, wie man das alles zu laufen bekommt:
Was bringt denn die Ausgabe von ir-keytable ?
Welche Protokolle werden denn überhaupt unterstützt bzw. aktiviert?
Und mach doch mal das ir-keytable -a /etc/rc_maps.cfg -s rc0 , evtl. den Pfad zur "rc_maps.cfg" anpassen.
Bei mir kommt da z.B. folgende Ausgabe, wobei ich nur die 1 keytable, welche ich für meine Fernbedienung erstellt habe, in der "rc_maps.cfg" aktiviert habe.
Erst jetzt wird doch das richtige Protokoll aktiviert!
Nachtrag:
Eine sehr gute und ausführliche Anleitung für "ir-keytable mit serial-ir" findest Du hier: Step by Step serial-ir mit ir-keytable
Hhhmm, bei mir sieht das etwas anders aus: type: rc-5 und nicht type: RC5
Meine Ausgabe von ir-keytable sieht dann auch so aus:
Wichtig hierbei ist m.M. nach auch die Angabe Aktivierte Protokolle: lirc rc-5
Laden der richtigen keymap kann man über:
ir-keytable -a /pfad-zur-keymap/rc_maps.cfg -s rc0
Man könnte natürlich auch den Default Debug Level (3) vom VDR runterschrauben,
indem man in /etc/vdr/conf.d/00-vdr.conf ein --log 1 oder --log 2 einfügt.
Yepp, genau das war/ist es. hatte ich irgendwie vergessen.
Denn das hatte ich in yavdr-0.6 auch gemacht, einfach den Loglevel auf --log=2 gesetzt und schon ist der VDR und das softhddevice-Plugin nicht mehr so geschwätzig!
Danke für den Tipp!
Würde ich heutzutage nicht mehr kaufen, denn die alten Amlogic S905x-SOC können bei UHD mit HDR nur 8bit farbtiefe.
Aber es werden in den nächsten Wochen neuere Boxen auf den Markt kommen, die dann UHD und HDR usw. voll mit 10bit unterstützen werden.
Siehe z. B. hier: ODROID N2 - Amlogic S922X Board
Zum Einen hat nun die Fa. Amlogic wohl entsprechende Treiber für Linux und co. bereitgestellt und zum Anderen wurden die Entwickler von Libreelec/Coreelec von der Firma mit Boxen ausgestattet, um darauf die Software weiter entwickeln zu können.
Wenn Du was kaufen solltest, dann warte einfach noch etwas.
Die Meldungen sind doch aber normal beim softhddevice.
Okay, dann muss ich mir keine ernsthaften Sorgen machen!
Allerdings muss es da doch noch irgendwelche Möglichkeiten geben, diese Meldungen zu unterdrücken.
Denn bei meinem anderen Produktiv-VDR, der noch mit yaVDR-0.6 und "softhddevice-???-Plugin" läuft habe ich keine solchen Meldungen im syslog.
Bei meinem hier gemeinten Test-VDR mit yavdr-ansible habe ich jetzt allerdings diese oben beschriebenen Meldungen, aber auch nur wenn ich ein "softhddevice-???-Plugin" verwende, beim "softhdcuvid-Plugin" gibt es diese Meldungen wiederum nicht.
Das ist wie gesagt kein Problem, sondern mehr etwas kosmetisches!
Aber neugierig bin ich schon, wo da die Unterschiede in yavdr-0.6 und yavdr-ansible sind!
Ich hatte zuerst das "softhddevice-vpp" probiert, aber da gab es ab und zu Probleme mit einem nicht synchronen Ton. Ein paar mal hin und herschalten, dann war der Ton wieder synchron, aber das hat mich dann doch genervt.
Dann habe ich das "softhddevice-openglosd" installiert und bin soweit zufrieden, da läuft alles richtig und es gibt auch keinen asynchronen Ton.
Seit der Installation des "normalen" softhddevice-Plugin (egal ob -vpp oder -openglosd) an Stelle des "softhdcuvid-Plugins" bekomme ich jetzt immer im Abstand von genau 1 Minute eine Meldung in das syslog geschrieben! 
Das ist jetzt nicht dramatisch, aber irgendwie unschön und müllt nur das syslog zu:
Ich würde gern wissen wo das her kommt, damit ich das weg bekomme.
Paul
Aha, jetzt bin ich etwas schlauer
HEVC braucht man ja nur für UHD und DVB-T2.
Da ich beides für einen Produktiv-VDR nicht benötige werde ich also mal "softhddevice-openglosd" nehmen und vielleicht auch "softhddevice-vpp" testen.
Momentan setze ich als Ausgabe-Plugin das "softhdcuvid" ein, weil ich ab und zu die UHD-Sender teste.
Um die Entwicklung des Plugins ist es z. Z. etwas ruhig geworden und die Probleme mit dem PIP wurden noch nicht beseitigt. Da ich doch ab und zu das PIP des Ausgabe-Plugins einsetze, gibt es dann immer wieder gravierende Probleme das mir der VDR hängen bleibt. Dann hilft nur noch ein "harter" Reset, um den VDR wieder neu sterten zu können.
Da das mit einem produktiven Einsatz nicht vereinbar ist, will ich jetzt erstmal wieder zum "normalen" softhddevice-Plugin wechseln.
Aber ich weiß jetzt gar nicht, welches der 4 im ppa:experimental-vdr vorhandenen softhddevice-Plugins ich nehmen soll?
Ich habe eine Nvidia-GT1030 im VDR und nutze das skingesigner-Plugin für das OSD.
Welches softhddevice-Plugin soll ich dafür nehmen bzw. worin unterscheiden sich die ganzen 4 softhddevice-Plugins?
Paul
