Beiträge von seahawk1986

    In https://www.whirlpools-world.d…ktblatt-maax-spas-811.pdf ist von 380V die Rede (Starkstrom dürfte bei der Kombination aus 3 kW Heizung und Pumpe Sinn machen) - laut https://www.thecoverguy.com/ba…x-Spas-Owners-Manual-.pdf Seite 17 ff. könnte eine Verkabelung für 50Hz möglich sein - hast du das Datenblatt, auf das du dich beziehst aus dem Netz oder die beigelegten Dokumente (laut Handbuch in der Nähe des Controllers im Pool-Inneren zu finden) gesichtet?

    1) Warum werden (ur)alte Aufnahmen immer wieder als neu erkannt und lösen Scraperei im großen Stil aus?

    Woran meinst du das im Log zu sehen? epg2vdr (und scraper2vdr) schauen beim Start, was für Aufnahmen existieren (prinzipiell kann sich das ja geändet haben während der VDR nicht lief, z.B. wenn Aufnahmen auf Netzwerkfreigaben eingebunden wurden), damit epghttpd diese anzeigen kann und EPG-Bilder und im Fall von scraper2vdr zusätzliche Bildchen von TVDB oder The MovieDB geladen werden können, falls das noch nicht passiert ist.


    Man sollte da beim Starten so eine Zeile im Log bekommen, die einem auflistet, was epg2vdr gefunden hat - in dem Fall hat sich z.B. seit dem letzten Start nichts an den Aufnahmen geändert:

    Code
    1. May 29 15:21:55 VDR vdr: epg2vdr: Info: Found 316 recordings; 0 inserted; 0 updated and 23 directories


    2) Wie kann ich erreichen, dass epg&co erst Loslaufen, wenn der VDR schon läuft?

    Für den regulären Startvorgang brauchen die Upstart-Dateien für die Dienste die zusätzliche Start-Bedingung on started vdr

    (vgl. http://upstart.ubuntu.com/cook…epends-on-another-service) - das musst du mit den anderen Startbedingungen kombinieren, also z.B. start on (runlevel[2345] and started vdr) wenn der Dienst starten soll, wenn ein Runlevel zwischne 2 und 5 erreicht wurde und der VDR schon gestartet sein soll.

    Da ich mir durchs Rumprobieren mit div. Parametern jetzt kurzfristig mysql zerschossen hatte (startete nicht mehr), konnte ich feststellen bzw. mitstoppen,

    dass ein Start ohne mysql (somit laufen epg & co ins Leere) nach ca. 1 Minute Bild und Ton bringt.

    Mit einer HDD wirst du unter Nutzung der aktuell genutzten Plugins kaum weniger schaffen. Mit SSD dürfte sich der Wert spürbar reduzieren lassen.


    Nur mal als Ausblick: mit yavdr-ansible für Ubuntu 18.04 startet auf meinem Testsystem mit einem Celeron G540, SSD, statischer IPv4-Addresse (und deaktiviertem DHCP für IPv6) liegen zwischen dem Drücken des Start-Buttons bis zum sichtbaren Bild unter 25 Sekunden. Mit eingeschalteten Boot-Optimierungen im UEFI könnte man das noch etwas drücken (aktuell braucht er ca. 7 Sekunden, bevor er Linux bootet).

    Das mit dem nicht gefundenen Video-Modus beim Start kann ich reproduzieren, wenn ich im UEFI die Boot-Optimierung für die Grafik einschalte, also die GPU vor dem Booten des Betriebssystems nicht initialisiert wird. Wenn man was vom Boot-Vorgang sehen will, sollte man die Option also deaktvieren.

    Einen syslog-Vergleich zwischen "langsamen" und "schnellem" Start kann ich leider nicht machen, weil das Aufwachen aus dem Ruhezustand dzt. nicht mehr klappt.

    Vom Ruhezustand (aus dem anderen Thread vermute ich, dass du Standby meinst) war bislang keine Rede...


    Für den Standby greifen auch anderen Skripte als bei einem normalen Start. epgd und MySQL werden dabei soweit ich weiß nicht gestoppt - wie sich epgd und MySQL generell verhalten, wenn man den Rechner in den S3 schickt, habe ich noch nie ausprobiert - vermutlich fällt epgd beim Aufwachen die Zeitdifferenz zum letzten Update auf und dann stößt es sofort die Aktualisierung der Daten an. Falls du da noch ältere Logs (/var/log/syslog.*) davon hast, könnte man sich ja mal ansehen, was da passiert ist, bevor er nach dem letzten Update (bei dem sich außer bei epgd nicht geändert haben sollte) nicht mehr richtig aufwachen kann.

    Hmm, mysql startet sehr zäh und auch irgendwie spät. In meinem upstart-script mysql.conf steht eigentlich nur der Runlevel ab 2 als Bedingung drin.

    Runlevel 2 bedeutet laut http://upstart.ubuntu.com/cookbook/#runlevels , dass er erst starten darf, wenn das System weitgehend initialisiert wurde, die Netzwerkverbindung steht und alle Voraussetzungen für den Start der graphische Oberfläche gegeben sind.

    Die Kombination aus SysV-Init und Upstart ist generell nicht die schnellste, mit systemd kann man bei der Bootzeit einiges verbessern, wenn man eine SSD im System hat und eine statische IP vergibt, damit das nework-online.target schnell erreicht wird.


    epgd auf einen Server zu verlagern (der im Idealfall durchläuft) bringt natürlich den Vorteil, dass man sich die Zeit und den I/O für die Initialisierung der Datenbank beim Start spart.

    Würde also im Umkehrschluss heißen: die paar mal wo es schnell geht, machen epgd und skindesigner einfach weniger?

    Da müsste man mal die Logfiles vergleichen, eigentlich sind epg2vdr und epgd recht gesprächig, was sie gerade tun - wenn epgd beim Start z.B. die EPG-Daten aus dem Netz holt und in die Datenbank schreibt, könnte das zusätzliche Festplattenzugriffe erzeugen. Ansonsten wird z.B. auch noch einmal täglich der Index für locate aktualisiert.


    Der skindesigner sollte bei gleich bleibenden Einstellungen eigentlich immer die selben Dateien beim Start laden und der VDR liest die Aufnahmen beim Start ein (je mehr man hat, desto länger dauert es).

    Kann ich das irgendwie verifizieren, dass die I/O-Operationen beim Starten am Anschlag sind?

    Mit dem Programm top würde ich auf den %wa Wert schauen, der ist ein Indikator dafür, dass die CPU auf I/O-Operationen warten muss. Ansonsten kann man auch noch mit iotop nachsehen, wie viel die Platte zu tun hat: http://bencane.com/2012/08/06/…ng-high-io-wait-in-linux/ - wobei es vermutlich nicht am absoluten Durchsatz scheitert, sondern an den Zwangspausen durch die Zugriffszeiten (die bei einer HDD so im Bereich von 10 - 15 ms liegen). Wenn viele Programme parallel an unterschiedlichen Positionen auf der Platte Daten lesen oder schreiben wollen, verliert man dadurch einfach eine Menge Zeit. Bei einer SSD liegen die Zugriffszeiten typischerweise bei unter 0,1 ms, da fällt das wesentlich weniger ins Gewicht, auch wenn man kein Spitzenmodell verbaut hat.

    Kann ich das so einstellen, dass das Ready-Signal kommt, auch wenn epgd noch nicht fertig ist?

    Das Ready-Signal wird abgesetzt, wenn der VDR die Initialisierung der Plugins abgeschlossen hat und dbus2vdr zum ersten Mal in der Mainloop aufgerufen wird. Vorher kann der VDR auch nicht auf Befehle von außen reagieren.


    Du könntest versuchen den Start von epgd (und ggf. MySQL) zu verzögern und dadurch den Start etwas zu entzerren, indem du sleep-Befehle in die Upstart-Jobs einbaust.

    Soweit ich das sehen kann, machen epgd und epg2vdr schon einiges, bevor dbus2vdr das erste Mal von der Mainloop aufgerufen wird und das Ready-Signal sendet (Meldung May 26 15:29:16 myVDR vdr.conf: vdr is ready). Das das Frontend-Skript attached softhddevice erst, wenn es das Signal erhalten hat.


    Wenn deine Signatur stimmt und da eine HDD zum Einsatz kommt, bremsen vermutlich die I/O Operationen, die von der MySQL-Datenbank, skindesigner und epgd/epg2vdr beim Start verursacht werden, erheblich. Eine SSD fürs System und die Datenbank sollte helfen.

    Wenn ich mit den Tasten 7 und 9 zwischen Markierungen in Aufnahmen mit MPEG2, h264 oder HEVC springe, crasht der VDR mit dem Plugin - habt ihr das auch?



    Du könntest mal probieren softhddevice detached starten zu lassen (Startargument -D) und es mit svdrpsend plug softhddevice atta -d $DISPLAYattachen, sobald der X-Server soweit ist.


    Ansonsten musst du die Startskripte so umbauen, dass der X-Server vor dem VDR läuft (was nur schwer möglich ist, wenn man einen Loign-Manager nutzt). In yavdr-ansible ist das z.B. so vorbereitet (aber in der Vorkonfiguration wird softhddevice trotzdem detached gestartet, damit es keine Konflikte mit anderen laufenden Programmen wie KODI gibt, falls der VDR unerwartet neu gestartet wird, während er nicht für die Ausgabe genutzt werden soll).

    Es gibt in den Anzeigen-Einstellungen von KODI eine Whitelist (vgl. https://github.com/xbmc/xbmc/pull/13274 und https://github.com/xbmc/xbmc/pull/13899) , mit der man die Modi setzen kann, die für das Wechseln von Auflösung und Bildwiederholrate genutzt werden sollen. Mit der von yavdr-ansible erzeugten xorg.conf werden mir da alle Modi mit den dazu gehörigen Refreshrates angezeigt.


    Das automatische Wechseln von Auflösung/Refreshrate beim Start eines Videos scheint aktuell nicht immer zuverlässig zu funktionieren, wenn das Videoformat nicht 100% passt (in den Einstellungen das Debug-Logging für alles Player-, Audio- und Video-bezogene aktivieren, dann sieht man was er bei der Wiedergabe macht).


    Bei 1920x1080p24 Material (wie man es von einer Blu-Ray bekommen würde) klappt es auf meinem System:

    Code
    1. 12:50:54.822 T:139675372963584 DEBUG: CRenderManager::Configure - change configuration. 1920x1080. display: 1920x1080. framerate: 23.98.
    2. [...]
    3. 12:50:54.923 T:139677681952960 DEBUG: Trying to find exact refresh rate
    4. 12:50:54.923 T:139677681952960 DEBUG: Matched exact whitelisted Resolution DP-0: 1920x1080 @ 23.98Hz (34)
    5. 12:50:54.923 T:139677681952960 NOTICE: Display resolution ADJUST : DP-0: 1920x1080 @ 23.98Hz (34) (weight: 0.000)


    Bei Sintel.2010.1080p.mkv (https://durian.blender.org/download/), bei dem es IIRC mit KODI 17 ohne Probleme ging automatisch auf 1920x1080p24 umzuschalten, klappt es vermutlich wegen der krummen Videoauflösung nicht:

    Code
    1. 12:30:37.016 T:139625611908864 DEBUG: CRenderManager::Configure - change configuration. 1920x818. display: 1920x818. framerate: 24.00.
    2. [...]
    3. 12:30:37.445 T:139627478067392 DEBUG: Trying to find exact refresh rate
    4. 12:30:37.446 T:139627478067392 DEBUG: No exact whitelisted resolution matched, trying double refresh rate
    5. 12:30:37.446 T:139627478067392 DEBUG: No double refresh rate whitelisted resolution matched, trying current resolution
    6. 12:30:37.447 T:139627478067392 DEBUG: No larger whitelisted resolution matched, trying current resolution with double refreshrate
    7. 12:30:37.447 T:139627478067392 DEBUG: No whitelisted resolution matched
    8. 12:30:37.447 T:139627478067392 NOTICE: Display resolution ADJUST : 1920x1080@ 50.00 - Full Screen (16) (weight: -0.000)

    In dem Fall kann ich über den Eintrag in den Wiedergabe-Optionen des Players den gewünschten Mode von Hand setzen.

    Im Gehäuse ist zusätzlich zum AtricUSB noch ein iMON Display samt IR-Empfänger verbaut und entweder beißt sich das in der jetzigen Konfiguration oder aber der IR-Empfänger ist defekt, jedenfalls kommt von ihm ständig ein CHAN+ am VDR an.

    Du könntest den Eintrag für rc-core Geräte aus der udev-Regel für eventlircd entfernen (also /lib/udev/rules.d/98-eventlircd.rules nach /etc/udev/rules.d/ kopieren und den Abschnitt https://github.com/yavdr/yavdr…v/98-eventlircd.rules#L62 rausnehmen. Dann sollte eventlircd die Tastendrücke ignorieren.


    Falls es die Knöpfe am IMON-Display sind, die Unsinn senden, wäre das diese Regel: https://github.com/yavdr/yavdr…ventlircd-names.rules#L46

    Zum Starten von Standalone Desktop-Anwendungen gibt es den Befehl frontend-dbus-send switchto APPLICATION, also z.B. wenn man sich nicht durch das Menü des Desktop-Plugins hangeln will (die Namen müssen entweder der .deskop-Datei für die Anwendung oder einer Systemd-Unit für die Systemd User-Session entsprechen (Beispiel für KODI 17)):

    Code
    1. frontend-dbus-send switchto kodi
    2. frontend-dbus-send switchto firefox
    3. frontend-dbus-send switchto debian-xterm

    Wenn man lieber über irexec geht, kann man die Fernbedienungstasten für die Anwendungen in der /var/lib/vdr/.lircrc definieren. Das Wechseln zwischen zwei Anwendungen geht mit dem Argument switchbetween, also z.B. um zwischen dem VDR und KODI zu wechseln:

    Code
    1. begin
    2. prog = irexec
    3. button = KEY_HOME
    4. config = frontend-dbus-send switchbetween kodi vdr
    5. end

    Da Polkit bei Ubuntu 18.04 leider zu alt ist, um flexible Regeln in *.rules Dateien zu erlauben, muss man für den Neustart des VDR und des Rechners weiterhin über sudo gehen:

    Code: /etc/sudoers.d/yavdr
    1. vdr ALL=NOPASSWD: /bin/systemctl --no-block restart vdr.service
    2. vdr ALL=NOPASSWD: /bin/systemctl --no-block reboot

    Und in der menuorg.xml würde das dann so aussehen:

    Code
    1. <command name="VDR neu starten" confirm="yes" execute="sudo /bin/systemctl --no-block restart vdr.service"/>
    2. <command name="Rechner neu starten" confirm="yes" execute="sudo /bin/systemctl --no-block reboot"/>

    Das ppa:yavdr/experimental-kodi habe ich eingebunden, nach apt update zeigt er Kodi 18 auch an, es läßt sich aber nicht upgraden

    Nimm am besten das PPA der KODI-Entwickler: https://launchpad.net/~team-xb…chive/ubuntu/xbmc-nightly

    Vermutlich musst du die bereits installierten KODI-Pakete vorher deinstallieren, wenndas KODI-Paket aus dem PPA die Konflikte zu den Paketen in den offiziellen Paketquellen nicht korrekt auflöst.


    ppa:yavdr/experimental-kodi hatte ich nur vorübergehend genutzt, um einem Problem bei den Build-Dependencies auf den Grund zu gehen und seitdem nicht mehr an die Änderungen bei Ubuntu 18.04 angepasst.

    Kannst du mal versuchen undelete so zu patchen (ich lasse in meinem PPA auch gerade ein Paket mit dem Patch bauen):