Komisches Verhalten auf TP 93

[ThulsaDoom]

Hi, ich habe ein für mich unerklärbares Problem(chen), das mich irgendwie doch beschäftigt:

 

Also mit meinem relativ schwachen Wohnzimmer-PC (siehe Signatur) lassen sich die beiden TV-Kanäle (SR-Fernsehen und BR-alpha) auf Transponder 93 zwar genauso schnell tunen, wie alle anderen SD-Kanäle auf Astra. Nur kurz nach dem tunen, habe ich für ca. 3-5 sek. Ruckler, Tonaussetzter, etc., danach ist alles wieder prima. Der DVBV-Filter zeigt in diesen paar Sekunden auch Discontinues. Mit geöffnetem Resourcen-Monitor des Taskmanager stelle ich fest, dass die CPU-Last beim tunen kurz sehr hoch geht und der Atom-Prozi damit dann wohl überfordert ist.

 

Aufnehmen über den Recordingservice geht ohne Diskontinues und wenn ich die Sender über TransEdit tune, dann ruckelt auch nix.

 

Die entscheidende Frage ist nun: Warum ist das bei diesem TP so? Alle anderen Sender (SD & auch HD) gehen ohne murren. Ich schaue eigentlich weder SR-Fernsehen noch BR-Alpha und kann desewegen auch nicht sagen, ob das nun seit gestern, seit Monaten oder Jahren so ist. Habe nur etwas bedenken, das sich dieses "unschöne" Verhalten irgendwann mal auf andere Sender ausbreitet.

 

Mein HTPC läuft nämlich ansonsten 1A mit dem alten WinXP. Habe auch einige Wochen in das Feintung gesteckt.

 

Ach so: Was ich noch probiert habe bzw. feststellte ist, dass ein 2. PC, der auf den RS vom HTPC zugreift (auch über Unicast-Device), keine Ruckler bringt (das ist aber auch ein potentes Teil mit Sandy-Bridge CPU und nvidia GTX 285 auf Win/-Basis). Dann habe ich noch einen 3. PC mit extra TV-Karte (nova-HD-S2) und extra Recording-Service (Win7) und wenn ich die Unicast-Device des HTPC mal daraufhin umbiege, dann sind die 2 Problemsender auch ohne Discontinues da. Sehr seltsam, oder ?

Plugins-Ordner umbenennen bringt gar nichts!

 

Noch kommischer ist allerdings: Wenn ich zwischen SR-Fernsehen und BR-Alpha zappe, also auf dem TP bleibe, dann ruckelt auch nix (ist vielleicht logisch, da nur die PIDs getauscht werden, oder?) Übrigens Transponder 93 ist 12266 H.

 

 

Warum erzeugt dieser TP nun eine kurzzeitige höhere Systemlast des DVBViewer plus RS, die anscheinend gerade die paar % zuviel für mein kleines schwächliches Kästchen ist?

 

Sollte ein support.zip zur Analyse notwendig sein, dann liefere ich das gerne nach. Bin auf der Arbeit und kann das dann zuhause erstellen!

 

Vielleicht hat hier irgendjemand eine Idee (ich selbst löse meine Probleme in der Regel selbst; hier scheitere ich aber bislang).

 

Danke für´s lesen und Gruß

ThulsaDoom

Edited August 21, 2012 by ThulsaDoom

[avdreith]

Also ich habe das gleiche Problem. Ich betreibe den DVBViewer in meiner Wohnung und bei meiner Freundin (zwei Lizenzen gekauft). Bei mir sind die TV Karten in einem Windows 7 Rechner eingebaut auf dem der Recordingservice installiert ist. Am TV war bisher ein Rechner mit Windows XP angeschlossen, der die Programme über das Netzwerk vom RS bekam (Unicast?!?!) Hier gab es nie Probleme. Alle Transponder ok!

 

Bei meiner Freundin lief bisher ein Rechner mit XP (RS und lokaler Zugriff darauf mit DVBViewer). Dieser Rechner hatte die von ThulsaDoom beschriebenen Störungen. Besonders schlimm war es bei BRAlpha. Nachdem der Rechner irgendwie nicht mehr wollte habe ich meinen Zweitrechner (s.o.) mitgebracht und diesen neu installiert und damit den alten Rechner ersetzt. Gleiches Problem bei Transponder 93.

 

In meiner Wohnung sind zwei Hauppauge HVR 4000 und eine PCTV Dual Sat Pro PCI verbaut. Im Rechner meiner Freundin steckt nur eine PCTV Dual Sat Pro PCI.

 

Codecs sind unter XP PowerDVD 8, ffdshow, AC3 Filter.

 

Zuerst dachte ich es würde an dem alten Rechner meiner Freundin liegen. Aber da der neue Rechner das gleiche Problem macht und auch ThulsaDoom dieses Problem kennt....

[gwr]

Mit dem DVBViewer Pro (4.9.6.20) erzeugt der TP 93 auf schwachen Systemen einen grossen "Berg" an CPU-Last, der mehrere Sekunden nach dem Tunen anhält. nach dem Process Explorer erzeugt vom thread um ksproxy.ax .

Wenn man "keine EPG Daten einlesen" anhakt, ist die CPU-Last weg. Der TP 93 überträgt nach Transedit-Analyser eine relativ

grosse Menge an EPG-Daten. Allerdings kommt der DVBViewer GE damit gut zurecht, der erzeugt diese CPU-LAst nach dem Tunen nicht.

[Griga]

erzeugt vom thread um ksproxy.ax

ksproxy.ax ist ein Wrapper, der BDA-Treiberfunktionen als DirectShow-Filter zur Verfügung stellt. Alles, was im DVBViewer direkt den Live-Stream verarbeitet (also vor der Umsetzung der Daten auf UI-, Wiedergabe- oder sonstige Threads), läuft in dem von ksproxy.ax erzeugten Thread, der die vom Treiber stammenden Daten anliefert. Da er besonders zeitkritisch ist (die Sender warten nicht), läuft er mit erhöhter Priorität, und man sollte *nach Möglichkeit* zeitraubende Datenmanipulationen aus diesem Thread heraushalten.

 

Offenbar werden im DVBViewer Pro aufwändige Operationen mit den live eintreffenden EPG-Daten durchgeführt (mit Sicherheit aufwändiger als im DVBViewer GE). Inwiefern sich das programmtechnisch vermeiden lässt, weiß ich nicht. Im Prinzip müssten die eintreffenden Rohdaten gepuffert, von einem anderen Thread ausgelesen und dort verarbeitet werden, um solche Störungen zu vermeiden.

 

Hier geht die Prozessorlast beim DVBViewer Pro auf einem relativ schwachen System (mit betagtem AMD Athlon 3200+ Single Core) auch deutlich nach oben. Allerdings kommt es zu keinen Störungen. Der EIT-Stream auf Astra 19° Ost 12266 H hat mit 2.2 MBit/s im Vergleich zu anderen ARD-Transpondern eine relativ hohe Datenrate, da er den EPG für ca. 60 Radioprogramme plus zwei TV-Programme 3 bis 4 Wochen im Voraus transportiert. Insbesondere werden die gesamten Daten für die erste Woche dem Empfänger mit einer Zykluszeit von ca. 10 Sekunden aufgedrückt, was ein erheblicher Ansturm ist. Die Daten der nachfolgenden Wochen lassen sich mit einer Zykluszeit von ca. 30 s mehr Zeit. Sobald der DVBViewer Pro die Daten bereits "kennt" und nur noch Wiederholungen kommen, geht die CPU-Last wieder runter.

 

Allerdings ist das alles noch harmlos gegenüber Astra 28° Ost, 12427 H. Dort gibt es einen "privaten" EIT-Stream (PID 3003), der mit 4.5 MBit/s innerhalb 30 Sekunden den gesamten EPG für sämtliche britische Freesat-Transponder Huffman-komprimiert (!) ausliefert. Da geht es richtig zur Sache

[gwr]

Hier geht die Prozessorlast beim DVBViewer Pro auf einem relativ schwachen System (mit betagtem AMD Athlon 3200+ Single Core) auch deutlich nach oben. Allerdings kommt es zu keinen Störungen.

 

Störungen gibt es bei mir auch nicht, der Rechner hier ist noch schwächer. Die CPU ist ja auch noch nicht am Anschlag.

[ThulsaDoom]

Vielen Dank an Alle für die Antworten & Erklärungen.

 

Es stimmt, dass es kein Geruckel mehr gibt, wenn ich den Haken bei "Keine EPG-Daten einlesen" setze. Bei einer Twin-Karte und dem periodischen EPG-Update durch den Recording-Service könnte ich das ja eigentlich so lassen, da das EPG über den RS aufgefrischt wird. Nur bei kurzfr. Anpassungen durch den Sender (bspw. Programm-Umplanungen oder Verschiebungen bei Live-Events) kriegt der Viewer das dann nicht mit, richtig ?

 

Das das EPG nur auf diesem Transponder nicht vom Viewer eingelesen wird, kann jetzt nicht separat eingestellt werden, oder ? Habe jedenfalls keinen Trick dafür gefunden. Die Haken im Serder-Editor bei EPG bringen nix, ausser dass das EPG nicht angezigt wird (es aber trotzdem ruckelt). Na ja, das Gute ist ja, dass ich jetzt weiss, dass mein System nicht vermurxt ist und das andere auch das Problem kennen. Das beruhigt dann doch!

 

 

Gruß

ThulsaDoom