yavdr ansible

seahawk1986  horchi vielen Dank für eure Unterstützung.

Der Update ist drin, ich werde berichten. Kann aber ein paar Tage dauern, bin unterwegs.

Noch ein Hinweis: Alle meine Timer sind ohne VPS. Somit müsste o.g. Ausdruck eh auch false liefern.

Ich möchte auch noch kurz eine Rückmeldung geben.

Auch bei mir kam es zu keinen Abstürzen mehr, seit das live-Plugin aktualisiert wurde.

Hier gab es bei Beendigung eines Timers doch noch einen VDR-Absturz:

Feb 19 02:55:00 ubuntuwz vdr: [1319] timer 18 (16 0225-0255 'alpha-Centauri~alpha-Centauri') stop
Feb 19 02:55:00 ubuntuwz vdr: [1319] removing /srv/vdr/video/alpha-Centauri/alpha-Centauri/2019-02-19.02.25.16-0.rec/.timer
Feb 19 02:55:00 ubuntuwz vdr: [1319] executing '/usr/lib/vdr/vdr-recordingaction after "/srv/vdr/video/alpha-Centauri/alpha-Centauri/2019-02-19.02.25.16-0.rec"'
Feb 19 02:55:00 ubuntuwz vdr: [4871] EPGSearch: recdone thread started (pid=1319, tid=4871, prio=high)
Feb 19 02:55:00 ubuntuwz recordingaction: executing /usr/share/vdr/recording-hooks/R90.custom after recording /srv/vdr/video/alpha-Centauri/alpha-Centauri/2019-02-19.02.25.16-0.rec as shell script
Feb 19 02:55:00 ubuntuwz vdr: [4871] EPGSearch: recdone thread ended (pid=1319, tid=4871)
Feb 19 02:55:00 ubuntuwz kernel: [19262.703361] show_signal_msg: 5 callbacks suppressed
Feb 19 02:55:00 ubuntuwz kernel: [19262.703365] epg2vdr-update[1383]: segfault at a0 ip 00007f89b6f4a225 sp 00007f898d7f9c90 error 4 in libvdr-epg2vdr.so.2.4.0[7f89b6ef8000+b6000]
Feb 19 02:55:00 ubuntuwz yavdr-frontend[1508]: INFO:pydbus2vdr:VDR Status: stopped
Feb 19 02:55:00 ubuntuwz yavdr-frontend[1508]: DEBUG:yavdr_frontend.frontends.genericfrontend:g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name de.tvdr.vdr was not provided by a
Feb 19 02:55:00 ubuntuwz systemd[1]: vdr.service: Main process exited, code=killed, status=11/SEGV
Feb 19 02:55:00 ubuntuwz systemd[1]: vdr.service: Failed with result 'signal'.
Feb 19 02:55:00 ubuntuwz systemd[1]: vdr.service: Service hold-off time over, scheduling restart.
Feb 19 02:55:00 ubuntuwz systemd[1]: vdr.service: Scheduled restart job, restart counter is at 1.
Feb 19 02:55:00 ubuntuwz systemd[1]: Starting Preprocess NFS configuration...
Feb 19 02:55:00 ubuntuwz systemd[1]: Stopped Video Disk Recorder.
Feb 19 02:55:00 ubuntuwz systemd[1]: Starting Video Disk Recorder...
Feb 19 0

horchi seit 2 Tage kein Crash, ich denke, das ist schon die richtige Stelle.

Um das Problem weiter einzugrenzen habe ich den Code wie folgt geändert:

bool vpsUsed1 = rr->timer->HasFlags(tfVps);
bool vpsUsed2 = rr->timer->Event();
bool vpsUsed3 = rr->timer->Event()->Vps();
bool vpsUsed = vpsUsed1 && vpsUsed2 && vpsUsed3;

Dann sehen wir, welche der 3 Funktionen das Problem verursacht. Ich melde mich mit dem nächsten Backtrace wieder.

Die Aussagen sind nicht eindeutig:

yavdr ansible

Da seahawk1986 es ins experimental-main vom yavdr ansible hochgeladen hatte, hatte ich es installiert. Jetzt habe ich es wieder entfernt.

MfG

horchi Hallo, ich habe jetzt den Backtrace von dem geänderten Code. Hilft dir das weiter ?

Program terminated with signal SIGSEGV, Segmentation fault.
#0  cUpdate::performRecordingActions (this=this@entry=0x5581aa4cc320) at status.c:210
210                 bool vpsUsed = vpsUsed1 && vpsUsed2 && vpsUsed3;
[Current thread is 1 (Thread 0x7f310abea700 (LWP 15227))]


(gdb) bt full
#0  cUpdate::performRecordingActions (this=this@entry=0x5581aa4cc320) at status.c:210
        pendingTimer = 0x0
        timerLengthSecs = 0
        vpsUsed2 = true
        pRecording = 0x5581ab862730
        complete = <optimized out>
        recFraction = 100
        vpsUsed1 = false
        vpsUsed3 = <error reading variable vpsUsed3 (Cannot access memory at address 0x110)>
        vpsUsed = <optimized out>
        rr = 0x5581ab8e4100
        lock = {mutex = 0x5581aa4cc578, locked = true}
        action = {name = "", fileName = "/srv/vdr/video/Archiv_9/Series/Köln_50667/2019-02-20_18#3A05-Reality_(D_2019)/2019-02-20.18.03.22-9.rec", cardIndex = 0,
          on = false}
        Timers_Lock = {stateKey = {stateLock = 0x5581a8939b00 <cTimers::timers+32>, write = false, state = -1, timedOut = false},
          list = 0x5581a8939ae0 <cTimers::timers>}
        Timers = <optimized out>
        timers = 0x5581a8939ae0 <cTimers::timers>
        Recordings_Lock = {stateKey = {stateLock = 0x5581a8931800 <cRecordings::recordings+32>, write = false, state = -1, timedOut = false},
          list = 0x5581a89317e0 <cRecordings::recordings>}
        Recordings = <optimized out>
        recordings = <optimized out>
#1  0x00007f3124c071c7 in cUpdate::Action (this=0x5581aa4cc320) at update.c:1339
        reconnectTimeout = 10
#2  0x00005581a8659005 in cThread::StartThread (Thread=0x5581aa4cc320) at thread.c:293
No locals.
#3  0x00007f312874e6db in start_thread (arg=0x7f310abea700) at pthread_create.c:463
        pd = 0x7f310abea700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139848610391808, -4109227939369886069, 139848610389824, 0, 94015396299552, 140726305125232, 4078857773549313675,
                4078930974559919755}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#4  0x00007f3126da988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.

Hallo seahawk1986 ,

bin grad wieder am Testen.

Den Ansatz mit Ansible finde ich echt geil. Vielen Dank dafür

Ich möchte zukünftig meine VDRs von einem zentralen Rechner administrieren und nutze deshalb Dein Playbook remote.

Da mein Hauptrechner mit Siduction (Debian Sid) läuft, sind da natürlich, durch unterschiedlichen Distris, Probleme zu erwarten.

Ein Problem habe ich identifiziert, vielleicht kannst Du die Lösung ins GIT übernehmen.

Die Jinja2 Templates machen aufgrund des iteritems() Probleme, Python3 kennt diese Methode nicht mehr.

Laut Ansible kann man den Code einfach ändern. Habe ich probiert und funktioniert bei mir.

Betroffen sind diese Dateien:

20-intel.conf.j2
nfs-exports.j2
smb.conf.j2

Geändert werden sollte:

iteritems()
ÄNDERN IN
items() | list

Gruß

Frank

Zitat von minixjr

Ein Problem habe ich identifiziert, vielleicht kannst Du die Lösung ins GIT übernehmen.

Bitte sehr: https://github.com/yavdr/yavdr…3f9adca0c5a895996d886c7a0

Perfekt, Danke.

Noch eine Frage.

Laut Manual.html gibt es eine einen Treiber "drivers: sundtek: auto" und eine Rolle "install-sundtek", im GIT finde ich die aber nicht.

Wie komme ich da ran?

Ich persönlich brauche kein HotPlug, mir würde es reichen wenn der Stick (DVB-S) standardmäßig eingebunden wird.

Habe ich jetzt manuell gemacht, aber im playbook wäre es natürlich schöner. So was wie Rolle sundtek-static, bis es eine Lösung mit dynamite gibt.

Gruß

Frank

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

Zitat von Paulaner

Welches softhddevice-Plugin soll ich dafür nehmen bzw. worin unterscheiden sich die ganzen 4 softhddevice-Plugins?

Wenn du 8-Bit HEVC-Material brauchst z.B. das vdr-plugin-softhddevice-vdpau-hevc (das wird gegen eine etwas ältere ffmpeg-Version gebaut, weil mit ffmpeg 3.4 die hardwarebeschleunigung für HEVC mit VDPAU nicht mehr geht), ansonsten vermutlich das vdr-plugin-softhddevice-openglosd, wenn du auf HEVC verzichten kannst, aber ein OSD mit Hardwarebeschleunigung haben willst.

Dann bleiben noch vdr-plugin-softhddevice-vpp - das entspricht dem letzten Stand aus dem Branch von rofafor vor der Abspaltung von vaapidevice (und funktioniert mit VDPAU und VA-API, weshalb das vom Playbook vorinstalliert wird) und vdr-plugin-softhddevice-hevc, das https://github.com/jojo61/vdr-plugin-softhddevice entspricht, bei dem jojo61 mit CUVID-Decoding bei VDPAU-Ausgabe (in 8 Bit) gespielt hatte.

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.

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:

...
Feb 26 10:54:54 yaVDR vdr: video: 26:20:57.870  +30  403   0/\ms  66+3+4 v-buf
Feb 26 10:55:54 yaVDR vdr: video: 26:21:57.870  +30  371   0/\ms  60+3+4 v-buf
Feb 26 10:56:54 yaVDR vdr: video: 26:22:57.870  +30  371   0/\ms  60+3+4 v-buf
Feb 26 10:57:54 yaVDR vdr: video: 26:23:57.870  +30  403   0/\ms  70+3+4 v-buf
Feb 26 10:58:54 yaVDR vdr: video: 26:24:57.870  +30  371   0/\ms  67+3+4 v-buf
Feb 26 10:59:54 yaVDR vdr: video: 26:25:57.870  +30  403   0/\ms  72+3+4 v-buf
Feb 26 11:00:54 yaVDR vdr: video: 26:26:57.870  +30  371   0/\ms  65+3+4 v-buf
...

Ich würde gern wissen wo das her kommt, damit ich das weg bekomme.

Paul

Die Meldungen sind doch aber normal beim softhddevice. Ob man es rausfiltern kann, keine Ahnung. Wenn das genau so im Abstand von 1min kommt, läuft dein softhddevice perfekt.

Lt. Wiki liegt ein Problem vor, wenn diese Meldungen öfter als im Abstand von 1min kommen.

Zitat von ofenheizer

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!

also ich habe die Meldungen sogar auf einem alten yavdr-0.5 und kenne die auch von meinem yavdr-0.6. das hat johns damals so in sein softhddevice eingebaut. inwieweit die vielen forks das übernommen haben, keine ahnung.

es gibt bestimmt eine möglichkeit das im syslog zu filtern, dass die nicht geschrieben werden.

Etwas in dieser Art sollte diese (und andere "unschöne" Ausgaben) unterdrücken:

root@htpc:/etc/rsyslog.d# cat 22-vdr.conf 
:msg, contains, "SVDRP htpc < " stop
:msg, contains, "SVDRP htpc > " stop
:msg, contains, "VNSI: Requesting clients to reload" stop
:msg, contains, " v-buf" stop

An Stelle von htpc ist natürlich der eigene Hostname einzutragen.

Anschließend noch ein systemctl reload syslog.service absetzen.

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.

Cheers,

Ole

Zitat von OleS

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!

seahawk1986

Hallo,

Das vdr-plugin-xmltv2vdr in deinem PPA sieht die eplists nicht, da es das Verzeichnis unter dem Home Verzeichnis sucht. Könntest du vielleicht die xmltv2vdr.conf Datei mit dem richtigen Pfad versehen?

[xmltv2vdr]
-e /var/cache/eplists/episodes

Und wenn du schon dabei bist, was hälst du davon auch den Ort zu verlegen, wo xmltv2vdr die Importierten EPG Daten speichert. Per default kommen sie auf die Aufnahmeplatte. Wäre es nicht sinnvoll sie nach/var/cache/vdr zu verlegen?

MfG

Wenn das xmltv2vdr plugin die eplists vom vdr-addon-seriestimer sieht, erscheint im xmltv2vdr die Option, es zu aktivieren. Jedoch wenn ich es aktivere, erhalte ich Abstürze. Kann jemand es bestätigen oder ist es ein Problem lokal bei mir?

MfG