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


  • Außerdem scheint mir das Fehlersuchen immer noch ein Stochern im Dunkeln zu sein, oder warum hat bisher noch keiner bemerkt, dass der Startkanal eine Rolle spielt? Oder kann mir irgend jemand erklären, warum manche Kanäle bei manchen Tune-Vorgängen die TS-Daten durcheinander wirbeln, Arte SD jedoch nicht?


    Timing ist alles. Bei mir hing es sogar davon ab, welche Treibermodule geladen wurden bzw. nicht geladen wurden.


    Quote

    Bisher sieht mir das re-align eher nach einem Workaround für ein nicht verstandenes Problem aus.


    Warum die Daten manchmal nicht packet-aligned sind, ist unklar. Da allerdings beim ngene das gleiche Problem auftritt, ist zu vermuten, daß es ein "Feature" des Demod-Chips ist.


    Offensichtlich dagegen ist, daß der ursprüngliche Workaround im Treiber letztendlich das Verwürfeln der Pakete verursacht. Wieso dies passiert, steht auch nicht im Datenblatt. Jetzt gibt es halt einen Workaround für das ursprüngliche Problem ganz in Software.


    Btw, so etwas ist nicht ungewöhnlich. Heutzutage sind SW-Workarounds in Treibern leider an der Tagesordnung...


    Quote

    Anyway, ich werde jetzt den aktuellsten Stand weiter testen. In etwa 2 Wochen werde ich euch dann informieren, ob er stabiler ist, oder nicht.


    Wenn ein Problem auftaucht, sollte man immer die aktuellsten Treiber probieren. Und nicht vergessen, den alten Treiber zu archivieren, damit man später notfalls vergleichen kann.


    CU
    Oliver

  • Es liegt mit Sicherheit nicht an mir. Irgendwie ist dein Kernel-Source korrupt. Der Grund warum die "UFO-Weise" so viel größer/viel mehr Module hat ist, dass dieser die Module nicht gegen den Kernelsource sonder gegen seinen eigenen v4l-Source kompiliert. Dadurch werden Kernelmodule überschrieben, die eigentlich gar nicht überschrieben werden müssten.


    Zum Problem mit der Module.symvers. Hast du die Kernel-Header installiert? Laut packages.debian.org liegt diese Datei in den Kernel-Headers.


    Ich habe die kernel-headers installiert, habe die Datei dort auch gefunden und mal einfach an den verlangten Ort kopiert.
    Nun ist die Warnung zwar weg, es ändert aber nichts am Ergebnis, der Kernel akzeptiert die Module nicht ?(


    Ist aber aus meiner Sicht nicht soo schlimm, da ich jetzt mit dem aktuellen Treiber vom 3.6. auf UFO-weise kompiliert keine Probleme mehr habe - offenbar sind wir da jetzt aus dem Schlimmsten raus.
    Ich fand halt Deine Methode sehr elegant da nicht so aufwändig und wollte Dir auf diese Weise rückmelden, dass es hier nicht funktioniert- trotzdem nochmal vielen Dank!


    CU Doc

    [size=10]Hardware:GIGABYTE GA-M720-US3, AMD Athlon II X2 250 3.00GHz AM3 , Desktop-Gehäuse, TT Premium S2-6400 dual HD, Logitech Harmony 525
    Software: Debian GNU/Linux 6.0, Kernel 2.6.38-bpo.2-amd64, vdr 1.7.18-1~ctvdr1 e-tobi/multipatch

  • Gestern Abend hatte ich ein seltsames Phänomen:


    Habe eine Aufgenommene Serie abgespielt und bin mit der Info-Taste in das Info-Menü gegangen. Dann Standbild (kein Ton)[21:28:02]. der Watchdoch schlug nach 60 Sekunden zu und hat den VDR neu geatrtet. Das Bild inkl. OSD-Menü blieb aber stehen. Nach mehreren Watchdog-Restartst Habe ich über die Konsole ein Reboot gemacht.
    Nach dem Reboot War auf Tuner #0 Schwarzbild und hohe BER (0080000). Ging auch nicht weg durch mehrfaches umschalten mit FEMON. Wegen den BER und weil Regen war habe ich in meiner Verzweiflung (Es sollten eigentlich 2 Aufnahmen laufen) Das Antennenkaben vom unteren Tuner (#1?) abgezogen und hatte dann auf einmal ein Bild...


    Was kann da schief gelaufen sein? Kann sich die Karte dermaßen vertun, dass sogar ein Reboot nicht funktioniert? Ich habe mal das Log hier:


    Nach dem Reboot findet man im Log auch nichts ausser den "timed out". Hier zum zeitpunkt, wo ich das Antennenkabel abgezogen habe und am Ende die Timer aktiviere:

    MP-Logos (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)


    Mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe wird bestraft, wer eine nukleare Explosion verursacht. [StGB §328 Abs.: 2 Nr.: 3]

    ___

    Gen2VDR V7; VDR 2.4.5; Gehäuse: Antec Fusion V2 Black & iMon LCD (15c2:ffdc); Atric IR-Einschalter Rev. 4; Board: Intel DH77EB, Core i5-3550, NVidia GTX 750 Ti, 4 GB RAM; DVB: 1x Digital Devices CineS2 Quad V6.5 [VDR-User #1540]

  • Der Absturz beim Drücken der Info - Taste kommt bei mir auch manchmal vor. Da liegt bei mir aber wohl am skinenigmang - Plugin. Was für Plugins hast du so in Benutzung?


    Dass nach dem Neustart nichts ging, kann Zufall gewesen sein (dicke, böse Wolke) oder aber der abgestürzte VDR hat die Karte in einem undefinierten Zustand zurückgelassen, aus dem sie auch mit einem reboot nicht herauskam. Wenn ein reboot nicht hilft, sollte man immer einen shutdown/restart versuchen, also mit Power off. Dann muß die Hardware garantiert einen Kaltstart machen.


    Falk

  • Hi,


    ich habe auch die Liste im Wiki mal angepasst. Falls noch jemand Probleme haben sollte kann er sein Mainboard wieder eintragen -> http://www.vdr-wiki.de/wiki/in…Kompatibilit%C3%A4tsliste


  • Hi,


    hat jemand das schon umgesetzt, so das zB. bei einer Aufnahme die LED statt grün, rot leuchtet? :)
    Bzw. in welchen Teil der Software müsste man suchen, um mehr Infos zum ansteuern zu finden? (Treiber, remote Plugin oder dvbhddevice-Plugin?)


    Gruß Uwe

  • Der Absturz beim Drücken der Info - Taste kommt bei mir auch manchmal vor. Da liegt bei mir aber wohl am skinenigmang - Plugin. Was für Plugins hast du so in Benutzung?


    Ich benutze Skinelchi 0.2.3


    Abgestürzt ist der VDR nicht. Nur der Watchdog hat den VDR restartet.


    Wie kann es sein, dass der Zustand durch ziehen des Antennenkabels sofort wieder i.O. war?
    Wolke kann nicht sein, wenn nur ein Tuner betroffen ist... auf der Budget-Karte war kein Timeout

    MP-Logos (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)


    Mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe wird bestraft, wer eine nukleare Explosion verursacht. [StGB §328 Abs.: 2 Nr.: 3]

    ___

    Gen2VDR V7; VDR 2.4.5; Gehäuse: Antec Fusion V2 Black & iMon LCD (15c2:ffdc); Atric IR-Einschalter Rev. 4; Board: Intel DH77EB, Core i5-3550, NVidia GTX 750 Ti, 4 GB RAM; DVB: 1x Digital Devices CineS2 Quad V6.5 [VDR-User #1540]

  • Hi MegaV0lt,

    Wie kann es sein, dass der Zustand durch ziehen des Antennenkabels sofort wieder i.O. war?
    Wolke kann nicht sein, wenn nur ein Tuner betroffen ist... auf der Budget-Karte war kein Timeout

    Unter Umständen liegt/lag Dein Problem am Kabel.
    Ich könnte mir Folgendes vorstellen...
    Da Du mit Femon hin und her geschaltet hast, waren beide Tuner und der Demod auf den gleichen Sender eingestellt. Nachdem Du ein Kabel abgezogen hast war ein Bild da, weil das Signal vom noch verbundenen Kabel ausreichte um es auch am 2. Tuner zu empfangen(Übersprechen). In der Femon-Anzeige sieht man das recht deutlich daran, dass STR 0 ist, aber SNR einen Wert hat.


    Jarod

    Gehäuse: Intertech 4U 4416, Board: Supermicro X11SAE; Karten: 2x TT S2-1600, Cine S2 V6; OS: Ubuntu 16.04; Plugins: xineliboutput, burn, femon, live, streamdev-server, text2skin:anthra-1920

    2x RPI2/3; Plugins: rpihddevice; videodir via NFS


  • Hi,


    ich habe bei mir leider auch so eine Art Coldboot Phänomen.


    Ich habe die folgende Option bei mir aktiv: Kanal beim Einschalten - Wie vorher


    Jedesmal wenn es sich dabei um einen HD Sender gehandelt hat, bekomme ich nach dem booten kein Bild,
    VDR reagiert nur sehr träge und auch ein Kanalwechsel bring kein Bild. Nach einem VDR restart funktioniert es dann wieder.
    So war es z.B. gerade eben mit Gran Torino auf ZDF HD.


    Hier mal ein kurzer Logfile Auszug:


    Ich habe bei mir Ubuntu 11.04 - 2.6.38-8-generic x86_64 mit VDR 1.7.18 + dvbhddevice (0.0.4) aus den yaVDR Repos laufen.

    Code
    1. [ 5.525785] SAA716x FF firmware version 0.2.B
    2. [ 187.868978] SAA716x FF FPGA version 1.08
    3. [ 187.930797] SAA716x FF loader version 1.03



    Hat dieses Problem sonst noch jemand?

  • Ein Problem, dass sich bei mir noch hartnäckig zeigt:


    Wenn VDR beim Kaltstart im Transfermodus startet gibt es einen Versatz zwischen Bild und Ton von 1..2 Sekunden! Der Transfermodus kommt dann vor, wenn meine zusätzlich vorhandene Tevii S470 als Tuner 0 erkannt wird.


    Einmaliges Umschalten behebt das Problem zuverlässig.


    Ich nutze aktuelle Firmware/Treiber auf SuSE 11.x (2.6.30)


    Falk

  • Hat dieses Problem sonst noch jemand?

    Dieses Phänomen trat bisher im Zusammenhang mit dem bösen Plugin auf, benutzt Du das vielleicht?

    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

  • So wie ich das sehe, wird der Fehler in der transfer.c des vdr geworfen:


    die Spur führt dann weiter zu den Funktionen:
    PlayTsVideo
    PlayTsAudio
    aus der dvbhdffdevice.c


    Eine von denen scheint irgendwie 0 zurückzugeben... vielleicht könnte der powarman da etwas Licht ins Dunkel bringen?

    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

  • Wenn VDR beim Kaltstart im Transfermodus startet gibt es einen Versatz zwischen Bild und Ton von 1..2 Sekunden! Der Transfermodus kommt dann vor, wenn meine zusätzlich vorhandene Tevii S470 als Tuner 0 erkannt wird.


    Einmaliges Umschalten behebt das Problem zuverlässig.

    Ich habe ein ähnliches Problem. Sobald ich einen DVB-T-Stick zur 6400 dazustecke, wird für diesen der Treiber als erster geladen (/dev/dvb/adapter0) und VDR erkennt ihn wohl daher zwangsläufig als erstes device. Beim Booten hängt der VDR knapp 30s, dann Fehlermeldung "not all devices ready after 30 seconds", danach scheint i.w. alles OK, bis auf zwei Dinge.
    Erstens gibt es den beschriebenen Ton-Versatz (und ja, durch Umschalten erledigt).
    Zweitens kann er nur mit einem der 6400-devices entschlüsseln - und das obwohl ich das modifizierte dvbhddevice verwende, was ohne den Stick auch einwandfrei funktioniert. So aber erkennt er zB einen Timer-Konflikt.


    Ich dachte Transfermodus ist genau das, wohin man mit der Modifikation beide devices zwingen will (oder ist es umgekehrt?). Insofern ist es bei mir umgekehrt: mit DVB-T-Stick klappt der Transfermodus bei einem device gerade nicht, und dazu habe ich am Anfang den Ton-Versatz.


    Was könnte man tun?
    Könnte man es schaffen, dass der Treiber für die 6400 als erster geladen wird? Oder dass VDR die 6400-devices in jedem Fall als die ersten nimmt (falls das helfen würde)? Warum behauptet er es wären nicht alle devices ready? Alle Treiber sind fertig initialisiert, der Fehler (not all devices ready) kommt auch beim VDR-Restart (ohne Modul-reload).


    Auch nicht ganz optimal-intelligent vom VDR: er erkennt zwar (Timer-Konflikt), dass er mit dem zweiten device eine geplante Aufnahme nicht durchführen kann, weil das dazu fähige device zu dem Zeitpunkt bereits mit einer anderen Aufnahme belegt ist (ebenfalls noch nicht aktiv) - obwohl es diese Fähigkeit für diese erste Aufnahme nicht braucht - aber er kommt nicht auf die Idee, es mal umgekehrt mit den devices zu versuchen / zu planen.


    Aber das ist ja ein altbekannter VDR-Makel: man hat zu wenig Kontrolle über die devices, kann sie zB nicht bei den Timern selbst auswählen.
    Genauso wie beim Streaming: er soll bevorzugt ein lokales device nehmen, sowohl für live wie auch für Aufnahmen (dann erst live eben über Streaming) - so ein Verhalten scheint nicht hinzubekommen zu sein.

  • Ich habe ein ähnliches Problem. Sobald ich einen DVB-T-Stick zur 6400 dazustecke, wird für diesen der Treiber als erster geladen (/dev/dvb/adapter0) und VDR erkennt ihn wohl daher zwangsläufig als erstes device. Beim Booten hängt der VDR knapp 30s, dann Fehlermeldung "not all devices ready after 30 seconds", danach scheint i.w. alles OK, bis auf zwei Dinge.
    Erstens gibt es den beschriebenen Ton-Versatz (und ja, durch Umschalten erledigt).
    Zweitens kann er nur mit einem der 6400-devices entschlüsseln - und das obwohl ich das modifizierte dvbhddevice verwende, was ohne den Stick auch einwandfrei funktioniert. So aber erkennt er zB einen Timer-Konflikt.

    Code
    1. echo "blacklist saa716x_ff" > /etc/modprobe.d/blacklist-saa716x_ff.conf
    2. echo "blacklist ?dvbtstick?" > /etc/modprobe.d/blacklist-?dvbtstick?.conf


    und dann in der runvdr


    ?dvtstick? ist durch das entsprechende Modul zu ersetzen. Dann wird die S2-6400 auch als erstes geladen.

    Ich dachte Transfermodus ist genau das, wohin man mit der Modifikation beide devices zwingen will (oder ist es umgekehrt?). Insofern ist es bei mir umgekehrt: mit DVB-T-Stick klappt der Transfermodus bei einem device gerade nicht, und dazu habe ich am Anfang den Ton-Versatz.

    Ich kenne den Begriff "Transfermodus" auch nur im Zusammenhang mit ATM?! Vielleicht könnte das einer mal vernünftig erklären...

    Was könnte man tun?
    Könnte man es schaffen, dass der Treiber für die 6400 als erster geladen wird? Oder dass VDR die 6400-devices in jedem Fall als die ersten nimmt (falls das helfen würde)? Warum behauptet er es wären nicht alle devices ready? Alle Treiber sind fertig initialisiert, der Fehler (not all devices ready) kommt auch beim VDR-Restart (ohne Modul-reload).

    s.o.
    oder schreibe Dir udev-Regeln

    Auch nicht ganz optimal-intelligent vom VDR: er erkennt zwar (Timer-Konflikt), dass er mit dem zweiten device eine geplante Aufnahme nicht durchführen kann, weil das dazu fähige device zu dem Zeitpunkt bereits mit einer anderen Aufnahme belegt ist (ebenfalls noch nicht aktiv) - obwohl es diese Fähigkeit für diese erste Aufnahme nicht braucht - aber er kommt nicht auf die Idee, es mal umgekehrt mit den devices zu versuchen / zu planen.

    stimmt, ist irgendwie uncool

    Aber das ist ja ein altbekannter VDR-Makel: man hat zu wenig Kontrolle über die devices, kann sie zB nicht bei den Timern selbst auswählen.
    Genauso wie beim Streaming: er soll bevorzugt ein lokales device nehmen, sowohl für live wie auch für Aufnahmen (dann erst live eben über Streaming) - so ein Verhalten scheint nicht hinzubekommen zu sein.

    Du kannst bestimmt Kanäle mittels channels.conf an bestimmte devices binden, eine andere Idee habe ich sonst auch nicht.

    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