Posts by Paulaner

Ich möchte bei meinem VDR bei der Ausgabe über das softhddevice-Plugin den Wert für die Helligkeit etwas verringern, da sonst das Bild bei mir leider etwas zu Hell ist.

Wenn ich KODI verwende ist alles o.k. so dass ich die Helligkeit am TV selbst nicht verändern möchte, sondern nur bei der Ausgabe über den VDR.

So habe ich testweise über das OSD den Wert unter Einstellungen -> Plugins -> softhddevice -> Helligkeit von "0" auf "-40" durch probieren der optimalen Helligkeit geändert.

Was auch super funktioniert, denn der Wert wird sofort nach schließen des OSD übernommen und die Bildhelligkeit geändert.

In der setup.conf steht dann auch der richtige Wert drin: softhddevice.Brightness = -40

Nach einem Neustart ist die Bildhelligkeit allerdings scheinbar wieder auf den Defaultwert "0" gesetzt, d.h. das Bild ist wieder wie vorher zu Hell.

Gehe ich jetzt wieder ins Einstellungs-OSD für das softhddevice-Plugin, so steht da für die Helligkeit mein eingestellter Wert von "-40" immer noch drin und nicht etwa der Wert "0".

Wenn ich jetzt mit OK diesen Wert bzw. einfach das Einstellungs-OSD bestätige wird dieser eingestellte Wert sofort aktiv, d.h. das Bild wird wie gewünscht etwas dunkler.

Nach jedem Neustart ist es dann allerdings wieder scheinbar auf Default = 0 gesetzt obwohl im OSD bzw. natürlich auch in der setup.conf der Wert richtig drin steht.

Um den Effekt einfach mal ganz deutlich zu sehen, kann man das Testen in dem man z.B. den Wert für den Farbton von "0" auf "1000" setzt und mit OK bestätigt!

Dann sehen die Menschen sofort wie Außerirdische mit pinkfarbenen Köpfen usw. aus und alles ist pink und grün!

Aber nach jedem Neustart des VDR ist wieder der Defaultwert "0" drin (obwohl der Wert in der setup.conf immer noch auf "softhddevice.Hue = 1000" steht) und die Menschen sehen wieder normal aus. Öffnet man jetzt einfach das Einstellungs-OSD für das softhddevice-Plugin und schließt es mit OK dann wird der Wert sofort übernommen und die Leute bekommen pinkfarbene Köpfe.

Das Verhalten scheint auch nur die Bildwerte: Helligkeit, Kontrast, Sättigung und Farbton zu betreffen, denn z.B. die Werte für 4:3 Display Format werden auch nach einem Neustart richtig wie eingestellt übernommen.

Getestet habe ich es mit dem "alten" softhddevice-0.6 von yavdr-0.6 und auch mit dem etwas neueren softhddevice-0.7 von yavdr-ansible.

In beiden Fällen ist das gleiche Verhalten zu beobachten!

Die Frage ist nun, mache ich etwas falsch oder es ist ein Fehler/Feature im softhddevice-Plugin?

Vielleicht ist es auch Absicht, das die Werte bei einem Neustart immer auf Default gesetzt werden?

Sollte es ein Fehler bzw. "Feature" im softhddevice-Plugin sein, dann würde ich mich über einen Fix des Problems freuen.

Momentan behelfe ich mich, in dem ich ein kleines Script nach dem Start des VDR ausführe, bei dem ich per vdr-dbus-send den Wert nochmals sende und somit stimmt dann die Bildhelligkeit auch nach einem Neustart des VDR. Wenn ich dann allerdings zwischendurch mal KODI verwende und dann zurück zum VDR schalte, dann ist die Bildhelligkeit wieder zu hell!

Das Startscript ist also nur eine Notlösung und ein fix des Problems wäre doch besser!

Paul

mini73 wrote:

Welche Features von dynamite verwendest du genau?

Ich benutze das Aktivieren und Deaktivieren von meinen DVB-S2-Karten beim Start des VDR bzw. während des Betriebes über das dynamite-Plugin.

Der Grund dafür ist, das ich meine SAT-Schüssel nur "versteckt" auf dem Balkon anbringen kann und ich dadurch nicht immer Empfang habe. So nutze ich für den Normalbetrieb DVB-T2 bzw. DVB-C und DVB-S2 nur wenn ich mal was in bester Qualität aufnehmen will.

Will ich also wirklich mal etwas aufnehmen, dann positioniere ich die SAT-Schüssel optimal und aktiviere die DVB-S2-Karten über das dynamite-Plugin.

Im Normalfalle deaktiviere ich immer die DVB-S2-Karten gleich nach dem Start des VDR über das dynamite-Plugin und kann diese dann auch bei Bedarf über das OSD wieder aktivieren.

seahawk1986 wrote:

nachdem mini73 noch keine Zeit gefunden hat, den Patch für dynamite auf die Änderungen für Multi-Frontend Devices anzupassen, habe ich in https://launchpad.net/~seahawk…+archive/ubuntu/vdr-2.4.1 ein PPA mit einem VDR ohne den dynamite-Patch (und damit ohne die Pakete vdr-plugin-dynamite und vdr-plugin-sundtek) erstellt, das dafür alle Patches aus Patches für VDR 2.4 enthält.

Wie sieht denn hier momentan der Stand der Dinge aus?

Wird es demnächst auch ein dynamite-Plugin für den vdr-2.4.1 geben?

Die fehlenden Änderungen für ein Multi-Frontend-Device brauche ich nicht unbedingt, da ich ein solches nicht benutze.

Aber ohne ein dynamite-Plugin kann/werde ich nicht auf den vdr-2.4.1 umsteigen, da ich das dynamite-Plugin aktiv benutze.

Paul

helau wrote:

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

jsffm wrote:

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!

seahawk1986

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:

• Aktuelle kann der Nvidia-Treiber maximal eine Farbtiefe von 8bit über den HDMI-Ausgang unter Linux. Für UHD mit HDR wären 10bit für ein wirklich gutes Bild optimaler. Das merkt man vor allem bei Bildern mit größeren dunklen Farbflächen, wo dann ein sogenanntes Color-Banding auftritt. Das fällt mir in letzter zeit leider immer mehr auf. Vor allem seit dem ein 65"-TV an der Wand hängt!
• Eine automatische Umschaltung auf andere Farbräume (BT709, BT2020) und Farbtiefe (8bit, 10bit), wie das z.B. bei HDR erforderlich gibt es nicht. Muss momentan manuell gemacht werden bzw. 10bit geht gar nicht.
• Eine automatische Umschaltung auf die Auflösung des Quellsignals (720p, 1080p, 2160p) gibt es gar nicht, d.h. es wird immer auf die einmal eingestellte Auflösung skaliert.

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

ODROID-N2 Forum (english)

Coreelec Forum (english)

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.

seahawk1986 wrote:

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:

kamel5 wrote:

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!

seahawk1986 wrote:

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:

Ab Beitrag #220 bis ca. #227

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

OleS wrote:

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.

ofenheizer wrote:

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!