Nach Update auf 1.7.21-1~ctvdr2 laeuft der VDR nicht mehr

    Hallo,


    heute kam ueber das Update 1.7.21-1~ctvdr2 und vdr-plugin-dvbsddevice_1.7.21-1~ctvdr2 mit.
    Seitdem restartet der vdr permanent.


    Im Log ist folgendes zu finden:



    Oct 27 21:44:57 vdr runvdr: restarting VDR
    Oct 27 21:44:57 vdr kernel: [ 3842.742253] saa7146: unregister extension 'dvb'.
    Oct 27 21:44:57 vdr kernel: [ 3842.747435] dvb 0000:01:06.0: PCI INT A disabled
    Oct 27 21:44:57 vdr kernel: [ 3842.755664] saa7146: unregister extension 'budget_ci dvb'.
    Oct 27 21:44:57 vdr kernel: [ 3842.759903] budget_ci dvb 0000:01:08.0: PCI INT A disabled
    Oct 27 21:44:59 vdr kernel: [ 3844.784896] saa7146: register extension 'dvb'.
    Oct 27 21:44:59 vdr kernel: [ 3844.784929] dvb 0000:01:06.0: PCI INT A -> Link[APC1] -> GSI 16 (leve
    Oct 27 21:44:59 vdr kernel: [ 3844.784951] IRQ 16/: IRQF_DISABLED is not guaranteed on shared IRQs
    Oct 27 21:44:59 vdr kernel: [ 3844.784968] saa7146: found saa7146 @ mem f8240000 (revision 1, irq 16
    Oct 27 21:44:59 vdr kernel: [ 3844.784983] dvb 0000:01:06.0: firmware: requesting dvb-ttpci-01.fw
    Oct 27 21:44:59 vdr kernel: [ 3844.790820] DVB: registering new adapter (Technotrend/Hauppauge WinTV
    Oct 27 21:44:59 vdr kernel: [ 3844.793233] adapter has MAC addr = 00:d0:5c:03:7b:e8
    Oct 27 21:44:59 vdr kernel: [ 3844.800700] dvb 0000:01:06.0: firmware: requesting av7110/bootcode.bi
    Oct 27 21:45:00 vdr kernel: [ 3845.006939] dvb-ttpci: gpioirq unknown type=0 len=0
    Oct 27 21:45:00 vdr kernel: [ 3845.032082] dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, v
    Oct 27 21:45:00 vdr kernel: [ 3845.032086] dvb-ttpci: firmware @ card 0 supports CI link layer inter
    Oct 27 21:45:00 vdr kernel: [ 3845.080148] dvb-ttpci: Crystal audio DAC @ card 0 detected
    Oct 27 21:45:00 vdr kernel: [ 3845.081349] saa7146_vv: saa7146 (0): registered device video0 [v4l2]
    Oct 27 21:45:00 vdr kernel: [ 3845.081717] saa7146_vv: saa7146 (0): registered device vbi0 [v4l2]
    Oct 27 21:45:00 vdr kernel: [ 3845.344521] DVB: registering adapter 0 frontend 0 (Philips TDA8083 DV
    Oct 27 21:45:00 vdr kernel: [ 3845.344696] input: DVB on-card IR receiver as /devices/pci0000:00/000
    Oct 27 21:45:00 vdr kernel: [ 3845.344738] dvb-ttpci: found av7110-0.
    Oct 27 21:45:00 vdr kernel: [ 3845.355961] saa7146: register extension 'budget_ci dvb'.
    Oct 27 21:45:00 vdr kernel: [ 3845.355999] budget_ci dvb 0000:01:08.0: PCI INT A -> Link[APC3] -> GS
    Oct 27 21:45:00 vdr kernel: [ 3845.357288] IRQ 18/: IRQF_DISABLED is not guaranteed on shared IRQs
    Oct 27 21:45:00 vdr kernel: [ 3845.357305] saa7146: found saa7146 @ mem f8266000 (revision 1, irq 18
    Oct 27 21:45:00 vdr kernel: [ 3845.357313] saa7146 (1): dma buffer size 192512
    Oct 27 21:45:00 vdr kernel: [ 3845.357316] DVB: registering new adapter (TT-Budget/WinTV-NOVA-CI PCI
    Oct 27 21:45:00 vdr kernel: [ 3845.358490] adapter has MAC addr = 00:d0:5c:24:4f:9c
    Oct 27 21:45:00 vdr kernel: [ 3845.362458] input: Budget-CI dvb ir receiver saa7146 (1) as /devices/
    Oct 27 21:45:00 vdr kernel: [ 3845.564191] DVB: registering adapter 1 frontend 0 (ST STV0299 DVB-S).
    Oct 27 21:45:15 vdr vdr: [28914] [xine..put] Listening on address '192.168.1.5' port 37890
    Oct 27 21:45:15 vdr kernel: [ 3860.898944] vdr[28914]: segfault at 0 ip b75a2ac3 sp bfdced8c error 4
    Oct 27 21:45:15 vdr runvdr: restarting VDR
    Oct 27 21:45:15 vdr kernel: [ 3860.924226] saa7146: unregister extension 'dvb'.



    Dieser Block wiederholt sich ca. 20-25 Sekunden. Also derzeit nix mit vdr... :(


    Ist das schon bekannt?



    the_duke

    Das Problem kenne ich nun auch seit gerade. Und ich bekomme das System nicht mehr lauffähig.
    Bei mir scheint es am streamdev-client zu liegen, obwohl dieser nicht aktualisiert wurde. Ich weiß leider nicht mehr, was bei dem Update noch so reingerutscht ist.


    vdr: [10466] Streamdev: Connected to server 192.168.178.10:2004 using capabilities TSPIDS,FILTERS,PRIO
    kernel: [ 2980.852862] vdr[10466]: segfault at 12 ip b702453d sp bf845f70 error 4 in libvdr-streamdev-client.so.1.7.21[b701d000+12000]


    Richtig spannend ist dann folgender Aufruf, mit dem Versuch einen Backtrace zu erzeugen:
    vdr-dbg -v /var/lib/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -s /usr/lib/vdr/vdr-shutdown-message -E /var/cache/vdr/epg.data -u vdr -g /tmp --port 6419 --lirc -P 'xineliboutput --local=none --primary --remote=192.168.178.11:37890' -P streamdev-client


    Es kommt direkt diese Ausgabe:
    vdr-dbg: malloc.c:3097: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.


    Und da verlassen sie mich dann....


    Anbieten könnte ich aber auch sowas
    vdrleaktest -P "xineliboutput --local=none --primary --remote=192.168.178.11:37890" -P streamdev-client


    ==12107== Invalid write of size 4
    ==12107== at 0x8162BDD: cMutex::cMutex() (thread.c:179)
    ==12107== by 0x80C011E: cDevice::cDevice() (device.c:78)
    ==12107== by 0x4C34BE4: cStreamdevDevice::cStreamdevDevice() (in /usr/lib/vdr/plugins/libvdr-streamdev-client.so.1.7.21)
    ==12107== by 0x4C34D09: cStreamdevDevice::Init() (in /usr/lib/vdr/plugins/libvdr-streamdev-client.so.1.7.21)
    ==12107== by 0x4C33B94: cPluginStreamdevClient::Start() (in /usr/lib/vdr/plugins/libvdr-streamdev-client.so.1.7.21)
    ==12107== by 0x81296DE: cPluginManager::StartPlugins() (plugin.c:364)
    ==12107== by 0x817055A: main (vdr.c:706)
    ==12107== Address 0x5e21ac4 is 0 bytes after a block of size 10,268 alloc'd
    ==12107== at 0x402471C: operator new(unsigned int) (vg_replace_malloc.c:255)
    ==12107== by 0x4C34CFF: cStreamdevDevice::Init() (in /usr/lib/vdr/plugins/libvdr-streamdev-client.so.1.7.21)
    ==12107== by 0x4C33B94: cPluginStreamdevClient::Start() (in /usr/lib/vdr/plugins/libvdr-streamdev-client.so.1.7.21)
    ==12107== by 0x81296DE: cPluginManager::StartPlugins() (plugin.c:364)
    ==12107== by 0x817055A: main (vdr.c:706)
    ==12107==
    ==12107== Invalid write of size 4
    ==12107== at 0x80C02A3: cDevice::cDevice() (device.c:110)
    ==12107== by 0x4C34BE4: cStreamdevDevice::cStreamdevDevice() (in /usr/lib/vdr/plugins/libvdr-streamdev-client.so.1.7.21)
    ==12107== by 0x4C34D09: cStreamdevDevice::Init() (in /usr/lib/vdr/plugins/libvdr-streamdev-client.so.1.7.21)
    ==12107== by 0x4C33B94: cPluginStreamdevClient::Start() (in /usr/lib/vdr/plugins/libvdr-streamdev-client.so.1.7.21)
    ==12107== by 0x81296DE: cPluginManager::StartPlugins() (plugin.c:364)
    ==12107== by 0x817055A: main (vdr.c:706)
    ==12107== Address 0x5e21ac8 is 4 bytes after a block of size 10,268 alloc'd
    ==12107== at 0x402471C: operator new(unsigned int) (vg_replace_malloc.c:255)
    ==12107== by 0x4C34CFF: cStreamdevDevice::Init() (in /usr/lib/vdr/plugins/libvdr-streamdev-client.so.1.7.21)
    ==12107== by 0x4C33B94: cPluginStreamdevClient::Start() (in /usr/lib/vdr/plugins/libvdr-streamdev-client.so.1.7.21)
    ==12107== by 0x81296DE: cPluginManager::StartPlugins() (plugin.c:364)
    ==12107== by 0x817055A: main (vdr.c:706)
    ==12107==



    Zabrimus

    hier liegt das problem auch am neuen ttxsubs-patch, viele plugins müssen neu gebaut werden und/oder der patch angepasst/entfernt werden. tobi habe ich schon ne mail dazu geschrieben.
    ich kann gerne nen vdr 1.7.21 paket ohne dem patch bauen fpr squeeze amd64/i386, damit läuft der vdr dann erstmal wieder, bis tobi das behoben hat.


    /EDIT
    ich baue grade mal vdr 1.7.21 ohne den patch neu, damit sollte der vdr dann erstmal wieder laufen bis tobi zeit dafür hatte.
    das sollte auch nur den mutipatch vdr betreffen.


    /EDIT2
    tobi hat mir geantwortet und hat wieder die ctvdr1 version ins repo gepackt. evtl hat er am wochenende zeit alle plugins/addons passend dazu neu zu bauen.
    mit einem
    aptitude update && aptitude install vdr=1.7.21-1~ctvdr1
    kommt ihr wieder zur alten version zurück und alles sollte soweit wieder passen, leider ist da der unitymedia patch noch nicht enthalten.

    Hallo hotzenplotz,


    danke fuer den Link.

    Zitat von hotzenplotz5

    http://www.e-tobi.net/blog/200…eicherlecks-im-vdr-finden

    Ich bin gemaess den Anleitungen dort vorgegangen. Das im Text erwaehnte file /tmp/memleaktest.log wurde bei mir nicht erzeugt.
    Nachdem ich vdrleaks gestartet hatte, hat es einen Moment gedauert, dann wurde Daten auf der Konsole ausgegeben.
    In einem weiteren Fenster habe ich nach /tmp geschaut, aber diese Datei nicht gefunden. In der Konsole in der vdrleaks gestartet
    war, konnte ich ausser STRG+C nichts eingeben (ich versuchte exit, quit). Uebr das VDR Menu war ein Beenden auch nicht moeglich,
    da der VDR all 20-25 Sekunden neu startete. Wie haette ich den valgrind bzw. vdrleaks Prozess korrekt beendet, so dass das
    erwuenschte Logfile geschrieben worden waere? Waere /etc/init.d/vdr restart eine Option gewesen?


    the_duke

    Hallo OppTupacShakur,


    gerade habe ich die vorhergehende Version wieder installiert und es laeuft wieder.
    Vielen Dank dafuer!


    the_duke

    Zitat von OppTupacShakur

    tobi hat mir geantwortet und hat wieder die ctvdr1 version ins repo gepackt. evtl hat er am wochenende zeit alle plugins/addons passend dazu neu zu bauen.
    mit einem
    aptitude update && aptitude install vdr=1.7.21-1~ctvdr1
    kommt ihr wieder zur alten version zurück und alles sollte soweit wieder passen, leider ist da der unitymedia patch noch nicht enthalten.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden