Beiträge von Paulaner

kamel5 schrieb:

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 schrieb:

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 schrieb:

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 schrieb:

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

speefak schrieb:

Der Fehler tritt nur bei EINEM Sender auf und nur beim Tuner 1.

Dann kannst Du doch in der channels.conf festlegen, dass er diesen einen Sender nur über den "anderen" Tuner empfängt.

Dazu musst Du die Device-Nummer des Tuners ermitteln, der keine Empfangsprobleme hat und diese in der CAID des Senders eintragen.

Siehe dazu auch hier: channels.conf - VDR Wiki

Ich habe heute wiedermal etwas getestet und dabei habe ich ein Problem mit dem PIP festgestellt, was vor allem bei verschlüsselten Sendern auftritt. Entweder sofort beim aktivieren von PIP oder nach ein paar Sekunden friert das Bild ein und dann geht gar nichts mehr. Nur ein "reboot" auf der Konsole hilft da noch!

Hier mal ein Auszug aus dem syslog, wenn ich PIP aktiviere, und hier ist dann das Bild sofort eingefroren:

Bei einer "älteren" softhdcuvid-Version war das auch schonmal so, aber da gab es dann eine Lösung und das PIP funktionierte.

Ist das nur bei mir so (yavdr-ansible mit softhdcuvid-1.1.0-GIT8682ab0) oder ein allgemeines Problem?

Paul

jojo61

danke für Deine Erklärungen zu meinen Problemchen.

Das das skindesigner-Plugin nicht weiterentwickelt wird ist wirklich schade, denn eigentlich möchte man auf die Funktionalität dieses Plugins nicht mehr verzichten. Das mit dem Patch ist irgendwie an mir vorbeigegengen, werde ich aber demnächst auch mal testen.

Mit den "bilinear-Shader" bin ich an sich sehr zufrieden. Wenn man mal die Testfunktion zum vergleich der Shader aktiviert, dann habe ich keine wesentlichen Verbesserungen bei anderen Shadern festgestellt. Bei manchen Filmsequenzen ist der eine Shader etwas besser und dann wieder der andere. Ich konnte keinen Shader feststellen, der durchweg ein besseres, kontrastreicheres Bild geliefert hat. Also reicht mir der "bilinear-Shader".

Das ist natürlich sehr bescheiden von NVIDIA, dass die Linuxfraktion bei der Treiberentwicklung (siehe z. B. nur 8bit Farbtiefe über HDMI) doch etwas benachteiligt wird.

Da verwundert es einen auch nicht, dass in Zukunft die Unterstützung von NVIDIA-Grafikkarten bei anderen Projekten, wie z. B. KODI nicht mehr unterstützt wird. Denn die KODI-Entwickler werden keine proprietären Treiber, wie z.B. NVIDIA-CUDA o. ä. in den kommenden KODI-Versionen einbauen.

Dafür habe ich dann zwar noch meine Chinabox mit dem Amlogic S912, auf der Coreelec mit Kodi schon ganz brauchbar läuft. Wenn man dann auf so einer kleine Box noch den VDR zum laufen bekommen würde, das wäre super!

Paul

Jetzt habe ich endlich etwas Zeit gehabt, nach dem ich mehrere Wochen nicht zu hause war, und habe mir nach dieser Anleitung für softhdcuvid mit libplacebo unter yavdr-ansible das aktuelle vdr-plugin-softhdcuvid installiert.

Erstmal vielen Dank an jojo61 für die Entwicklung des neuen softhdcuvid-Plugins und auch an seahawk1986 für die super Anleitung um das Plugin auf das neue yavdr-ansible zu installieren!

Bei mir ist alles ohne Fehlermeldungen usw. durchgelaufen und prinzipiell ist das Plugin nutzbar, mit ein paar kleineren Einschränkungen:

1.

Wenn ich das softhdcuvid mit Unterstützung für libplacebo verwende, dann habe ich Abstürze, wenn ich das skindesigner-Plugin verwende.

Das ist leider ein Problem, was sich vermutlich nicht ohne weiteres lösen lässt, weil ja louis die weitere Entwicklung des skindesigner-Plugins nicht machen wird.

Momentan verwende ich in diesem Fall den "klassischen VDR-Skin", bei dem es keine Abstürze gibt. Den LCARS-Skin finde ich persönlich einfach nicht nach meinem Geschmack, da nehme ich lieber den einfachen klassischen VDR-Skin.

Frage wäre: Welche Skins verwendet Ihr so für softhdcuvid mit libplacebo?

Ich habe mir des softhdcuvid-Plugin auch nochmals "ohne" libplacebo Unterstützung kompiliert und hier scheint der skindesigner weniger Probleme zu bereiten, denn es gab bei meinen ersten Tests keine Abstürze.

2.

Welche Shader vom libplacebo verwendet Ihr so? Ich habe die besten Erfahrungen mit "bilinear" gemacht, da ist Bild und Ton einwandfrei.

Bei den meisten anderen Shadern hingegen habe ich Probleme mit dem Bild (Ruckler) und/oder auch mit dem Ton (Aussetzer).

Wie sieht das hier bei Euch aus?

3.

Frage zu UHD mit HDR: Irgendwie verstehe ich hier nicht so richtig, was da so abläuft.

Ich dachte, dass würde automatisch funktionieren, d.h. ich schalte auf einen UHD-Sender und wenn der zufällig mit HDR sendet, dann werden die entsprechenden Daten mit übertragen und mein TV schaltet dann automatisch in den HDR-Modus.

So funktioniert es zumindestens bei meiner Android/Coreelec-Chinabox.

Hier beim softhdcuvid-Plugin kann/muss ich aber im Setup auswählen, wie das Signal ausgegeben werden soll.

Aber auch wenn ich HDR-HLG auswähle und z.B. auf den SES-UHD-Demo-Sender schalte, der immer in HDR-HLG sendet, dann schaltet mein TV nicht in den HDR-Modus.

Unabhängig davon ist das m.M. nach auch nicht optimal und die Erkennung und Ausgabe eines HDR-Signales sollte automatisch erfolgen.

Paul

Was hat den die Diskussion über die Anzeigen von "tune2fs" mit yavdr-ansible zu tun?

Könnt Ihr das nicht separat diskutieren!

Paul

PS: Der Wert "Max mount count = -1" bedeutet, dass die fsck-Überprüfung deaktiviert ist!

SurfaceCleanerZ schrieb:

Stefan (der nicht versteht, warum man sich für <1% der Quellen (UHD) einen TV kauft, der alles andere aufblähen muss, weil nur SD uder ÖR HD (1280) gesendet wird..., da ist ein Full-HD TV schon ausreichend, da selbst 1080p selten gesendet wird, aber zumindest einigermaßen nahe dran liegt) Aber OT hier... Nur ein Denkanstoß

Dann versuche mal einen aktuellen 65"-TV zu kaufen, der ein gutes Bild machen soll (also nicht die einfachsten TV-Serien eines Herstellers, sondern eher ein Modell aus den Top-Serien) und der kein UHD-TV ist!

So etwas wirst Du nicht mehr bekommen, weil inzwischen alle TVs nur noch UHD-TVs sind!