Bin total happy, dass die Lösung nun stabil ist :)!
highrgb: Hat soweit alles geklappt oder hast Du ggf. noch Probleme beim vdr kompilieren?
Ich musste unter Ubuntu 9.1 64 bit das Makefile von reelplugin noch anpassen um dem compile -fPIC mitgeben damit es gelinkt wird und einige devel Pakete waren natürlich auch noch zu installieren. Wenns da noch Probleme gibt kann ich gerne mein codelisting noch mal aufräumen und posten
Hey danke für's Feedback. Das hat mich noch mal bestätigt, dass vom Setup her eigentlich alles OK sein müsste (habe ja den gleichen Patch und ein vdr 1.7.15).
Ich glaube ich hab's gefunden: Thermales Problem! Die Karte hängt sich nach kurzer Zeit komplett auf (auch telnet will nicht mehr) und ein reboot muss her. Dann funktioniert sie wieder ein paar Minuten und das gleiche Spiel. Mit aktiver Kühlung sieht das anscheinend schon besser aus. Die Karte wird ohne auch echt recht heiss! Ich muss da dringend einen Slotlüfter etc. danebenbauen.
Ich wundere mich nur, weil ich bisher zum Thema Kühlung und eHD nicht viel gelesen hatte und nicht mit der Abwärme gerechnet hätte. Aber so warm wie das Teil am passivkühlkörper wird ist es nicht wirklich ein Wunder, dass sie aussteigt. Ihr scheint alle ür gute Kühlung in ihren Büchsen zu sorgen, dass die Probleme bei Euch nicht auftreten?
Zumindest von IG88 habe ich jetzt gerade den Thread gefunden, dass eine Kühlung notwendig ist... ( http://www.vdrportal.de/board/thread.php?postid=821529 )
ZitatOriginally posted by IG88
hi,
das der neue hdplayer instabil ist kann ich bei mir nicht beobachten, allerdings verwende ich den alten ehd patch (der vdr umpatched)
Ja, meine Aussage bzgl. der Stabilität kann man wohl knicken - es ist bei mir aktuell generell nicht stabil, egal welche Version der linux.bin noch des hdplayer. Es muss also was anderes sein. Mainboard habe ich schon getauscht.
Welche Version von vdr mit welchem patch genau verwendest Du? Wenn Du vdr einmal stoppst und wieder anstartest - fuktioniert dann noch was oder musst Du zwangsläufig neu booten?
OK also die starke Instabilität hing hier mit der neuen Version von hdplayer zusammen, die seit 2010-09-16 in testing eingecheckt worden ist (r15104). Mit der Version geht hier nicht viel....
r14812 von hdplayer zusammen mit dem aktuellen linux.bin vom 2010-03-15 (r14546) ist mal halbwegs stabil...
ZitatOriginally posted by highrgb
insmod meldet das:Codeinsmod: error inserting 'x86/driver/hdshm.ko': -1 Operation not permitted
Ich hatte mich an http://www.vdr-wiki.de/wiki/in…p/Ubuntu_8.04_LTS_mit_eHD orientiert
Was macht ein:
mkdir /lib/modules/$(uname -r)/misc
cp hdshm_host.ko hdshm.ko /lib/modules/$(uname -r)/misc
depmod -a
modprobe hdshm
Wahrscheinlich wird das hdshm_host.ko dann mitgeladen.
Das aktuelle testing ist aber dermaßen instabil bei mir unter Ubuntu 9.10. Spätestens nach drei mal Senderumschalten kneift die eHD den Hintern zusammen und stürzt ab. Keyboard Setup also remote.conf erstellen lassen geht auch gar nicht, da schmiert es direkt nach dem Startbildschirm ab.
Ich tippe schon auf eine unverträglichkeit mit meinem Mainboard (DDR3 AMD basiert also recht neu). Eine easyVDR 0.7.x war schon mal halbwegs stabil (umschalten und live-TV gar kein Problem, crashes erst beim Spulen in Aufnahmen).
Edit: Vielleicht sollte ich mal ein paar Hintergrundinfos nennen: KDG DVB-C von Budget Karte, vdr 1.7.15 mit reelbox plugin und reelbox-svn14835-v4-vdr.diff patch aus dem "Reel eHD mit Vanilla-VDR zum Laufen bringen " Thread gegen aktuelles svn (applied ohne Probs).
An der PCI Latency habe ich auch schon mal geschraubt (erhöht) schien aber keinen Effekt zu haben. Ich probiere mal ein anderes Mainboard. In der Zwischenzeit interessiert mich natürlich die Stabilität des OSDs und Live-TV (SD / HD) bei Euren Installationen.
Ergebnis hier: Mit 2.6.31-22-generic von Ubuntu 9.10 (karmic) *64 bit* geht es einwandfrei....
Jetzt ist immer noch nicht geklärt ob's an 2.6.32 oder an i386 liegt, aber ich denke nehme mal an es ist 2.6.32... ich mach erstmal mit karmic weiter, vielleicht lässt sich hdshm3 für 2.6.32 ja fixen...
Ich habe genau das gleiche Problem mit 10.04 i386.
Es liegt entweder an i386 oder am 2.6.32er Kernel.
Mit 8.04 LTS (2.6.24er Kernel) geht das gleiche check out von heute ohne Probleme nur da baut ein 1.7.15er vdr ja nicht richtig, wegen zu alter API. Ich probiere aktuell mal ob 2.6.31 vielleicht geht.
Hat jemand die eHD mit 2.6.32 am laufen - wenn ja 64 oder 32 bit?
Ich habe mittlerweile einen 3 W (2 x 20 db) Vorverstärker dran. Damit bekommt die KNC1 v1 wunderbar einen Lock auf allen Frequenzen bei 2 stelliger BER (FuSI BER bei ~500). D.h. jeder, der mit seiner KNC1 / Cinergy Empfangsprobleme hat und mit einer FuSI überhalb der 500er BER liegt, kann mit das Problem mit einem Verstärker beheben! Jippeee!
Nochmal kurz Spam von mir zur Bestätigung :):
Ich habe mittlerweile einen 3 W (2 x 20 db) Vorverstärker dran. Damit bekommt die KNC1 v1 wunderbar einen Lock auf allen Frequenzen bei 2 stelliger BER (FuSI BER bei ~500). D.h. jeder, der mit seiner KNC1 / Cinergy Empfangsprobleme hat und mit einer FuSI überhalb der 500er BER liegt, kann mit das Problem mit einem Verstärker beheben! Jippeee!
laga: PN gesehen?
ZitatOriginally posted by Pengo
ETM: nein die Karte habe ich unter Windows noch nicht getestet
hast du es bei dir (wie hannsens schreibt) schon mal mit einem Verstärker probiert?
Wäre mal spannend, ob die Cinergy unter Windows besser tuned, dann wäre noch potential im Linux-Treiber. Bei der KNC 1 v.1.0 (anno 2003) soll das laut anderem Thread leider nicht der Fall sein.
Ich habe einen Verstärker bei kab24 bestellt (2 ausgänge / 20db) ... bin mal gespannt..aber wenn ich das hier so lese, müsste es das ja bringen.
ZitatOriginally posted by ULF
zu den KNC :
Sie rennen (!) bei mir nur mit einem Zweigeräte HF Verstärker davor, dann tun sie aber.
Ich habe auch den Eindruck dort ist der Loop ehr schlechter, als bei der FF.
Genau und das wundert mich. Der Tuner an sich ist top, wenn er mal einen Lock bekommen hat (BER im zweistelligen Bereich).
Woran es hapert ist, überhaupt erstmal auf der Frequenz einen Kanal zu bekommen. Gerade im Mid-Band, bei der die FuSI bei mir locker ein SNR von 90% hat, komme ich mit der KNC auf manchen Frequenzen gerade mal auf 67% - das ist der gleiche Wert, als wenn gar kein Kabel eingesteckt wäre!
Was ich so in anderen Posts gelesen habe scheint das bei den Cinergy's aber auch nicht wesentlich besser zu sein, da arbeiten auch zig Leute mit einem weiteren Signalverstärker, obwohl ihre FuSI einen Lock bekommt (aber eben nicht QAM256 fähig ist).
Ich habe jetzt auch erstmal einen Verstärker bestellt und dann schau ich mal weiter, obs was bringt...
Eigentlich müsste das Ziel sein, den Tuner so zu optimieren, dass er - genau wie die FuSI auch ohne weiteres Verstärken des SNR den Kanal findet....
Dir geht es besser als mir - ich habe auf 90% der Kanäle gar kein Tuning (verschiedene Dosen probiert + ordentliche Kabel mit Ferritkernen etc.).
Hast Du die Karte mal unter Windows ausprobiert - macht das ggf. einen Unterschied auf dem Budget? Wenn ja, läßt sich unter Linux ggf. noch was verbessern ansonsten musss eine bessere Verkabelung her oder sogar ein Zwischenverstärker.
ZitatOriginally posted by e9hack
So wie es aussieht, wird der Gain vom Nyquist-Filer so lange verändert, bis die Symbol-Clock-Frquenzabweichung minimal wird. Da es diese Sachen auch beim VES1820 gibt, ist das möglicherweise auch für Besitzer der älteren TT-FF Karten interessant.
Das ist nach dem Lock auf den Transponder nehm ich mal an und bringt nichts um das SNR zu erhöhen... aber sauber funktionierendes QAM256 auf ner FuSI ist wohl auch ein Traum vieler. Gibt's einen einfachen Ansatzpunkt, dass in die budget_av - ich nehme mal an in die philips_cu1216_tuner_set_params() einzubauen?
Verständnisfrage für den Laien: Lieg ich falsch oder wird philips_cu1216_tuner_set_params() nur einmal beim Laden des Moduls gemacht? Wenn dem so ist, kann dann entschieden werden z.B. welcher Gain oder Band-Switch bei welcher Frequenz angwendet werden soll?
Wieso wird bei philips_cu1216_tuner_set_params gerade in Register 0x60 geschrieben? Laut Datenblatt müsste man ja von 0x40 hoch bis 0x70 oder so Werte zur korrekten Konfiguration des Tuners/Mixers/sonstwas schreiben können? Die Inittab wiederum hat nur an die 40 Werte? Was passiert mit den anderen. Fragen über Fragen 
Hier ist ggf. ein interessanter Code-Steinbruch vom Twinhan Mantis DVB-C mit CU1216:
http://www.mail-archive.com/li…linuxtv.org/msg19954.html
Der Code scheint sich ausführlicher mit Spectral Inversion, Gain und Auto Gain Control usw zu beschäftigen. Könnte da was sinnvolles für budget-av dabei sein?
Wahnsinn, dass sich da überhaupt jemand mit brauchbaren Infos zurückgemeldet hat, aber was von KNC1-Jungs mal interessant wäre, wenn Du im Kontakt stehst: Inwiefern unterscheidet sich der Prototyp aus 2003 denn vom "Serienprodukt" 2004?
Ich hab ja eine solche Karte komplett aufgemacht - bislang konnten wir nicht wirklich abweichungen von den verwendeten Chips her feststellen, jedenfalls keine Überraschungen. Evntl. sind die Chips nur etwas anders miteinander verdrahtet, aber theoretisch müssten sie genau so funktionieren können wie die neueren.... diese bestätigung wäre interessant
ZitatAlles anzeigenOriginally posted by laga
Der Mann könnte was wissen! Janne hat mich darauf aufmerksam gemacht, dass die Metzler Brothers einen eigenen Tarball mit DVB-Treibern auf ihrer Website haben. Ich habe versucht, den auf 2.6.17 ans Laufen zu bringen, aber das war mir nicht vergönnt. Ob's was gebracht hätte ist auch fraglich, aber mir gingen gerade die Strohhälme aus
Auf obiges Posting bin ich übrigens gestoßen, als ich nach dem Namen des Ansprechpartners für Software-Entwicklung bei "IT Solutions" gegoogelt habe. Ein Zeichen?!
Ich hoffe jetzt erstmal, von IT Solutions einen Linux-Treiber bekommen zu können. Ich halte euch auf dem laufenden.
Ja gut ehh.... würde der Kaiser jetzt sagen:
Wenn man da jetzt 1+1 zusammenzählt:
http://www.linuxtv.org/mailing…004/09-2004/msg00716.html
Zitat
The driver was a commercial project and when the customer never got
around to paying it we shelved it. There was no card on the market yet
using it anyway.
Since the code is out now not much can be done to undo it.
Wer könnte da wohl der Kunde von den Metzler Bro's gewesen sein... wundert mich jetzt auch nicht wirklich, wieso er absolut keine Lust hatte die Karte im linuxtv tree zum Laufen zu bekommen!
Der Treiber *ist* raus und als tda10021 im Kernel implementiert. Die angesprochenen beiden Probleme sind mittlerweile gelöst (I2C Adresse und "screwed signal timing") - ich befürchte aber fast, das CAM haben auch die Metzlers nicht zum laufen gebracht (bzw. bringen müssen).
Sehr interessante Info aber, dass die "Prototypen" v1 eben doch anders funktionieren, als die neuren Karten und dass die Hacks für CAM auf den neueren Karten ggf. doch nötig sind (jedenfalls sieht man das im Archiv von linux-dvb um 2005 als Andrew CAM für die Cinergy Leute gefixt hat).
Das Problem: Es werden über ebay beträchtliche Mengen von den Prototypen an den Mann gebracht. Ich werde in den wikis mal aktualisieren, dass man sich mit CAM bei den Dingern erstmal keine Hoffnungen machen sollte....
Interessante Abendlektüre - außer vielleicht für e9hack, der kennt's bestimmt auswendig :):
Hier geht's zwar um DVB-T, aber der PLL scheint der gleiche zu sein
http://www2.elektroniknet.de/t…hemen/2003/0003/index.htm
Noch habe ich nicht genau gefunden, wo im budget-av Treiber eigentlich für den Cable-Tuner eine Änderung des Frequenzbereiches, respektive Änderung der Stromstärken stattfindet oder ist das bei DVB-C irrelevant? Für die DVB-T budget ist es ja recht gut erkennbar.
LordZodiac: Danke für die sehr interessanten Informationen!! Ich trau mich mal zu fragen: Sah das unter Windows anders aus, hattest Du das zufällig getestet? Laut ULF machte das bei Ihm keinen Unterschied.
Wenn Du das bestätigen kannst würde es ja heißen, dass die Linux-Treiber per default dann jetzt schon so gut wie unter Windows sind - fragt sich obs Sinn macht zu versuchen, sie noch besser als die Win-Treiber zu machen :)...
ZitatOriginally posted by e9hack
Interessant ist noch, daß damals andere Band-Switch-Bytes benutzt wurden.
Aha, vielleicht sollte ich einfach mal einen 2.6.10er Kernel an den Start bekommen und einfach nur die I2C Adresse für die KNC1 anpassen, vielleicht tunt sie dann ja bereits ordentlich aufs Midband :).
Im Grunde läuft ja fast alles, nur ich denke wir holen noch nicht das optimale aus dem Tuner raus - frage mich nur, ob das bei der Cinergy anno 2004 wesentlich anders ist, aber scheint so, da auch bei der Inversion etc. Unterschiede vorhanden sind.
Ich kann mir noch nicht erklären, wieso der Tuner der FuSI ohne Probleme in der Lage ist ein Lock und sehr stabiles Bild zu bekommen und bei der KNC v1 die SNR für einen Lock so gut sein muss, als würde man neben der Kabel-Kopfstelle wohnen
wirbel. Nitek und Ulf: Was für BERs habt ihr lauf femon bei der FuSI überlicherweise auf euren Kanälen?
ARD (bzw. das ganze Low-Band) liegt bei mir bei der FuSI auf ~200 und die KNC1 kann tunen. ZDF + ein paar andere im Midband sind bei ~800-1000 und das ist bereits zu wenig für die KNC1 um ein Lock zu bekommen, kann doch nicht sein. Gut, ggf. gibt's keinen ausschlaggebenden Zusammenhang zwischen BER und SNR für das Lock-Problem, aber irgendwas ist da noch faul.
