Produktive Problem- und Pluginlösungen für VDR 2.3.2 und höher

kls · 3. Januar 2017

Beiliegender Patch macht osdteletext-0.9.5 (Source von hier) mit VDR 2.3.2 übersetzbar.
Ein kurzer Test hat auch funktioniert, Teletext wurde angezeigt. Ob alles läuft sollte mal jemand testen, der das tatsächlich verwendet.

ACHTUNG: da dieses Plugin die Funktion cOsd::GetBitmap() verwendet muß im VDR-Header-File osd.h die Zeile

//#define DEPRECATED_GETBITMAP

durch Entfernen der '//' aktiviert werden. Irgendwann wird das mal jemand ändern müssen, so daß das Plugin ohne diese Funktion auskommt.

Klaus

kls · 3. Januar 2017

Beiliegender Patch macht dvbhddevice (für die TT S2-6400) mit VDR 2.3.2 übersetzbar.
Das Plugin ist bei mir im produktiven Einsatz und funktioniert damit.

Klaus

fnu · 4. Januar 2017

Ich habe die fast 42 produktiven Posts zu Lösungen rund um VDR Developer 2.3.2 und höher mal aus dem News Thread [ANNOUNCE] VDR developer version 2.3.2 in diesen neuen Thread unter VDR Core ausgelagert.

Leider sind einige Posts nicht sehr produktiv, vorallem vom Nutzer speed.

speed

Du kannst natürlich Deine Meinung hier kundtun, aber bitte ohne frech und beleidigend zu werden. Beleidigungen wie gegen jsffm möchte ich hier bitte nicht mehr von Dir lesen!

Das vdr-portal.de hat Nutzungsbedingungen, welche jeder User bei Anmeldung akzeptiert hat und sich dran halten wird. Bitte richte Dein Augenmerk auf §1:

Zitat von genka

1. Höflichkeit
Achten Sie auf Höflichkeit. Bitte bedenken Sie, dass sich hinter jeder Nachricht ein Mensch befindet. Auch wenn eine Diskussion einmal kontrovers geführt wird, dürfen keinerlei beleidigende, beschimpfende oder persönlichkeitsverletzende Äußerungen getroffen werden. Behandeln Sie andere so, wie Sie auch behandelt werden wollen.

kls

Vielen Dank für Deine Mühen, ich werde mich bemühen all die Anpassung ASAP zu testen.

Regards
fnu

seahawk1986 · 4. Januar 2017

Ich habe den VDR 2.3.2 mit dem streamdev-client Plugin (aktuelle Git-Version) auf einem Rasbperry Pi 2 Modell B. Wenn ich mittels SVDRP mit ca. 0,5 - 1 Sekunde Verzögerung zwischen den Befehlen durch die Kanäle zappe, hängt sich der VDR reproduzierbar auf, svdrpsend meldet dann nur noch timeouts und einige Zeit später beendet sich der VDR mit dem Exit-Code 1. Leider schaffe ich es nicht mit gdb einen Backtrace zu erzeugen, da der Stack danach leer ist:

gdb vdr

Code

(gdb) run
Starting program: /usr/bin/vdr
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7181d3f0 (LWP 7201)]
[New Thread 0x7101d3f0 (LWP 7202)]
[Thread 0x7101d3f0 (LWP 7202) exited]
[New Thread 0x7101d3f0 (LWP 7203)]
[New Thread 0x704ff3f0 (LWP 7204)]
[New Thread 0x6fcff3f0 (LWP 7205)]
[New Thread 0x6f4ff3f0 (LWP 7206)]
[New Thread 0x6ecff3f0 (LWP 7207)]
[New Thread 0x6e4ff3f0 (LWP 7208)]
[New Thread 0x6dcff3f0 (LWP 7209)]
[New Thread 0x6d4ff3f0 (LWP 7210)]
[New Thread 0x6ccff3f0 (LWP 7211)]
[New Thread 0x6c4ff3f0 (LWP 7212)]
[New Thread 0x6baff3f0 (LWP 7213)]
[New Thread 0x6b2ff3f0 (LWP 7214)]
[New Thread 0x6a8ff3f0 (LWP 7215)]
[New Thread 0x6a0ff3f0 (LWP 7216)]
[New Thread 0x698ff3f0 (LWP 7217)]
[New Thread 0x690ff3f0 (LWP 7218)]
[New Thread 0x688ff3f0 (LWP 7219)]
[New Thread 0x680ff3f0 (LWP 7220)]
[New Thread 0x670ff3f0 (LWP 7222)]
[New Thread 0x678ff3f0 (LWP 7221)]
[Thread 0x678ff3f0 (LWP 7221) exited]
[Thread 0x698ff3f0 (LWP 7217) exited]
[New Thread 0x698ff3f0 (LWP 7223)]
[New Thread 0x678ff3f0 (LWP 7228)]
[Thread 0x698ff3f0 (LWP 7223) exited]
[Thread 0x680ff3f0 (LWP 7220) exited]
[New Thread 0x680ff3f0 (LWP 7231)]
[New Thread 0x698ff3f0 (LWP 7232)]
[Thread 0x7181d3f0 (LWP 7201) exited]
[Thread 0x698ff3f0 (LWP 7232) exited]
[Thread 0x680ff3f0 (LWP 7231) exited]
[New Thread 0x680ff3f0 (LWP 7235)]
[New Thread 0x698ff3f0 (LWP 7236)]
[Thread 0x698ff3f0 (LWP 7236) exited]
[Thread 0x680ff3f0 (LWP 7235) exited]
[New Thread 0x680ff3f0 (LWP 7240)]
[New Thread 0x698ff3f0 (LWP 7242)]
[Thread 0x698ff3f0 (LWP 7242) exited]
[Thread 0x680ff3f0 (LWP 7240) exited]
[New Thread 0x680ff3f0 (LWP 7246)]
[New Thread 0x698ff3f0 (LWP 7247)]
[Thread 0x698ff3f0 (LWP 7247) exited]
[Thread 0x680ff3f0 (LWP 7246) exited]
[New Thread 0x680ff3f0 (LWP 7250)]
[New Thread 0x698ff3f0 (LWP 7251)]
[Thread 0x698ff3f0 (LWP 7251) exited]
[Thread 0x680ff3f0 (LWP 7250) exited]
[New Thread 0x680ff3f0 (LWP 7253)]
[New Thread 0x698ff3f0 (LWP 7256)]
[Thread 0x698ff3f0 (LWP 7256) exited]
[Thread 0x680ff3f0 (LWP 7253) exited]
[New Thread 0x680ff3f0 (LWP 7257)]
[New Thread 0x698ff3f0 (LWP 7258)]
[Thread 0x680ff3f0 (LWP 7257) exited]
[New Thread 0x680ff3f0 (LWP 7260)]
[Thread 0x680ff3f0 (LWP 7260) exited]
[Thread 0x698ff3f0 (LWP 7258) exited]
[New Thread 0x698ff3f0 (LWP 7263)]
[New Thread 0x680ff3f0 (LWP 7264)]
[Thread 0x680ff3f0 (LWP 7264) exited]
[Thread 0x698ff3f0 (LWP 7263) exited]
[New Thread 0x698ff3f0 (LWP 7267)]
[New Thread 0x680ff3f0 (LWP 7268)]
[Thread 0x680ff3f0 (LWP 7268) exited]
[Thread 0x698ff3f0 (LWP 7267) exited]
[New Thread 0x698ff3f0 (LWP 7270)]
[New Thread 0x680ff3f0 (LWP 7271)]
[Thread 0x6a8ff3f0 (LWP 7215) exited]
[Thread 0x678ff3f0 (LWP 7228) exited]
[Thread 0x690ff3f0 (LWP 7218) exited]
[Thread 0x688ff3f0 (LWP 7219) exited]
[Thread 0x680ff3f0 (LWP 7271) exited]
[Thread 0x698ff3f0 (LWP 7270) exited]
[Thread 0x670ff3f0 (LWP 7222) exited]
[Thread 0x6a0ff3f0 (LWP 7216) exited]
[Thread 0x6b2ff3f0 (LWP 7214) exited]
[Thread 0x6baff3f0 (LWP 7213) exited]
[Thread 0x6c4ff3f0 (LWP 7212) exited]
[Thread 0x6ccff3f0 (LWP 7211) exited]
[Thread 0x6d4ff3f0 (LWP 7210) exited]
[Thread 0x6e4ff3f0 (LWP 7208) exited]
[Thread 0x6ecff3f0 (LWP 7207) exited]
[Thread 0x6f4ff3f0 (LWP 7206) exited]
[Thread 0x6fcff3f0 (LWP 7205) exited]
[Thread 0x704ff3f0 (LWP 7204) exited]
[Thread 0x7101d3f0 (LWP 7203) exited]
[Thread 0x76ff3380 (LWP 7199) exited]
[Inferior 1 (process 7199) exited with code 01]
(gdb) bt
No stack.

Alles anzeigen

Mit dem satip-Plugin kann ich eine Schleife wie

Code

while true; do svdrpsend chan +; sleep 0.5; svdrpsend chan +; svdrpsend hitk up; sleep 1; svdrpsend hitk down; svdrpsend hitk down; done

hingegen über Minuten ohne Hänger ausführen.

Interessant ist aber, dass der VDR crasht, wenn man svdrpsend mitten in seiner Ausführung abschießt (ist mir aufgefallen, als ich die Endlosschleife mit STRG+C abgebrochen habe), das lässt sich aber auch mit einem einzelnen svdrpsend-Befehl reproduzieren, mit dem sleep muss man ein bisschen spielen, je nachdem wie schnell das System ist):

Code

svdrpsend LSTE & sleep 0.2; kill $!

Backtrace

Code

Thread 30 "SVDRP server ha" received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x635ff3f0 (LWP 10215)]
0x76f5df48 in write () from /usr/lib/libpthread.so.0
(gdb) bt
#0  0x76f5df48 in write () at /usr/lib/libpthread.so.0
#1  0x00121904 in safe_write(int, void const*, unsigned int) (filedes=6, buffer=<optimized out>, size=26)
    at tools.c:71
#2  0x00113c7c in cSVDRPServer::Send(char const*, int) (this=0x70417458, s=<optimized out>, length=<optimized out>)
    at svdrp.c:1027
#3  0x00113820 in cSVDRPServer::Reply(int, char const*, ...) (this=this@entry=0x70417458, Code=Code@entry=250, fmt=0x13db3c "%d %s") at svdrp.c:1051
#4  0x00114074 in cSVDRPServer::CmdCHAN(char const*) (this=0x70417458, Option=0x7040d68d "+") at svdrp.c:1146
#5  0x0011a390 in cSVDRPServer::Process() (this=0x70417458) at svdrp.c:2387
#6  0x0011a5b8 in cSVDRPServerHandler::ProcessConnections() (this=this@entry=0x420490) at svdrp.c:2494
#7  0x0011a7bc in cSVDRPServerHandler::Action() (this=0x420490) at svdrp.c:2518
#8  0x0011c920 in cThread::StartThread(cThread*) (Thread=0x420490) at thread.c:288
#9  0x76f53fbc in start_thread () at /usr/lib/libpthread.so.0
(gdb) bt full
#0  0x76f5df48 in write () at /usr/lib/libpthread.so.0
#1  0x00121904 in safe_write(int, void const*, unsigned int) (filedes=6, buffer=<optimized out>, size=26)
    at tools.c:71
        p = 0
        written = 26
        ptr = 0x70410d28 "28 Hope Channel (Internet)"
#2  0x00113c7c in cSVDRPServer::Send(char const*, int) (this=0x70417458, s=<optimized out>, length=<optimized out>)
    at svdrp.c:1027
#3  0x00113820 in cSVDRPServer::Reply(int, char const*, ...) (this=this@entry=0x70417458, Code=Code@entry=250, fmt=0x13db3c "%d %s") at svdrp.c:1051
        cont = <optimized out>
        number = "250 \000\000\000\000\000\000\000\000\000\355_c"
        ap = {__ap = 0x635fed04}
        buffer = {_vptr.cString = 0x16cbf0 <vtable for cString+8>, s = 0x70410d28 "28 Hope Channel (Internet)"}
        s = 0x70410d28 "28 Hope Channel (Internet)"
#4  0x00114074 in cSVDRPServer::CmdCHAN(char const*) (this=0x70417458, Option=0x7040d68d "+") at svdrp.c:1146
        Channel = <optimized out>
        ChannelsLock =
    {stateKey = {stateLock = 0x16fcbc <cChannels::channels+16>, write = false, state = -1, timedOut = false}, list = 0x16fcac <cChannels::channels>}
#5  0x0011a390 in cSVDRPServer::Process() (this=0x70417458) at svdrp.c:2387
        c = 10 '\n'
        r = <optimized out>
#6  0x0011a5b8 in cSVDRPServerHandler::ProcessConnections() (this=this@entry=0x420490) at svdrp.c:2494
        i = <optimized out>
        MutexLock = {mutex = 0x4204c4, locked = true}
#7  0x0011a7bc in cSVDRPServerHandler::Action() (this=0x420490) at svdrp.c:2518
        MutexLock = {mutex = 0x4204c4, locked = true}
#8  0x0011c920 in cThread::StartThread(cThread*) (Thread=0x420490) at thread.c:288
#9  0x76f53fbc in start_thread () at /usr/lib/libpthread.so.0

Alles anzeigen

Der VDR 2.2.0 reagiert da im Vergleich deutlich gelassener, wenn man das macht:

Code

Jan  4 08:26:41 VDR vdr: [1421] connect from 127.0.0.1, port 44370 - accepted
Jan  4 08:26:42 VDR vdr: [1421] ERROR (svdrp.c,428): Datenübergabe unterbrochen (broken pipe)
Jan  4 08:26:42 VDR vdr: [1421] closing SVDRP connection

fnu · 4. Januar 2017

Zitat von jsffm

iptv

Nachtrag, ein Blick in rofafor's git Repo von vdr-plugin-iptv zeigt, dass die nötigen 2.3.1 Anpassungen schon letzten September durchgeführt wurden.

=> https://github.com/rofafor/vdr…37fd61b6f412563f200b33abd

Das gilt im übrigen auch für seine anderen Plugins satip, femon, skinsoppalusikka. Mag sein das die Änderungen noch nicht in den Upstream .tar.gz reflektiert sind.

Regards
fnu

kls · 4. Januar 2017

seahawk1986: ich habe das jetzt auf zwei VDRs (PC mit TT S2-6400 und RasPi mit satip) probiert, mit beiden Varianten deiner SVDRP-Befehle, auch mit Abbrechen durch Ctrl+C, konnte aber keinen VDR-Absturz herbeiführen.
Streamdev verwende ich allerdings nicht, so daß ich nicht ausschließen kann, daß der Fehler eventuell dort liegt.
Gibt es denn auch ein Szenario, wo der Fehler ohne streamdev auftritt?

Klaus

jsffm · 4. Januar 2017

fnu

Der aktuelle git compiliert, danke.

seahawk1986 · 4. Januar 2017

Zitat von kls

Gibt es denn auch ein Szenario, wo der Fehler ohne streamdev auftritt?

Den Crash beim Abbruch der Telnetverbindung kann ich ohne streamdev provozieren - ich habe svdrpsend mal so angepasst, dass es den Crash bei mir zuverlässig auslöst:

svdpsend

Man muss also einen Befehl wie LSTE abschicken, einen Teil der Antwort lesen (in der Funktion ReceiveRigged) und dann die Verbindung hart kappen, indem man das Programm beendet.

gdb backtrace

Code

Thread 29 "SVDRP server ha" received signal SIGPIPE, Broken pipe.
0x76b20948 in write () from /usr/lib/libc.so.6
(gdb) bt
#0  0x76b20948 in write () at /usr/lib/libc.so.6
#1  0x76ac8160 in _IO_new_file_write () at /usr/lib/libc.so.6
#2  0x76ac733c in new_do_write () at /usr/lib/libc.so.6
#3  0x76ac9334 in __GI__IO_do_write () at /usr/lib/libc.so.6
#4  0x76ac882c in __GI__IO_file_xsputn () at /usr/lib/libc.so.6
#5  0x76aa1cfc in vfprintf () at /usr/lib/libc.so.6
#6  0x76aa7260 in fprintf () at /usr/lib/libc.so.6
#7  0x000a6c98 in cEvent::Dump(_IO_FILE*, char const*, bool) const (this=this@entry=0x70468118, f=f@entry=0x7050d720, Prefix=Prefix@entry=0x142b30 "215-", InfoOnly=InfoOnly@entry=false) at epg.c:453
#8  0x000a6f5c in cSchedule::Dump(_IO_FILE*, char const*, eDumpMode, long) const (this=this@entry=0x7043dfe8, f=f@entry=0x7050d720, Prefix=Prefix@entry=0x142b30 "215-", DumpMode=DumpMode@entry=dmAll, AtTime=AtTime@entry=0) at epg.c:1101
#9  0x000a706c in cSchedules::Dump(_IO_FILE*, char const*, eDumpMode, long) (f=0x7050d720, Prefix=0x142b30 "215-", DumpMode=DumpMode@entry=dmAll, AtTime=AtTime@entry=0) at epg.c:1268
#10 0x00116834 in cSVDRPServer::CmdLSTE(char const*) (this=<optimized out>, Option=0x7050b694 "") at svdrp.c:1668
#11 0x0011a390 in cSVDRPServer::Process() (this=0x7050b650) at svdrp.c:2387
#12 0x0011a5b8 in cSVDRPServerHandler::ProcessConnections() (this=this@entry=0x447c28) at svdrp.c:2494
#13 0x0011a7bc in cSVDRPServerHandler::Action() (this=0x447c28) at svdrp.c:2518
#14 0x0011c920 in cThread::StartThread(cThread*) (Thread=0x447c28) at thread.c:288
#15 0x76f53fbc in start_thread () at /usr/lib/libpthread.so.0
(gdb) bt full
#0  0x76b20948 in write () at /usr/lib/libc.so.6
#1  0x76ac8160 in _IO_new_file_write () at /usr/lib/libc.so.6
#2  0x76ac733c in new_do_write () at /usr/lib/libc.so.6
#3  0x76ac9334 in __GI__IO_do_write () at /usr/lib/libc.so.6
#4  0x76ac882c in __GI__IO_file_xsputn () at /usr/lib/libc.so.6
#5  0x76aa1cfc in vfprintf () at /usr/lib/libc.so.6
#6  0x76aa7260 in fprintf () at /usr/lib/libc.so.6
#7  0x000a6c98 in cEvent::Dump(_IO_FILE*, char const*, bool) const (this=this@entry=0x70468118, f=f@entry=0x7050d720, Prefix=Prefix@entry=0x142b30 "215-", InfoOnly=InfoOnly@entry=false) at epg.c:453
#8  0x000a6f5c in cSchedule::Dump(_IO_FILE*, char const*, eDumpMode, long) const (this=this@entry=0x7043dfe8, f=f@entry=0x7050d720, Prefix=Prefix@entry=0x142b30 "215-", DumpMode=DumpMode@entry=dmAll, AtTime=AtTime@entry=0) at epg.c:1101
        p = 0x70468118
        Channel = <optimized out>
        ChannelsLock =
          {stateKey = {stateLock = 0x16fcbc <cChannels::channels+16>, write = false, state = -1, timedOut = false}, list = 0x16fcac <cChannels::channels>}
        __FUNCTION__ = "Dump"
#9  0x000a706c in cSchedules::Dump(_IO_FILE*, char const*, eDumpMode, long) (f=0x7050d720, Prefix=0x142b30 "215-", DumpMode=DumpMode@entry=dmAll, AtTime=AtTime@entry=0) at epg.c:1268
        p = 0x7043dfe8
        sf = 0x0
        SchedulesLock =
          {stateKey = {stateLock = 0x171404 <cSchedules::schedules+16>, write = false, state = -1, timedOut = false}, list = 0x1713f4 <cSchedules::schedules>}
#10 0x00116834 in cSVDRPServer::CmdLSTE(char const*) (this=<optimized out>, Option=0x7050b694 "") at svdrp.c:1668
        f = 0x7050d720
        SchedulesLock =
          {stateKey = {stateLock = 0x171404 <cSchedules::schedules+16>, write = false, state = -1, timedOut = false}, list = 0x1713f4 <cSchedules::schedules>}
        Schedule = 0x0
        DumpMode = dmAll
        AtTime = 0
        fd = 17
#11 0x0011a390 in cSVDRPServer::Process() (this=0x7050b650) at svdrp.c:2387
        c = 10 '\n'
        r = <optimized out>
#12 0x0011a5b8 in cSVDRPServerHandler::ProcessConnections() (this=this@entry=0x447c28) at svdrp.c:2494
        i = <optimized out>
        MutexLock = {mutex = 0x447c5c, locked = true}
#13 0x0011a7bc in cSVDRPServerHandler::Action() (this=0x447c28) at svdrp.c:2518
        MutexLock = {mutex = 0x447c5c, locked = true}
#14 0x0011c920 in cThread::StartThread(cThread*) (Thread=0x447c28) at thread.c:288
#15 0x76f53fbc in start_thread () at /usr/lib/libpthread.so.0

Alles anzeigen

TomJoad · 4. Januar 2017

Zur Erinnerung:
In diesem Post gibt es einen Patch für osdteletext, wo u.a. auch auf DEPRECATED_GETBITMAP verzichtet werden kann, weil mit pixmaps gearbeitet wird. Die Änderungen sehen auch ohne Highlevel-OSD gut aus. Man braucht nur zusätzlich den ttf-Font aus dem Thread.

Zitat von kanadakruemel

Hallo,
hier ist die aktuelle Version meines OSDTeletxt TTF Patches.

Gruß,
kanadakruemel

kls · 4. Januar 2017

Hab's mit deinem Script auf beiden VDRs probiert, aber keinen Absturz provozieren können.

Code

Jan  4 12:09:38 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33826 client connection accepted
Jan  4 12:09:38 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33826 server created
Jan  4 12:09:40 raspi4 vdr: [2410] ERROR (svdrp.c,1027): Broken pipe
Jan  4 12:09:40 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33826 connection closed
Jan  4 12:09:40 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33826 server destroyed
Jan  4 12:09:40 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33827 client connection accepted
Jan  4 12:09:40 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33827 server created
Jan  4 12:09:42 raspi4 vdr: [2410] ERROR (svdrp.c,1027): Broken pipe
Jan  4 12:09:42 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33827 connection closed
Jan  4 12:09:42 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33827 server destroyed
Jan  4 12:09:42 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33828 client connection accepted
Jan  4 12:09:42 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33828 server created
Jan  4 12:09:44 raspi4 vdr: [2410] ERROR (svdrp.c,1027): Broken pipe
Jan  4 12:09:44 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33828 connection closed
Jan  4 12:09:44 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33828 server destroyed
Jan  4 12:09:44 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33829 client connection accepted
Jan  4 12:09:44 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33829 server created
Jan  4 12:09:47 raspi4 vdr: [2410] ERROR (svdrp.c,1027): Broken pipe
Jan  4 12:09:47 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33829 connection closed
Jan  4 12:09:47 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33829 server destroyed
Jan  4 12:09:47 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33830 client connection accepted
Jan  4 12:09:47 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33830 server created
Jan  4 12:09:49 raspi4 vdr: [2410] ERROR (svdrp.c,1027): Broken pipe
Jan  4 12:09:49 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33830 connection closed
Jan  4 12:09:49 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33830 server destroyed
Jan  4 12:09:49 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33831 client connection accepted
Jan  4 12:09:49 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33831 server created
Jan  4 12:09:51 raspi4 vdr: [2410] ERROR (svdrp.c,1027): Broken pipe
Jan  4 12:09:51 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33831 connection closed
Jan  4 12:09:51 raspi4 vdr: [2410] SVDRP < 192.168.1.11:33831 server destroyed

Alles anzeigen

Klaus

jsffm · 4. Januar 2017

In dem Patch von kanadakruemel für osdteletext sind die Änderungnen für 2.3.x schon drin, der Patch von Klaus braucht nicht eingespielt zu werden.

jrie · 4. Januar 2017

[PATCH] statusleds für VDR 2.3.2

Diff

diff -Nrup statusleds/statusleds.c statusleds.neu/statusleds.c
--- statusleds/statusleds.c	2012-03-27 00:11:32.000000000 +0200
+++ statusleds.neu/statusleds.c	2017-01-04 18:37:45.000000000 +0100
@@ -529,8 +529,9 @@ void cRecordingPresignal::Action(void)
   for(active = true; active;)
   {
     // get next timer
-    cTimer * NextTimer = Timers.GetNextActiveTimer();
-
+    {
+    LOCK_TIMERS_READ;
+    const cTimer * NextTimer = Timers->GetNextActiveTimer();
 
     if (iConsole >= 0 && NextTimer)
     {
@@ -558,6 +559,7 @@ void cRecordingPresignal::Action(void)
         }
       }
     }
+    }
 
     sleep(1);
   }

Alles anzeigen

Man beachte die hinzugefügten Klammern vor dem Makro und am Ende, die sind zwingend nötig.

jinx · 4. Januar 2017

Does anyone have a patch for vdr-eepg so it works with 2.3.x? The plugin may have been abandon by its' author, I'm not sure. If any coder has a free moment, please have a look at it - perhaps it's an easy fix?

Thanks

fnu · 6. Januar 2017

Angehängt der Patch den ich zum Paketbau von vdr-plugin-markad gegen VDR 2.3.2 verwendet habe.

[EDIT] Aktualisierte Version mit Abfrage nach VDR API Version ...

Regards
fnu

fnu · 6. Januar 2017

Ich weiß es ist alt, alle sagen das nutzt man nimmer und drehen die Augen. Dennoch gibt es viele da draussen die noch tomas' Anthra Skins mögen und benutzen, wenn's also hilft die Verbreitung von VDR Developer 2.3.2 zu erhöhen ...

Im Anhang zwei Patches die den letzten mir bekannten GIT Stand fit machen für vdr-2.1.2+ bzw. dann auch für vdr-2.3.2.

Aber Achtung an die Paketbauer! Das historisch gewachsene Debian/Ubuntu Paket was wir verwenden, enthält weitere Patches welche aktiv angepasst werden müssen. Das sind diese die mal jemand sinnvollerweise u.a. "patch-1" & "patch-2" benannt hat ...

VDR Developer 2.3.2 benötigt ausserdem DEPRECATED_GETBITMAP ²) aktiviert. Schaut am Besten einfach in mein Paket unter ppa:fnu/unstable-vdr-fnu.

Credits gehen hier auch an Klaus & Rolf für die Nachhilfe in Sachen VDR 2.3.x.

[EDIT] Aktualisierte Version mit Abfrage nach VDR API Version ...

!!! Die Patches sind inzwischen Upstream Master inkl. der Patches die sich in den verschiedenen DEB Paketen der DISTROs befunden haben:

- https://projects.vdr-developer…vdr-plugin-text2skin.git/

vdr-plugin-text2skin_1.3.3 wurde als VDR 2.2.0 Version getaggt.

Regards
fnu

PS.: Der der vdr-2.1.2 patch stammt nicht von mir, wird aber benötigt, daher habe ich diesen mit angehängt.

²) => Produktive Problem- und Pluginlösungen für VDR 2.3.2 und höher

MatthiasK · 6. Januar 2017

Hallo zusammen,

für obige Plugins hatte ich noch keinen Patch gefunden. Vielleicht braucht die Plugins ja noch jemand.

Vielen Dank für die 2.3.x an alle.

Viele Grüße
Matthias

fnu · 7. Januar 2017

Hi,

vllt. etwas unkonventionell, aber es war für mich praktikabler und hilft evtl. auch jemand anderem weiter.

Ich habe mir ein Diff aus allen Änderungen von mini73 & TomJoad für vdr-plugin-epgsearch gegenüber winni's letztem Stand erstellt:

Original GIT: https://projects.vdr-developer…vdr-plugin-epgsearch.git/
Changed GIT: https://github.com/flensrocker…-epgsearch/tree/vdr-2.3.1

Danke an mini73 & TomJoad.

[EDIT] Geänderte Version hier: Produktive Problem- und Pluginlösungen für VDR 2.3.2 und höher

Regards
fnu

fnu · 7. Januar 2017

Hi,

ich habe meine o.a. Patches für markad & text2skin nochmals aktualisiert:

- vdr-2.3.2-markad-0.1.4.git20160925_v2.diff
- vdr-2.3.2-text2skin-1.3.2+git20130504_v2.diff

Hier werden nun die nötigen Anpassungen per VDR API Version abgefangen. Die entsprechend gepatchten Plugins bleiben somit auch für ältere VDR Version baubar. Hilfreich für Paketpfleger bzw. könnten natürlich auch so Upstream übernommen werden.

Das Gleiche habe ich mit einem von MatthiasK oben geposteten Patch für epgsync 1.0.1 auch gemacht:

- vdr-2.3.2-epgsync-1.0.1_v2.diff

Auch hier wird die VDR API Version abgefangen, der Dank geht an MatthiasK.

[EDIT] Ditto für den lcdproc Patch von MatthiasK, hier auch mit APIVERSNUM ...

Regards
fnu

Hollywood · 7. Januar 2017

Hi,

nachdem nun viele Patches und Anpassungen verfügbar sind, wollte ich mich eigentlich auch mal ranmachen und auf 2.3.2 umsteigen. Aber sehe ich das richtig, dass epg2vdr noch nicht angepasst wurde ? Das wäre ja für alle die, welche auf epgd umgestiegen sind, "der Haupthinderungsgrund". Oder habe ich einen Patch übersehen ?

Gruss

Hollywood

fnu · 7. Januar 2017

Hollywood

Es gibt viele Plugins die gar keinen Patch brauchen, weil technisch nicht nötig bzw. Upstream bereits, teilweise vor langer Zeit, von den Authoren aktiv angepasst.

Hier einfach mal das entsprechende GIT Repo prüfen.

Regards
fnu

Produktive Problem- und Pluginlösungen für VDR 2.3.2 und höher

Jetzt mitmachen!

Teilen