UPT und kein Ende...

hallo,

also bei mir half nur:
2te FF karte rausbauen. die hat nun meine tochter in ihrem windows PC

das mit dem EPG scan auf der zweiten karte hab ich auch schon vermutet.
was half, war mit tuxzap z.B. auf ARD beim VDR start zu schalten,
aber nach einigen stunden, kamen die UPT doch wieder.

kann mir gar nicht vorstellen, dass es mit 2 FF karten bei anderen VDRlern funktioniert.

Zitat

kann mir gar nicht vorstellen, dass es mit 2 FF karten bei anderen VDRlern funktioniert.

Ist aber so. Bestes Beispiel ist Klaus selbst, aber auch viele andere auf der ML. Ich bin leider auch ein UPT-geplagter und das an 2 verschiedenen VDR Systemen. Jedoch läuft iMo einer mit vdr 1.2.6 und dem Old-Descriptor-Handling-Patch ohne das seit Wochen auch nur einmal der UPT-Fehler aufgetreten ist. Am 2. habe ich testweise vdr 1.3.2 am laufen und dort funktioniert der Patch nicht. Viele, viele Rejects. Deshalb bekomme ich dort auch UPTs.

Da durch den Patch aber eigentlich kein Fehler im VDR behoben sondern nur dessen Verhalten etwas geändert wird, liegt die Vermutung nahe, dass der Fehler bei den DVB-Treibern zu suchen ist. Und da kann es dann viele Gründe geben, warum es bei einem geht und beim anderen nicht: Chipsatz, Bustakt, Speicher, Kernel, Timing, ... Der Fehler kann auch in der Firmware liegen...

btw. ich habe bereits dvb-kernel und dvb-treiber probiert. Mit dem Patch bekam ich unter vdr 1.2.x keinen UPT-Fehler, ohne Patch bekam ich unter vdr 1.2.x und vdr 1.3.x ständig UPT-Fehler.

Joe

Zitat

Original von mrjoe

Ist aber so. Bestes Beispiel ist Klaus selbst,...

Stimmt, kann ich bestätigen.

Zitat

Mit dem Patch bekam ich unter vdr 1.2.x keinen UPT-Fehler, ohne Patch bekam ich unter vdr 1.2.x und vdr 1.3.x ständig UPT-Fehler.

Joe

Kannst du mal auf einem Rechner, auf dem du den UPT-Fehler hinreichend nachvollziehbar
bekommst, die DVB-Karte kräftig kühlen und schauen, ob er dann immer noch auftritt?

Möglicherweise ist es ja ein thermisches Problem...

Klaus

Zitat

Kannst du mal auf einem Rechner, auf dem du den UPT-Fehler hinreichend nachvollziehbar bekommst, die DVB-Karte kräftig kühlen und schauen, ob er dann immer noch auftritt?

Ich kann es auf beiden Rechnern gleichermassen nachvollziehen. Und auf beiden Rechnern habe ich mit dem CA_Old_Descriptorhandling-Patch (unter vdr 1.2.x) den Fehler sofort weg, ohne an der Hardwarekonfiguration auch nur eine Kleinigkeit zu ändern. Da auch auf der ML immer wieder der Verdacht in Richtung Firmware fällt, stellt sich mir die Frage, wie man an den Source derselbigen kommt. Mir ist bisher nur bekannt, dass es einen NDA mit Technotrend gibt. Jedoch will ich doch keine Firmware von denen, sondern die jeweils im DVB-Treiber/-kernel aktuell benutzte. Kannst du mich da aufklären?

btw. einer der Rechner hat ein offenes Gehäuse, sprich er ist kühl gelagert.

Joe

Zitat

Original von mrjoe

Ich kann es auf beiden Rechnern gleichermassen nachvollziehen. Und auf beiden Rechnern habe ich mit dem CA_Old_Descriptorhandling-Patch (unter vdr 1.2.x) den Fehler sofort weg, ohne an der Hardwarekonfiguration auch nur eine Kleinigkeit zu ändern. Da auch auf der ML immer wieder der Verdacht in Richtung Firmware fällt, stellt sich mir die Frage, wie man an den Source derselbigen kommt. Mir ist bisher nur bekannt, dass es einen NDA mit Technotrend gibt. Jedoch will ich doch keine Firmware von denen, sondern die jeweils im DVB-Treiber/-kernel aktuell benutzte. Kannst du mich da aufklären?

Die FW-Source gibt's leider nur nach Unterzeichnung eines NDA

Zitat

btw. einer der Rechner hat ein offenes Gehäuse, sprich er ist kühl gelagert.

Joe

"Offenes Gehäuse" muß noch nicht unbedingt heißen, daß die DVB-Karte nicht dennoch
lokal überhitzt. Kannst du mal einen zusätzlichen Lüfter direkt auf die DVB-Karte blasen
lassen? Damit wären wir dann ziemlich sicher, daß, wenn der UPT-Fehler dann immer noch
auftritt, es kein thermisches Problem ist.

Sollte es sich bewahrheiten, daß es nicht an einer Überhitzung liegt, dann müsste
mal jemand, bei dem der UPT-Fehler hinreichend oft auftritt, das im Treiber debuggen.
Ich selber kann das nicht machen, weil bei mir der Fehler nicht auftritt.
Ich wäre aber bereit, mich da mal ein paar Stunden hinzusetzen und das zu debuggen
(auch in der Firmware ;-), wenn mir jemand per 'ssh' Zugriff auf seinen Rechner
geben würde. Ich bräuchte dazu allerdings 'root'-Rechte, da ich ja den Treiber
immer wieder neu laden müsste. Falls also jemand dazu bereit wäre, soll er mich
mal per PM kontaktieren. Am besten wäre, wenn er dazu eine dedizierte VDR-Box
mit sonst nichts drauf hätte, die von außen per Flatrate erreichbar ist.

Klaus

Zitat

Die FW-Source gibt's leider nur nach Unterzeichnung eines NDA

Die Frage war: NDA von Technotrend oder NDA von jemand anderem. Denn letztendlich benötige ich nicht das Development-Zeug von Technotrend, sondern Zugang zu den Firmware-Sourcen der DVB-Treiber. Damit könnte ich selbst einige Debug-Versuche im kompletten DVB-Source starten. Denn ohne die Firmware-Sourcen hat man nunmal eine blackbox, die u.U. macht, was sie will.

Zitat

Falls also jemand dazu bereit wäre, soll er mich mal per PM kontaktieren. Am besten wäre, wenn er dazu eine dedizierte VDR-Box
mit sonst nichts drauf hätte, die von außen per Flatrate erreichbar ist.

Scheitert iMo an der Flatrate. Vielleicht hat von den anderen UPT-geplagten einer die Möglichkeit, dir eine Debug-Plattform zur Verfügung zu stellen.

Joe

Zitat

Original von mrjoe

Die Frage war: NDA von Technotrend oder NDA von jemand anderem. Denn letztendlich benötige ich nicht das Development-Zeug von Technotrend, sondern Zugang zu den Firmware-Sourcen der DVB-Treiber. Damit könnte ich selbst einige Debug-Versuche im kompletten DVB-Source starten. Denn ohne die Firmware-Sourcen hat man nunmal eine blackbox, die u.U. macht, was sie will.

Wer auf die im LinuxDVB-Treiber verwendete FW-Version Zugriff haben möchte
muß ein NDA bei Convergence unterschreiben.

Zitat

Scheitert iMo an der Flatrate. Vielleicht hat von den anderen UPT-geplagten einer die Möglichkeit, dir eine Debug-Plattform zur Verfügung zu stellen.

Joe

Tja, mal sehen...

Klaus

Hallo,

zum kühlen der DVB kann ich folgendes sagen:

In meinem VDR sind 3 DVB FF Karten 1.3 im Einsatz mit einem Lüfter der quer über den Karten sitzt und diese kühlt.

Leider habe ich auch den UPT Fehler.

ciao
Frank

stimmt,

ich habe meine 2 auch schon so gesteckt, dass 2 steckplätze raum dazwischen ist und
einen 80er lüfter direkt obendrauf und noch das gehäuse offen.
hat nichts gebracht.

werde mich mal auf die suche nach dem CA_Old_Descriptorhandling-Patch machen,
den hab ich noch nicht getestet.

Den Patch gibt es hier

Joe

Hi (Klaus),

ich nehm mal an das die UPT Fehler direkt oder indirekt mit den allseits bekannten outcommand/soutcommand Errors zusammenhängen. Ausserdem vermute ich mal das schnelle CPU´s zusätzlich dazu beitragen, denn die soutcommand errors habe ich nun schon seit 3 verschiedenen Boards und 2 verschiedenen CPUs (Sockel 370 Via-Chipset + Celeron 1.3/1.4, i845G + nun i865G mit Celeron 2.4Ghz) mit/ohne shared interrupts, mit/ohne ACPI, mit/ohne Zusatzkühler für die beiden Rev. 1.3 DVBs. Im Grunde tritt der Fehler seit dem API3 Treiber/Firmware auf.

Einen von beiden o.A. Fehler bekomme ich zu 99% immer, wenn ich folgendermaßen vorgehe:

1. Treiber laden.
2. vdr starten mit epgscan=0 und auf einem Kanal der von der primary empfangen wird.
3. 5-10min warten, und dann auf einen Kanal schalten der im Transfermode läuft (hier zum Testen ZDF).

Das klappt hier fast immer, auch wen ich vor vdr beide DVBs mit szap auf einen bestimmten Kanal tune.

Was hier auch zu 80% zu einem der Fehler führt ist, der secondary (nachdem die auf nen bestimmten Kanal getuned wurde) das Signal "wegzunehmen" für einige (10) Minuten. Nachdem die Karte wieder Signal tritt dann der Fehler auf, der hin und wieder durch Umschalten, manchmal durch neustart von vdr, und meist nur durch Treiber-Reload zu beseitigen ist.

Wenn ich die 2. Karte gleich nach dem starten von Hand auf zB ZDF schalte sind zumindest die kurz darauf folgenden Aufnahmen OK, aber spätestens nach ein paar Tagen verabschiedet sich die 2. Karte dennoch mit einem der beiden Fehler.

Ach ja...was auch häufig zu einem der beiden Fehler führt ist den Treiber zu laden, und direkt ohne Pause vdr zu starten, zumindest hier erwischts dann zu 60% auch eine der beiden DVBs.

Naja, und hier zumindest halt auch irgendwann während des EPG-Scans. Wobei ich das Gefühl hatte das ohne angeschlossenes CA der Fehler später auftritt. Leider ist das, besonders was den EPG-Scan angeht, nur schwer nachvollziehbar:(

Da wir sowieso gerade bei Firmware sind: Ich habe seit Monaten Aussetzer bei Replays jeglicher Art (vdr, mplayer, vcd) wenn ein CA-Interface an der primary hängt, die ich irrtümlich vdr in die Schuhe geschoben hatte*schäm*. Da das mit allen bisher getesteten Treibern auftrat, habe ich mich die letzten 7 Tage mal dranngemacht und habe ältere Firmware (nur Firmware, Treiber dvb-kernel vom letzten WE) Versionen getestet. Die letzte Firmware mit der dieser Fehler nicht auftritt ist vom 10.04.2003, mit der Änderung vom 22.04.03 (und allen folgenden Versionen) habe ich die Aussetzer mehr oder weniger oft (1-5x in 45min).

Andy

Hi,

zu den outcommand errors: Wollte am Freitag einem Kollegen ein VDR-System einrichten, allerdings ließ sich der Treiber nicht starten: outcommand errors. Gestestet unter Windows zeigte sich, dass die Karte auch hier nicht funktionierte, genauer, dass wohl das Initialisieren des ARM fehlschlug.
Ich gehe also davon aus, das outcommand erros immer dann auftreten, wenn die Kommunikation zur Karte gestört ist.
Wie sieht´s denn bei Euch z.B. mit der Latency der Karte aus? Habe gelesen, dass 128 ms besser als 64 ms ist (habe hier 64 ms). Zudem sehe ich gerade per "lspci -v", dass sich meine Karte mit anderen einen IRQ teilen muss (Elitegroup K7S5A :(; u.a. USB) ). Wie ist es bei Euch?
Eine echte Hardware-Statistik wäre mal interessant. Zwar denke ich, dass Andy.2ks Aussage durchaus richtig ist, aber ich denke, dass es bei seinen Systemen irgendeine Gemeinsamkeiten gibt (z.B. Kernel, Prozessorgeschwindigkeit etc.), die auf das von Klaus und anderen Nicht-UPT-Opfern nicht zutreffen (wenn ich mich recht erinnere verwendet Klaus noch SuSE 7.3 und damit einen älteren Kernel u.ä.).

Bei mir traten die UPTs zunächst auf einem 1-Karten-System (Nexus 2.1) auf. Jetzt habe ich noch eine Nova-CI drin, und meine per Timer gestartete Aufzeichnung von "Clever" heute auf SAT.1 (inkl. DD) hat zu Beginn auch Blöcke, wie ich sie vom UPT kenne - allerdings ist wenigstens ein Teil zu erkennen und später hören die Störungen ganz auf. Auf meinem 1-Karten-System gab´s dank "emergency exit" auf dem primären Gerät in solchen Fällen immer einen Reset von VDR, was zuletzt immer fehlerfreie Aufnahmen erzeugte :(.
Die Nova ist seit knapp 2 Wochen drin, alle Aufnahmen waren bisher okay, die SAT.1-Aufnahme ist die erste mit solchen Problemen. Auch bei einer ProSieben-Aufnahme letzte Woche waren beim Live-Schauen Blöcke im Bild, nach dem weg- und wieder zurück-Schalten war das Bild wieder okay, und auch die Aufnahme war da aber glücklicherweise ohne Fehler. Noch etwas hat sich seit dem Einbau der Nova geändert: Ich kann die rund 60 Kanäle nicht komplett durchzappen, ohne dass nicht irgendwann mal das Bild in Blöcken endet. Bleibt ebenfalls nur noch "Einstellungen -> Neustart" übrig.

Habe hier SuSE 9 (vorher 8.2, ebenfalls mit UPT) mit einer Nexus Rev. 2.1 und Nova-CI, VDR 1.2.6 mit Elchi, Autopid, Logopatch, AC3overDVB, 256 MByte auf einem Elitegroup K7S5A.

Bis dann - und hoffentlich wird das Problem endlich bald gelöst... Direkt helfen per SSH kann ich leider
nicht, da der UPT bei mir anscheinend nicht so oft wie bei anderen auftritt und ich zudem keine DSL-Standleitung habe... - noch nicht

Grüße

Jörg

Und hier meine Beobachtungen zum Thema:

Auch ich habe gut gekühlte DVB-S Karten (2 mal 2.1), mit eigenem Kühlkörper für den ARM chip und einem "getunten" Tunerblech. Ich hatte die Karten nebeneinander, habe sie jetzt 4 Slots auseinander, die eine Karte ist direkt am Gehäuserand (mit extra Lüftungslöchern), die andere ist mit den Chips auf einen freien Slot, gefolgt von einer Low-Profile Netzwerkkarte gerichtet montiert. Die DVB-Karten teilen sich keinen Interrupt, die Latency ist auf 128. Die Treiberoption hw_sections war lange Zeit auf 0, jetzt habe ich sie wieder entfernt.

Dennoch, die zweite Karte schmiert regelmäßig ab (UPT und OutCommand errors). Das kann ich besonders gut mit dem OSDPIP PlugIn nachvollziehen, da ich da den aktuellen Output der zweiten Karte direkt im Auge habe. Herbeiführen kann ich es meist durch:

- VDR oft restarten, ohne den Treiber zu restarten
- viele Receiver an die Sekundärkarte ankoppeln und wieder abkoppeln (also oft die zweite Karte zum extrahieren der MPEG-Daten zutzen)

Das äussert sich dann dadurch, dass OSDPIP entweder nur Schrott decodiert (Bilder, die hauptsächlich aus bunten Artefakten bestehen), oder garnicht anläuft (Bild-im-Bild bleibt aus). Leider passiert dies, wenn nicht wie oben herbeigeführt, auch gerne mal nach längerer Laufzeit ohne besondere Einwirkung.

Im übrigen ist es seit ich den Treiber zuletzt geupdated habe (von Stand etwa Juli auf Stand November, das Archiv welches bei kls verfügbar ist) schon mehrmals vorgekommen, dass dvb-core sich nicht mehr entladen liess (use-count 1). Hier half nur ein Reboot des Rechners.

Das habe ich bereits sehr lange (schätzungsweise V3 der API) und es ist doch etwas irritierend auf die Dauer.

Im Übrigen (vielleicht hängt das sogar damit zusammen?!) ist mir aufgefallen, dass wann immer ich den "kein Ton auf RTL"-Fehler (oder ARD, ich habe gelesen das steht in Zusammenhang mit ganz bestimmten APIDs) habe, auch die Sekundärkarte nicht zum aufnehmen fähig war (Zufall?).

kls: Im übrigen habe ich eine 768/128 flatrate und mein Router ist gleichzeitig mein VDR. Insofern könntest Du Dich ruhig dort austoben, falls das zur Lösung dieses leidigen Problems beitragen kann.

Ach, und ein letzter Edit:
Zuletzt hatte ich den UPT ununterbrochen während eines Recordings auf RTL am 23.01.. Nicht überraschend war natürlich dass das Recording absoluter Schrott war (decoden dieser Datei mit mplayer u.a. bringt exakt das gleiche Artefaktbild was OSDPIP auch zeigt). Für den Fall dass das Recording zu irgendwas nutze sein könnte habe ich es mal behalten.

Zitat

JK1974:
Ich gehe also davon aus, das outcommand erros immer dann auftreten, wenn die Kommunikation zur Karte gestört ist.

Ich hatte diese Meldungen oft bei einer bestimmten Kernelversion. Ich weis iMo nur nicht mehr, welche es zwichen 2.4.20 und 2.4.22 war. Imo setze ich 2.4.23 ein und habe keine derartige Meldung mehr.

Zitat

JKA1974:
Wie sieht´s denn bei Euch z.B. mit der Latency der Karte aus? Habe gelesen, dass 128 ms besser als 64 ms ist (habe hier 64 ms).

Habe ich ausführlichst mit allen möglichen Werten getestet. Kein Unterschied bezgl. des UPT und minimaler Unterschied bezgl. des video data stream broken-errors. Ähnliches wurde auch von anderen auf der ML berichtet.

Zitat

JKA1974:
Eine echte Hardware-Statistik wäre mal interessant.

Wurde auch auf der ML schonmal ansatzweise gemacht, mit dem Ergebnis, dass es keine Gemeinsamkeiten (SW und HW) gab. Und wie ich auch bereits geschrieben habe, habe ich hier 2 komplett verschiedene Systeme im Einsatz, wo bei beiden dieser Fehler auftritt. Sprich: ich verstehe nicht, warum es nicht eine größere Menge an DVB-Nutzern so geht.

Zitat

LordJaxom:
Die Treiberoption hw_sections war lange Zeit auf 0, jetzt habe ich sie wieder entfernt.

Wenn du Treiber ab September 2003 (oder sogar noch früher) einsetzt, dann ist hw_sections=0 der Standard! Das war nur mal für kurze Zeit anders. Hing damals glaube ich mit dem RTL-Aufnahmeproblem zusammen.

Zitat

LordJaxom:
- VDR oft restarten, ohne den Treiber zu restarten

Hab ich noch nie probiert, könnte aber mit der zweiten Fehlervariante zusammenhängen:

Zitat

LordJaxom:
- viele Receiver an die Sekundärkarte ankoppeln und wieder abkoppeln (also oft die zweite Karte zum extrahieren der MPEG-Daten zutzen)

Das ist analog, wie bei mir. Viele Kanalwechsel auf der 2. Karte und die 2. Karte bekommt Ihren UPT-Fehler. So sicher wie die Rente es nie sein wird.

Zitat

LordJaxom:
Im übrigen ist es seit ich den Treiber zuletzt geupdated habe (von Stand etwa Juli auf Stand November, das Archiv welches bei kls verfügbar ist) schon mehrmals vorgekommen, dass dvb-core sich nicht mehr entladen liess (use-count 1). Hier half nur ein Reboot des Rechners.

Wenn du dabei die Meldung bekommst: "device or ressource busy", dann haben wir das selbe Problem. Wobei ich dieses Problem nie mit Treibern vom Herbst letzten Jahres hatte.

Zitat

LordJaxom:
Im Übrigen (vielleicht hängt das sogar damit zusammen?!) ist mir aufgefallen, dass wann immer ich den "kein Ton auf RTL"-Fehler (oder ARD, ich habe gelesen das steht in Zusammenhang mit ganz bestimmten APIDs) habe, auch die Sekundärkarte nicht zum aufnehmen fähig war (Zufall?).

Da gab es auf der dvb-ML den Hint von (Name vergessen), dass man beim Laden von dvb-ttpci zusätzlich

pids_off=1

angeben soll. Das löst das Problem nicht vollständig. Verbessert es aber, sprich ich bekomme es weniger oft.

Zitat

LordJaxom:
kls: Im übrigen habe ich eine 768/128 flatrate und mein Router ist gleichzeitig mein VDR. Insofern könntest Du Dich ruhig dort austoben, falls das zur Lösung dieses leidigen Problems beitragen kann.

Das ist doch ein Wort. Schreib das doch per PM an Klaus, damit er weis, dass er eine Debug-Plattform hat.

Zitat

LordJaxom:
Zuletzt hatte ich den UPT ununterbrochen während eines Recordings auf RTL am 23.01.. Nicht überraschend war natürlich dass das Recording absoluter Schrott war (decoden dieser Datei mit mplayer u.a. bringt exakt das gleiche Artefaktbild was OSDPIP auch zeigt). Für den Fall dass das Recording zu irgendwas nutze sein könnte habe ich es mal behalten.

Da behaupte ich mal, dass dieses Aufnahme Schrott ist und immer sein wird, da vdr einen fehlerhaften Datenstrom aufgenommen hat.

Joe

Zitat

Original von Andy.2k
...
Da wir sowieso gerade bei Firmware sind: Ich habe seit Monaten Aussetzer bei Replays jeglicher Art (vdr, mplayer, vcd) wenn ein CA-Interface an der primary hängt, die ich irrtümlich vdr in die Schuhe geschoben hatte*schäm*. Da das mit allen bisher getesteten Treibern auftrat, habe ich mich die letzten 7 Tage mal dranngemacht und habe ältere Firmware (nur Firmware, Treiber dvb-kernel vom letzten WE) Versionen getestet. Die letzte Firmware mit der dieser Fehler nicht auftritt ist vom 10.04.2003, mit der Änderung vom 22.04.03 (und allen folgenden Versionen) habe ich die Aussetzer mehr oder weniger oft (1-5x in 45min).

Andy

Das kommt von einer Änderung in der FW die bewirkte, daß die Kommunikation
mit dem CAM während einer Wiedergabe nicht abreißt. Vorher (vor 2003-04-22)
war es so, daß die CAM-Kommunikation abriß sobald eine Wiedergabe gestartet
wurde. Dadurch war es nicht möglich, eine CA-Sendung aufzunehmen während
eine Wiedergabe lief. Daß es dabei zu Aussetztern bei der Wiedergabe kommt
ist mir wohl nicht aufgefallen, da ich normalerweise mein CAM an der dritten
DVB-Karte habe und diese nur kurz zum Testen dieser Änderung als primäre
Karte betrieben hatte.

Um das wriklich in den Griff zu kriegen müsste man wohl die gesamte Kommunikation
zwischen Treiber und Firmware (die ja durch das "Nadelör" Dual-Ported-RAM
durch muß) grundlegend überarbeiten...

Klaus

Hi

Zitat

Original von JK1974
.
Ich gehe also davon aus, das outcommand erros immer dann auftreten, wenn die Kommunikation zur Karte gestört ist.
Wie sieht´s denn bei Euch z.B. mit der Latency der Karte aus? Habe gelesen, dass 128 ms besser als 64 ms ist (habe hier 64 ms). Zudem sehe ich gerade per "lspci -v", dass sich meine Karte mit anderen einen IRQ teilen muss (Elitegroup K7S5A :(; u.a. USB) ). Wie ist es bei Euch?

ich habe 32, 64 und 128 durchprobiert, ohne das das was geändert hätte. Die Karten sharen bei mir mit der aktuellen Hardware auch keinen Interrupt, zumindest nicht direkt durch ACPI.

Zitat

]Original von mrjoe
Ich hatte diese Meldungen oft bei einer bestimmten Kernelversion. Ich weis iMo nur nicht mehr, welche es zwichen 2.4.20 und 2.4.22 war. Imo setze ich 2.4.23 ein und habe keine derartige Meldung mehr.

Habe alle durchprobiert, .20-24 sowie 2.6.0 & 2.6.1, ohne Unterschied oder ohne Verbesserung.

Im übrigen liefen die API2 Treiber (0.9.4) ohne Probleme, bei gleicher Hardware und API3 Treiber (ehem. Newstruct) fingen die Probleme erst an.

Zitat

Original von klsUm das wriklich in den Griff zu kriegen müsste man wohl die gesamte Kommunikation zwischen Treiber und Firmware (die ja durch das "Nadelör" Dual-Ported-RAM
durch muß) grundlegend überarbeiten...

Naja, ich bin erstmal froh das ich jetzt weiß woran das tatsächlich liegt, denn es kann ganz schön zermürben, wenn man auf einmal einen solchen Fehler hat, ohne die Ursache zu kennen bzw. das ganz anderen Dingen zuschreibt...zumal das scheinbar auch nur wenigen aufgefallen ist bisher. Und unterm Strich sind die UPT und soutcommand Errors eh wichtiger;)

Andy

mrjoe:

Bin auch in der ML, aber die Umfrage war IHMO dort nicht richtig strukturiert durchgeführt. Fazit war z.B. das letzte Mal, dass es nur bei 2-Karten-System auftritt, was ich aus eigener Erfahrung nicht bestätigen kann.

Aber wenn ich Deine Aufstellung sehe: Dieses Fazit zeigt ja wohl ziemlich genau, wo es lang geht. Bleibt aber immer noch die Frage, warum es bei Klaus nicht auftritt.

Was ich auch gerne wissen würde: Wie geht es den Softdevice- oder DXR3-Jungs, die keine FF-DVBs eingebaut haben?

Was ist eigentlich mit dem Old_Descriptor_Handling-Patch? Auf meinen Hinweis in der ML vor kurzem, den doch nochmal auszuprobieren, gab´s plötzlich das Feedback, dass der doch nicht funktioniert, obwohl andere User vorher das Gegenteil behauptet hatten. Ich selbst habe ihn (noch) nicht installiert...

Jörg

Zitat

JKA1974:
Bin auch in der ML, aber die Umfrage war IHMO dort nicht richtig strukturiert durchgeführt. Fazit war z.B. das letzte Mal, dass es nur bei 2-Karten-System auftritt, was ich aus eigener Erfahrung nicht bestätigen kann.

Es gab sehr wohl auch in der ML Berichte darüber, dass es auch bei 1-Karten-Systemen auftritt und zwar bei allen Revisionen der DVB-s.

Zitat

JKA1974:
Bleibt aber immer noch die Frage, warum es bei Klaus nicht auftritt.

Wenn wir das wissen, dann haben wir zu 99% den Fehler gefunden und hätten auch sicherlich relativ schnell einen Fix dafür.

Zitat

Was ist eigentlich mit dem Old_Descriptor_Handling-Patch?

Da ich ihn an einem System einsetze und an einem nicht, kann ich ganz klar (für meine Situation) sagen: bei mir hilft's. Am gepatchten vdr keine Probleme, am ungepatchten tägliche (und öfter) UPTs. Ich habe bis jetzt keine Nachteile mit dem Patch festgestellt, so dass man ihn ruhig installieren kann.

Joe

Zitat

Es gab sehr wohl auch in der ML Berichte darüber, dass es auch bei 1-Karten-Systemen auftritt

Korrekt, aber als das Thema das letzte Mal wieder 'heiß' war in der ML, war wirklich ein Fazit davon, dass es nur bei 2-Karten-Systemen auftritt. Hab´ mich dann aber gleich gemeldet

Ansonsten kann ich aber leider nicht viel weiterhelfen. Ich gehöre (leider) zu denen, bei denen das Problem nur gelegentlich auftritt. Selbst wenn ich also den Patch draufspiele, müsste ich wohl 2 Wochen testen - oder die richtigen Programme aufnehmen. Denn ich kann mich erinnern, z.B. mehrere Tage eine Kindersendung auf S-RTL per Autotimer ohne Probleme aufgenommen zu haben, während dann z.B. Lindenstraße auf der ARD dann doch Probleme bereitete. Gleiches Problem ja auch mit Clever am Samstag auf SAT.1 (siehe ein paar Threads vorher).

Hoffen wir mal, das wir das leidige Problem bald los sind...

Danke auf jeden Fall, dass das Thema nochmal angesprochen worden ist, vielleicht passiert ja jetzt was. Spätestens, wenn mehr Leute mhp4free ausprobieren, dürfte sich Convergence etwas mehr drum kümmern, denn auch da hatte ich gelegentlich ein schwarzes Bild (besser als Blöcke, aber auch nicht optimal :))