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

  • Hallo,


    das teilweise geschilderte Tonproblem konnte ich jetzt auch verifizieren.
    Wenn ich im femon-plugin mit der rechts Taste das device wechsele, dann bekomme ich auch nach dem hin und zurück wechseln auf das Ursprungsdevice keinen Ton. Wenn ich dann mit Grün die Audio Spuren durch wechsele, kommt der Ton stotternd. Wechsele ich den Kanal ist alles wieder gut.


    Gruß Fr@nk

  • Verwendet man einen Splitter um das SAT-Kabel auf beide Tuner aufzuteilen schaltet die Karte unkontrolierbar zwischen beiden Tunern um und damit geht das Signal laut femon komplett auf 0.


    Ich habe bei mir den VDR mit dem LNB-Sharing Patch versehen. Dadurch läufts perfekt. Ist aber weiterhin unschön, dass nur mit einem Tuner HD+ geschaut werden kann.

  • Ich habe immer mal wieder das Problem, dass die Karte komplett abstürzt. Sie liefert dann kein Signal mehr am HDMI - Ausgang und VDR kann keine Daten mehr zur Karte senden.


    Heute Nacht lief bis 4:11 alles normal. VDR war die ganze Zeit auf ZDF HD und hat diesen Sender per Tranfermode wiedergegeben, weil er als Tuner die zusätzlich vorhandene TeVii S470 ausgewählt hatte. Zu besagtem Zeitpunkt tauchten dann die ersten Fehler im VDR-Log auf:



    Apr 24 04:11:05 vdr vdr: [19420] ERROR: TS packet not accepted in Transfer Mode
    Apr 24 04:31:05 vdr -- MARK --
    Apr 24 04:35:43 vdr vdr: [19420] ERROR: TS packet not accepted in Transfer Mode
    Apr 24 04:35:44 vdr vdr: [19421] buffer usage: 70% (tid=19420)
    Apr 24 04:35:44 vdr vdr: [19421] buffer usage: 80% (tid=19420)
    Apr 24 04:35:44 vdr vdr: [19420] ERROR: TS packet not accepted in Transfer Mode


    Diese Meldungen wiederholen sich ab dann in Abständen von 5...10 Minuten. Wie das Bild zu dieser Zeit aussah ist unbekannt.


    Dann, um 8:55 kam offensichtilich der Endgültige Crash:



    Apr 24 08:55:15 vdr vdr: [19420] ERROR: TS packet not accepted in Transfer Mode
    Apr 24 08:55:15 vdr vdr: [19421] buffer usage: 90% (tid=19420)
    Apr 24 08:55:16 vdr vdr: [19421] buffer usage: 100% (tid=19420)
    Apr 24 08:55:16 vdr vdr: [19420] ERROR: TS packet not accepted in Transfer Mode
    Apr 24 08:55:17 vdr vdr: [19420] ERROR: TS packet not accepted in Transfer Mode
    Apr 24 08:55:17 vdr vdr: [19421] ERROR: driver buffer overflow on device 1
    Apr 24 08:55:18 vdr vdr: [19420] ERROR: TS packet not accepted in Transfer Mode
    Apr 24 08:55:19 vdr vdr: [19420] ERROR: TS packet not accepted in Transfer Mode
    Apr 24 08:55:19 vdr vdr: [19421] ERROR: driver buffer overflow on device 1


    Danach kamen nur noch Fehler und um ca. 13:00 als ich den TV angeworfen habe, meldete dieser nur "No Sync Signal".


    Die Abstürze treten 2..3 mal pro Tag auf, was nach meinem Geschmack entschieden zu oft ist.


    Falk


  • Das sind so ungefähr 2..3 Abstürze/Tag zuviel. ;(


    Läßt es sich näher einkreisen?
    1) Enthält der Stream von der TeVii Datenfehler? -> femon
    2a) Reicht es, VDR neu zu starten (kein Neuladen der Treiber!)?
    2b) Oder ist ein Neuladen der Treiber notwendig?
    2c) Oder ist ein Neustart des Rechners notwendig?


    CU
    Oliver

  • Läßt es sich näher einkreisen?
    1) Enthält der Stream von der Tevil Datenfehler? -> femon
    2a) Reicht es, VDR neu zu starten (kein Neuladen der Treiber!)?
    2b) Oder ist ein Neuladen der Treiber notwendig?
    2c) Oder ist ein Neustart des Rechners notwendig?

    Datenfehler sind es eher nicht. Die TeVii hat einen Super Empfang. Außerdem ist es egal, woher das Signal kommt, die Abstürze passieren trotzdem.


    VDR - Neustart reicht definitiv nicht.


    Neuladen der Treiber ist mir in der Situation noch nicht gelungen. Habe es 2x versucht, beide Male hing rmmod und im Log stand hinterher ein Kernel OOps. Den habe ich in einem früheren Post schon mal dokumentiert.


    Neustart des Rechners hilft zuverlässig (Power off nicht nötig).


    Eben hat's aber nur 'ne knappe Stunde gehalten.


    Falk

  • Bei mir hat das Kompilieren der Treiber erst einmal nicht geklappt. Im Wiki steht, dass man folgenden Link setzen soll

    Code
    ln -s /usr/src/linux-headers-$(uname -r)/include/linux/compiler.h compiler.h


    Dort fand sich aber keiner compiler.h. Ich musste den Link wie folgt setzen

    Code
    ln -s /usr/src/linux-headers-2.6.32-5-common/include/linux/compiler.h compiler.h


    Ich verwende allerdings Debian und nicht Ubuntu.


    Bei Debian hat es die compiler.h noch nicht in alle Header geschafft, und ist nur im -common Zweig vorhanden, statt dem übersetzungsspezifizschen Zweig (-486, -686, -amd64, etc.)


    Bei mir hat aber das Übersetzen der Treiber trotz allem funktioniert, und da die 0.0.4-Version des dvbhddevice auch gegen vanilla Kernel Header compiliert, ist auch die compiler.h nur bei Installation der powarman-DVB-Header erforderlich.


    Gruß,


    Udo

  • Hallo,


    das teilweise geschilderte Tonproblem konnte ich jetzt auch verifizieren.
    Wenn ich im femon-plugin mit der rechts Taste das device wechsele, dann bekomme ich auch nach dem hin und zurück wechseln auf das Ursprungsdevice keinen Ton. Wenn ich dann mit Grün die Audio Spuren durch wechsele, kommt der Ton stotternd. Wechsele ich den Kanal ist alles wieder gut.


    Gruß Fr@nk

    Hallo, hast du die neuste version vom dvbhhddevice-plugin? powarman hatte dort ja schon einen kleinen quickFix eingebaut und will demnächst den richtigen Fix bringen.



    Ich hatte gestern beim zappen auch wieder ein kleines Problem:

    • Auf Arte geschaltet. Arte lief.
    • Kanal hoch -> OSD zeigt EPG usw vom nächsten Kanal an, Bild und Ton bleiben jedoch Arte. Auf Eingaben von der FB wurde nicht mehr reagiert (Ich benutze das remote-Plugin zusammen mit der HDFF-Karte).
    • Dann manuel per vdradmin den Kanal gewechselt. VDR schreibt in die Log, dass er den Kanal gewechselt hat. Bild von Arte blieb stehen, jedoch kam der Ton vom neuen Kanal.
    • VDR ausgemacht. Bild wechselte jetzt auch zum neuen Kanal.


    Leider gibt es ziemlich wenig Infos in den Logs. Kann man den Treiber/Karte/VDR gesprächiger machen?

  • Ebenso hier.


    Passiert reproduzierbar wenn ich in einer Aufnahme (RTL SD) zw. den Schnittmarken springe und sie dann verschiebe, mit gedrückter "4".
    Nach einigen Sekunden Schnelldurchlauf bleibt das Bild stehen und alles wird träge. Die Load steigt dann kurz auf 1.00, VDR-Load gegen 0.


    Ich kann allerdings dann mit Exit die Wiedergabe beenden, bekomme aber kein Live-Bild. Das Menü reagiert wieder ganz normal. Starte ich die Wiedergabe erneut, ist das OSD wieder träge, die Load wieder auf 1.00.
    Exit -> Load wieder runter, Menü ok.


    Während der gesamten Zeit habe ich aber keinen Fehler im Log.


    Nur VDR neustarten hilft nicht. wenn ich das versuche hat VDR einen kurzen Hänger:


    Code
    Apr 24 15:00:24 video1 vdr: [23662] creating cDvbHdFfDevice
    Apr 24 15:00:24 video1 vdr: [23662] new device number 1
    Apr 24 15:00:24 video1 vdr: [23662] frontend 0/0 provides DVB-S2 with QPSK ("STV090x Multistandard")
    Apr 24 15:00:24 video1 vdr: [23666] tuner on frontend 0/0 thread started (pid=23662, tid=23666)
    Apr 24 15:00:24 video1 vdr: [23667] section handler thread started (pid=23662, tid=23667)
    <2 Sekunden Pause>
    Apr 24 15:00:33 video1 vdr: [23662] probing /dev/dvb/adapter1/frontend0
    Apr 24 15:00:33 video1 vdr: [23662] creating cDvbDevice


    Ein neuladen des Treiber klappt problemlos und hilft immer.


    Getestet mit folgenden Aufnahmen:


    Es tritt nicht auf bei SD-ts Aufnahmen von meinem alten VDR.
    Es tritt nicht auf bei HD-Aufnahmen mit der neuen Karte.


    Es tritt reproduzierbar auf bei SD Aufnahmen (ARD, RTL) mit der neuen Karte.


    System: Squeeze, 2.6.38.3 mit linux-media.tar.bz2, aktuellstes dvbhddevice aus GIT, vdr-1.7.18

    VDR1: Gigabyte GA-M720-US3 (nVidia Corporation MCP78S [GeForce 8200]), Athlon II X2 240, 2GB RAM, Intel 82574L Gigabit, Debian Squeeze, Kernel 2.6.38.3 mit linux-media.tar.bz2 vom 20.04. 10:04, dvbhddevice fb6b1beedb72, VDR-1.7.22 (extension-Patch, 15 Plugins), epgsearch, extrecmenu, ...
    VDR2: Debian Etch, 2.6.21.3, K6-2 400, 192MB, NFS-Root, 466GiB über NFS, 1xNexus 2.1, 1xNova S, VDR-1.4.7
    Server: Debian Squeeze, 2.6.35.7, AMD X2 240e, 4GB, System: Raid1 2x500GB, Aufnahmen: Raid5 4TB + 1x 500GB, 1000MBit LAN
    Episodenlisten für epgsearch, VDRSeriesTimer

  • Zu dem Hänger-Problem mal einen Schuß ins Blaue: Welchen Kernel/welche Treiberversion setzt ihr ein?


    Oder genauer, was steht in saa716x_ff_main.c


    Code
    static struct file_operations dvb_osd_fops = {
    ...
            .unlocked_ioctl = dvb_generic_ioctl,
    ...
    };


    oder


    Code
    static struct file_operations dvb_osd_fops = {
    ...
            .ioctl          = dvb_generic_ioctl,
    ...
    };


    ?


    CU
    Oliver

  • /usr/src/linux-2.6.38.3/drivers/media/common/saa716x/saa716x_ff_main.c

    Code
    static struct file_operations dvb_osd_fops = {
            .owner          = THIS_MODULE,
            .unlocked_ioctl = dvb_generic_ioctl,
            .open           = dvb_generic_open,
            .release        = dvb_generic_release,
    };

    VDR1: Gigabyte GA-M720-US3 (nVidia Corporation MCP78S [GeForce 8200]), Athlon II X2 240, 2GB RAM, Intel 82574L Gigabit, Debian Squeeze, Kernel 2.6.38.3 mit linux-media.tar.bz2 vom 20.04. 10:04, dvbhddevice fb6b1beedb72, VDR-1.7.22 (extension-Patch, 15 Plugins), epgsearch, extrecmenu, ...
    VDR2: Debian Etch, 2.6.21.3, K6-2 400, 192MB, NFS-Root, 466GiB über NFS, 1xNexus 2.1, 1xNova S, VDR-1.4.7
    Server: Debian Squeeze, 2.6.35.7, AMD X2 240e, 4GB, System: Raid1 2x500GB, Aufnahmen: Raid5 4TB + 1x 500GB, 1000MBit LAN
    Episodenlisten für epgsearch, VDRSeriesTimer

  • Es wäre insbesondere interessant, ob das Problem verstärkt mit ".unlocked_ioctl" auftritt.
    (Achtung, die ".ioctl" Variante läßt sich wahrschenlich nur mit Kernel < 2.6.36 übersetzen.)


    CU
    Oliver

  • Hallo, hast du die neuste version vom dvbhhddevice-plugin?


    ich hatte gestern alles ausgecheckt und vdr meldet auch Version 0.0.4. Ich ging avon aus, das die Änderungen im HG eingeflssen sind. Welchen Quickfix meinst Du konkret, dann schaue ich mal in die Quellen.


    Gruß Fr@nk

  • Ich kann die Probleme hier auch bestätigen.


    Ich habe jetzt mal die Treiber mit unlocked_ioctl und .ioctl ausprobiert. Beides lässt sich bei mir übersetzen und auch benutzen, aber mit .ioctl bekomme ich gar keine Ausgabe (kein Bild, kein Ton und auch kein OSD).
    Der VDR läuft aber, man sieht das im Log-File und auch bedienbar ist er, man kann ihn z.B. mit der Fernbedienung neu starten, allerdings ohne Effekte.


    Ich habe hier allerdings auch noch eine alte SD-Aufnahme, die ich mal in ein MPG-File umgewandelt hatte. Das läuft unter verschiedenen Programmen (vlc.o.ä.) ohne Probleme. Jetzt habe ich die mal in .ts und .vdr mit ProjectX zurückgewandelt (sollte hier vorerst mal als Ersatz für das mplayer-plugin dienen). Diese beiden Dateien lassen sich aber reproduzierbar nicht abspielen, in beiden Fällen tritt nach kurzer Zeit das genannte Problem auf (Wiedergabe bleibt stehen, OSD ist noch bedienbar, Wiedergabe lässt sich auch beenden aber kein Live-Bild und Ton) Helfen tut hier nur ein Neuladen der Treiber.


    Mein System wie in Signatur, dvbhhddevice-plugin letzter Stand, Treiber (nur SAA716x zum Originalkernel dazu) aktuell

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich hatte gerade einen Ooops:
    Bin in einer Aufnahme hin und hergesprungen, dann blieb alles stehen. Habe dann den VDR beendet und versucht wieder zu starten. Das Bild blieb aber schwarz. Dann habe ich mittels modprobe -r saa716x_ff versucht zu entladen. In der Log tauchte dann folgendes auf:



    Bei meinen folgenden Tests habe ich das streamdev-Plugin testweise weggelassen. Dann bekomme ich eine Kernelpanic(glaube ich) nach dem Laden des Moduls. Der ganze PC reagiert nicht mehr.


    Kernel: 2.6.32-30-server #59-Ubuntu SMP Tue Mar 1 22:46:09 UTC 2011 x86_64 GNU/Linux
    Ubuntu: 10.04


    Root-FS über iscsi
    /video über nfs
    DVB-Treiber aus http://powarman.dyndns.org/hgwebdir.cgi/v4l-dvb-saa716x/ (aktueller stand) und


    .ioctl = dvb_generic_ioctl,

  • ich hatte gestern alles ausgecheckt und vdr meldet auch Version 0.0.4. Ich ging avon aus, das die Änderungen im HG eingeflssen sind. Welchen Quickfix meinst Du konkret, dann schaue ich mal in die Quellen.


    Gruß Fr@nk


    Hallo Frank, ich bezog mich auf folgenden Post

    Mit der letzten Änderung im plugin sollte der Ton in dem Fall wieder OK sein, bis auf eine Ausnahme: Direkt nachdem die Aufnahme gestartet wird, ist der Ton erstmal weg, einfaches Zappen behebt das Problem. Zur endgültigen Lösung muss ich die SetChannelDevice Funktion mal komplett überdenken, die enthält scheinbar noch ein paar Altlasten von der SDFF drin, die so nicht mehr nötig sind.


    Du hast dann wahrscheinlich schon den "QuickFix" drinne.

  • Hi,


    was mir zusätzlich zu den genannten Problemen noch aufgefallen ist:


    Wenn man live Fernsehen schaut, sind (fast) keine Bildfehler zu sehen (mir sind allerdings einzelne Pixelfehler aufgefallen). Nimmt man im Hintergrund auf, oder macht nur Timeshift, fangen Bildfehler an. Ich dachte zunächst, dass es nur Wiedergabefehler sind. Aber die Aufnahme ist tatsächlich kaputt. Ich habe die Aufnahme mit xine am Rechner im X angeschaut und die gleichen Bildfehler sind in der Aufnahme.


    Also kann man (ich) z.Zt. keine Aufnahme machen, die 100% ok ist.


    Viele Grüße

  • Hatte eben massive Bildstörungen, aber immerhin noch ein Signal am Ausgang. In der Situation konnte ich das Modul saa716x_ff entladen. Nach erneutem Laden des Moduls hat die Karte sich wieder gefangen.


    Ein Hitzeproblem kann man wohl ausschließen. Habe mal einen Lüfter direkt vor die Karte gesetzt. Der Kühlkörper ist nur noch Handwarm, die Karte stürzt aber weiterhin ab. Schade.


    Falk

Jetzt mitmachen!

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