Beiträge von torsten lang

    Hallo Falk,
    tja, wie gesagt, int_type=1 funktioniert bei meinem Board überhaupt nicht, die Karte selbst läuft ansonsten mit den Standard-Einstellungen aber absolut stabil.


    Was mich aber wundert - wie soll man diese Seite nur finden? Von der Hauptseite über die S2-6400 scheint sie überhaupt nicht verlinkt zu sein...


    Viele Grüße,
    Torsten

    Hallo wtor,
    bei mir geht das zumindest nicht - mit int_type=1 läßt sich bei mir die Karte überhaupt nicht zum Leben erwecken.


    Die Absturzursache wäre damit aber tatsächlich weiter eingegrenzt:


    Code
    rmmod saa716x_ff


    geht noch gut, beim anschließenden


    Code
    modprobe saa716x_ff


    bleibt der Kernel instantan mit einer Exception im Interrupt stehen!


    Als Workaround habe ich in runvdr den saa716x_ff vom Neuladen ausgenommen:


    Code
    get_modulenames()
    {
        MODULES=`lsmod | awk '/^dvb/ {gsub(/,/,"\n", $4); print $4}' | uniq | tac | grep -v "^$" | grep -v saa716x_ff`
        [ "$MODULES" ] && MODULES="$MODULES dvb_core"
    }


    Copperhead:


    Kannst Du das reproduzieren? Dann wäre das wohl noch ein Fall für die Problemliste...


    Viele Grüße,
    Torsten

    Copperhead:


    Noch ein Nachtrag zu diesem Post:


    Ich hatte immer wieder mal Probleme mit harten Abstürzen (s. a. TechnoTrend Premium S2-6400 dual HD Technik / Treiber / Installation und bitte nur das). Anfangs hatte ich noch an ein Hardware-Problem geglaubt, mittlerweile aber nicht mehr, da die Karte i. a. stabil läuft und auch die Aufnahmen OK sind (getestet mit bis zu 12 Aufnahmen über alle vier Tuner verteilt).


    Ich wollte es erst nicht glauben, aber bei meinem System ist es so: Harte Abstürze mit Kernel-Panic bedingt durch den saa716x_ff treten bei mir reproduzierbar auf, wenn der VDR hart beendet wird.


    Die Kernel-Treiber müssen doch damit klar kommen, wenn mal eine sie verwendende Applikation hart "den Bach runter geht", das darf doch keinesfalls den ganzen Kernel ins Grab reißen.


    Kann das mal jemand gegentesten (ein einfaches killall -9 vdr reicht bei mir, um das System einzufrieren).


    Viele Grüße,
    Torsten

    Copperhead:


    Ich habe hier gerade noch einen ganz üblen Effekt entdeckt (e-Tobi VDR-1.7.21 Multipatch, Hardlink-Cutter aktiv): Wenn ich gerade schneide und die Quell-Aufnahme lösche, dann stürzt nicht nur reproduzierbar der VDR ab, sondern das ganze System wird mit einem Kernel-Panic heruntergerissen. Ähnlich wie beim von Falk berichteten Problem mit einer Exception im Interrupt.


    Kann das jemand verifizieren?


    Gruß,
    Torsten

    Hallo Dirk,
    da muß ich auch mal Vermutungen anstellen. Ich würde mittels

    Code
    dpkg-reconfigure locales


    mal de_DE.UTF8 mit anwählen, die Defaulteinstellung für das System aber bei de_DE@euro belassen. Dann - würde ich jedenfalls erwarten - müßte auch die Vorgabe für den VDR funktionieren.


    Ob Du Dir damit aber wirklich einen Gefallen tust weiß ich nicht. Ich habe in der info.vdr bzw. info Datei nämlich keinen Hinweis auf die Zeichenkodierung gefunden. D. h. Du müßtest bei so einer Umstellung alle Alt-Aufnahmen anfassen.


    Für die Ablage auf meinem RAID per samba-Mount hatte ich bisher zumindest immer schon die Dateinamen konvertiert, der Server selbst läuft nämlich wie jedes moderne System mit UTF8, das wollte ich auch so belassen.


    Viele Grüße,
    Torsten


    Hallo Oliver,
    danke für die Info - ja, durch die Threads hatte ich mich schon durchgebissen, aber speziell was den Tausch irgendwelcher Widerstände anging gab es verschiedene recht unpräzise formulierte Ansätze. Die 33pF-Kondensatoren hatte ich schon eingebaut (das stand auch so mal in der c't) und daher einfach mal unverändert drin gelassen. Die 330/380pF hatte ich bereits gegen 100pF getauscht, und den 100nF rechts neben dem IC (das hatte ich also richtig interpretiert) auf 200nF verdoppelt. D. h. damit habe ich aktuell genau den von Dir vorgeschlagenen Umbau-Zustand.


    Damit startet die Karte bisher zuverlässig (egal, wie lange der Rechner ausgeschaltet bleibt) und ich habe bisher auch keine Probleme mit der Videoausgabe auf der TT FF 2300 beobachten können - der Beamer rastet sauber ein und es gibt beim Live-Bild keine Ruckler o. ä.


    Ich denke, damit kann ich die Karte so lassen. Der Decoder liegt dann momemtan brach, was ich mir mal überlegt hatte war, ein Video-Display anzusteuern (GraphTFT kann das ja auch rudimentär über die FF-Karten) und dabei das Menü zur Hauptsache zu machen und das Live-Bild klein im Menü einzublenden. Ich weiß nicht, ob der Chip auf der TT FF das leistet. Aber die Idee kam mir beim Spielen mit der MediaMVP als VDR-Client, da wird das beim Aufruf der EPG-Übersicht gemacht.


    Gruß,
    Torsten

    Copperhead:


    Naja, das hält jeder wie er mag. In einem Server-System würde ich wohl auch eher einen unverpatchten VDR aufsetzen. Im Wohnzimmer-VDR habe ich halt schon einige Plugins installiert.


    Aber zurück zum Problem: Dieses ist reproduzierbar, mittlerweile weiß ich auch wie:


    Wenn beim Compilieren der fribidi-Support aktiv ist (BIDI=1 in Make.config) und der VDR mit einem westeuropäischen ISO-Zeichensatz läuft, dann knirscht es.


    Das sollte sich recht leicht bestätigen lassen. Für die e-Tobi-Pakete läßt sich der Spuk beheben, indem in debian/patches/81_Make_config.dpatch diese Option einfach abgeschaltet wird:



    Code
    +ifdef VDRDIR
    + include $(VDRDIR)/Make.global
    +endif
    +
    +# BIDI = 1


    Dann einmal die Änderung bestätigen


    Code
    PATCHVARIANT=multipatch debian/rules accept-patches


    und das Ganze durch den Compiler jagen



    Code
    export PATCHVARIANT=multipatch ; dpkg-buildpackage -tc



    und gut ist.


    Da sich an den entscheidenden Stellen am Code nichts geändert hat, gehe ich mal davon aus, daß auch der VDR 1.7.21 noch von dem Problem betroffen ist.


    Das Problem liegt lokal in font.c, an der VDR-API ändert sich durch die Umstellung nichts. Wer sich also aus dem e-Tobi Repository bedient muß nicht alles neu compilieren, sondern lediglich den VDR. Zumindest, solange nicht irgendeins der Plugins seinerseits irgendwo auf fribidi zurückgreift...


    Ich hoffe, daß ich damit denjenigen, die ihre VDRs noch - aus welchen Gründen auch immer - mit ISO8859 betreiben, etwas geholfen habe.


    Viele Grüße,
    Torsten

    Hallo,


    bei mir gibt die neue dvb_ttpremium_st7109-01_v0_2_11 einen Kernel Panic beim Booten ;( . Treiber und alle anderen Firmware-Teile sind aktuell.
    Es scheint was mit den Interrupts zu tun zu haben. Vielleicht gibt der untenstehende "Screenshot" dem kundigen Betrachter mehr Aufschluß.
    Ansonsten möchte ich hier mal die Gelegenheit nutzen und allen Machern, Testern und Denkern für die Firmware und Treiber der neuen S2-6400 ausdrücklich danken! Ich freu mich (fast) jeden Tag über den neuen vdr - Super Job!


    [Blockierte Grafik: https://s3-eu-west-1.amazonaws.com/seyboldt.public/panic-1.jpg]


    Hallo Falk & Falk,
    da seid ihr nicht die Einzigen. Ich hatte diesen Effekt mittlerweile auch mehrfach, allerdings nicht direkt beim Booten, sondern völlig zufällig während des Betriebs.Wenn es das nächste Mal kracht, werde ich den Trace mal per Kamera sichern...


    Auf jeden Fall checke ich heute abend nochmal den Firmware-Stand.



    Nachtrag: Die Abstürze sahen bei mir verdächtig gleich aus, hatten aber nach meinem bisherigen Erkenntnisstand eine andere Ursache - das RAM. Seitdem ich alte "known good" Riegel eingesetzt hatte habe ich keinen die Abstürze mehr gehabt. Toi toi...


    Nachtrag 2: Zu früh gefreut - seit meinem gestrigen Update (wegen VDR 1.7.21) sind die Probleme wieder da. Beim nächsten Crash versuche ich mal dran zu denken, die Kamera auszupacken...


    Gruß,
    Torsten

    Geht das denn mit 2 parallel aktiven Frontends (S2-6400 FF + PVR350)? Spätestens bei der OSD-Auflösung wird das doch etwas widersinnig...

    Ja, das funktioniert so gut oder schlecht wie das Umschalten der Auflösung der S2-6400. Die Frontends kann man einfach auswählen, wie das auch bei reinem SD schon ging, das OSD paßt sich halt an die aktuelle Auflösung an.


    Nachtrag: "Parallel" im Sinne von "gleichzeitig aktiv" laufen die Frontends ohnehin nicht, im VDR kann ich ja nur genau eins auswählen.

    Hallo zusammen,
    das Thema ist zwar alt, bei mir aber gerade durch ein Kernel-Upgrade (wegen S2-6400) wieder hochgekocht. Meine Lösung sieht wie folgt aus:


    /etc/default/grub:


    Code
    GRUB_CMDLINE_LINUX_DEFAULT="quiet"
    GRUB_CMDLINE_LINUX="vga=792 nomodeset video=vc:0-0 video=map:1"


    Damit erhalten die fb-Devices korrekte Namen und das PVR350-Plugin funktioniert einfach so. Außerdem funktionieren so auch die Single-User-Konfigurationen, ohne daß da plötzlich die Konsole weg ist!


    Das "nomodeset" ist wichtig, falls es Probleme mit dem Auslesen der EDIDs aus dem Monitor gibt. Das scheint ein bekanntes (aber bisher ungelöstes) Problem bei verschiedenen GPUs zu sein zu sein. Wenn es auftritt, werden Konsole und Logs u. U. minutenlang vollgemüllt, das System ist während dieser Zeit nahezu unbedienbar. "nomodeset" habe ich als Workaround in einem der Bug-Reports dazu gefunden.


    Viele Grüße,
    Torsten

    Kann ich ebenfalls nicht bestätigen. Das OSD wurde bei mir bisher immer sauber dargestellt. Vielleicht liegts ja am verwendeten Font, oder an irgendeinem Patch: Menuorg, Setup

    Copperhead:
    Wie ist denn Dein VDR gepatcht (gar nicht, eines von e-Tobis Patchsets (standard, multipatch), oder wie sonst)? Im Moment fische ich hier ziemlich im Trüben...


    Gruß,
    Torsten

    Die Probleme mit femon kann ich nicht bestätigen. Zu den Tuner kann ich nix sagen, 2 reichen mir.

    Hallo Copperhead,
    schon merkwürdig - bei mir hat es sich mittlerweile erledigt. Ich habe aber mittlerweile die Module manuell sortiert (per blacklist und modules), damit die Karten nicht ständig "auf Wanderschaft" gehen...


    Viele Grüße,
    Torsten

    Hallo zusammen,
    ich wärme den Thread hier mal auf, weil mich seit einem Mainboard-Wechsel ebenfalls Startprobleme bei der TT 2300 modded plagen.


    Die nicht bestückten Kondensatoren habe ich nach Angaben aus einem c't Artikel nachbestückt, das bringt aber bei mir überhaupt nichts.


    Was ist denn nun final die zuverlässige Lösung? Und: gibt es irgendwo ein Foto, wo genau (außer den kleinen Cs im Schwingkreis) noch Bauteile getauscht (R) hinzugelötet (C) werden sollen? Ich glaube zwar zu wissen, wo das passieren soll, aber Angaben wie "Kondensator rechts von" sind doch recht frei interpretierbar (da "rechts" abhängig davon ist, wierum die Karten vor mir liegt ;) ).


    Gruß,
    Torsten

    Hallo zusammen,
    ich krame diesen Thread mal wieder raus, da seit ein paar Tagen mein HD-VDR aufgebaut und aufgesetzt ist.


    Stand der Erkenntnisse:


    TS-h.264-Aufnahmen, die der aktuelle Reel-VDR erzeugt, verwenden auch das aktuelle Namensschema für die Dateien, die der offizielle VDR von Klaus verwendet. Die Aufnahmen sind dann direkt verwendbar.


    TS-h.264-Aufnahmen, die ältere Reel-VDR-Stände erzeugt haben, verwenden das alte Namensschema für PES-Aufnahmen, d. h. es handelt sich nicht wie an anderer Stelle im Thread behauptet um PES-Aufnahmen, sondern um TS-Aufnahmen, die einfach nur das Dateinamensschema der PES-Aufnahmen verwenden. Diese Aufnahmen können ganz einfach dadurch gangbar gemacht werden, daß man sie ins neue Namensschema überführt.


    PES-h.264-Aufnahmen, wie sie der gepatchte VDR von Klaus getätigt hat, laufen aktuell überhaupt nicht. Hier brauche ich noch immer eine Lösung.


    PES-MPEG2-Aufnahmen habe ich noch nicht getestet, hier geht es aber auch lediglich um die wenigen Testausstrahlungen, die mal gemacht wurden, nichtsdestotrotz einige Sachen, die ich nicht verlieren möchte.


    Viele Grüße,
    Torsten

    Hallo Falk,
    zu 2)
    Nein, auch mit einem ganz frischen Setup gibt's die gleichen Probleme. Wechsle ich auf die SD FF Karte, ist die Darstellung OK, was für mich dafür spricht, daß es nicht an irgendwelchen Einstellungen liegen kann. Ich reiche nochmal Fotos zu den Effekten mit den Tunern und dem OSD nach.


    Gruß,
    Torsten


    Nachtrag: Der Effekt ist tatsächlich von der eingestellten Auflösung der HD-Karte abhängig: Bei 576i wird der Skin korrekt dargstellt, bei 1080i werden die Texte übereinander gemalt. Der klassische und der ST:TNG funktionieren immer...

    Hallo Falk,
    wenn ich das OSD auf fix 720x576 konfiguriere klappt es. Irgendwie verstehe ich da beim Text2Skin wohl das Konzept nicht ganz: Entweder der Kram ist auflösungsunabhängig programmiert, dann müßte er sich doch einfach an die neue Auflösung anpassen, oder wenn er auf eine feste Auflösung (z. B. SD 720x576) ausgelegt ist, müßte das OSD einfach nur einen kleinen Teil der Anzeigefläche belegen, aber doch in sich wenigstens korrekt dargestellt werden.



    Copperhead:


    Ich habe noch ein weiteres Problem mit dem OSD: Die Umlaute sind wie schon z. B. in keine Umlaute im OSD beschrieben "merkwürdig" verwürfelt. Der Effekt hängt aber interessanterweise von der "Hi Level OSD" Einstellung im dvbhddevice ab. Bei "Ja" --> Umlaute OK, bei "Nein" -->Umlaute verwürfelt. Ich zitiere mal aus dem anderen Thread:

    Zitat

    Statt "Kanäle" wird im OSD bei mir "Kan䬥".Ich weiß nicht, ob die Darstellung hier funktioniert: Nach dem "ä" kommen die Zeichen "logisches NOT" (dez 108 ) und das Yen Zeichen (dez 165).


    Mein VDR läuft mit ISO-8859-15, was einfach daran liegt, daß ich noch andere Geräte mit dieser Konfiguration und jede Menge Aufnahmen auf dem Server liegen habe.

    zu 2) Das wird an irgendwelchen Einstellungen liegen. Skinenigmang basiert auch auf text2skin und wird sauber angezeigt. Lösch mal Alles, was mit OSD zu tun hat aus der setup.conf, damit das OSD auf die Defaultwerte fällt. Außerdem probier mal die OSD-Einstellungen im Plugin dvbhddevice aus.


    ...


    Falk

    Hallo Falk,
    zu 2)
    Nein, auch mit einem ganz frischen Setup gibt's die gleichen Probleme. Wechsle ich auf die SD FF Karte, ist die Darstellung OK, was für mich dafür spricht, daß es nicht an irgendwelchen Einstellungen liegen kann. Ich reiche nochmal Fotos zu den Effekten mit den Tunern und dem OSD nach.


    Gruß,
    Torsten


    Nachtrag: Der Effekt ist tatsächlich von der eingestellten Auflösung der HD-Karte abhängig: Bei 576i wird der Skin korrekt dargstellt, bei 1080i werden die Texte übereinander gemalt. Der klassische und der ST:TNG funktionieren immer...

    zu 2) Das wird an irgendwelchen Einstellungen liegen. Skinenigmang basiert auch auf text2skin und wird sauber angezeigt. Lösch mal Alles, was mit OSD zu tun hat aus der setup.conf, damit das OSD auf die Defaultwerte fällt. Außerdem probier mal die OSD-Einstellungen im Plugin dvbhddevice aus.


    zu 3) Dass die Tuner verwechselt werden, glaube ich nicht. Du musst nicht glauben, dass die beiden Tuner der S2-6400 auch immer hintereinander kommen. Ich habe auch oft die Situation, dass der erste Tuner der S2-6400 die Nr. 0 ist, dann kommt der Tuner meiner Tevii S2-470 und dann der 2. S2-6400-Tuner. Es ist reiner Zufall, wie die Tuner nummeriert werden.


    Falk


    Ich verstehe Deine Antwort ehrlich gesagt nicht so ganz - z. Z. sind nur zwei Kabel angeschlossen, wenn beide an der S2-6400 hängen, hat von der aber angeblich nur ein Tuner Empfang, dafür aber auch die KNC1. Wie soll der STB0899 denn Deiner Meinung nach ohne angeschlossenes Kabel Empfang haben? femon ordnet die Tuner-Namen in meiner Konfiguration definitiv falsch zu!


    Copperhead:


    Und noch was: War ein HD-Kanal eingestellt und ich aktiviere femon, kam es auch zu harten Abstürzen. Ich werde das heute abend nochmal etwas genauer untersuchen.


    Torsten