TechnoTrend Premium S2-6400 dual HD Technik / Treiber / Installation und bitte nur das

  • Code
    Jul  2 12:16:44 htpc vdr: [12645] VDR: writeallornothing: len=188 written=-1 errno=11


    Hmm, alles errno=11 ... lt. /usr/include/asm-generic/errno-base.h ist das EAGAIN, also (später) nochmal probieren.
    Der Treiber akzeptiert also momentan keine Daten und vertröstet die Anwendung damit, dass sie es später nochmal probieren soll ... da müssten jetzt die Treiber-Profis ran :]

  • Mir ist gerade aufgefallen, dass beim Verschieben von Schnittmarken immernoch "irgendwas" abstürzt. Es gibt dann für 2-3 min gar keine Reaktion auf dem Fernseher, dann kommt zumindest das OSD wieder und lässt sich bedienen.

    VDR-User #992
    Server: Asrock N3700-ITX mit Cine S2 6.5 headless
    System: Ubuntu 22.04.LTS
    VDR: VDR 2.2.0 mit epgsearch, live, vnsiserver
    Client: Raspberry Pi v4 mit LibreElec

  • Jetzt muss ich auch einen Fehler melden :( :( :( auch wenn es schon ein paar Tage her ist:



    Zwei Stunden davor hat er einwandfrei aufgezeichnet und ist ordnungsgemäß runtergefahren, am Abend danach auch keinerlei Probleme. Die Aufnahme selbst hat 0 Byte Größe. (Log auf das Notwendige gekürzt, komplettes Log auf Anfage)
    Treiber und alle drei Firmwares sind auf dem neuesten Stand, VDR 1.7.18


    any ideas?

  • Code
    Jul  2 12:16:44 htpc vdr: [12645] VDR: writeallornothing: len=188 written=-1 errno=11


    Hmm, alles errno=11 ... lt. /usr/include/asm-generic/errno-base.h ist das EAGAIN, also (später) nochmal probieren.
    Der Treiber akzeptiert also momentan keine Daten und vertröstet die Anwendung damit, dass sie es später nochmal probieren soll ... da müssten jetzt die Treiber-Profis ran :]

    ...habe mal versucht, den Treibercode zu lesen. Habe nur WTF gesehen, liegt aber an mir ; )


    :hilfe

    HD-VDR
    Hardware: TT S2-6400, DD Cine S2 V6, ASUS P8H67-M Rev.3, Intel Core i3-2100T, 2x1GB RAM, SSD 40GB Intel X25-V, 2TB, Western Digital WD20EARS, Silverstone Grandia GD04
    Projektor: Epson LH-TW5500 LPE
    Audio: Onkyo TX-SR309, HECO Superior
    Software: Ubuntu 12.04 64bit, vdr 2.0.0, osdteletext, femon, markad, dvbhddevice, remote, streamdev-server
    Status:läuft 1a

    Einmal editiert, zuletzt von Mr_T ()

  • Hallo Leute,


    bin neu hier, bitte nicht gleich steinigen ;)...
    Ich habe (hoffe ich zumindest) die aktuelle Firmware/Treiber Version laut Wiki installiert. Nun habe ich folgende Probleme:
    Femon kann ich praktisch nicht verwenden, nach ein paar mal Umschalten der Kanäle oder Tuner bleibt der OSD stehen (gut reproduzierbar). Im Syslog habe ich folgende Einträge (gerald hatte auch ähnliche?)



    Starte ich vdr-sxfe, bevor der Watchdog-Timer zuschlägt, läuft alles bestens und es geht auch weiter. Generell gibt es keine Probleme, wenn ich über xineliboutput femon verwende. Als Skin verwende ich skinenigmang. Komisch ist auch, dass keine Senderlogos mehr angezeigt werden. Die Symbole, die Im Hauptmenü für die einzelne Menüpunkte rechts angezeigt werden, sind allerdings da.


    In kern.log treten sporadisch folgende Einträge auf (ohne irgendeine Fernbedienung in der Wohnung zu betätigen!)


    Code
    Jul  5 19:15:57 Supernova kernel: [ 2039.366575] saa716x_ff_pci_irq (0): REMOTE EVENT: 0
    Jul  5 19:17:43 Supernova kernel: [ 2145.812288] saa716x_ff_pci_irq (0): unknown interrupt source


    Ausserdem kann z.B. ARD-HD nach einem Boot nicht empfangen werden. Ein Umschalten der Tuner über femon hilft auch nicht. Nach einem Neustart von vdr geht es meistens.
    Nun meine (inkompetente :D) Fragen:
    - kann es sein, dass die Spannung zum Umschalten V/H (oder was auch immer mit Spannung umgeschaltet wird) durch all die Geräte an der Strippe nicht ausreichend ist? Ich habe LNB Verteiler + LNB-Switch (Spaun SUR schlagmichtot...) im Einsatz. Könnte ich mit einem stink-normalen digitalen 10 € Spannungsmesser die Spannungen messen, um diese Fehlerquelle auszuschließen? Oder gibt es vielleicht irgendwelche SAT-Prüf-Geräte für einen bezahlbaren Preis? (beträfe jedenfalls nur die 6400, davor ging ja alles).
    - gibt es vielleicht Probleme durch Multithreading (4 Core CPU)? Wie kann ich VDR auf einen CPU-Core festnageln?
    - können die Umschaltprobleme durch eine falsche diseqc.conf hervorgerufen werden? (In der vorherige Konfiguration mit VDR 1.7 und FF Hauppauge Nexus-S + Nova HD hat alles funktioniert)
    - und noch eine (blöde) Frage, die eigentlich kein Problem, sondern eher Feature wäre: könnte man evtl. den Rechner via HDMI einschalten? Mein Sony Fernseher erkennt zumindest die Karte als HDMI-Gerät (Bravia Sync) und bietet die Steuerung an.
    Wenn weitere Infos benötigt werden, stehe gerne zur Verfügung, aber bitte gleich mit howto, sonst schaffe ich es u.U. nicht... Ich finde jedenfalls das Engagement der User hier OAG und würde gerne mitwirken :]
    Vielen Dank im Voraus!

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • Erstmal vielen Dank für die Antworten!


    Wiki war das hier.
    Sieht ziemlich aktuell aus, das ganze Prozedere habe ich am vergangenen Wochenende gemacht, sollte aktuell sein, oder? Wenn ich richtig gelesen habe, sind die verschiedene Patches, die hier vor Wochen erwähnt wurden, alle bereits in die Repositories eingeflossen.

    Code
    dmesg|grep SAA|grep version
    [   21.211683] SAA716x FF FPGA version 1.08
    [   21.272685] SAA716x FF loader version 1.03
    [   22.927795] SAA716x FF firmware version 0.2.B


    Meines wissen auch die neuesten?
    Jetzt werde ich mal rumexperimentieren, ob ich zumindest das Umschaltproblem wegbekomme. Bleibt noch das OSD-Problem mit Femon, die ich wahrscheinlich nicht lösen kann :( Gebe es vielleicht eine Möglichkeit, die Syslog-Ausgaben des Treibers bezüglich timed out OSD Commands sinnvoll zu erweitern?
    Ausserdem habe ich noch diese OSD-lockups auch beim Setzen von Schnittmarken beobachten können, wenn ein Schnitt bereits aktiv war und die Festplatte voll ausgelastet war. Wenn die Festplatte nicht ausgelastet ist (bzw. keine Aufzeichnung gerade geschnitten wird), hatte ich noch nie Probleme beim Setzen/Verschieben der Schnittmarken.
    Würde noch gerne die Prozessorzugehörigkeit ausprobieren (die Interrupts scheinen nur noch eine CPU zu beschäftigen, obwohl ich nichts in die Richtung gemacht habe), wenn mir jemand dabei helfen könnte, wie man das macht:D. Unter Windows wüsste ich es selber, unter Linux muss ich passen...

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • Mach in den Einstellungen des dvbhddevice "High Level OSD" aus. Dann geht femon.


    Probiere ich sofort. Was bedeutet eigentlich diese Einstellung?

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • Es ist nur schlimmer geworden, jetzt komme ich nicht mehr mal in das Hauptmenü ;(


    es geht so weiter mit einigen timed out... /Sekunde

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • Ich habe jetzt einige Zeit den Rechner nicht mehr beobachtet, nach etwa 20 Minuten habe eine syslog von 430 MB voll mit folgendes:


    Der Rechner wollte auch nicht mehr herunterfahren, es half nur ein reset.... Das wird ja immer bunter... :(

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • Ich weiß ja nicht, was genau du gemacht hast, aber das ist sicherlich nicht normal.

    Ich habe den watchdog timer in VDR abgeschaltet und der ist für etwa eine halbe Stunde mit der nicht reagierende OSD weiter gelaufen. Sonst nix, habe gegessen und ein paar stamperl hinterher geschickt :D

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • Kurzes Update zum Kernel Panic in Beitrag 690 (TechnoTrend Premium S2-6400 dual HD Technik / Treiber / Installation und bitte nur das) :
    Da der Rechner 24x7 läuft wird er recht selten neu gestartet. Ein Umzug des Rechners machte einen Neustart notwendig und bei dem kam es auch mit der dvd-ttpremium-st7109-01_v0_2_10 zu dem Kernel Panic.
    Am Ende hat ein Umbau der Karte vom PCIE16X_1 Slot in den PCIE16X_2 geholfen. MB ist Asus M4A88T-V EVO USB3. FW war 0306. Mehrere Neustarts und tagelanger Betrieb mit FW dvd-ttpremium-st7109-01_v0_2_11 bislang erfolgreich. :]


    der andere Falk

  • Auch von mir mal ein kleiner Bericht zu meinem neuen TT-6400-basierten VDR. Eingebaut in einem Shuttle SH67 (siehe Sig "VDR0").


    Nach den vernichtenden ersten Tests in einem MSI-H67-Board im April lief es nun eigentlich recht gut (aktuelle Treiber/FW), so dass ich nach zwei Wochen beschlossen habe produktiv umzusteigen. Erst sah alles wirklich sehr gut aus (absolut stabil, und nat. ist die Wiedergabe mit der 6400 im Vergleich zu vdpau ein Traum), und ich plante schon weitere VDR mit einer 6400 auszustatten.


    Allerdings - war klar - je länger man im Alltag damit lebt, desto mehr Probleme fallen auf, von Kleinigkeiten bis zu Besorgnis Erregendem.


    Zuerst gab es schon einen Schock beim Umbau an den angestammten VDR-Platz: plötzlich (nachdem es nie auch nur ein Klötzchen gab) war alles voller Artefakte. Liess sich allerdings auf ein (sehr kurzes, aber defektes?) USB-Kabel zurückführen, an dem der DVB-T-Stick hing (zuvor direkt angesteckt, USB 3.0). Mit einem längeren Kabel (und vorsichtshalber an einem anderen Port, USB 2.0) verschwand der Spuk wieder. Ausserdem hing der Rechner zT sogar beim Booten im BIOS, also war da wohl wirklich was nicht ganz in Ordnung mit dem Kabel (oder - hoffentlich nicht - USB-Port).
    Das ganze zeigt aber, wie fragil das Glück sein kann - offenbar kann alles mögliche zu Artefakten führen, nicht nur Treiber/FW, sondern schon das falsche Kabel am falschen Ort. Fragt sich, ob es der 6400 anzulasten ist, dass sie so sensibel ist - mangelnde EM-Störfestigkeit oder sowas?


    Leider habe ich seither nun schon mehrfach doch wieder Artefakte "gesehen". Einmal nur in Eins Festival (Demoschleife), nach Umschalten war es wieder weg.
    Dann nach dem Booten: Startprogramm war ServusTV-HD, Bild schwarz, Ton nur in Fetzen. Wieder nach Umschalten alles OK.
    Zuletzt wieder nach dem Booten in der Aufnahme und live: Artefakte! Streckenweise massiv, streckenweise weniger, aber dauerhaft. Umschalten half nichts. Restart des VDR (via OSD-Setup) half auch erst nichts, aber nach einiger Zeit war wieder alles OK. Einfach so. Wetter die ganze Zeit bestens.
    Im Log absolut nichts verdächtiges.
    Das ist natürlich die grösste Sorge - wenn die erste wichtige Aufnahme verpixelt ist, ist der Ärger gross. Stabilität und Zuverlässigkeit ist das absolut wichtigste, und nachdem es erst so gut aussah, steht nun alles wieder in Frage.
    Leider kann ich nichts dazu beitragen, dem Fehler auf die Spur zu kommen - wie gesagt keinerlei Fehler im Log.
    Aber perfekt ist das noch lange nicht.


    Dann gibt es noch so gewisse Seltsamkeiten.


    So 1-x mal am Tag/Abend wird das letzte FB-event nach einigen Minuten wiederholt, einfach so. Also ich habe zB gemutet, plötzlich ist der Sound wieder da. Oder ich habe zuletzt umgeschaltet "nach unten", plötzlich schaltet er von selbst nochmal eins zurück. Das heisst der IR-Receiver doppelt sporadisch das letzte event und schickt es mit grosser Verzögerung nochmal. An der FB kann es kaum liegen, die verwende ich seit 8 Jahren mit allen Vorgänger-VDR problemlos.


    Manchmal (bisher sehr selten) ist der Ton einfach weg. Nach Umschalten ist er nur kurz da, dann wieder dauerhaft weg - auf allen Sendern. Nur ein VDR-Restart hilft.


    Einzelne ganz wenige Sender (Sport1 SD) sind nur auf einem der Tuner zu empfangen - beim anderen schwarzer Schirm. Nach dem Umschalten dort hin dann plötzlich auch Probleme mit anderen Sendern, die zT gar nicht mehr kommen wollen. Erst Restart hilft. Die Details habe ich allerdings schon wieder verdrängt.


    Also - Licht und Schatten. So ganz uneingeschränkt kann ich die 6400 noch nicht empfehlen.. auch wenns mich bei Threads wie "mein täglicher HD-Wahnsinn" schon jucken würde das zu tun - Wiedergabe-seitig ist es natürlich wunderbar, eben "wie früher" mit der FF.. Sprünge gehen fix, und man kann tatsächlich wieder _spulen_ - Wahnsinn! ;)

  • Ich habe den watchdog timer in VDR abgeschaltet und der ist für etwa eine halbe Stunde mit der nicht reagierende OSD weiter gelaufen. Sonst nix, habe gegessen und ein paar stamperl hinterher geschickt :D

    Ich habe auch diese Meldungen im Log File

    Code
    [ 9677.337276] saa716x_i2c_send (0): TXFIFO not empty after Timeout, tried 1000 loops!
    [ 9677.337287] saa716x_i2c_send (0): I2C Send failed (Err=-5)
    [ 9677.337294] saa716x_i2c_xfer (0): Data send failed
    [ 9677.337306] saa716x_i2c_hwinit (0): Adapter (c000) SAA716x I2C Core 1 RESET
    [10982.207796] saa716x_i2c_send (0): TXFIFO not empty after Timeout, tried 1000 loops!
    [10982.207804] saa716x_i2c_send (0): I2C Send failed (Err=-5)
    [10982.207807] saa716x_i2c_xfer (0): Data send failed
    [10982.207815] saa716x_i2c_hwinit (0): Adapter (c000) SAA716x I2C Core 1 RESET


    Das führt bei mir auch ganz selten zum Watchdog Timeout. Was für einen Skin benutzt du, ich hab skinenigmang und anthra im Einsatz.

  • Erst sah alles wirklich sehr gut aus (absolut stabil, und nat. ist die Wiedergabe mit der 6400 im Vergleich zu vdpau ein Traum), und ich plante schon weitere VDR mit einer 6400 auszustatten.


    Es ist schon erstaunlich, wie individuell unterschiedlich die Symptome sind. Und da die Hardwareausstattung auch unglaublich viele Nuancen haben kann, wird es wohl auch noch mehr Fehlerbilder geben.
    Eigentlich habe ich keinen Grund mich hier ans "Sorgentelefon" zu wenden, trotzdem möchte ich auch was zum jetzt mehrmonatigen Produktiveinsatz sagen. Nach den ersten Meldungen habe ich die Karte ca. 2 Wochen ausgiebig getestet. Anfangs im Dauerlauf - da berichtet wurde, das es beim Dauerlauf zu Problemen kommen könnte. Danach dann habe ich den Rechner mehrmals täglich gestartet um Kaltstartprobleme zu beobachten. Dann habe ich Aufnahmen getestet in allen Facetten, nur für 6 oder mehr gleichzeitige HD Aufnahmen fehlte mir der Ehrgeiz bzw. Equipment. Auch habe ich das Ganze auf einem zweiten Board getestet, falls das primäre Board einmal stirbt (damaliger Verdacht, das einige Chipsätze problematisch sind). Als die 2 Wochen herum waren ( Wahrung des Rückgaberecht) konnte ich nur den Soundfehler beim Umschalten der Tuner festmachen. Alle anderen Dinge die ich sonst noch so beobachtete, ließen sich nicht reproduzieren bzw. waren Einzelerscheinungen. Danach ging die Karte in den Produktiveinsatz und macht seitdem täglich das, was wir so täglich benötigen.


    Gruß Fr@nk

Jetzt mitmachen!

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