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.
Beiträge von horchi
-
-
ich finde keine Möglichkeit den Kernel zurück zu drehen, im git finde ich auch keinen mit dem entsprechenden Tag. Übersehe ich etwas?
Die einzige Option scheint das 20.04 statt dem 22.04 Image. -
danke euch! Ich schaue mal nach was älterem.
Hoffentlich kommt das bald in den mainline Kernel
-
das habe ich überall so kommt aus dem PPA von seahawk198:
Code
Alles anzeigen[Unit] Description=Video Disk Recorder After=network.target [Service] Type=notify ExecStartPre=/bin/bash /usr/lib/vdr/merge-commands.sh "commands" ExecStartPre=/bin/bash /usr/lib/vdr/merge-commands.sh "reccmds" ExecStartPre=/root/bin/smp-affinity.sh ExecStart=/usr/bin/vdr Restart=on-failure RestartPreventExitStatus=0 2 [Install] WantedBy=multi-user.target
denke hier liegt das Problem (gerade mit dmesg entdeckt):
Code
Alles anzeigen[ 78.671430] mem flags 4099 4099, 4 [ 78.675162] Input block allocation failed [ 78.679370] vframe_block storage allocation failed [ 78.710628] not enough mem for VFRAME_INPUT size 524288, ret=-10003 [ 78.711419] mem flags 4099 4099, 4 [ 78.715172] Input block allocation failed [ 78.719464] vframe_block storage allocation failed [ 78.750634] not enough mem for VFRAME_INPUT size 524288, ret=-10003 [ 78.751424] mem flags 4099 4099, 4 [ 78.755555] Input block allocation failed [ 78.759607] vframe_block storage allocation failed [ 78.850534] vdec requested to be disconnected [ 80.870465] vdec_disconnect timeout!!! status: 0x3 [ 80.870508] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 80.878015] pgd = ffffffc0c92e0000 [ 80.881568] [0000000000000000] *pgd=0000000000000000, *pud=0000000000000000 [ 80.888677] Internal error: Oops: 96000045 [#1] PREEMPT SMP [ 80.894396] Modules linked in: cpufreq_ondemand cpufreq_powersave cpufreq_userspace cpufreq_conservative joydev i2_meson_master sch_fq_codel amvdec_vp9 amvdec_vc1 amvdec_real amvdec_mmpeg4 amvdec_mpeg4 amvdec_mpeg12 amvdec_mmjpeg avdec_mjpeg amvdec_h265 amvdec_h264mvc amvdec_mh264 amvdec_h264 amvdec_avs stream_input decoder_common firmware media_lock fuse ip_tables x_tables pv6 spidev spi_meson_spicc [ 80.930278] CPU: 1 PID: 3255 Comm: device 1 receiv Not tainted 4.9.337-31 #1 [ 80.937468] Hardware name: Hardkernel ODROID-N2Plus (DT) ... ... [ 82.101839] [<ffffff8009ca009c>] wait_for_common+0x9c/0x160 [ 82.107556] [<ffffff8009ca01d0>] wait_for_completion_timeout+0x30/0x40 [ 82.114231] [<ffffff8009992e40>] video_receiver_event_fun+0xd0/0x140 [ 82.120730] [<ffffff800987c39c>] vf_unreg_provider+0x138/0x1ec [ 82.126766] [<ffffff8001de3220>] vdec_release+0x70/0x430 [decoder_common] [ 82.133680] [<ffffff8001e2645c>] video_port_release+0x6c/0xc0 [stream_input] [ 82.140864] [<ffffff8001e28c6c>] amstream_release+0x1ec/0x310 [stream_input] [ 82.148032] [<ffffff800924ead0>] __fput+0xac/0x1fc [ 82.152969] [<ffffff800924eca4>] ____fput+0x24/0x30 [ 82.157998] [<ffffff80090cc7c8>] task_work_run+0xd8/0x110 [ 82.163544] [<ffffff80090bc088>] get_signal+0x708/0x7c0 [ 82.168917] [<ffffff800908b7a0>] do_signal+0x80/0xa94 [ 82.174117] [<ffffff800908c588>] do_notify_resume+0xa8/0xc0 [ 82.179836] [<ffffff80090836ac>] work_pending+0x8/0x10
die Plugin Optionen habe ich identisch zu der chroot Umgebung unter welcher es prima funktioniert:
-
-
-
-
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 -
Alle welche du zusammen mit dem epgd verwendest, also die epgd Plugins nicht die vdr Plugins
-
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. -
Zitat
Wenn ja schick mal die Letzte vor und die Erste nach so einer Deadlock Meldung, am besten den Bereich zw. den beiden.
-
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:
CodeUpdate 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?CodeFeb 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:
Code
Alles anzeigenroot@gate~> ll /var/log/vdr.log* -rw-r----- 1 syslog adm 290K Feb 21 09:41 /var/log/vdr.log -rw-r----- 1 syslog adm 886K Feb 20 23:59 /var/log/vdr.log.1 -rw-r----- 1 syslog adm 65K Feb 20 00:00 /var/log/vdr.log.2.gz -rw-r----- 1 syslog adm 59K Feb 19 00:00 /var/log/vdr.log.3.gz -rw-r----- 1 syslog adm 70K Feb 17 23:59 /var/log/vdr.log.4.gz -rw-r----- 1 syslog adm 62K Feb 16 23:59 /var/log/vdr.log.5.gz -rw-r----- 1 syslog adm 55K Feb 15 23:59 /var/log/vdr.log.6.gz -rw-r----- 1 syslog adm 90K Feb 14 23:59 /var/log/vdr.log.7.gz root@gate~> zgrep -i Deadlock /var/log/vdr.log* root@gate~>
-
Hier aber habe ich Einträge mit derselben IP drin, von denen einer einen leeren Port hat:
ja das eine ist der epgd da wird das nicht benötigt.
Sieht alles gut aus und erklärt nicht die locks. -
nein ist nicht egal, dafür u.a. trägt das Plugin den vdr in Tabelle ein:
CodeMariaDB [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
-
du kannst von dem Host auf welchem der eogd läuft alle vdrs mit svdrpsend über die jeweils in der vdrs Tabelle eingetragenen IP erreichen?
-
Das interface im setup Menü des epg2vdr