TV-Karte wird nicht mehr erkannt

Hast Du evtl. mal detect_dvb.sh ausgeführt?

Ich habe vorhin die V6 mit der 2. Flex auf 6 Tuner erweitert und da mal detect_dvb ausgeführt.

Wie man sieht, wird die Anzahl der DVB-Karten von 4 auf 6 korrigiert, es wird aber auch versucht xine zu aktivieren, da keine FF gefunden wird.
Ist vermutlich ein Überbleibsel aus der V3, was bei der Installation nicht auffällt, da die init.sh die detect_dvb.sh vor der detect_x.sh ausführt und detect_x.sh xine wieder deaktiviert und dafür softhddevice aktiviert, wenn eine VDPAU-fähige nVidia-GPU gefunden wird.
Bei mir hat dieser Versuch xine zu aktivieren vorhin jedoch nicht gewirkt.
Es ist weiterhin nur softhddvice aktiv.
Evtl. wird diese Aktivierung von xine nur unter bestimmten Rahmenbedingungen übernommen, die bei Dir vorhanden waren, als Du detect_dvb.sh mal nach einem Karten-Umbau ausgeführt hast.

Die BIOS-Version könnte schon damit zusammenhängen, wie gravierend die Probleme einer CineS2V5.5+FlexS2 ausfallen, wenn sie in einem M4N78 Pro MB betrieben wird.
Ein weiterer Unterschied ist ja auch noch, dass meine 4-Tuner-Kombi aus einer Bridge-Karte+2xFlexS2 besteht.

Das ändert aber Alles nix an der Tatsache, dass sich offensichtlich eine 4-Tuner-Kombi mit Micronas-Bridge-Chip (ngene) nicht vernünftig mit dem M4N78 verträgt.

Aber hier mal meine Bios-Version und auch die CPU- und RAM-Bestückung:
Bios: 1109
Build Date: 12.09.2009
CPU: AMD Phenom II X4 925 @ 2800MHz
RAM: 8GB
Ich verwende das MB seit Anfang 2010 nicht mehr aktiv als VDR-MB und hatte damals CPU und RAM für Windows7 Ultimate 64 aufgerüstet.
Da ich auf der Kiste neben Gen2VDR (erst seit der V4 wieder drauf) mehrere spezielle Windows Installationen betreibe, möchte ich auch nicht viel am BIOS ändern und schon gar kein Upgrade durchführen.
Das würde nur wieder Ärger mit der Windows-Aktivierung machen.

@ Helmut
Soll ich zur detect_dvb.sh, wegen der Aktivierung des xine Plugin, einen Eintrag im Bugtracker machen?

EDIT: Die CineS2 V6 (ddbridge) läuft mit dem M4N78 auch im 6-Tuner Betrieb total stabil.
Habe gerade 5 Aufnahmen (3x HD 2x SD) so programmiert, dass auf Tuner1 Live-TV + eine Aufnahme in HD laufen und weitere 4 Aufnahmen die Tuner 2 bis 5 nutzen.
Nur Tuner 6 (gebonded mit Tuner 5) ist noch frei.
Dann einen EPG-Scan gestartet, der primär den noch freien jedoch gebondeten Tuner 6 verwendet.
An Änderungsmeldungen zur channels.con sieht man auch, dass der EPG-Scan läuft.
Live-TV und alle 5 Aufnahmen laufen aber stabil weiter.

Erst mal tausend Dank für die viele Arbeit die du dir gemacht hast, echt 1a++ Support von dir!

Ja, ich habe detect_dvb.sh ausgeführt. Wie deaktiviere ich nun Xine wieder sauber, ohne mir das Sys zu zerschießen?


Die Aktivierung Windows Aktivierung soll durch ein Bios Update erneuert werden müssen? Das wäre mir neu! Ich mache häufiger Bios Updates und musste noch nie Win neu aktivieren. Aber das Brauchst du wirklich nicht für mich testen ;-) Die Bisher von dir erarbeitet Erkenntnisse sind für mich sehr Hilfreich.

Aktuell habe ich das 1303 (Neuste) drauf und alle die seit dem ich die Felx S2 besitze dürfte ich auch schon mit der Flex getestet haben. Die Flex lief von Anfang an nicht mit dem M4N78 Pro.

Ich hatte anfangs noch gehofft das durch ein Treiber-update das Problem sich lösen lässt und hatte damals den Händler kontaktiert, der das an die Entwickler weiter gegeben hatte.

Ich habe den L4M Shop bereits über alles informiert mal sehen wie der reagiert.

Xine deaktivierst Du am Besten mit /_config/bin/g2v_setup.sh auf Konsole (putty).
Überprüfe auch, ob softhddevice noch aktiviert ist, laut log war es das aber noch.
Vorher stp vdr g2vgui und nach der Änderung mit stt wieder starten.
Dann sollte softhddevice wieder als Ausgabe-Device laufen.

Also ich habe mir mit einem BIOS-Update nicht nur einmal eine Neuaktivirung von Win7 (auch XP) und installierter Win-SW eingehandelt.
Hängt halt davon ab, wie umfangreich die Änderungen am BIOS durch das Update ausfallen und ob anschließend neue Treiber installiert werden müssen.
Seitdem bin ich vorsichtig und mache ein BIOS-Update nur dann, wenn es unbedingt sein muss.

Als bei mir das Problem mit dem Micronas-Produkten und den CedarTrail MBs aufgetreten ist, hatte ich einen intensiven Kontakt zum L4M Support.
Nach Aussage L4M hält sich der Micronas-Chip genau an die PCIe Spec, hat aber ein fixes Feature-Set, dass nur in geringem Umfang per Treiber oder FW beinflussbar ist.
So hat er auch eine fixe, nicht ladbaren Anteil Basis-FW für die PCIe-Kommunikation und ein per Laufzeit ladbaren Anteil der hauptsächlich für die Anbindung der Tuner zuständig ist.
Auch wenn man den Grund finden würde, weshalb der Chip Kommunikations-Probleme mit dem MB hat, ist es in den meisten Fällen nicht möglich das Problem über den ngene-Treiber oder den ladbaren FW-Anteil (aktuell fw18) zu lösen.
Bei den Cedar-Trail MBs, wo weder Cine V5.x noch die Micronas-Bridges funktionieren, war das der Fall.

Da der neue Lattice-Chip ein FPGA ist, können seine Funktionalitäten total flexibel angepasst werden.
Hier wird die komplette FW geflasht und eine zur Laufzeit ladbaren FW-Anteil, wie beim Micronas, gibt es nicht.
Man kann das Flashen der FW aber mit dem eigenen PC über einen FirmwareUpdater machen.
Leider gibt es diese FirmwareUpdater nur nur für Windows in Verbindung mit dem Windows-Treiber.
Auch bei den Cedar-Trail MBs hatte die V6 erst mal nicht funktioniert.
Durch ein FW-Upgrade, das ich damals bei meiner älteren V6 auf einem Win-PC geflasht hatte, konnte L4M das CedarTrail Problem für die ddbridge (Lattice-Chip) beheben.
Daher hab ich auch auf allen meinen CineV6 (auch der mit dem M4N78 getesteten) und Octopus ein relativ aktuelle FW.

Ich denke L4M verhält sich auch bei Dir sehr kulant.
Bei meinem CedarTrail-Problem hat man mir auch Micronas-miniPCIe-Bridges und Cine zu kulanten Konditionen getauscht.
Das ist halt auch der Vorteil eines Produktes "Made in Germay" bzw. "Made in Blackforest" im Vergleich zu billigen China-Produkten.

Das ist aber geographisch nicht ganz richtig, das ist Oberschwaben, nicht der Schwarzwald :)

Das ist aber geographisch nicht ganz richtig, das ist Oberschwaben, nicht der Schwarzwald :)

Hallo Helmut,

hast ja recht.
Aber "Made in Blackforest" hört sich halt besser an als "Made in Upper Swabia".
Auf jeden Fall sind die L4M-Karten ein Qualitätsprodukt aus dem schönen Schwabenland. :)

Ich hoffe, es ist nicht so schlimm, aus einem Oberschwaben einen Schwazwälder zu machen, als aus einem Badenser einen Schwaben. ;)
Oder irre ich mich da?

Damit es nicht in Vergessenheit gerät.
Soll ich für das Problem mit detect_dvb.sh (xine wird aktiviert), wie 4 posts weiter oben beschrieben, ein Ticket aufmachen?

Gruß
Klaus

Aua - fuer nen Badener ist "Badenser" ein absolutes Unwort.

Ja - mach mal !

Ganz genau so ist es!

Und weil so ist und wir Württemberger die Badenser nicht beleidigen wollen, sagen wir zu den Badensern nicht Badenser, sondern Gälfiäßler. :)

Ganz genau so ist es!

Und weil so ist und wir Württemberger die Badenser nicht beleidigen wollen, sagen wir zu den Badensern nicht Badenser, sondern Gälfiäßler. :)

Das muss ich mir für meine Verwandten aus Pforzheim merken.
Das teste ich das nächste mal, wenn ich sie sehe aus.
Aber ich vermute fast, da tappe ich dann ins nächste Fettnäpfchen. ;)

Ich war schon froh, als ich mir gemerkt hatte, dass sie es nicht mögen, wenn man sie als Schwaben bezeichnet.
Und war dann total erstaunt, als Badenser fast noch schlimmer war. :huh:
Ich hab aber immer noch keine Ahnung wieso.

Oder zur Not auch "badensische Gelbfiassler" :)

Wenn Du mal in PF bist melde Dich !
Ich bin zum Glueck auf der anderen Seite der Grenze :)

Hallo,

die V6.5 ist da. Nun läuft der Scan durch. Xine habe ich abgeschaltet. Gerade eben ist leider der Absturz der etwa alle paar Wochen/Monate auftritt eingetroffen.

So ein weiterer Absturz innerhalb weniger Minuten. Dabei lief die Kiste vom Nachmittag an stabil, ich habe nur das tvm2vdr Plugin auf ein automatische Aktualisierung eingestellt (Standard: 30min).

Ich habe es nun vorerst deaktiviert.

Das Deaktivieren vom tvm2vdr Plugin hat nicht geholfen. Ich nutze nun die Cine S2 V5.5 und die TwinLux V6.5 und hoffe das es stabil(er) läuft.

Ein Freund von mir hat mit einem anderen Athlon Board mit onboard Geforce 8200 aehnliche Probleme. Die Kiste schmiert desoeftern aus heiterem Himmel ab. Mit der V3 hatte er aber schon dasselbe Problem.
Lief die V3 bei Dir reibungslos ?

Nein, das hatte ich seit der V3 beta X

Ich fasse jetzt mal Zusammen.
Sporadische Abstürze hattest Du also mit dem M4N78 Pro schon seit BetaX immer wieder.
Die Flex an der CineS2 V5.5 hatte nie richtig funktioniert, was sich ja auch bei mienen Tests mit dem M4N78 Pro bestätigt hat.
Deshalb hattest Du das System ja mit der CineS2 V5.5 + einer TwinLux (auch V5.5) betrieben.
Dieses Thema hattest Du ja gestartet, als Du die V3 noch installiert hattest, weil plötzlich die TwinLux gar nicht mehr erkannt wurde.
Nach dem Umbau mit der Flex an der CineS2 V5.5 gab es dann, wie vorher auch schon immer, das Probleme mit der Flex.
Das System hatte sich bei einem auf der Flex laufenden EPG-Scan reproduzierbar immer nach wenigen Minuten aufgehängt.
Probleme mit der CineS2 V5.5+Flex konnte ja auch ich mit meinem M4N78 Pro feststellen, die aber mit der Flex an einer V6.5 weg waren.

Und auch bei Dir scheinen ja diese durch EPG-Scan reproduzierbaren Probleme der Flex jetzt an der V6.5 nicht mehr zu existieren.
Aus meiner Sicht muss da noch ein anders Problem bei diesem MB existieren, das evtl. erst bei intensiverer Nutzung und längerer Laufzeit aus "heiterem Himmel" auftritt.

Ich hatte vergangene Nacht schon mal versucht die neuen syslogs zu analysieren, was aber wegen der 500 Timer wieder mal extrem schwierig war.
Die über 500 Timer mit teilweise bis zu 46 Timer-Konflikten machen das syslog auch total unübersichtlich.
Irgendwann sind mir die die Augen übergegengen.

Der EPG-Scan ab 12:29:15, der auf der Flex (Tuner 3 und 4) einwandfrei durchgelaufen ist, war noch relativ einfach zu finden.
Dabei wurde am Ende des Scans noch über 30min lang vergeblich versucht irgendwelche Kanäle doch noch zu tunen und zu scannen, weshalb der komplette Scan ca. 55 min gedauert hat.

Danach lief das System aber ohne Problme bis Du es um 13:50 trotz ansthender Timer und laufendem Streaming runtergefahren hast.

Um 14:00 startet das System dann wieder mit ACPI-Wakeup für eine Aufnahme und läuft über 8 Stunden ohne Probleme.
Auf der Flex wird auch problemlos aufgenommen.
Also auch keine Anzeichen, dass die Flex Probleme macht.

Aufgrund der vielen Timer-Meldungen, war der Absturz recht schwierig zu finden.
Aber um 22:05, kam er dann ohne jegliche Anzeichen, die den Absturz angekündigt hätten, aus heiterem Himmel.
Die Flex als Absturzgrund kann ich davor wirklich niergends erkennen.

Zwischen letzter "normaler" Meldung von softhddevice und dem Neustart liegen ca. 11 Minuten.
Die Meldungen des neuen Bootvorganges sind auch gegenüber den Meldungen eines "normalen" Bootvorganges verstümmelt.

Hast Du da das System gewaltsam abgewürgt, da es sich total Aufgehängt hat, oder hat das System den Reboot selbst durchgeführt?

Einen weitern Totalabstürz oder kompletten Hänger aus heiterem Himmel, der sich so äußert, konnte ich nicht finden.
Aber in diesen chaotischen durch Timer-Meldungen verseuchten logs kann man auch mal was übersehen.

Um 22:17 gab es aber z.B. noch einen segfault wegen EPGsearch, bei dem "nur" der vdr einen Neustart gemacht hat.

Mir sind jetzt noch bei der Suche nach Segfaults, Meldungen aufgefallen, die vorher in den Timer-Meldungen untergegangen waren.
Vor dem Shutdown um 13:50 gab es um 13:46 noch einen Shutdown/Reboot mit unschönen Meldungen:

Hattets Du diesen Shutdown, der evtl. wegen dem Segfault in einen Reboot gemündet ist, auch schon gezielt ausgelöst?
Es schaut auf jeden Fall so aus, als ob Du den Shutdown ausgelöst hättest.
Auf jeden Fall gab es da Probleme, die auf die nVidia-GPU hin deuten.
Es gab da einen "video: fatal i/o error_" und dann einen Kernel-Segfault, weshalb auch kein ACPI-Timer mehr gesetzt wurden.

Da kann die Flex nichts dafür.
Sie hatte den 55Minuten EPG-Scan überstanden und ist danach noch 30min problemlos gelaufen.
Und sie ist dann nach dem Timer-Wakeup mehrere Stunden gelaufen, wobei die Tunern der Flex für Aufnahmen verwendet wurden.
Aus meiner Sicht lief die Flex jetzt einwandfrei an der CineS2 V6.5.
Ich sehe in den logs keine Hinweise, dass die Flex noch Probleme gemacht hätte.

Für mich schaut es so aus, als ob das MB, oder evtl. auch der die onboard nVidia-GPU einfach nach längerer Laufzeit mal aussteigt.

Ich bezweifle daher, dass dein System mit den Beiden CineS2 (V5.5 und V6.5) ohne solcher Abstürze aus "heiterem Himmel" auf Dauer ohne Probleme laufen wird.

Jetzt muss ich aber los. Genug gelabert.

Also das Flex Problem betrachte ich auch als erledigt, da der Scan ohne Problem durchlief.

Wenn der PC abschmiert muss ich manuell Hard Reseten.
Das Absturz Problem mit der Cine S2 und TwinLux S2 war sehr selten und trat nur alle paar Tage eher Wochen auf, je näher ich an einem 24/7 Betrieb war. Bei dem Abend bis in die Nacht Betrieb trat er alle paar Monate auf.

Also vor allem wenn ich vormittags Timer hatte war ggf. abends/nachts ein Absturz, selbst den der PC für 1-3h dazwischen aus war.

Die Wahrscheinlichkeit wenn dich den PC manuell Eingeschaltet habe, scheint die Wahrscheinlichkeit eines Absturzes zu erhöhen. Zu mindestens ist mir aufgefallen das wenn der PC abgestürzt war ich fast immer den PC eingeschaltet hatte!?

Das Merkwürdige ist aber das die mit der KNCone S/S2 diese Abstürze nicht habe, zumindestens bisher konnte ich keine Feststellen.

Ich hatte erst ein Temperatur Problem mit dem Chipsatz in verdacht, aber in der V3 konnte ich mir die Temp anzeigen lassen diese war zwar ziemlich Warm aber nicht zu heiß.

Bisher war es auch immer so das wenn ich nach so einem Absturz Rebootet hatte, lief der PC wieder für einen längeren Zeitraum stabil. Gestern aber ist er alle paar Minuten/Stunden abgestürzt. Kurz vor dem Absturz den ich gestern live beobachtet hatte Zitterte das Bild.

In der V4 kannst Du Dir auch über Befehle-System die GPU-Temeperatur anzeigen lassen.
Da der onboard 8300er GPU ja in den Chipsatz integriert ist, ist das dann auch die Chipsatz-Temperatur
Was bedeutet denn hei Dir warm und nicht zu heiß?

Schau Dir jetzt bei der V4 auch mal die GPU-Temperatur an (nach dem Einschalten und nach längerer Laufzeit).

Fakt ist auf jeden Fall, dass hier in letzter Zeit schon häufiger von anderen Usern, die ihre Systeme ähnlich intensiv nutzen, über seltsame Probleme mit dieser MB-Generation berichtet wurde.
Da war z.B. auch das Asus M3N78-EM dabei, das den identischen Chipsatz "nVidia GeForce 8300" verbaut hat, wie das M4N78 Pro.
Hier mal die Specs der beiden MBs:
http://www.asus.com/Motherboards/M3N78EM/#specifications
http://www.asus.com/Motherboards/M4N78_PRO/#specifications

Ich hab hier einen interresanten Artikel über diesen Chipsatz gefunden, der eigentlich aufzeigt, wieso er so problematisch ist:
http://techreport.com/review/14993/nvidia-...ce-8300-chipset
Im Gegensatz zu anderen Chipsets ist dieser nicht in eine North- und Southbridge aufgeteilt, sondern komplett incl. der GPU auf einem Chip integriert.
Beim M4N78 Pro findest Du ihn zwischen CPU und ersten PCIex1-Slot mit dem größeren blauen Kühlkörper der keine aktive Kühlung hat.
D.h. wenn die GPU durch das HW-Decoding per VDPAU warm wird, wird der Chipsatz, der sich um den PCIe/PCI-Bus kümmern muss, genauso warm oder heiß.
Ich sehe auch diese Aussage im Artikel problematisch:

Eine CineS2 muss sich also ihre x1 Lane ziemlich sicher mit anderer Peripherie teilen.
Wenn dann bei sehr viel Verkehr auf so einer shared Lane der Chipsatz, der den PCIe-Bus steuert, zu heiß wird, kann es schon zu seltsamen Effekten kommen.
Von den Auswirkungen eben auch abhängig davon, wie viel Verkehr auf dem Bus abläuft und wie heiß der Chipsatz gerade ist.

Ich habe momentan noch die V6+1xFlex in meinem M4N78 verbaut.
Da schaue ich mir heute Abend mal die GPU-Temperatur an.
Mein M4N78 ist in einem Thermaltake BigTower verbaut, der von 3 Gehäuselüftern gut belüftet wird.
Einer dieser Lüfter bläst auch den Chipsatz-Kühlekörper an.
Bin mal gespannt, wie heiß MB-Chipsatz und GPU werden.

Er meldet eine Kern Temp von 52°C bei offenem Gehäuse, das betrachte ich eigendlich als unkritisch.
CPUs werden mit 65°C bzw. GPUs mit bis zu 95/100°C spezifiziert.

Ich habe den Deinterlancer auf half_tem herunter gestellt, um die Last des Grafikprozessors zu reduzieren und damit die Leistungsaufnahme/Verlustleistung. Leider hatte das auch nicht geholfen.

Ein Wechsel von VDPAU auf x11 als Test steht noch an.
Auch könnte ich noch den PCIe 16x Steckplatz testen.


Als erstes hatte ich ein ASRock mit 780G Chipsatz, da es keine Videobeschleunigung unterstützte wechselte ich zum ECS GF8200.
ECS GF8200 das hatte definitiv ein Temp Problem, des wegen bin ich zum Asus M4N78 Pro gewechselt. Also ich habe schon eine kleine Odysse hinter mir. Mit dem Asus M4N78 Pro war ich bis vor ein paar Tagen zufrieden. Auf die Behebung der unschönen Aussetzer hatte ich anfangs auf VDPAU Instabilitäten später DVB-Treiber Probleme vermutet und in die Kategorie wahrscheinlich durch Updates behebbar eingeordnet, mit der Zeit habe ich mit der Macke arrangiert.


Die Abstürze treten nur leider häufiger auf und ein Reboot behebt das Problem nun nur noch kurzfristig.

Den Versuch mit X11 kannste Dir schenken, denn das Bild willst Du nicht wirklich sehen ;)
Aber ich wuerde es mal mit einem zusaetzlichen Kuehler direkt auf die GPU versuchen.