TimeshiftPlus Plugin, erweiterte Timeshift Funktionalität (Ringpuffer)

[Klassikfan]

So!

 

Ich kann mich jetzt als Versuchskaninchen für Windows7x64 anbieten.

Es läuft zwar noch nicht alles so, wie ich es möchte, so zB. ruckelt die Videoausgabe im DVBViewer, wenn ich Overlay nehme (aktuell geht es nur mit "EVR" ganz ordentlich, aber immerhn läuft es.

 

Auch TimeshiftPlus läuft grundsätzlich. Allerdings sah es am Anfang nicht so aus. Da habe ich den RAM-Puffer auf 3000MiB hochgesetzt und "Lock DVBViewer in RAM" angekreuzt. Ersteres scheint die Ursache für den Fehler zu sein, denn wenn ich mit diesen Einstellungen fahre, und den Timeshift-Schieber nach links rücke, wird das Bild schwarz, und der Schieber springt ruckweise wieder nach rechts zurück.

 

Sowohl die serienmäßige Timeshift-Funktion des DVBViewer als auch die mit Ringpuffer und 1024MiB RAM (und aktiviertem "Lock...") funktionieren aber ordentlich, auch inklusive der Aufzeichnung des Pufferinhaltes. Sogar wenn man nach Aufnahmestart wieder ins Livebild zurück geht, die Aufnahme ist komplett.

 

Bliebe die Frage, warum es mit 3000MiB nicht geht. Muß das etwa ein Vielfaches von 1024 sein? Oder gibt es eine Größenbeschränkung?

Am vorhandenen RAM kann es nicht liegen, 8GB sollten dicke reichen.

[erwin]

Erstmal Dank euch allen für eure Berichte. Werde auch darauf eingehen. Hab aber im Moment ein par private/familiäre Sorgen so dass ich nicht zum proggen komme. Bis später.

 

erwin

[CiNcH]

Hab aber im Moment ein par private/familiäre Sorgen so dass ich nicht zum proggen komme. Bis später.

Ohje, da drück ich dir mal die Daumen, dass du die Probleme lösen kannst und die Sorgen los wirst..

[skeal]

Ich drück auch die Daumen und komme aber gleich mit einer Frage

 

Also im Kurzen: Hab ich das richtig verstanden, dass ich mit diesem Plugin auch "Spulen" kann im Timeshift?

 

Mein Problem ist allerdings, dass nichts passiert, wenn ich beispielsweise auf den Slowmotion Pause zugewiesenen button auf der fernbedienung drücke ...

Ich nutze die neueste Beta von DVBViewer (4.3.1.25) auf Windows 7 Home Premium 64bit

Das Plugin erscheint im Menü von DVBViewer (Allerdings ist SlowMotion ausgegraut?)

Ich habe alle Dateien aus der Zip-Datei in Plugins (In Programme nicht Users) entpackt und die remote Datei importiert...

Die Pluginoption erscheint auch und ich kann dort die Werte ändern ...

 

Mache ich hier was komplett falsch? Bestimmt was sehr einfaches/doofes übersehen oder?

Bin auch noch nicht so sehr in der Materie DVBViewer drin, weil ich grad von Mediaportal wechsel, weil die TV-Funktion dort träge ist und nicht alle Sender findet...

[erwin]

Hab ich das richtig verstanden, dass ich mit diesem Plugin auch "Spulen" kann im Timeshift?

Jein! Spulen ist mit Einschränkungen möglich. Erstens hängt es vom eingestellten Decoder ab. Die meisten haben eine maximale Speed oder spulen gar nicht. Zweitens ist die Dauer beschränkt. Das hängt mit der Arbeitweise des Haalifilters zusammen. Man muss bedenken dass Haali von der Wiedergabe einer (endlichen) Datei ausgeht, in Wirklichkeiit aber die Wiedergabe eines (nicht beschränkten) Streams abläuft. Konkret geht Haali kurz nach dem Start an das vermeindliche Dateiende (um die Dauer festzustellen?) und ich muss das irgendwie simulieren. Und diese Dauer bestimmt dann nach Haali-Logik auch die maximale Spuldauer. Hier hakt es an etlichen Stellen und ich habe auch noch nicht alle Hürden umschifft, bleibe aber dran. Generell kann man sagen, dass die max. Spuldauer mit der TimeshiftPlus-Betriebsdauer steigt.

 

Mein Problem ist allerdings, dass nichts passiert, wenn ich beispielsweise auf den Slowmotion Pause zugewiesenen button auf der fernbedienung drücke ...

Die Slowmotion-Wiedergabe pausiert nicht?

 

mfg erwin

Edited November 9, 2009 by erwin

[erwin]

Da hast du genau mein oben angesprochenes Problem. Versuch mal folgendes:

...

Da landest du _nicht_ in der Vergangenheit (was du durch Linksverschiebung des Sliders erwartet hättest), sondern in der Zukunft, weil sich der Slider bei >50% befindet (vor der Verschiebung befand man sich im Ringpuffer bei 50%).

 

Ja hast Recht. Grundproblem ist, dass der DVBV den Slider nach _seinen_ Regeln setzt und hier das im vorigen Post angesprochene Dilemma Datei vs Stream wirksam wird. Allerdings habe ich in der Zwischenzeit doch eine Möglichkeit gefunden den Slider vom Plugin zu setzen (die Toyota Affen lassen grüßen). Zusammmen mit einer eigenen Jumpverwaltung... ? Ich arbeite dran.

 

mfg erwin

[erwin]

...und den Timeshift-Schieber nach links rücke, wird das Bild schwarz, und der Schieber springt ruckweise wieder nach rechts zurück.

Das könnte daran liegen dass Du den Kanal gewechselt hast und "release buffer on timeshift stop" deaktiviert ist. Wenn jetzt das aufgezeichnete Videoformat (z.B. MPEG2) nicht zum Videoformat des aktuell getunten Senders (z.B. H264) passt, wird dieser Teill übersprungen. Folge: schwarzes Bild und Sprünge des Sliders. Bei Nichtübereinstimmung im Audioformat bleibt dieser Teil einfach stumm.

 

Bliebe die Frage, warum es mit 3000MiB nicht geht. Muß das etwa ein Vielfaches von 1024 sein? Oder gibt es eine Größenbeschränkung?

Nein. Die Anforderung ist ein Maximalwert. Von diesem ausgehend wird das maximal Mögliche allokiert. Ich habe z.B. 5000 eingestellt.

 

mfg erwin

[skeal]

Jein! Spulen ist mit Einschränkungen möglich. Erstens hängt es vom eingestellten Decoder ab. Die meisten haben eine maximale Speed oder spulen gar nicht. Zweitens ist die Dauer beschränkt. Das hängt mit der Arbeitweise des Haalifilters zusammen. Man muss bedenken dass Haali von der Wiedergabe einer (endlichen) Datei ausgeht, in Wirklichkeiit aber die Wiedergabe eines (nicht beschränkten) Streams abläuft. Konkret geht Haali kurz nach dem Start an das vermeindliche Dateiende (um die Dauer festzustellen?) und ich muss das irgendwie simulieren. Und diese Dauer bestimmt dann nach Haali-Logik auch die maximale Spuldauer. Hier hakt es an etlichen Stellen und ich habe auch noch nicht alle Hürden umschifft, bleibe aber dran. Generell kann man sagen, dass die max. Spuldauer mit der TimeshiftPlus-Betriebsdauer steigt.

 

 

Die Slowmotion-Wiedergabe pausiert nicht?

 

mfg erwin

 

Codec ist PDVD9

 

Ich dachte Pause bedeutet, dass er die aktuelle Live-Wiedergabe pausiert und danach wieder weitermacht wenn ich play drück

anscheinend bring ich da einiges durcheinander bei diesem plugin

[erwin]

Ich dachte Pause bedeutet, dass er die aktuelle Live-Wiedergabe pausiert und danach wieder weitermacht wenn ich play drück

Dies wird über die normalen in DVBV eingebauten Buttons/Funktionen erreicht, die nach wie vor funktionieren.

Die Slowmotion-Pause ist etwas anderes: Wenn Timeshift aktiv ist, dann wird der Menüpunkt Slowmotion/FastForward verfügbar. Wenn dann dieser Menüpunkt gewählt wird, erscheint (dauert ein wenig) ein neues Fenster mit dem gebremsten/beschleunigten Video. Hier sind dann Buttons für Play/Pause/Stop verfügbar.

 

mfg erwin

[CiNcH]

Allerdings habe ich in der Zwischenzeit doch eine Möglichkeit gefunden den Slider vom Plugin zu setzen (die Toyota Affen lassen grüßen).

Hört sich interessant an, kannst du das etwas genauer erläutern?

[erwin]

Hört sich interessant an, kannst du das etwas genauer erläutern?

Na ja, alles sehr tricky. Jedenfalls gilt die Antwort von Lars nach wie vor. Für eine normale Pluginentwicklung ist mein Verfahren völlig ungeignet. Es setzt die von mir eingesetzte Infastruktur voraus und die ist wie schon mal erwähnt "von hinten durch die Brust ins Auge".

 

mfg erwin

Edited November 9, 2009 by erwin

[CiNcH]

Ich habe nun noch einen Hinweis zu meinen UI-Darstellungsfehlern. Diese habe ich nur mit dem klassischen Windows-Design, nicht aber mit dem Windows XP Design (siehe Systemsteuerung -> Anzeige -> Designs).

[CiNcH]

Ich habe nun Windows 7 installiert und da ist die Umschaltung leider problematisch, wenn das TimeshiftPlus-Plugin aktiv ist. Da reagiert der DVBViewer dann für etwa 3 Sekunden nicht, Video ruckelt in der Zeit und das MiniEPG-OSD kommt erst nach diesen 3 Sekunden zum Vorschein. Da dauert das Reallokieren des Speichers wohl sehr lange. Wieder ein Pro für File .

[CiNcH]

Kann man kanalübergreifendes Timeshift (HISTORY) und Realloc bei Timeshift-Close()/Open() wieder trennen? Der negative Aspekt dabei ist halt, dass der Speicher auch bei Medienwiedergabe usw. allokiert bleibt. Aber evtl. könnte man einen Timeout einführen. Dieser wird mit Timeshift-Close() gestartet und wenn nach Ablauf (ein paar Sekunden) kein Open() erfolgt ist, gibt man den Speicher frei.

Edited November 16, 2009 by CiNcH

[erwin]

Ich habe nun Windows 7 installiert und da ist die Umschaltung leider problematisch, wenn das TimeshiftPlus-Plugin aktiv ist. Da reagiert der DVBViewer dann für etwa 3 Sekunden nicht, Video ruckelt in der Zeit und das MiniEPG-OSD kommt erst nach diesen 3 Sekunden zum Vorschein. Da dauert das Reallokieren des Speichers wohl sehr lange. Wieder ein Pro für File .

Also die File-Option kommt (irgendwann ;-)).

Ansonsten habe ich gerade die RingBuffer.exe als native Windows 7 - 64-Bit Version gebaut und habe derartige Probleme nicht bemerkt. Kann hier jemand für Windows 7 bestätigen?

 

Ich habe nun noch einen Hinweis zu meinen UI-Darstellungsfehlern. Diese habe ich nur mit dem klassischen Windows-Design, nicht aber mit dem Windows XP Design (siehe Systemsteuerung -> Anzeige -> Designs).

OK. Jetzt sehe ichs auch. Ich werd den Dialog mal in die Breite ziehen. Auf Grund der größeren Stellenzahl in der Anzeige der Puffergröße bei 64 Bit ist dies sowieso notwendig.

 

Kann man kanalübergreifendes Timeshift (HISTORY) und Realloc bei Timeshift-Close()/Open() wieder trennen? Der negative Aspekt dabei ist halt, dass der Speicher auch bei Medienwiedergabe usw. allokiert bleibt.

Naja muß ja allokiert bleiben, was dann bei Medienwiedergabe natürlich stört. Ich könnte allerdings die Speicherfreigabe (und Verlust der HISTORY-Timeshift-Daten - oder auch nicht wenn mit der File-Option gearbeitet wird ;-)) bei Medienwiedergabe einbauen. Oder steckt bei Deiner Timeout-Anregung mehr dahinter als ich jetzt überblicke?

 

mfg erwin

Edited November 16, 2009 by erwin

[CiNcH]

Oder steckt bei Deiner Timeout-Anregung mehr dahinter als ich jetzt überblicke?

Da ich halt das Problem unter Windows 7 (bei mir x86) habe, dass das Freigeben und neu Allokieren nicht problemlos funktioniert bzw. etwas Zeit in Anspruch nimmt (davon gehe ich jedenfalls aus, dass das das Problem ist), wollte ich vermeiden, dass das bei jedem Umschalten gemacht wird und der Speicher allokiert bleibt. Aber History will ich auch vermeiden (da ich es für unbenutzbar halte) und momentan stecken die beiden Fälle halt in einer Option und das eine geht nicht ohne das andere.

 

Wenn ich das richtig verstanden habe erfolgt zum Beispiel beim Übergang von Live-TV nach Medienwiedergabe ein Timeshift-Close (oder auch andere Übergänge, wo halt Live-TV und somit Timeshift abgeschaltet werden, sprich, nur auf Medienwiedergabe zu prüfen ist IMHO zu wenig) und logischerweise kein Timeshift-Open mehr. Mein Vorschlag ist, dass wenn auf Timeshift-Close ein paar Sekunden lang kein Timeshift-Open folgt, das Plugin den Timeshift-Speicher freigibt, und nur dann, nicht bei jedem Umschalten bzw. jedem Timeshift-Close. Bei mir kostet das definitiv was. Man merkt es recht gut, wenn man über die DVBViewer-UI-Kanalliste umschaltet. Da hängt dann der DVBViewer bei jedem Schaltvorgang ca. 3 Sekunden und dieser Kringel (ehemals Sanduhr) wird in dieser Zeit eingeblendet.

Edited November 16, 2009 by CiNcH

[erwin]

Gut. Problem verstanden.

Ich versuch aber erstmal dieser langen Allokationszeit auf die Spur zu kommen. Wieviel forderst Du denn an und wieviel RAM hast Du? Hintergrund: Ausgehend von der Anforderung wird versucht diese zu erfüllen, wenn dies nicht gelingt wirds mit 4KB weniger versucht usw usf. Wenn Du also 5000 anforderst und nur 1000 MiB hast, gibst einen Haufen Fehlversuche. Vielleicht bringt es hier schon was die Anforderungsgröße näher an die tatsächliche RAM-Ausstattung zu setzen.

 

mfg erwin

[CiNcH]

Nein, ich fordere prinzipiell nicht zu viel an, bzw. so viel, dass noch ca. 20% vom RAM frei sind. Ich habe 2GB drin und habe im Plugin 1GB eingestellt.

 

Ich werde am Abend noch probieren, was passiert, wenn ich HISTORY aktiviere und somit nicht neu allokiert wird. Bis jetzt habe ich nur mit und ohne Plugin probiert, und das Plugin war definitiv für die "Glitches" bei Kanalumschaltung verantwortlich. Unter XP hatte ich damit gar keine Probleme. System und Einstellungen sind bis auf das Betriebssystem dieselben.

[CiNcH]

Das Deaktivieren von 'release buffer on timeshift stop' bringt wie bereits vermutet Besserung und eliminiert die Hänger beim Umschalten. Ist für mich wegen HISTORY aber leider keine Lösung. Bzw. ganz gelöst ist es noch nicht, denn beim Starten des DVBViewer muss das Plugin natürlich den Speicher allokieren und da bleibt das Bild oft hängen. Irgendwann verursacht der DVBSource dann einen Buffer-Overflow und für einen Stop/Run-Graph durch, anschließend wandelt sich dann das Standbild in Video um .

Edited November 16, 2009 by CiNcH

[erwin]

... und da bleibt das Bild oft hängen. Irgendwann verursacht der DVBSource dann einen Buffer-Overflow und für einen Stop/Run-Graph durch, anschließend wandelt sich dann das Standbild in Video um .

Das ist ja nun wirklich echt grausig! Ich muß nun mal versuchen irgendwo eine Windows 7 x86 Umgebung zu finden. Läuft bei Dir DVBV als normale x86 Anwendung oder in diesem virtuellen XP-Mode? Wie gesagt unter Windows 7 x64 hatte ich nichts dergleichen bemerkt.

 

mfg erwin

[CiNcH]

Das dürfte als normale x86 Anwendung laufen, sofern das die Default-Methode ist. Ich habe jedenfalls nichts spezielles eingestellt.

Edited November 17, 2009 by CiNcH

[erwin]

So, ich kanns nun reproduzieren. Die CPU-Auslastung geht aus irgendeinem Grund auf 100%.

 

 

mfg erwin

[erwin]

Bzw. ganz gelöst ist es noch nicht, denn beim Starten des DVBViewer muss das Plugin natürlich den Speicher allokieren und da bleibt das Bild oft hängen.

Hast Du dies nun beobachtet oder geschlussfolgert? Meine Erkenntnisse bisher: Die 100% CPU-Auslastung werden NICHT beim Allokieren erreicht, sondern beim Freigeben des Speichers. Starte mal Timeshift manuell. Hier gibs nur einen kleinen Peak. Beende Timeshift manuell (nicht umschalten), und ich habe über einige Sekunden 100%. Wenn ich anstatt RAM virtuellen Speicher verwende, habe ich diese Effekte nicht. Meine Vermutung geht in die Richtung "Fault tolerant Heap - FTH" - ein neues Feature von Win7 welches zur Runtime den Heap überwacht.

 

mfg erwin

[CiNcH]

Hast Du dies nun beobachtet oder geschlussfolgert?

Nein, das habe ich beobachtet und nicht geschlussfolgert. Ich werde das bei Gelegenheit nach deinen Vorgaben prüfen.

[CiNcH]

So, hier noch ein paar Tests von mir...

 

 

Wie man sehen kann, sind die Spikes beim Allokieren und Deallokieren nicht so extrem, wenn ich manuell Timeshift starte und stoppe.

 

 

Folgender Screenshot zeigt die Auslastung beim Umschalten, wenn automatisches Timeshift aktiv ist...

 

 

Wie man sehen kann, sind es 4 Schaltvorgänge. Die Auslastung ist da kurzzeitig 100%.

Was man nicht sehen kann ist, dass beim Starten vom DVBViewer das Bild hängen blieb und es erst nach durch Buffer-Overflow getriggertem Stop/Run-Graph wieder weiterlief (passiert ca. in 30% der DVBViewer-Starts bei mir, würde ich jetzt so aus dem Bauch heraus sagen). Der Spike beim Starten vom DVBViewer sieht aber nicht wirklich dramatisch aus!?

Auch interessant finde ich, dass da scheinbar nicht bei jedem Schaltvorgang gleich viel deallokiert wird . Memory Leaks?

Edited November 17, 2009 by CiNcH

[erwin]

Da sich hier eine XP/Win7-Diskrepanz aufzeigt, die auch unabhängig vom TimeshiftPlus-Plugin von Interesse sein dürfte, stelle ich mal hier mal meine Erkenntnisse dar, die sich weitgehend mit denen von CiNcH decken. THX!

 

Bilder vom Resourcenmonitor

 

 

 

Ablauf:

Manueller Timeshift Start (TimeshiftPlus-Plugin aktiv, 1GB RAM-Request): Man sieht in der blauen Kurve den Anstieg des verwendeten Arbeitspeichers und unter 1) einen moderaten Peak bei der CPU-Auslastung.

 

Stoppen Timeshift: Unter 2) sieht man die CPU-Auslastung auf fast 100%, die mehrere Sekunden (über 10 Sek.) anhält und das obwohl die Freigabe längst vollzogen ist (blaue Kurve) .

 

Wieder manueller Timeshift Start: siehe oben.

 

Schneller Wechsel Timeshift-Stop/Start: Verhalten wie oben. Man sieht aber an der abgeflachten blauen Kurve unter 4) wie die CPU-Auslastung den Speicherrequest deutlich ausbremst.

 

Hier noch mal ein Schnappschuss im Moment der 100% CPU-Auslastung nach dem Timeshift-Stop.

 

 

"NT Kernel & System" mit 45% über mehrere Sekunden. Wow!

 

Jetzt noch mal zum Vergleich dieselbe Timeshift.dll/RingBuffer.exe unter XP:

 

 

Blau ist hier der Prozessor, rot die _verfügbaren_ MB's (geht deshalb nach unten).

Selber Ablauf wie oben. Man sieht am ersten "Free" - nur 55%. Und unter 1) (der Schnelle Wechsel Stop/Start) dass der neue Request NICHT ausgebremst wird (Flankensteilheit).

 

MICROSOFT WAS IST HIER LOS?

 

 

Was man nicht sehen kann ist, dass beim Starten vom DVBViewer das Bild hängen blieb und es erst nach durch Buffer-Overflow getriggertem Stop/Run-Graph wieder weiterlief (passiert ca. in 30% der DVBViewer-Starts bei mir, würde ich jetzt so aus dem Bauch heraus sagen).

Könnte durchaus ein anderen Grund haben, denn Dein erster Shoot, wie auch meine zeigen keinen dramatischen Anstieg der Auslastung beim Request.

 

Auch interessant finde ich, dass da scheinbar nicht bei jedem Schaltvorgang gleich viel deallokiert wird .

In Anbetracht der Beobachtungen will ich das nicht unbedingt schlußfolgern. Was macht hier z.B. der DVBV beim Kanalwechsel?

 

mfg erwin

Edited November 18, 2009 by erwin

[erwin]

Zusatz: Bei Verwendung von virtuellem Speicher sieht alles ganz smooth aus. Also das eigentliche "Free" ist es nicht. Bleibt noch das "VirtualUnlock" - also das Entsperren des Physischen RAM's -was bei mir im Quelltext den Unterschied ausmacht.

 

erwin

Edited November 18, 2009 by erwin

[CiNcH]

Ich verwende hier übrigens den DVBViewer (Recording) Service als Streamquelle und nicht direkt die physikalische Hardware. Evtl. gibt es da Timing-Probleme beim Starten (aber ein Standbild bekomm ich, d.h. die Daten sind irgendwie da und wie gesagt passiert es nicht immer), auch wenn ich unter XP diesbezüglich nie Probleme hatte.

 

Auch werde ich mir einmal die virtuelle Methode bei mir anschauen.

Edited November 18, 2009 by CiNcH

[erwin]

Ich verwende hier übrigens den DVBViewer (Recording) Service als Streamquelle und nicht direkt die physikalische Hardware. Evtl. gibt es da Timing-Probleme beim Starten, auch wenn ich unter XP diesbezüglich nie Probleme hatte.

Bis Du sicher dass das "Buffer-Overflow getriggerte Stop/Run-Graph" nicht auch unter XP passiert ist? Denn das führt auch zu Stop/Start Timeshift mit den hier geschilderten Problemen unter Win 7. Dort unter XP sind die Folgen auf Grund der performanteren Freigabe nur nicht so aufgefallen?

 

erwin

[CiNcH]

Ein Einfrieren des Bildes mit anschließendem Stop/Run wäre mir bestimmt aufgefallen . Mit der performanteren Freigabe hat das IMHO nichts zu tun, was ja erst bei Stop/Run durchgeführt wird. Das Problem äußert sich aber bereits davor, wo sich wohl die Puffer im DVBSource füllen, der Graph aber scheinbar nicht damit gefüttert wird (Bild friert ein, aber wenn ich mich recht entsinne, lief Audio weiter muss ich wohl nochmal untersuchen) bis die Puffer halt überlaufen und Stop/Run getriggert wird.

[erwin]

Das Problem äußert sich aber bereits davor, wo sich wohl die Puffer im DVBSource füllen, der Graph aber scheinbar nicht damit gefüttert wird (Bild friert ein, aber wenn ich mich recht entsinne, lief Audio weiter muss ich wohl nochmal untersuchen) bis die Puffer halt überlaufen und Stop/Run getriggert wird.

Das hat jetzt aber mit TimeshiftPlus nichts zu tun, oder ist bei nicht aktivem TimeshiftPlus anders?

Ab Stop/Run ist dann auch TimeshiftPlus involviert mit der Folge das schneller Stop/Start-Wechsel die gezeigten negativen Auswirkungen hat.

 

erwin

Edited November 18, 2009 by erwin

[CiNcH]

Das hat jetzt aber mit TimeshiftPlus nichts zu tun, oder?

Naja, würde ich schon sagen, wenn das nur dann passiert, wenn permanentes Timeshift aktiv ist und sich das TimeshiftPlus-Plugin im Plugins-Ordner befindet .

 

Ab Stop/Run ist dann auch TimeshiftPlus involviert mit der Folge das schneller Stop/Start-Wechsel die gezeigten negativen Auswirkungen hat.

Ja, aber mit Windows XP hatte ich beim Start nie Stop/Run durch Buffer-Overflow.

[erwin]

Na dann werde ich mal den Recording Service aufsetzen.

 

erwin

[CiNcH]

Musst du nicht. Ich werde diesen Fall erst bei mir ausschließen. Wahrscheinlich ist das gar nicht das Problem. Recording Service, DVBViewer-Client mit TimeshiftPlus und XP waren bei mir auch nie ein Problem... Service und Client laufen bei mir übrigens auf demselben Rechner, also nicht über ein physikalisches Netzwerk verbunden.

Edited November 18, 2009 by CiNcH

[CiNcH]

Wieder ein paar Erkenntnisse:

 

- Der Recording Service hat mit der Sache NICHTS zu tun.

 

- Hier mal ein Screenshot, was beim Starten des DVBViewer im DVBSource im Buffer-Overflow-Fall _vorher_ passiert:

 

 

Video steht still und wie man sieht, laufen die Video-Puffer voll bis zum Überlauf schlussendlich. Audio läuft ganz normal.

 

- Die virtuelle Methode scheint die "Lösung" zu sein, weil da im physikalischen RAM erstmal nichts allokiert wird. Sowohl die Umschaltvorgänge als auch die DVBViewer-Startvorgänge sind sauber. Die Probleme hängen definitiv zusammen.

 

Lösung deshalb unter Anführungszeichen, weil der RAM mit der Zeit vollläuft, wenn tatsächlich TS-Daten geschrieben werden. Wenn man also lange auf einem Kanal schaut und der Puffer einmal vollgeschrieben wurde, befindet der sich wohl vollständig im RAM und das Deallokieren dürfte dann nicht so problemlos ablaufen... Das ist jetzt aber nur eine Einschätzung meinerseits, keine Beobachtung..

 

 

Optimal wäre entweder...

 

- kein Neuallokieren bei Kanalwechsel (aber ohne History ) zusammen mit der virtuellen Methode, weil dann beim Starten vom DVBViewer nicht direkt der RAM allokiert wird, wodurch der DVBViewer nicht stecken bleibt

 

oder...

 

- File

Edited November 18, 2009 by CiNcH

[erwin]

Leider kann ich das Problem noch nicht reproduzieren. Hast Du mal mit den Videodekodern gespielt? Welchen hast Du eingestellt? Zusammenhang mit dem Plugin? Weiß nicht, vielleicht fordert der Decoder auch RAM an und es kommt zu Kollisionen?

 

erwin

[CiNcH]

Welchen hast Du eingestellt?

Ich verwende die CyberLink-Dekoder, die mit TerraTec kommen, weil die relativ aktuell sind. Die haben unter XP immer wunderbar funktioniert und funktionieren auch jetzt unter W7 mit DXVA 2.0 problemlos.

 

Zusammenhang mit dem Plugin?

Wie meinen? Fakt ist, Plugin drin.. Probleme, Plugin raus.. keine Probleme . Und wie gesagt, das Hängenbleiben beim Start passiert nur in ca. 30% der Starts.

 

Ich habe übrigens im DVBSource eine Latency von 200ms eingestellt (Default ist 350ms). Evtl. macht das den Unterschied bei uns!? War aber auch unter XP schon so und da gab es wie gesagt keine Probleme.

Edited November 19, 2009 by CiNcH

[erwin]

Wie meinen?

Naja ich sehe im Moment keinen offentsichtlichen Zusammenhang (außer der RAM-Vermutung) warum der Videodekoder ohne das Plugin sauber funktioniert, mit aber _nicht aus dem Knick kommt_. Das unter Win7 das Management mit gelocktem RAM anders als unter XP funktioniert, haben wir ja schon festgestellt.

 

Ich habe übrigens im DVBSource eine Latency von 200ms eingestellt (Default ist 350ms). Evtl. macht das den Unterschied bei uns!? War aber auch unter XP schon so und da gab es wie gesagt keine Probleme.

Deine DVBSource-Einstellungen habe ich schon übernommen.

 

erwin

[CiNcH]

Naja ich sehe im Moment keinen offentsichtlichen Zusammenhang (außer der RAM-Vermutung) warum der Videodekoder ohne das Plugin sauber funktioniert, mit aber _nicht aus dem Knick kommt_. Das unter Win7 das Management mit gelocktem RAM anders als unter XP funktioniert, haben wir ja schon festgestellt.

Hängt evtl. aber mit dem Video-Renderer zusammen. Ich verwende die aktuelle DVBViewer-Beta mit EVR Custom Presenter unter W7. Normalerweise pullt der ja die Daten. Aber im Streaming-Fall müsste eigentlich der Source-Filter (DVBSource) pushen..

 

Unter XP habe ich VMR Custom Presenter verwendet, da gab es keine Probleme, hat aber auch ganz ein anderes Frame-Scheduling als EVR CP.

Edited November 19, 2009 by CiNcH

[erwin]

Ja, oder möglicherweise der Renderer. Da Du gesagt hast, nur in ca. 30% der Fälle (ich gehe mal vom selben Sender aus) ist meine Arbeitshypothese momentan eine zeitliche Koinzidenz: Init Decoder/Renderer und Speicheranforderung durch das Plugin. Einstellen des WorkingSets, Speicheranforderung und letzlich das Locken des Speichers im RAM sind bei mir keine atomare Transaktion (weiß gar nicht ob das überhaupt geht). Wenn hier die Dekoder/Renderer ähnliches zur selben Zeit machen.. Wer weiß?

Übrigens, ist das bloße Vorhandensein des Plugins schädlich oder der automatische Start von Timeshift? Man könnte um die obige Hypothese zu testen mal verzögert Timeshift starten (manuell).

 

erwin