Beiträge von horchi

    generell habe ich nichts dagegen. Nur wie sieht es in der Zukunft aus, weißt du/ihr schon etwas darüber wie es mit der Unterstützung im Kernel weiter gehen soll?

    Beim Wohnzimmer VDR werde ich sehr wahrscheinlich erst mal bei der chroot Lösung bleiben.
    Der Test wie es unter Ubuntu läuft ist für zwei weitere Anwendungen. Einmal im Wohnmobil, da läuft eine Haussteuerung drauf (die habe ich in c++ implementiert) und ein mal im Garten mit der selben Steuerung nur da für den Pool. Beides betreibe ich im Moment mit einem Rasperry Pi auch jeweils mit VDR, nur ist der für den VDR nicht wirklich gut daher denke ich darüber nach es mit dem odroid n2+ abzulösen.
    Und auch die Haus-/Pool-Steuerung nebst Zugriff auf GPIO, W1, ... und alles was ich da sonst noch drauf (squeezebox Server, ...) benötige fühlt sich in chroot etwas umständlich an.

    das habe ich überall so kommt aus dem PPA von seahawk198:


    denke hier liegt das Problem (gerade mit dmesg entdeckt):

    die Plugin Optionen habe ich identisch zu der chroot Umgebung unter welcher es prima funktioniert:

    Code
    [softhdodroid]
    -a hw:CARD=AMLAUGESOUND,DEV=0

    danke für das Skript !

    Hier wieder so ein Effekt, nach systemctl restart vdr zwei instanzen da sich die eine nicht beendet hat und SIGKILL hilft nicht

    Code
    root@odroid:~# killall -9 vdr
    root@odroid:~# psg vdr
    root        4166       1  0 14:15 ?        00:00:02 /usr/bin/vdr
    root        4385       1  0 14:22 ?        00:00:02 /usr/bin/vdr

    ich finde im ersten Post diesen Link: https://wiki.odroid.com/odroid-n2/os_images/ubuntuder der führt mich ganz unten bei Ubuntu 22.04 nach hier: https://wiki.odroid.com/odroid-n2/os_images/ubuntu/20220622
    der Link dann wiederum nach hier: https://de.eu.odroid.in/ubuntu_22.04lts/N2/

    von dort habe ich ubuntu-22.04-4.9-minimal-odroid-n2-20220622.img genommen
    Das habe ich dann ohne einen anderen Kernel zu installieren verwendet.


    Passt das oder oder bin ich irgendwo falsch abgebogen?

    ich möchte mal schauen wie das ganze unter Plain Ubuntu also ohne CoreElec auf dem odroid n2+läuft

    Dazu habe ich mir dieses Image installiert: https://odroid.in/ubuntu_22.04…odroid-n2-20220622.img.xz
    Und den VDR nebst Plugins identisch zu dem in der UBUNTU chroot unter CoreElec.


    Generell läuft es jedoch mit stochastischen für mich noch nicht greifbaren Problemen, wie hin und wieder schwarzes Bild bis zum Neustart, langsame Reaktion, mal 100%CPU dann wieder nicht, VDR Crashes, hängen bleiben des VDR beim beenden bis zum defunct, ...

    Bevor ich weiter suche mal die Frage hier in die Ruden, muss man bei der Installation etwas etwas spezielles beachten bzw. habe ich etwas generelles übersehen (boot.ini, config.ini, Kernel Version, spezielle Treiber Version, ...) oder ist der Ansatz 'einfach' den VDR nebst Plugins auf Basis des genannten Ubuntu Images zu installieren richtig?

    Das aus dieser Basis UHD nicht richtig läuft ist mir bekannt.

    Danke Grüße Jörg

    läuft, ich bin nun auch auf 384k.
    Interessant/merkwürdig ist das ich wirklich nicht nur booten (weiß nicht ob das überhaupt nötig war) sondern den TV neu Starten musste.
    Also es läuft hier sowohl mit 512k als auch mit 348k, mit 260k geht es nicht

    der Deadlock passiert im Handler (das Statement wird nur von Handler ausgeführt, der Handler ist auch (wie man im Log sieht) schon wieder 'active'. Das ist auch richtig da der epgd zwar noch 'busy' ist dies aber nur noch mit den images.
    Aus deinem Log:

    Code
    #> egrep "(Got epgd state|Deadlock|handler)" server.log.txt
    Feb 20 10:05:52 server vdr[22142]: epg2vdr: Got epgd state 'busy (images)' (6)
    Feb 20 10:05:52 server vdr[22142]: epg2vdr: Change handler state to 'active'
    Feb 20 10:05:56 server vdr[22142]: epg2vdr: SQL-Error in 'execute(stmt_execute)' - Deadlock ...
    Feb 20 10:06:09 server vdr[22142]: epg2vdr: Got epgd state 'busy (scraping)' (5)

    In dieser Situation hatte ich hier noch nie einen Deadlock und kann es mir erst mal nicht erklären.
    CKone kennst du eine maria/mysql Server Einstellung welche das Lock Verhalten dementsprechend beeinflussen könnte? Mir fällt gerade nichts ein.

    Nein, hab ich nicht. Trotzdem mal hier das Drumherum um den letzten Deadlock:

    wenn du in deinem log keine Got epgd state Meldungen des epg2vdr Plugins findest ist das die Ursache für die Deadlocks.
    Diese Meldungen kommen mit log level 1, also wenn du den auf 1 oder größer hast und die Meldungen ausbleiben müssen wir nur noch herausfinden warum des Plugin den Status des epgd nicht mitbekommt.

    es steht zwar bereits im README des Plugins ich habe die Formulierung jetzt noch ein klein wenig angepasst:


    Code
    Update DVB EPG Database
    Master/Slave Mode (one client should be master, e.g. 24/7 Server, all others slave)
    - auto: Normally first VDR will be master - the master transfers the DVB events to the mariadb Server
    - yes: Master mode on
    - no: Master mode off
    Make sure that only one VDR will be master or you run into DB performance issues or deadlocks.

    kommt aber erst mit der nächsten Version ins git.

    die Deadlocks kommen jedenfalls aus dem EPG Handler. Du verwendest das epg2vdr 1:1 aus dem git ohne weitere Patches wie z.B. den VPS Patch?

    Wie oft hast du die Deadlocks?


    Hast du diese Meldungen?

    Code
    Feb 21 09:28:44 gate vdr: epg2vdr: Got epgd state 'busy (match)' (4)
    Feb 21 09:29:09 gate vdr: epg2vdr: Got epgd state 'standby' (1)

    Wenn ja schick mal die Letzte vor und die Erste nach so einer Deadlock Meldung, am besten den Bereich zw. den beiden.


    Ich habe hier keinen einzigen Deadlock in der gesamten log Historie:

    nein ist nicht egal, dafür u.a. trägt das Plugin den vdr in Tabelle ein:


    Code
    MariaDB [epg2vdr]> select ip, svdrp  from vdrs;
    +-----------------+-------+
    | ip              | svdrp |
    +-----------------+-------+
    | 192.168.200.114 |  6419 |
    | 192.168.200.101 |  6419 |
    | 192.168.200.203 |  6419 |
    | 192.168.200.103 |  6419 |

    das Skript rufst du (vom host aus auf welchem der epgd läuft) nur um es zu testen auf.

    Z.B. mit CHAN zur Anzeige des Kanals. Wenn es geht kann man das schon mal ausschließen