Beiträge von Andy.2k

Hi Oliver,

hab hab gestern morgen auch meine Treiber aktualisiert, und lasse seit dem meine Budget und auch die 2. FF aktiv EPG scannen (da im Moment nix an Timern anliegt).

Als kurzen Zwischenbericht kann ich sagen das nach 36h sowohl die Budget als auch die FF (bezogen auf die Treiber/Firmware Änderung von neulich) ohne Probs EPG scannen und noch immer fleissig IRQ´s produzieren, also *laufen*

Ich werde das ganze mal bis zum WE beobachten, wenn die Budget dann immer noch läuft würde ich sagen das einer der gröbsten Bugs gefixt wäre:)

Gruss

Andy

Hi,

mal wieder etwas OnTopic;)

kls & Ufo

Imho machen die ganzen Patches gegen die Video Datastream Errors im Grunde alle das gleiche: Ne Zeitlang loopen bis die Karte nen guten Lock hat. Der Author des dvbdevice patches hats über die Events gemacht, ich hab mit FE_READ_STATUS rumgespielt und dabei im Treiber sichergestellt das das während des tunens überhaupt kein HAS_LOCK auftreten kann.

Geholfen hats mit nur insofern das ich nun weiß, das die SS2 recht sensibel auf Section Filter reagiert. Und ich bin auch der Meinung, das es keinen richtigen Workaround geben kann, der jedem hilft.

Ich hab hier beim testen mit allen meiner Karten das gleiche Problem: Früher oder später liefern sie keine Daten mehr (kein IRQ-Handling), hauptsächlich während des EPG-Scans. Die Tuxbox Jungs die ja den Treiber mit uns sharen haben das gleiche Problem: Denen stürzen die Framer ab. Aber im Gegensatz zu uns können sie die Framer im Avia-Chip resetten....

Ich denke mal das das größte Problem durch das massive Threating und die unterschiedlichen Laufzeiten der Treiberteile verursacht wird...Beispiel: Wenn man tuned und dann Filter setzt, sollte dies auch in dieser Reihenfolge passieren....nun ists aber so, das das tuning länger dauert als das setzen der Filter...und der Demux-Threat die Filter schon gesetzt hat, bevor wir überhaupt nen Lock haben....

Daher helfen einige patches die auf nen lock warten bevor es weitergeht in vdr ja....

Im 0.9.4 war das, wenn ich es richtig interpretiere, anders: Dort wurde ein I/O-Befehl abgeschlossen, bevor der nächste bearbeitet wurde (Ich hoffe ich irre mich jetzt nicht).

Ich denke das einzige was wirklich helfen könnte wäre eine "dvb_io" Treiberkomponente, die sequentiell alle I/O Befehle abarbeitet und auf die einzelnen Treiberteile verteilt, und auch erst nach beendigung eines I/O´s den nächsten bearbeitet....aber leider erfordert das wohl Grundlegende Änderungen am Treiber:(

Andy

Hi,

ich wills nochmal sagen....ich hab den einfachen Umbau bei meinen beiden 1.3er im aktiven VDR gemacht, vor ca. einem Jahr.

Und ich hatte NULL Probleme, auch wenn der Widerstand sehr heiß wurde. In der zwischenzeit hab ich den Widerstand zwar gewechselt, aber nicht weil der orginal defekt war, sondern weil mir die Spannung hinter dem Widerstand zu tief abfiel. Und der 1/2W der nu drinn ist tuts jetzt auch schon seit Monaten....

Ausserdem sollte man bedenken das TT eben auch nur die Spule entfernt hat und all 5V Spannungen des Tuners nun über den 5V Regler macht. Naja gut, teilweise haben die Karten wohl auch nen 2W Widerstand nu....

Andy

Hi,

wobei der Tuner bzw. der Frontend sicher nicht crashed, sondern die FF Karte, vermutlich mit fw_command errors...

Andy

Hi,

getan hat sich leider nix, ausser das ich jetzt weiß das die Ursache für die fw_command Errors die gleiche ist wie für den Video Datastream Error - Nach einer gewissen Zeit verarbeitet die Karte einfach keine Daten mehr, und daraufhin crashed die Firmware.

Und irgendwie sind die TT Karten (incl. Budget) in meinen Setup´s recht resistent gegen das was ich alles ausprobiere derzeit:(

Also, weiter warten, hoffen und beten....

Andy

Hi,

nö...Spule ersatzlos entfernen und und 13 mit 4 oder 6 verbinden.

Was den Spannungsregler betrifft: Da diese Mod bei allen Karten > 1.3 schon von Hause aus vorhanden ist, sollte es für den normalen Regler auf der Karte kein Problem sein.

Und meine 1.3er laufen nun seit April 2003 mit diesem Mod ohne weitere Probs, trotz des extrem heißen Sommers letztes Jahr...

Andy

Hi,

bei der SS2 und auch nur wenn das dvb_delay im dvb_frontend.c "passt hilfts, bei den anderen Karten hilfts leider doch nicht.

Insofern lohnt es die Arbeit nicht....

Da ist schwerpunktmäßig weitersuchen angesagt....:(

Andy

Hi,

da wird kein frontend für die Rev. 1.3 geladen....

ERROR: Module alps_bsrv2 does not exist in /proc/modules

Kann nämlich auch nicht, da der passende Treiber nu ves1x93 heißt.

Ändere das in deinem Startscript, dann gehts wieder...

Andy

Hi,

das dürfte vielmehr an nem Treiber-Bug liegen....ARD kein Bild, RTL kein Ton.

Da kannste erstma nix machen ausser den Treiber restarten.

Andy

Hi,

die Änderungen passen auch zum aktuellen CVS. Diff´s mach ich keine, weil ich noch am rumtesten bin, und es einfach zu viele differenzen gerade im Treiber gibt.

Aber vieleicht nochwas: Das hat mir bei meiner SS2 geholfen, aber ich weiß nicht ob es generell hilft. Ich würde mich natürlich über jeden Gegentest freuen, aber würde dennoch nur Leuten die wissen was sie machen raten das zu testen.

Andy

Hi,

mal den Threat wieder ausgraben;)

kls

Beim basteln am Treiber hab ich gesehen das der section handler derzeit beim starten des Tuner Threats gestartet wird. Da ich immer noch glaube das die Karten das teilweise nicht mögen wenn Filter gesetzt werden obwohl die Karte nicht oder nicht richtig getuned ist, wäre es da nicht besser den section handler beim 1. tunen zu starten?`

zB in cDevice::SetChannel

[...]
// Stop section handling:
if (sectionHandler) {
sectionHandler->SetStatus(false);
sectionHandler->SetChannel(NULL);
}
if (SetChannelDevice(Channel, LiveView)) {
// Start section handling:

+ if (!(sectionHandler)
+ StartSectionHandler();

if (sectionHandler) {
sectionHandler->SetChannel(Channel);
sectionHandler->SetStatus(true);
}
}

Wenn jetzt noch SetChannelDevice() Liveview=false setzt falls kein Look vorhanden ist und in dem Fall auch per "return false" zurückkommt, also dann gar keine Filter geöffnet werden, könnte das vieleicht verhindern das die Karten die ohne Signal laufen (da nur wegen MPeg Decoder benutzt) abstürzen.

Das mit dem section handler hab ich mal getestet, Einschränkungen sah ich keine. Und den Rest (signalless) müßte man mal testen...

Andy

Hi,

zumindest mit meinen SS2 läuft das so wie angegeben....ich hab aber Hoffung das auch die Nova auf diese Art länger als 12h läuft.

Die Nova teste ich die nächsten Tage, und auf dem 2. PC schau ich mir (nochmal) die FF Karten an...meine 1.3 schmiert mir nämlich immer noch ab.

Zu erwähnen wäre noch, das man die full diseqc sequenz benutzen muss falls man diseq hat, sonst greift das delay nicht.

Ach ja...man müßte den 1.1.1er Treiber benutzen;)

Für ne SS2 sollte es aber zumindest so gehen...meine liefen so ca. 24h

Andy

Hmm,

wenn man mal die Section Filter aussen vor läßt und sich nur die PES_Filter ansieht, die teilweise gesetzt werden *bevor* der Frontend seinen FE_SET_FRONTEND bekommt, obwohl vdr im gleichen Threat die Filter definitiv erst nach der Frontend I/O setzt, isses ein Treiber Problem.

Das Threating in vdr machts allerdings nicht gerade leichter das irgendwie als workaround zu syncen....und um da (Treiber und vdr) größere Teile umzuschreiben, dazu bin ich nicht in der Lage:(

Nachtrag: Sollte ich recht haben, dann sollte der Treiber normalerweise keine Filter setzen solange kein Lock da ist, bzw. die Filter löschen wenn der Lock verloren geht, um abstürze bei schlechtem Wetter zu vermeiden. Im core Treiber (dvb_frontend.c)ist eine solche Callback Funktion wohl sogar vorhanden, aber irgendwie scheint da gar nix im Demux anzukommen bzw. es existiert nix was die Callback Daten weiter benutzt.

Andy

Hi,

ich glaub eher das das Zufall war mit dem UPT und mit am Wetter lag...ich hatte übers WE mit meiner SS2 auch nur verhältnismäßig kurze Laufzeiten von 30-90min statt wie sonst 2-3h.

BTW: Ich kloppe mich immer noch damit rum die Ursache zu finden und habe inzwischen auf eine gezielte Vermutung was da passiert.

Normalerweise sollte ein Kanalwechsel folgendermaßen vonstatten gehen: alle Filter schließen, neu tunen (Diseqc, Tone, Voltage, Frontend), Filter neu setzen.

vdr geht in etwa auch diesen Weg...übergabe eines Parameters an den Section Threat um die Section Filter zu schließen, schließen eventueller PES-Filter (Live Pids!, nicht während EPG Scan), tunen wie oben, eventuell PES-Filter öffnen, übergabe eines Parameters an den Section Threat um die Section Filter zu starten, wobei hier sogar noch ein usleep greift falls man noch keinen Lock hat.

Verteilt man nun einige printk´s im Treiber an entscheidenden Stellen, sieht das leider meist ganz anders aus:(

Nahezu immer werden Diseqc, Tone, Voltage zuerst ausgeführt, danach meist der Frontend getuned, danach die Filter geschlossen und gleich wieder geöffnet...hin und wieder werden die Filter auch mal früher geschlossen..und gleich wieder geöffnet, obwohl das tuning immer noch nicht fertig ist...alles in allem sieht das also recht wild aus...

Im Prinzip unterbricht man einen Datenstrom, und setzt ihn mit einem anderen, nicht mehr passenden fort...das scheinen die Core Chips auf den Karten nicht zu mögen...

Läßt man die Karten auf einem Kanal stehen, dann arbeiten die Duracell-like (läuft unf läuft und läuft....), ebenso wenn man den EPG-Scan ohne Section Filter laufen läßt (wobei allerdings dann auch 0 Daten verarbeitet werden;)).

Ich habe mal versucht das mit ein paar usleeps zu syncen, im besten Falle lief das dann auch 2h mal so wie erwartet, um dann doch "auseinander zulaufen". Im schlimmsten Fall hatten die usleeps auswirkungen an einer gänzlich unerwarteten Stelle...

Zumindest meiner Meinung nach müßte das die Ursache sein, denn der Frontend Demod wird vom Treiber nicht angehalten (und wurde ja auch für solche Bedingungen gebaut), und der dvb-core hat keinen Einfluss darauf ob die Chips auf der Karte Daten verarbeiten oder nicht. Und im Karten Treiber selbst wird im einfachsten Fall (TT Budget`s) gerade mal die Verarbeitung des Streams gestartet und gestoppt.

Ich versuche zumindest weiterhin einen Workaround zu finden, mit dem man den Dev´s zeigen kann wo das Problem liegt...

Andy

Hi,

ich möchte auch noch nen Grund für Löschung (insbesondere des Users!!!) beitragen....

Wer sich für sowas extra in einem Board anmeldet, hat an der Materie eh kein Interesse, sondern nur seine eigenen!

Ich haße Forums-Spam sowieso...

Andy

Hi,

EPG Fehelerbereinigung hat nix mit der EPG-Zeit zu tun, sondern ist 3 Stufig dazu gedacht, von den Sendern falsch ausgestrahlte EPG-Daten zu korrigieren.

Wenn die EPG-Daten zeitlich nicht stimmen ist es 100% immer ein Problem der Hardware-CLock/Systemclock.

Andy

Hi,

wenn der CT vdr nen 2.6er Kernel benutzt, müssen die nvnet Sourcen gepatched werden, da sich diese sonst nicht kompilieren lassen. Der Patch geistert irgendwo im Net rum....

Alternative ab 2.6.4: Das forcedeth modul, das ist ein durch reversed enginering geproggter Treiber für die nforce Nic.

Andy

Dentec

Wenn er nur vertikal empfangen könnte, müßte Pro7 zB laufen....

hanswurst

Ich behaupte jetzt einfach mal das das LNB *kein* Universal LNB ist....

Alternativ könnte die DVBs defekt sein und nicht mehr ins Highband schalten, aber normalerweise (wenn ich nicht irre) werden die Sender die du bekokmmst auch nicht mehr im Lowband empfangen.

Andy

Hi,

haste dir Firm von dvb-ttpci-01.fw-261c -> dvb-ttpci-01.fw umbenannt und auch nach /usr/lib/hotplug/firmware kopiert?

Andy

Hi,

also erstmal, mit Suse 9.1 und nem Vanilla 2.6.7 gibts an sich keine Probleme!

Zitat

Original von no_expert
[...]
- im DVB-Verzeichnis ./makelinks und ./MAKEDEV-DVB.sh ausgeführt
- die config vom alten Kernel hergenommen und make menuconfig ausgeführt, ob die Einstellungen passen. Die DVB-Treiber werden hier mit der Firmware erstellt
- Kernel komplett mit Modulen erstellen, neustarten
- im Verzeichnis DVB/build-2.6 ./getlinks und make gestartet, dabei kam dann die Fehlermeldung oben zu stande.

Ich denke hier solltest du "entweder oder" machen. Also entweder die CVS-Sourcen mit Makelinks in die Kernel Sourcen verlinken, ODER die Treiber separat maken.

Das insmod.sh kannst du auch für innerhalb des Kernels gemachte Module benutzen wenn du es etwas anpasst.

Beispiel:

aus -> insmod ./ves1x93.ko
wird -> modprobe ves1x93

Alternativ kannst du das Suse dvb Initscript benutzen, hier müssen gegebenenfalls noch ein paar Module nachgetragen werden.

Ach so, ich habe bei mir dafür den aktuellen CVS Treiber benutzt.

Andy