Posts by Zabrimus

    Kanaländerungen werden hier beschrieben
    http://www.vdr-wiki.de/wiki/in…p/Fernbedienung_-_USB_X10
    http://www.x10receiver.net/support_manual_manchangechannel



    Folgendes solltest Du nach dem Kanalwechsel auf jedem System noch machen.


    Falls Du ati_remote verwendest: Die Datei /etc/modprobe.d/ati_remote.conf anlegen

    Code
    1. # channel 1
    2. # echo "65535 - 2 ^ 1" | bc
    3. options ati_remote channel_mask=65533


    Falls Du lirc_atiusb verwendest: Die Datei /etc/modprobe.d/lirc_atiusb.conf anlegen

    Code
    1. # channel 1, Werte siehe http://www.vdr-wiki.de/wiki/index.php/Fernbedienung_-_USB_X10
    2. options lirc_atiusb mask=0x0001


    Der Kanal muss natürlich angepasst werden und dann Treiber neu laden oder System durchstarten. Falls eine der beiden Dateien nicht auf jedem System angepasst und angelegt wird, kann es ein durchaus interessantes Verhalten der Systeme geben.

    Hi,


    es gab wohl doch einen Error 40. Etwas erschrocken war ich bei der Untersuchung der lib/modules. Doppelte und teilweise dreifache Versionen von Modulen. Das kann ja nur zufällig funktionieren.


    Nachdem das Verzeichnis media komplett gelöscht und der Treiber neu gebaut und installiert wurde, läuft alles wieder gut. Eigentlich sogar noch besser, als mit meiner alten Version.


    Die beiden problematischen Frontends können zwar immer noch nicht auf einen bestimmten Kanal tunen, aber zumindest gibt es keine gruseligen Fehlermeldungen und Abstürze mehr. Ich werde mal die Verkabelung überprüfen müssen bzw. ein wenig rumdoktoren - sprich wahllose und zufällige Lösungsmöglichkeiten in Erwägung ziehen.


    Danke und Grüße
    Zabrimus

    Hallo,


    ich habe nach einigen Tests von den 8 Frontends genau 2 deaktivieren müssen (D2 und D6). Seitdem scheint VDR keine Probleme mehr zu machen. Es gibt auch keine beunruhigenden Meldungen mehr im Syslog.


    Das spricht eher weniger dafür, daß eine "Mischung" der Module des Kernels und des Treibers stattgefunden hat. Zumal D2 und D6 zu unterschiedlichen Revisionen der DVB-C Karten gehören. Aber ich werde trotzdem mal alle Module löschen und den Treiber neu installieren.


    Grüße
    Zabrimus

    Hallo,


    ich wollte nach längerer Zeit mal wieder auf eine aktuelle Version des Treibers wechseln. Allerdings bekomme ich einen Fehler.


    Laden des Treibers:


    Start des VDR:


    Die Treiber lassen sich auch nicht mehr entladen. Es treten Fehler auf, wahrscheinlich Folgefehler:




    Grüße
    Zabrimus

    Ich versuche mich an yaVDR als reinen Streaming-Client für den headless Server. Der Client-VDR hat nach einem Neustart nahezu 100% CPU Last.
    Interessant finde ich allerdings dann folgendes:
    Wenn die Last bei 100% liegt, wird das syslog mit Meldungen der Art


    Code
    1. Jun 18 21:50:24 vdr1 vdr: [2729] cStreamdevFilter::PutSection socket overflow, Pid 18 Tid 64
    2. Jun 18 21:50:24 vdr: last message repeated 199 times
    3. Jun 18 21:50:24 vdr1 rsyslogd-2177: imuxsock begins to drop messages from pid 2370 due to rate-limiting
    4. Jun 18 21:50:30 vdr1 rsyslogd-2177: imuxsock lost 2136 messages from pid 2370 due to rate-limiting
    5. Jun 18 21:50:30 vdr1 vdr: [2729] cStreamdevFilter::PutSection socket overflow, Pid 18 Tid 64
    6. Jun 18 21:50:30 vdr: last message repeated 199 times
    7. Jun 18 21:50:30 vdr1 rsyslogd-2177: imuxsock begins to drop messages from pid 2370 due to rate-limiting
    8. Jun 18 21:50:36 vdr1 rsyslogd-2177: imuxsock lost 2424 messages from pid 2370 due to rate-limiting
    9. Jun 18 21:50:36 vdr1 vdr: [2729] cStreamdevFilter::PutSection socket overflow, Pid 18 Tid 64
    10. Jun 18 21:50:36 vdr: last message repeated 199 times


    geflutet, bis zu dem Punkt, an dem das Bild einfach stehen bleibt.


    Nach einem restart dbus, dreht sich das Verhalten um 180 Grad. Die CPU Last sinkt extrem und das syslog bleibt frei von unerwünschten Meldungen. BIsher trat auch kein Freeze des Bildes mehr auf.
    2370 ist der VDR selber.


    Zabrimus

    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

    Voller Freude entnahm ich dem heutigen Paket die neue Duoflex CT (V2). Im Rechner sind schon eine Octopus-Bridge und eine Duoflex CT (V1), die auch erkannt werden und funktionieren.
    Obwohl ich nun schon mehrfach sowohl die Stromversorgung, als auch die Verkabelung geprüft habe, wird die neue Karte nicht erkannt.
    Sowohl die alte, als auch die neue Karte habe ich an den verschiedensten Panel der Bridge angeschlossen. Soweit ohne Erfolg: Erkannt wird immer nur die alte Karte.


    Wird die Duoflex CT (V2) überhaupt unterstützt? Mir fallen ansonsten keine weiteren möglichen Fehlerquellen ein.


    Zabrimus

    Plugins kann ich eigentlich ausschliessen. Die Backtraces oben sind mit einem nacktem VDR (vollständig ohne Plugins) erstellt worden.


    Aus den anderen Threads zu dem Thema kann ich nur schliessen, daß es sich wohl um ein reines Problem mit VDR und Unitymedia handelt. Zumindest schien eine andere Kombination dieses Problem nicht zu verursachen. Ich kann nur empfehlen, mal einen Blick auf valgrind zu werfen. Damit war die Ursache bzw. eine mögliche Lösung ziemlich schnell gefunden.


    Zabrimus

    Zur Info:
    Das Problem trat bei mir auch auf einem VDR-Client-Only Rechner (streamdev-client) auf. Zuerst hatte ich eine oder mehere Aufnahmen im Visier, aber nach einspielen des Patches trat auch hier eine Besserung auf.


    Zabrimus

    Die geänderte Variante scheint ohne Abstürze zu laufen. (UpdateChannels=5 und wieder die volle channels.conf)



    Meine aktive C-Sturm und Drangzeit liegt schon einige Jahre zurück und vielleicht gibt es auch eine bessere Lösung. Schöner wäre es natürlich die Ursache zu beseitigen, anstatt an den Symptomen rumzudoktorn.



    Was immer auch EIT ist, aber es scheint einen Zusammenhang zwischen den Abstürzen und den Änderungen zu geben. Vielleicht werden jetzt ein paar Sender mehr gescanned, als vorher. Dies würde zumindest den Workaround mit der Kürzung der channels.conf erklären. Aber da sollten Experten lieber ein Auge drauf werfen.


    Edit:
    Der VDR lief die ganze Nacht ohne Probleme durch.


    Zabrimus

    Ich hatte irgendwie das Gefühl, daß interne Datenstrukturen nicht valide sind oder werden.
    Meine channels.conf habe ich fast vollständig gelöscht und nur noch einen Sender drin gelassen, der bei mir einen Fehler verursacht hatte um dann mittels valgrind bzw. vdrleaktest den VDR neu zu starten.


    Recht schnell kam diese Meldung:



    Ob dies allerdings die Ursache ist, kann ich nicht sagen...


    Edit:
    Ein kleine Änderung in der entsprechenden Methode - sprich eine Ausgabe ergab folgendes:


    -- Length 1, Index 6, Last 0
    -- Length 1, Index 6, Last 0
    -- Length 1, Index 6, Last 0
    -- Length 1, Index 6, Last 0


    Warum das passiert, kann ich nicht sagen, allerdings prüfe ich mal, was passiert, wenn ich solche Werte einfach ignoriere.


    Zabrimus

    In dem Rechner (der mehr als nur ein VDR-Server ist) steckt ein Core2Quad. Das System lief ja eine zeitlang recht problemlos und ich dachte schon daran live zu gehen und den Haushaltsvorstand damit zu beglücken. Nur wird die Frau an die Decke springen, wenn das Programm dauernd stockt *g*


    Ich habe versuchsweise mal die alte channels.conf eingespielt und VDR neugestartet. Mit UpdateChannels = 0 schien es auch zu laufen. Femon ist auch installiert, aber die Ausgabe per svrdp (plug femon info) erschliesst sich mir irgendwie nicht.


    Aber ich werde heute Abend noch ein paar Untersuchungen starten.


    Wie kann ich denn eine Zuordnung von
    cEIT (this=0xb2df7240, Schedules=0x818fa40, Source=1124073472, Tid=80 'P', Data=0xb2df7338 "P\362%Z@\331\300", <incomplete sequence \370>, OnlyRunningStatus=false)
    oder
    cEitFilter:: process (this=0xb6c33b88, Pid=18, Tid=80 'P', Data=0xb11f3338 "P\360qZ?׀", <incomplete sequence \370>, Length=116)
    auf den oder die problematischen Channel machen? Geht das überhaupt?



    Zabrimus

    Vielleicht eine dumme Frage, aber wie kann ich denn die BER eines bestimmten Channels bestimmen?
    Der Server läuft vollständig headless und dient als streamdev-server.


    Zabrimus

    Die EPG-Data hatte ich schon einmal gelöscht. Der Erfolg dieser Aktion war recht unscheinbar: Es hat nichts gebracht. VDR stürzte immer noch ab.


    Aber ich bin einen Schritt weiter. Mir ist aufgefallen, daß fast immer derselbe Kanal im Logfile zuletzt auftauchte, bei dem eine PID/Name-Änderung erfolgte. Bei mir war es Teleklub (DVB-C, Unitymedia)..


    Nachdem ich diesen Kanal, alle ausländischen Kanäle und auch die Radiosender aus der channels.conf gelöscht habe (Paranoia pur) und in der setup.conf den Parameter UpdateChannels auf 0 setzte, läuft VDR nun schon seit phänomenalen 30 Minuten ohne Fehler.
    Aktuell würde ich dies als Erfolg bezeichnen.


    UpdateChannels auf den Default 5 brachte nur kurzfristig Erleichterung, einer der problematischen Kanäle wurde wieder gefunden und VDR beendete sich kurz danach wieder.


    Jetzt müsste ich nur noch irgendwie eine Möglichkeit haben bestimmte Channels von VDR komplett zu ignorieren und nicht mehr hinzuzufügen. Aber selbst wenn es eine Lösung dazu gäbe, würde dies wohl auf Trial und Error hinauslaufen, bis ich alle problematischen Kanäle gefunden habe.


    Edit: Es liegt wohl tatsächlich an bestimmten Channels. VDR lief jetzt die ganze Nacht ohne Probleme durch.


    VG,
    Zabrimus

    Hallo,


    mein VDR-Server (1.7.21, e-Tobi Standard) lief eine Zeitlang problemlos durch. Nur startet dieser seit neustem immer wieder durch.
    Zuerst hatte ich verschiedene Plugins im Verdacht, aber selbst nachdem ich diese alle deaktiviert habe, springt mich immer ein Segfault an.


    Aktueller Aufruf von VDR (nach Deaktivierung aller Plugins):
    Starting program: /usr/bin/vdr-dbg -v /share/nfs/video -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -E /var/cache/vdr/epg.data -w 0 --userdump --lirc



    Als Alternative erhalte ich auch folgenden BT:


    Das ganze passiert immer ein paar Minuten nach dem Start von VDR und ich weiß nicht mehr weiter :(



    VG
    Zabrimus