Posts by hivdr

    Mit dem aktuellen VDR (1.7.18, TT 6400) erlebe ich im Moment immer wieder folgendes Phänomen: ich schalte den Ton ab (mute) und wende mich anderen Dingen zu - plötzlich ist der Ton wieder da. Kennt das wer?


    Es ist _kein_ Absturz mit Restart, das geht klar aus dem Log hervor. Im Log steht garnichts zu den Zeitpunkten.
    Auch habe ich nicht etwa mit sonstigen FB hantiert.


    Lässt sich leider nicht klar reproduzieren, aber ist jetzt eben schon öfter passiert, grade zweimal im Abstand von vielleicht 5min, seither ist nun schon wieder länger Ruhe. Komisch..

    Also nochmal ein Statusbericht: im Kern läuft die 6400 tadellos auf dem Board.


    Die Meldung "not all devices ready after 30 seconds" sowie gewisse zähe Reaktion zeitweise lagen wohl an einem noch dazugesteckten DVB-T-Stick, ohne jetzt nicht mehr aufgetreten. Bootet kalt innerhalb von 40s bis Bild (inklusive 5s Startverzögerung f. alle Fälle, von SSD wie gesagt).


    ABER! Nach wie vor keine Chance bei ACPI Wakeup (und WOL). Und das alternative nvram-wakeup klappt auch nicht: guess-helper findet die richtigen Stellen im nvram nicht. Ausserdem hat die RTC-Alarm-Einstellung im BIOS nur Felder für die Zeit, keinen Tag - d.h. man könnte da auch nur innerhalb von 24h arbeiten - lächerlich. Ist vielleicht auch der Grund, warum guess-helper scheitert, schliesslich kann ich eins der vorgegebenen Felder je Durchgang gar nicht erst setzen.


    Ich stehe nun zwar mit einem im Kern gut laufenden FF-HD-VDR da (das wichtigste, und im Prinzip wovon man jahrelang geträumt hat), aber habe kein WakeUp. Und ein VDR ohne WakeUp ist letztlich auch wieder ein Witz. Was für ein Mist.


    Von daher kann man das Barebone leider nicht empfehlen. Es sei denn, ich mache irgendwas falsch, oder habe nur die richtige Kombination von Einstellungen nicht gefunden oder Ubuntu macht noch irgendwas kaputt beim Runterfahren. Aber ich hab nun wirklich alles mögliche probiert. SH*!


    Wär natürlich schön wenn es jemand anderes trotzdem riskiert und rausfindet wie es funktioniert.. (dream on)

    Also habe den Patch jetzt gemacht, und hat geholfen.
    Aber etwas spanisch kommt mir das immer noch vor, die 20s sind ja hartkodiert, und ich hatte in meinem alten VDR 10s-Sprünge, nicht 20. Das muss was anderes gewesen sein.


    Der Rest von dem Patch erscheint mir jetzt nicht soo nützlich, vieles ist ja auch mit plugins wie extrecmenu abgedeckt.
    Interessant geklungen hätte noch: "Change position of main menu commands: Setup / OSD / Main menu command position"
    Man hätte es so verstehen können, dass man damit die Reihenfolge im Menu umsortieren kann. Aber lässt sich wohl nur von oben nach unten schieben. Wobei es bei mir auf "bottom" steht und trotzdem oben aligned ist (skinenigmang).


    mhanu


    Gut zu wissen, genau sowas habe ich jetzt nat. auch von dem Patch her vorgefunden, und konnte mir da aus den 20s wieder meine 10s machen. Danke!

    Kannst Du sagen, welches Board in Deinem PC verbaut ist? Ich wußte nicht daß es ein ITX-H67 Mainboard gibt, welches noch einen kleinen PCIe-Steckplatz hat.

    Die Shuttle Barebones haben ein eigenes Mainboard drin, das ist fertig eingebaut, passt genau zum Gehäuse (zB Front-Panel-Connector nicht via 10 Stecker die man hinfingern darf, sondern über ein genau passend konfektioniertes Flachbandkabel), dazu eine fertige Kühl-Lösung mit Heatpipes. Super kühl ist es nicht da drin, aber recht leise.


    Das hier ist es:
    http://www.heise.de/preisvergleich/a631839.html


    Schon angenehm, wenn man mal einen Teil der ganzen Schrauberei nicht mehr selbst tun muss. Solide aufgebaut, angenehm zu komplettieren.
    Nicht ganz billig, aber Gehäuse und Board und Netzteil kommen vermutlich auch nicht soo viel billiger, jedenfalls bei vergleichbarer Qualität.


    Wenn ich jetzt noch das mit ACPI und WOL hinbekommen würde, könnte man das Teil für die 6400 wirklich empfehlen (trotz der Unverträglichkeit mit dem PEG, der andere tuts auch, und bis jetzt sehr gut).

    Seltsam, kann mich ganz und gar nicht erinnern, bei meinem letzten Eigenbau-Client-VDR vor knapp zwei Jahren (1.7.8) da irgendwas gepatcht zu haben.. aber wird dann schon irgendwie da reingekommen sein. Werde ich dann wohl mal probieren, diesen Patch.

    Edit: In welchem VDR-Handbuch steht das bitte? Ich wollte das ändern und finde es nicht.

    http://www.vdr-wiki.de/wiki/index.php/Benutzerhandbuch
    (verlinkt zB von der Wiki-Seite VDR)


    Gleich oben die erste (teilbunte) Tabelle: Spalte "Wiedergabe", Zeile "0..9" -> 1 Sprung -10sec 3 Sprung +10sec



    Ich schlage aber vor, Du entfernst das nicht komplett, sondern machst einen Sternchentext dazu, der darauf hinweist, mit welchem Patch das zu bekommen ist. Ist nämlich wirklich extrem praktisch.

    Steht ja so im VDR-Handbuch/Wiki, hat auch bisher bei allen meinen VDRs funktioniert: Springen mit den Tasten 1 und 3 um 10s zurück/vor.
    Sollte also eine Standard-Funktion sein, nicht irgendein Patch oder Plugin.


    Leider reagiert mein neuester VDR (1.7.18 ) gar nicht darauf. Hatte das schon mal jemand?
    Tasten sind nat. korrekt zugewiesen (im live kann man damit also Kanäle eingeben), Springen mit gelb/grün um 1min ist auch OK.


    Nur 1 / 3 mag nicht.. und wenn man das gewohnt ist fehlt einem das ganz schön - trotz der grösseren Sprünge gelb/grün und der Spulmöglichkeit.


    Kann da was kaputtkonfiguriert sein? Eigentlich eine brandneue Installation..

    Erster Bericht: im Grunde läuft alles recht gut mit der 6400 im "kleinen" PCIe - beide Tuner funktionieren, zuverlässig und keine Artefakte bisher, auch bei gleichzeitiger Aufnahme.
    Natürlich noch nicht sonderlich ausführlich/Langzeit getestet, aber sieht gut aus.
    Mit aktuellem Treiber / FW, grob anhand Ubuntu-Anleitung aus dem Wiki vorgegangen, modifiziertes dvbhddevice (beide Tuner können entschlüsseln).


    Braucht 20s bis der Boot startet, dann keine 10s bis KDE Login (Kubuntu 11.04), System auf kleiner Intel SSD. Bis allerdings aus Kaltstart VDR mit Bild da ist: 60s. (Meldung "not all devices ready after 30 seconds")


    Was mir dagegen mit dem Board einfach gar nicht gelingen will bisher ist der ACPI-Wakeup.
    - BIOS: wake on rtc mal an mal aus (nvram), HPET disabled, wake on ring auch probiert
    - kernel/grub: hpet=disable
    - /etc/init/hwclock-save.conf - hwclock-Aufruf auskommentiert
    - doppeltes Schreiben nach /sys/class/rtc/rtc0/wakealarm
    - /proc/driver/rtc zeigt korrekte Aufwach-Zeit
    Aber wacht nicht auf, keine Chance. Das ist auch jedesmal wieder, mit jedem Board, ein ewiger K(r)ampf. Mann!


    Auch der Netzwerk-Link bleibt tot trotz:
    - BIOS: wake on lan enabled
    - /etc/init.d/halt: NETDOWN=no
    Great.

    Wollte jetzt Ernst machen mit einem neuen VDR und der 6400. Dazu das Shuttle Barebone SH67 H3 gekauft.
    Enthält eben auch ein H67 Mainboard / Sockel 1155. Macht sonst einen guten Eindruck, aber:


    6400 wird nicht erkannt. lspci zeigt nichts! Strom gesteckt, Karte wird warm.


    Neuestes BIOS geflashed (1.06). Einige BIOS-Einstellungen probiert, wobei nichts direkt passend zum Problem erschien.


    Die Kennzeichnung "gelöst" für diesen Thread passt ja wohl nicht so wirklich - anderes Mainboard kaufen, schwierig bei einem Barebone..


    Im PEG-x16-Slot läuft sie also nicht!


    Im zweiten PCIe, einem x1-Slot, wird sie erkannt. Aber ob das reicht bzw. wie sie da läuft - Fortsetzung folgt..

    Quote

    Was ist denn genau alles gleich gewesen bei beiden gestörten Systemen

    Tja, siehe oben - kaum etwas. Bei der Hardware buchstäblich gar nichts: unterschiedlicher Rechner, unterschiedlicher DVB-Empfänger.


    Bei der SW eben auch praktisch nur der VDR selbst (aktuelle Version).


    Und auch der LNB ist unterschiedlich: es handelt sich um zwei verschiedene Standorte. Andere Schüssel, anderer LNB.


    Daher ja meine Verwirrung: zwei komplett unabhängige Systeme, das gleiche Phänomen, aber weit und breit sonst niemand, dem das auch schon mal passiert ist.. also jedenfalls keiner der hier mitliest offenbar.

    Schwierig, dieser FitPC kommt mit beiliegendem (externem) Netzteil, weiss nicht ob sich dafür so leicht ein Ersatz finden lässt.


    Was dagegen spricht ist ja, dass das gleiche Phänomen bei der komplett anderen Kiste damals auch auftrat, das war ein ganz normales brandneues ATX-Netzteil, das sonst keinerlei Probleme gemacht hat.


    Aber wenn sonst niemand irgendeine Idee hat, werde ich vielleicht mal schauen, was das für ein Netzteil ist..


    Die CPU dürfte nicht mehr "rauf- und runterschalten", wie gesagt habe ich sie ja per cpufreq-set "oben" festgenagelt (was cpufreq-info bestätigt). Allerdings der Stromverbrauch schwankt natürlich trotzdem je nach Auslastung, schätze ich.


    Interessant wäre dann noch, warum sich sowas gerade und nur auf die Übertragung von DVB-Daten über USB (und PCIe im alten Fall) auswirkt - kommen da keine Checksummen zum Einsatz? Es gibt jedenfalls keine Log-Einträge in dieser Hinsicht.

    Tja, offenbar wirklich niemand, dem das irgendwas sagt..


    Mittlerweile hatte ich noch die Erkenntnis, dass speziell der Atom-Z offenbar doch runtertaktet, ist ja die besonders stromsparende Version. Also habe ich die cpufreq-utils installiert und damit scheinbar erfolgreich beide (virtuellen!?) Kerne fix auf das Maximum von 1.6 GHz gesetzt.


    Nur helfen tuts nicht. Evt. nicht ganz so schlimm wie vorher, aber nach wie vor komplett unbrauchbar, dauerhaft total durchklotzt.
    Für ein sauberes Bild brauche ich nach wie vor die totale Auslastung via urandom.


    Das gibts doch nicht!?

    Ich sehe mich hier einem wirklich seltsamen Phänomen gegenüber, in vielerlei Hinsicht. Und finde bisher keine vergleichbaren Berichte (oder suche ich nur falsch?).


    Das Problem: Der DVB-S(2)-Empfang ist massivst gestört, voller Artefakte, völlig unbrauchbar. Sobald ich die Maschine voll unter Last setze, ist alles gut.
    (eine simple aber wirksame Methode dazu ist übrigens: cat /dev/urandom > /dev/null)


    Der erste Fall betraf meine Versuche mit einer FF TT-6400, ich hatte berichtet. Viele Leute hatten und haben ja Probleme damit, aber diese Art von Problem hatte scheinbar nur ich (inzwischen scheint es bei vielen besser zu laufen, mein nächster Versuch steigt demnächst - aber bei meinem Glück, siehe im Folgenden, sehe ich jetzt schon wieder schwarz..).
    Jetzt habe ich exakt das gleiche Phänomen bei einem anderen VDR. Und zwar einem komplett anderen.


    Beim einen also die TT-6400 - eine PCIe Karte.
    Beim anderen ein TT-3600, angeschlossen per USB(!).


    Beim einen war es eine SandyBridge-Kiste, Intel H67, Core i3-2120 - ziemlich flottes System (mittlerweile anderweitig in Betrieb, ohne VDR).
    Beim anderen nun ein Atom Z. Schnarch. Keine Ausgabe (kein VDR-Frontend), recording server only.


    Beim einen ein Ubuntu 11.4 mit Kernel 2.6.38.
    Beim anderen nun ein altes Suse 11.2 mit Kernel 2.6.31.


    Zwei völlig unterschiedliche Systeme. Aber beide zeigen das gleiche Phänomen. Das scheinbar ausser mir niemand anderer hat. Grossartig.
    Es reicht jeweils, einen Kern voll unter Last zu setzen (der AtomZ hat ja nur einen, aber zwei virtuelle dank HyperThreading).


    Die TT-3600 hing übrigens davor an einem Acer Revo, ebenfalls ein Atom (230), da aber wiederum mit Ubuntu 11.4 - keinerlei Probleme dieser Art.


    Der Atom hat ja angeblich keine Prozessor-Takt-Drosslung, an einem ständigen "Runter- und Hochtakten" dürfte es also nicht liegen?
    /proc/cpuinfo zeigt jedenfalls zwei Kerne, und seltsamerweise einen mit 800, einen mit 1600 MHz im aktuellen Last-Zustand (dass zwei HyperThreading-virtuelle Kerne unterschiedliche Taktraten zeigen ist jetzt aber auch seltsam, oder??)


    Gibt es wirklich niemanden, der sowas kennt?
    Wäre schon sehr interessiert an einer Lösung, die ohne Voll-Last auskommt - das Teil wird so schon sehr warm (ein FitPC2, cooles Teil sonst) und verbraucht nur unnötig Strom..


    Danke fürs Mitdenken!

    Bin der Sache jetzt nicht weiter nachgegangen, denn mittlerweile erlauben die aktuellen Treiber für die Satix S2 Karte einen sauberen shutdown. Mit normalem shutdown ging zwar seltsamerweise die nvram-Variante nicht mehr, die grade zuletzt noch lief, aber umgestellt auf ACPI gehts nun, und das ist ja ohnehin die bessere Lösung, wenn sie denn funktioniert.

    Sorry, ist jetzt wieder zu spät, geht mal wieder in knapp zwei Wochen weiter..


    Die grub.cfg ist eben die die yavdr zusammenbaut, wenn man in der WebOberfläche den shutdown mit reboot setzt.
    Ich hatte gehofft jemand der den Mechanismus gut kennt (oder sogar gebaut hat :) kennt die Symptome und hat eine Idee wo es hakt.


    Es folgt die grub.cfg, nur die Zeile set default=0 habe ich bereits so manipuliert, dass das nicht mehr passieren kann, da steht halt im Original sowas wie default = $saved_entry, nur dass da dann oft PowerOff drinsteht (aus grubenv), ohne dass das dann wieder zurückgesetzt wird..


    Nach diversen Problemen (siehe Thema Komplett-Havarie) ist soweit alles wieder OK, nur eines mag nicht klappen: der wakeup.


    Ich habe ihn auf shutdown-reboot und nvram-wakeup gestellt.


    Beim Runterfahren schreibt nvram erfolgreich die Aufwachzeit, nach dem shutdown passiert der reboot in PowerOff, VDR schaltet ab.
    VDR wacht zur richtigen Zeit auf - ABER: er schaltet sofort wieder ab. D.h. irgendwie bleibt das PowerOff hängen, es klappt nicht mit dem "nur einmal".


    Wo steht das, welche config-Dateien muss ich prüfen??


    Und bitte, wäre es nicht möglich ein Boot-Menu mit einigen Sekunden Wartezeit zu konfigurieren, das einem erspart, in so einem Fall dann ein Live-System booten zu müssen, um überhaupt die Kiste wieder hochzukriegen!?
    Danke!!

    Natürlich liegt die Datei auch bei mir unter /boot, vertippt noch mal..


    Man darf sie nicht editieren, sonst passt die Gesamtgroesse von 1kb (1024 Byte) nicht mehr, und der Befehl grub-reboot, mit dem sie administriert wird, meldet Fehler.
    Habe sie auch nochmal vom Backup restauriert, nun klappt es mit dem reboot-shutdown und wakeup wieder. Leiderschaltet der VDR dann aber (wieder wie oben schon berichtet) sofort ab. Also da brauche ich jetzt echt mal Hilfe von jemandem der sich damit genau auskennt, daher mache ich ein neues Topic. Das hier ist ansonsten wohl abgeschlossen, Danke.

    Heute Nacht fiel es mir wie.. Bretter von den Augen..
    Ich hatte dem vdr mal ein -D0 mitgeben wollen - natürlich im /etc/init/vdr.conf - und dabei "vorsichtshalber" das Original in einem Unterverzeichnis bak gesichert. Voila - zwei VDRs. upstart nimmt offensichtlich auch Unterverzeichnisse gerne mit. Man kann sagen "start bak/vdr". Grossartig. Ist auch im Log zu sehen, wäre sicher dem ein oder anderen hier noch aufgefallen.


    Ich könnte mich selbst in den A*wertesten treten. Aber ich hasse es auch, wenn solche Automatismen gar zu weit gehen. Wegen so einer Kleinigkeit so viel Zeit vertan.
    (Bei der System-Restaurierung hatte ich den alten Stand drüberkopiert, aber nicht vorher komplett gelöscht -> das blieb erhalten)


    Offenbar hat manchmal (wo alles klappte) der "richtige" der beiden die Oberhand bekommen, oder das Frontend den richtigen erwischt - und der andere ist vielleicht endgültig gestorben, oder ich habe von den dauernden Restarts des anderen tatsächlich nichts mitbekommen. Mann!


    Jetzt wäre es bloss noch schön, wenn man den shutdown/wakeup noch wieder richtig hinbekommen könnte. Ist es falsch, die Zeile in /etc/grub/grubenv zu löschen, wenn er dauernd sofort poweroff macht? Und wie bekomme ich im Einklang mit yavdr ein sichtbares Startmenu für ein paar Sekunden hin??

    Ich habe mal den ein oder anderen kosmetischen Fehler korrigiert, das iptv-plugin gelöscht (apt-get remove hätte jede Menge Pakete deinstallieren wollen, darunter yavdr-essentials, darauf habe ich lieber verzichtet) usw - aber das hatte nicht wirklich was damit zu tun.


    Die Fehlermeldung dass er die DVB-devices nicht öffnen kann ebenso wie die Fehler von streamdev-server (Konfiguration ist Standard - nur localhost - wird bisher nicht benutzt - ich hatte ja auch schon mal fast alle Plugins entfernt ohne dass es was gebracht hat) liegen wohl daran, dass da ein vdr nicht wirklich weg ist und noch seine Hand auf den device-files bzw. ports hält. Nach "stop vdr" muss ich noch per "killall -9 vdr" den hängenden Prozess killen.
    Die PID der crashenden VDRs ist jeweils die des Haupt-Prozesses, steht dann auch bei "vdr main process (xxxx) killed by SEGV signal" im syslog.


    In seltenen Fällen, mit viel Glück, klappt es danach mit einem Neustart "start vdr", und alles läuft. Meistens aber gleicher Ablauf mit ständigen Restarts.


    Ich habe jetzt mal an den Anfang der Kette geschaut, der eine erste vdr der am Ende gekillt werden muss.. und es sieht folgendermassen aus: am Anfang starten im Abstand von 1s zwei VDR parallel. Dass die sich dann gegenseitig behindern ist ja naheliegend. Der zweite semmelt ab, zieht die ständigen Restarts nach sich. Der erste läuft bis zum kill -9, dabei steht dann im Log "bak/vdr main process (1197) killed by KILL signal".


    Nochmal ein komplettes syslog (ja, noch mit den config-Errors):
    http://pastebin.com/8iCRTC01
    Fängt oben an mit dem ersten VDR-Start (pid 1197), kurz darauf gefolgt vom zweiten parallelen (1309), und endet als ich den ersten manuell gekillt habe - dazwischen die regelmässigen Neustarts des zweiten.


    Bleibt jetzt also die grosse Frage: warum starten da zwei VDR!? Und warum passiert das plötzlich? Wie gesagt, ich hatte den Software-Stand nun ja einfach mal einen Monat zurückgesetzt, und hier nun die gleichen Symptome (die hier beschriebenen) erhalten wie vor zwei Wochen mit dem neueren Stand. Damals ist das nie passiert.


    Die Treiber initialisieren laut Ausgabe im syslog übrigens normal, lediglich steht bei beiden frontends "0" - aber der kosmetische Fehler ist glaube ich bekannt vom ngene.


    Nebenschauplätze: manchmal ist das Bild "schwarz", man hört Ton. Eingangs-Wechsel am TV hilft nicht. Vielleicht eine Art Screensaver von X?
    Shutdown: wenn ich über die Weboberfläche wieder "poweroff kernel" (== grub poweroff / halt) aktiviere, fährt er wieder fortan bei jedem Start direkt sofort wieder runter, erwischt also _immer_ den poweroff. Entferne ich das in grubenv wieder (über Booten vom Stick), führt dafür dann wieder jeder shutdown stattdessen zum Neustart.
    Ich hätte ja gerne ein bootmenu, wenigstens für 1 Sekunde, damit einem sowas erspart bleibt. Aber ich nehme mal an eigenes Editieren von /etc/default/grub und Aufruf von update-grub ist nicht kompatibel mit den yavdr-Mechanismen?


    Danke fürs Mitdenken!

    Neues vom Problemkind.


    Gestern Abend erst mal in Ubuntu Live gebootet - keinerlei Anzeichen für Hardware-Probleme, auch memtest OK.
    Dann daran erinnert, dass ich ein Komplett-Backup der Systempartition gemacht hatte, ca 1 Monat vor der Havarie. Drüberkopiert, und damit war erst mal alles wieder soweit OK - abgesehen davon dass nur das DVB-T interface ging, aber kein Bild auf den Satellitenkanälen über die Satix-Dual-S2 (ngene). Extrem schlechte Werte bei femon, unverändert wenn man Kabel ganz abzieht. Kabel mit Kaufreceiver probiert, OK, Kabel wieder dran. Erst mal nix.


    Heute will ich in Ruhe der Sache auf den Grund gehen. Kiste schaltet sofort aus. Jedesmal. OK, erwischt wohl immer PowerOff im grub (gestern ganz normal abgeschaltet, kein Timer). Also per USBStick gebootet und den Eintrag in grubenv entfernt. Bootet wieder.


    lspci: Karte da. grep auf kern.log: ngene lädt, inklusive firmware. grep auf user.log: VDR findet beide frontends. Und siehe da: Bild! Alles läuft scheinbar wieder normal. Doch erst mal Reboot probieren.


    Und siehe da - wieder alles kaputt: alle 7s VDR-Neustart.


    Hier ein typischer Zyklus aus der user.log:
    http://pastebin.com/pSSfEFKG


    Auffällig sicherlich das "ERROR: can't open DVB device 0/0" - nur dafür gibt es keinen Grund, ausserdem habe ich in jedem Zyklus kurz ein Bild (und manchmal auch eine halbe Sekunde Ton).


    Code
    1. # ll /dev/dvb/adapter0/
    2. insgesamt 0
    3. drwxr-xr-x 2 root root 160 2011-05-21 19:37 ./
    4. drwxr-xr-x 3 root root 60 2011-05-21 19:37 ../
    5. crw-rw---- 1 root video 212, 0 2011-05-21 19:37 demux0
    6. crw-rw---- 1 root video 212, 3 2011-05-21 19:37 demux1
    7. crw-rw---- 1 root video 212, 1 2011-05-21 19:37 dvr0
    8. crw-rw---- 1 root video 212, 4 2011-05-21 19:37 dvr1
    9. crw-rw---- 1 root video 212, 2 2011-05-21 19:37 frontend0
    10. crw-rw---- 1 root video 212, 5 2011-05-21 19:37 frontend1


    Und schliesslich im kern.log:


    Code
    1. May 21 20:08:17 xx kernel: [ 1889.027503] vdr[31314]: segfault at 5a0bcc ip 08130a72 sp bf9dcfa0 error 4 in vdr[8048000+143000]
    2. May 21 20:08:24 xx kernel: [ 1895.766426] vdr[31420]: segfault at 219bcc ip 08130a72 sp bffd3980 error 4 in vdr[8048000+143000]
    3. May 21 20:08:31 xx kernel: [ 1902.445934] vdr[31526]: segfault at 421bcc ip 08130a72 sp bfa6ca50 error 4 in vdr[8048000+143000]
    4. May 21 20:08:38 xx kernel: [ 1909.126518] vdr[31633]: segfault at 4bbbcc ip 08130a72 sp bfe3cd50 error 4 in vdr[8048000+143000]
    5. May 21 20:08:44 xx kernel: [ 1915.889086] vdr[31739]: segfault at 18dbcc ip 08130a72 sp bfc31dd0 error 4 in vdr[8048000+143000]


    Unendlich so weiter, eben alle 7s.
    Warum crasht der bloss andauernd..

    iseeberg


    Obwohl dieser Thread vom Titel her bestens passt, solltest Du den "grossen" Thread zur 6400 lesen (im gleichen Forum unter den obersten), zumindest die letzten paar Seiten. Dort wird das Problem in den letzten Tagen auch wieder verstärkt diskutiert, ausserdem wird grade eine Wiki-Seite mit betroffenen HW-Kombinationen/Boards aufgebaut.


    Dort hatte ich auch schon von schlechten Signalstärken laut femon berichtet, aber scheinbar fällt diese Anzeige bei der 6400 einfach etwas schwächer aus und ist nicht 1:1 mit Werten vergleichbar, die die selbe Leitung an anderen Karten zeigt.


    Die Artefakte haben relativ wahrscheinlich nichts mit der Signalstärke zu tun. Jedenfalls wenn die gleiche Leitung an anderen Karten problemlos funktioniert.