Reply to thread

Message: <blockquote data-quote="FloMann" data-source="post: 795587" data-attributes="member: 66772">AW: MePo 1.2 und Ruckler bei TV -> TSreader log, zeigt dabei "Pause 200mS Renderer"Servus,Ich habe die Tage über nochmal ein wenig MePo beobachtet und verglichen mit der älteren MePo 1.1.3..Also Prinzipiell hat auch die Version 1.1.3 auch schon dieses verhalten, das hier durch clock drifts Provider/Broadcaterund System, Buffer leer rennen und es zu dem Pause 200ms Renderer führt.Was ich in der vergangenheit beim testen nicht beachtete und daher ausgangsbedingungen anders waren,ist der umstand, das die Buffer nach dem start/aufbau des Graphen für TV Wiedergabe deutlich gefüllter sind,als wenn TV schon aktiv ist und gezappt wird. Im fall des TV start liegen die Meldungen für den Audio to render Bufferbei in der regel >500ms, nach dem Zappen deutlich weniger meist im bereich 200-300ms aber auchmal darunter.Somit laufen die buffer nach dem zappen in der regel schneller leer und es kommt früher zu dem Pause 200ms Renderer um die buffer wieder zu füllen. Nach einem TV start reichen die 500-700ms die sich aufbauen bei MePo 1.2 auchmal 5-7std,ich denke das ist für den alltag völlig ok.. Leider unterscheidet sich das verhalten meines Systems dennoch von MePo 1.1.3 undMePo 1.2.. Es ist so das es bei der neuen Version 1.2 gelegentlich, gerade nach dem Zappen die Buffer so schnell leerrennen das es meist innerhalb der ersten minute noch zu einem Pause 200ms Renderer kommt.Man sieht es auch an den bisher geposteten logs, am 24.09 habe ich 13mal eingriffe mit Pause 200ms Renderer,dabei habe ich 24 Zappvorgänge gezählt, neunmal tritt es innerhalb einer minute nach dem zapping auf weitere 2mal innerhalb der ersten 5minuten nach dem zapping, und zweimal dauerte es ein paar länger(24min; ~47min).Das Log vom 25.09 zeigt 3mal den Pause 200ms Renderer eingriff, hier wurde 5 mal gezappt (wenn ich micht verzählte).Es fällt einfach auf das dies oft auftritt recht zeitnah nach einem Zappvorgang, dies war zuvor mit MePo 1.1.3 so im alltag nicht auffällig zu beobachten, zumindest hatte mich es bis dato noch nicht auffällig gestört.Ich habe jetzt nochmal kurz MePo 1.1.3 und MePo 1.2 auf meinem Aktuellen System gegengetestet und mir auchnochmal MePo 1.1.3 auf meinem alten System angesehen. Was ich mal vorwegnehme ist, das bei meinemAlten system im vgl. zu meinem neuen, dieser audio to render Buffer langsamer leerläuft und dies system damit noch unanfälliger war, aber tendenziell sich alles hier auch verhält wie weiterführend mit dem aktuellen system beschrieben... Nun wie gesagt habe ich nochmal mein aktuelles system mit beiden Versionen  verglichen, dabei wurde TV gestartet,und dann noch 5 mal gezappt, normal wollte ich 5min intervalle beim zapping halten, leider hab ichs bei MePo 1.1.3 mal verschlafen. Die Log Dateien sind im Anhang, ich nehme aber mal vorgweg das es bei MePo 1.1.3 keinerlei probleme gab,bei Mepo 1.2 kam es jedoch schon wieder 2 mal zu dem Pause 200ms Renderer eingriff. Mal etwas im Detail aus den Logs (ich erwähne nur mal den Audio to Render Buffer weil dieser bei mir leerläuft und der auslöser der Pause 200ms Renderer ist).Die angegebenen Zeiten sind aus dem Log zu dem Zeitpunkt wo auch ein Demux: Audio to Render xxxs eintrag existiert.In der regel wollte ich eigentlich schauen wie schnell wann wie wo die Buffer leerlaufen, ist nicht immer zu exacten zeiten möglich mangels einträgen im Log, geplant waren bestimmte zeitabschnitte in 5min intervallen, naja ist halt nicht alles wie geplant.Gezappt wurde von Pro7 (start) zu Kabel1 und zurück, auch auf anderen Kanälen stellt sich dies problem ein, ich entschiedmich nur eben dafür da hier um die uhrzeit wenigstens noch was imo verträgliches im TV läuft.  Zu MePo 1.1.31) Start TV 14:27:08 Audio to Render (A to R) 0,633s14:32:30 A to R 0,615s (das macht in 5:22min ein delta von 18ms)14:42:52 A to R 0,556s (das macht in 10:22min ein delta von 59ms)Gesamt in 15:44 min ein delta von 77ms2) Zapping 115:00:04 A to R 0,345skeinere weiteren einträge zum Audio buffer im Log in den weiteren 15min bis zum zapping, aber auch keine Probleme.3) Zapping 215:15:01 A to R 0,275s15:19:55 A to R 0,246s (4:54min mit delta 29ms)4) Zapping 315:20:04 A to R 0,263s15:22:33 A to R 0,223s (2:29min mit delta 40ms)5) Zapping 415:25:06 A to R 0,226s15:29:42 A to R 0,203s (4:36min mit delta 23ms)6) Zapping 5 15:30:07 A to R 0,259s15:34:44 A to R 0,221s (4:37min mit delta 38ms)15:45:29 A to R 0,207s (10:45min mit delta 14ms)16:00:19 A to R 0,187s (14:50min mit delta 20ms) Gesamt 30:12min mit delta 72ms  So das Problem soll ja sein, das die Clocks von System und zum Provider/Broadcaster differieren und dies im gegensatz zum STB bereich am PC nicht in den griff zu bekommen ist über eine Syncronisation.Zumindest wenn man hier im verlinkten Thread mal weiter Ließt äusert sich arionP dazu, ich stecke nicht so tief in der materie in sachen TS-Streams  vom Broadcaster und HW Entwicklung dafür (bin in der Messtechnik tätik)für dieses Detail wissen.<a href="https://forum.team-mediaportal.com/mediaportal-1-1-0-rc-3-6-519/continous-glitches-livetv-both-sd-hd-83762/" target="_blank">https://forum.team-mediaportal.com/mediaportal-1-1-0-rc-3-6-519/continous-glitches-livetv-both-sd-hd-83762/</a>Nun was aber hier schon auffällt ist doch, das die Buffer degration über die Zeit stellenweise ebbes unterschiedlich ist, was so schon ein seltsammes verhalten ist, ich bezweifel  das system clock und Provider Clock so schwanken als das sich ein so zeitlich unterschiedliches leerlaufverhalten des buffers ergibt, hier muss/könnte doch noch was anderes mit im argen liegen. Ebenso laufen die buffer in der regel/überwiegend zu beginn schneller leer und mit der zeit wird die degration dann etwas kleiner, ich habe hier nach andere logs über die dauer und hier ist es dann eher zu erkennen(gerade auch für Mepo 1.1.3 noch wo diese hier es nicht so richtig zeigt).Das ist imo auch nicht ganz so optimal und kann sicher nicht durch Provider/System Clock differenzen entstehen, die sich garantiert nicht so verhalten werden, das sich abnehmende buffer drifts einstellen...Wir befinden uns hier auch in kleinst bereichen von abweichungen, wenn man mal von 10min mit 50fields/sec eines SD Streams vom Provider ausgeht (das macht 30000 Fields, die der PC als Progressives ausgabegerät als 30000 Frames zeigen müsste), der Buffer dabei um 50ms abnimmt, damit das system 2,5 fields mehr zeigt in der Zeit, macht das ~83ppm schneller für den PC. Sowas liegt denke ich noch im rahmen des möglichen. Erklärt mir aber immer noch nicht das verhalten das die buffer drifts doch zeitweise recht unterschiedlich sind. Die Toleranzen der Taktgeber sind gegeben, temp drifts und aging kommt noch dazu, nur das wird dieses schnelle sporadische verschiedene verhalten von Mepo imo auch nicht alleine erklären können.Im folgenden mal ein paar Details zu dem MePo 1.2 logs, hier sieht man dann auch das diese Varianzen des Buffer leerlaufnoch größer sind und genau dann hier meine probleme entstehen, so das ich dies im Alltag das erstemal so richtigstörend empfinde mit dem Pause 200ms Renderer, welcher getriggert wird sobald Audio to Render 0,1s erreicht/unterschreitet. Zu MePo 1.2.0(RC)1) Start TV 12:12:02 Audio to Render (A to R) 0,575s12:16:55 A to R 0,516s (4:53min mit delta von 59ms)12:27:47 A to R 0,487s (10:52min mit delta von 29ms)12:41:55 A to R 0,452s (14:08min mit delta von 35ms)12:59:33 A to R 0,429s (17:38min mit delta von 23ms ; Gesamt bis hier her 47:31min mit delta 146ms)13:44:51 A to R 0,364s (45:18min mit delta von 65ms)Gesamt 1:32:49 Std. mit delta 211ms2) Zapping 113:45:04 A to R 0,184s 13:47:14 A to R 0,158s (2:10min mit delta 26ms)3) Zapping 213:50:08 A to R 0,238s13:54:52 A to R 0,134s (4:44min mit delta 104ms)4) Zapping 313:55:03 A to R 0,226s13:57:15 A to R 0,140s (2:12min mit delta 86ms)5) Zapping 414:00:02 A to R 0,188s 14:00:24 A to R 0,098s (22sec mit delta 90ms und Pause 200ms ausgeführt)14:00:32 A to R 0,401s (neustart, erster A to R eintrag nach Pause 200ms)14:04:25 A to R 0,295s (3:52min mit delta 106ms)6) Zapping 5 14:05:14 A to R 0,204s14:09:38 A to R 0,08s (4:24min mit Delta 124ms)14:09:38 A to R 0,309s (neustart, erster A to R eintrag nach Pause 200ms)14:12:47 A to R 0,275s (3:09min mit delta 34ms)Was mir hier generell als erstes aufällt sind das einmal tendenziell die buffer nach dem Zapping etwas weniger gefüllt sind als noch bei Mepo 1.1.3 (für schnelllers Zapping ??? oder warum?? oder einfach nur zufall)desweiteren fallen auch die noch größeren Varianzen beim leerlaufen des Buffer auf.. Und gerade weil sich hier MePo 1.1.3 und 1.2.0 hier unterschiedlich verhalten, bezweifel ich das hier reine auswirkungen der System/ Provider Clocks sind sondern auch die Arbeitsweise MePo`s mit reinspielt..Taktgebern ist die Software egal, die differieren alleine betrachtet sicher nicht anders mit verschiedener SW..In manchen fällen, konnte ich in logs auch sehen, das direkt die erste A to R Meldung nach dem Zappennegativ ausfällt und gleich ein Pause 200ms Renderer getrigert wird, finde ich auch seltsam...Für mich als Workarround, weis jemand ob man "einfach" einfluss darauf nehmen kann wie viel A/V to R buffer nach dem zappen angelegt wird, denn eine erhöhung auf 0,5-0,6s würde mir hier denke ich schon für den alltag helfen die nervigen Pause 200ms renderer hänger zu minimieren. Das dies einfluss auf das zapping haben kann wäre mir bei zusätzlichen 200-400ms egal, ich bin nicht der ums leben zapper.Generell denke ich aber da könnte nochmal drüber gebrütet werden, warum es a) zu solchen varianzen in den Driffts des Buffer kommt und dies b) vorallem auch SW übergreifend zur neuen version ( zumindest bei mir) nochmals defizieler wurde... In anbetracht dessen das ich mit MePo 1.0.2 auch nie stutter probleme hatte (std. lang Mio`s von Bilder am stück ohne Probs), die ja mit dazu führten diese funktion des pause renderer einzuführen, ist für mich persönlich zumindest dieses verhalten ein rückschritt der neueren versionen zu den alten, die mir aber zumindest in der paar monatigen MePo 1.1.3 phase so störend noch nicht aufgefallen ist . Wie gesagt dieses verhalten, in anderen Punkten auch um TV herrum sind natürlich verbesserrungen  bei MePo auszumachen,aber das jetzt ist für mich ein stärkere rückschritt in sachen MePo und laufendes alltags TV..Das ganze bezieht sich auch, nochmals erwähnt, auf eine Single Seat nutzung. Mich würde mal interessieren ob es bei anderen mit MePo 1.2 nicht auch zu den Pause 200ms Renderer hängern kommt,aufgrund leerlaufender buffer ( das sieht man natürlich nicht wenn man im Timesshift mit noch vorlauf hängt), wie sieht dies bei euch aus??? mit MePo 1.2 und eventuell auch zuvor?</blockquote>

Verification