Posts by seahawk1986

    Ich habe das gerade mal nachgestellt - eventlircd kann da eigentlich nichts dafür, da kommen laut ir-keytable -t ständige Wiederholungen vom Kernel Input Device.

    Im Changelog habe ich da auf die Schnelle auch nichts gefunden, was das verursachen könnte. Am besten meckerst du im Ubuntu-Bugtracker.

    Wo genau könnte ich den Notausstieg deaktivieren - der Schalter ist mir neu/nicht bekannt.

    Der steckt im Setup-Menü des VDR unter Sonstiges. Alternativ bei gestopptem VDR in der setup.conf den Wert für den EmergencyExit auf 0 setzen.


    Wegen den fehlgeschlagenen Aufnahmen: hast du alle Tuner, die der VDR besitzt angeschlossen bzw. dafür gesorgt, dass nicht angeschlossene Tuner nicht benutzt werden?

    Grundsätzlich kann man vor und nach dem Ausführen von Aufnahmen Befehle ausführen lassen, vgl. http://git.tvdr.de/?p=vdr.git;…121223b52cc4;hb=HEAD#l263 ff. - aber damit verzögerst du zwangsläufig die Ausführung der Aufnahme - vermutlich ist es eleganter regelmäßig nachzusehen, ob ein Timer ansteht (svdrpsend NEXT) und dann mit ausreichendem Vorlauf die Platte zu wecken. Oder dem NAS oder MLD-Rechner eine SSD für die neuen Aufnahmen spendieren und die später auf die Platten kopieren.


    Wenn der VDR nicht aufnehmen kann, führt der standardmäßig aktive Notausstieg dazu, dass sich der VDR beendet und dann von außen erneut gestartet werden kann (das passiert bei der MLD über das runvdr Skript: https://www.minidvblinux.de/gi…f=template/usr/bin/runvdr). Wenn du den Notausstieg in den Einstellungen abschaltest, sollte der VDR sich nicht beenden, sondern weiterhin versuchen den Sender für die Aufnahme zu tunen. Es gibt dann für jeden Aufnahmeversuch eine extra *.ts Datei, wenn dabei keine Daten empfangen wurden, bleibt die leer, wenn die Aufnahme wegen Empfangsstörungen abbricht, wird die kleiner als die eingestellte maximale Größe für einzelne Dateien sein.

    apt policy zeigt alle eingebundenen Paketquellen an.


    Hab den Überblick verloren, welche PPAs notwendig sind

    Neue Paketversionen lasse ich nur für die aktuelleren PPAs bauen - das sind aktuell ppa:yavdr/experimental-vdr und ppa:seahawk1986-hotmail/vdr-2.4.6-patches sowie ppa:seahawk1986-hotmail/experimental-vdr (was zusätzlich Pakete für armhf und arm64 beinhaltet).

    Wenn man viel Geld in die Hand nehmen will, gibt es da Anbieter wie RTI - damit kann man dann gleich noch das restliche Haus mit steuern lassen - als Verbraucher kommt man da dummerweise nicht direkt dran, die vertreiben ihre Produkte nur über zertifizierte Gewerbetreibende.


    Und ansonsten gäbe es noch diverse Lösungen mit mehr oder weniger starkem Zwang zur Cloud-Anbindung, z.B. von Sofabaton, BroadLink usw.

    Woran kann das liegen? Wo kommen die Bilder her und wie landen die in der DB?

    TheTVDB hat ihr Geschäftsmodell und die API umgestellt und damit ist der thetvdbscraper von epgd hinfällig: https://thetvdb.com/subscribe - d.h. man muss den Scraper-Teil für Serien neu schreiben (womit ich in den letzten Wochen mit TheMovieDB (die auch die Bilder für Filme liefert) als Datenquelle begonnen habe: https://github.com/seahawk1986/vdr-epg-daemon). Das Grundgerüst steht schon, der nächste Schritt ist die Methoden in https://github.com/seahawk1986…bscraper/thetmdbscraper.c funktional zu machen (aktuell ist das größtenteils nicht-funktionaler bzw. ungetesteter Dummy-Code, der lediglich dafür sorgen soll, dass ein make erfolgreich durchläuft, da gibt es zwischen der TheTVDB und der TMDb u.a. Unterschiede bei Fernsehfilmen, die da nicht immer als Serie angesehen werden und für die Bestandsdaten in meiner Datenbank hatte ich mit einem Python-Skript mit einer Suche nach TVDB-ID oder Titel nur 85% Trefferquote in den Seriendaten.


    Die schlechte Nachricht ist, dass die TMDb aktuell keine dokumentierte API anbietet, um an die Logos (was den Bannern bei der TheTVDB entspricht) einer Serie zu kommen.

    Hast du noch eine Idee? Ich kann kaum glauben, dass es bei dir damit ging.

    Ich habe gerade noch mal den Rechner mit der EasyVDR Installation angeworfen und die Pakete aktualisiert (also nvidia-450 und ein selbst gebautes aktuelles softhddevice von lnj) - damit hatte ich dann wieder die Darstellungsprobleme mit dem Skindesigner und dem estuary4vdr Skin. Als Workaround hat es geholfen die Ein- und Ausblendzeiten in den Optionen des Themes auf 0 zu setzen, damit fallen dann die ganzen Animationen weg, aber dafür sieht das OSD normal aus.

    Das dürften Snap-Images sein (vgl. https://wiki.ubuntuusers.de/snap/), die im Hintergrund aktualisiert und eingehängt werden (und davor wird das alte Image ausgehängt). Du kannst dir mit df -h die Zuordnung von loop-Device und Mountpoint ansehen und dann in der Ausgabe von mount nachsehen, was da an welchem Mountpoint eingebunden wurde.

    Also z.B.:

    Code
    1. $ df -h
    2. Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
    3. [...]
    4. /dev/loop1 200M 200M 0 100% /snap/code/60
    5. /dev/loop0 157M 157M 0 100% /snap/code/59
    6. /dev/loop2 100M 100M 0 100% /snap/core/10908
    7. /dev/loop4 56M 56M 0 100% /snap/core18/1988
    8. /dev/loop3 100M 100M 0 100% /snap/core/10958
    9. /dev/loop5 56M 56M 0 100% /snap/core18/1997
    10. [...]

    und

    Code
    1. $ mount
    2. [...]
    3. /var/lib/snapd/snaps/code_60.snap on /snap/code/60 type squashfs (ro,nodev,relatime,x-gdu.hide)
    4. [...]

    Was in dem Fall z.B. ein Snap für VS Code wäre.


    Snapd wird vom Ubuntu Server Installer mit installiert. Für den Betrieb von yaVDR-ansible ist es nicht notwendig.

    Der VDR muss beim TS-Format eigentlich nur den nackten Stream weiterreichen und solange das auf dem selben Host bleibt, sollte ein Stream mit maximal 20 MBit/s, der auf /dev/null landet, wenig Einfluss haben (das Verschicken des kompletten Transponders durch den Netciever dürfte da mehr ausmachen). Die Stream-Rate zu begrenzen macht keinen Sinn, weil der streamdev-server die Daten sonst nicht los wird. Man könnte ggf. über http://www.vdr-wiki.de/wiki/index.php/Externremux.sh den Stream herunterrechnen lassen, bevor man ihn verschickt - aber dabei muss der Stream immer noch an irgendjemanden über eine lokale Pipe gesendet werden, der ihn einliest.

    Das muss vom Ausgabeplugin unterstützt werden die Tastendrücke weiter zureichen - dazu müssen die Tasten dann eigentlich auch nicht extra in der remote.conf eingetragen werden.


    Ich habe gerade nachgesehen und wie es aussieht, hat lnj das in seinem Fork des softhddevice-Plugins auskommentiert, deswegen funktioniert das aktuell nicht: https://github.com/ua0lnj/vdr-…vid/softhddevice.cpp#L330 ff.


    Ich kann das später mal wieder per Patch aktivieren.

    Einziges Problem: es gibt keine Möglichkeit via PCIe irgendwelche GPUs oder sonstiges nachzurüsten.


    Deswegen ja der USB-Hauppage Dongle

    Ohne brauchbare iGP/CPU ist man halt arg beschränkt. Grundsätzlich reicht alles über Haswell für in 8 Bit Farbtiefe gesendetes MPEG2 und x264 Material bis FullHD. Für HEVC will man dann Sky Lake (8-Bit, reicht also für DVB-T2 in Deutschland) oder >= Kaby Lake (10 Bit Material bei UHD Sendern) mit passendem HDMI-Ausgang.


    Virtualisierung und hardwarebeschleunigte Videowiedergabe beißt sich ziemlich und auch die USB-Kommunikation kann in VMs unschöne Verzögerungen haben.


    IMHO hat man da mit einem halbwegs aktuellen Intel NUC bessere Karten (da gibt es ja auch Modifikationen, die einen passiven Betrieb ermöglichen).