Jump to content

TimeshiftPlus Plugin, erweiterte Timeshift Funktionalität (Ringpuffer)


erwin

Recommended Posts

hmm, dann wäre die möglichkeit interessant daß der ringpuffer deaktiviert wird wenn man auf pause drückt bzw der ringbuffer automatisch vergrößert wird. dann müsste man aber den ringbuffer früher oder später auf die festplatte schreiben

 

Könnte man machen. Pause bewirkt Rückkehr in den normalen Timeshift-Modus. Ich werd mal drüber nachdenken. Ich verstehe Dein Problem. Bisher waren gepauste Sendungen sicher noch vorhanden. Jetzt könnten sie überschrieben werden. Momentan verfolge ich allerdings einen anderen Ansatz. Unter Nutzung von virtuellem Speicher möchte ich Ringpuffer-Zykluszeiten von mehreren Stunden ermöglichen, was dann Dein Problem relativiert. Hintergrund sind die Datenmengen die bei HD anfallen.

 

Noch ein Tip: (die native DVBViewer-) PAUSE kann auch nachgebildet werden (nicht ganz, ich weiss) durch Sofortaufnahme plus Sofort Abspielen bei Beenden derselben.

 

mfg erwin

Link to comment
Das Plugin kann nicht mit Bestimmtheit unterscheiden ob eine beginnende Aufnahme einer .mpg/.ts-Datei durch einen regulären Timer verursacht wird oder durch eine Sofortaufname.
Zumindest im COM Interface gibt es da was bei ITimerItem > Instant.
Link to comment

Danke für den Hinweis mit dem ActionID-Remapping, funktioniert super, ich remappe jetzt je nach Kontext (OSD, TimeShift usw.)..

 

Also das Plugin scheint nun tauglich für den Pruktiveinsatz zu sein. Mit SlowMotion habe ich im Moment noch Problem. Ich habe einen 1 GB Puffer gefüllt und bin dann in die Mitte gesprungen und habe SlowMotion gestartet. Unabhängig von der gewählten Geschwindigkeit bricht die Wiedergabe nach kurzer Zeit ab, obwohl das logische Pufferende noch lange nicht erreicht ist.

 

slomo.jpg

 

Wenn ich nun 2 DVB-Geräte habe und auf Gerät 1 eine Aufnahme starte und dann umschalte, wird für den nun gesetzten Kanal das 2. DVB-Gerät verwendet. Ich nehme an, dass für weitere parallel laufende Geräte das TimeshiftPlus-Plugin dann nicht aktiv ist? Das holt sich die Plugins ja aus dem Verzeichnis Plugins\Plugins1, wenn ich das richtig sehe...

Edited by CiNcH
Link to comment

Die hauptwiedergabe nutzt IMMER \plugins. Aufnahmen und PiP nutzen IMMER \plugins\plugins1 .. \plugins\plugins32, die zuteilung erfolgt dynamisch (wenn vorhanden).

Mein Tipp: finger weg davon, ansonsten hast Du plötzlich 5 aufnahmen und jede fordert 3 GB an speicher an für timeshift :)

 

Wäre 'nen versuch wert, wenn man ein Windows system spektakulär in die knie gehen sehen will :blush::D

Link to comment

Also ich starte die Sofortaufnahme, wenn ich dann umschalte, bekommt der neue Kanal mit der anderen Karte das TimeshiftPlus-Plugin. Fatal wäre dann, wenn die Sofortaufnahme aus dem Puffer laufen würde. Bei Mehrkartenbetrieb ist die Sofortaufnahme aus dem Puffer also nicht empfehlenswert.

Link to comment

Ja, genau. Das gleiche würde auch beim "ein karten" betrieb passieren, wenn das Plugin keine vorkehrungen für solche fälle trifft (und das wird dann richtig kompliziert).

 

Was mir noch an begehrlichkeiten einfällt, die aufkommen werden: teletext (subtitel) und DVBSubtitel. Ohne sowas wäre das ganze für unsere finnischen, dänischen, schwedischen, chinesischen und und und... freunde nicht zu gebrauchen.

Link to comment
Mit SlowMotion habe ich im Moment noch Problem. Ich habe einen 1 GB Puffer gefüllt und bin dann in die Mitte gesprungen und habe SlowMotion gestartet. Unabhängig von der gewählten Geschwindigkeit bricht die Wiedergabe nach kurzer Zeit ab, obwohl das logische Pufferende noch lange nicht erreicht ist.

Die Größe des SlowMotion-Puffers ist z.Z von mir bewußt begrenzt. Längeres SlowMotion schauen scheint mir ja auch nicht normal und forciert die befürchteten Auffahrprobleme von Write-/Readpointer nur. Über die konkrete Auslegung der Puffergröße muß natürlich noch nachgedacht werden. Du meinst, derzeit zu klein?

 

Ja, genau. Das gleiche würde auch beim "ein karten" betrieb passieren, wenn das Plugin keine vorkehrungen für solche fälle trifft (und das wird dann richtig kompliziert).

Ja in der Tat. Zur Zeit wird die rückwirkende Aufnahme ab Pufferposition vollständig aus dem Ringpuffer realisiert. Jegliches deaktivieren/resetten von Timeshift (und damit des Ringpuffers) während einer Sofortaufnahme führt zumindest zum Abbruch der Aufzeichnung. Mal schauen was sich machen läßt.

 

Was mir noch an begehrlichkeiten einfällt, die aufkommen werden: teletext (subtitel) und DVBSubtitel. Ohne sowas wäre das ganze für unsere finnischen, dänischen, schwedischen, chinesischen und und und... freunde nicht zu gebrauchen.

An was man alles denken muß! Habe dies am Wochenende allerdings realisiert/gefixed.

 

@Lars_MQ/Griga/sonstige Kundige

Gibt es eine Möglichkeit (COM?) für das Plugin festzustellen ob sich Timeshift im Realtime-Modus (Slider rechts am Anschlag) befindet??

 

mfg erwin

Link to comment
Gibt es eine Möglichkeit (COM?) für das Plugin festzustellen ob sich Timeshift im Realtime-Modus (Slider rechts am Anschlag) befindet??
Wenn ich das mir mit DVBViewer Spy (Mitgliederbereich) angucke müsste das über das COM Interface mit #TV.Timeshift.remain gehen, das gibt den Zeitversatz bei Timeshift an.
Link to comment
Wenn ich das mir mit DVBViewer Spy (Mitgliederbereich) angucke müsste das über das COM Interface mit #TV.Timeshift.remain gehen, das gibt den Zeitversatz bei Timeshift an.

Da Dein letzter Tip bezüglich INSTANT sehr fruchtbar war (das Plugin kann nun auf die erwähnte Kontrollabfrage verzichten) gehe ich mal ungeprüft davon aus, dass Du auch diesmal mir weitergeholfen hast. Danke!

 

mfg erwin

Link to comment
  • 3 weeks later...

Irgendwas versteh ich noch nicht. Irgendwann stimmt der Slider-Bereich einfach nicht mehr, logischer Anfang entspricht nicht mehr der Slider-Position ganz links und wenn ich nur ein paar Sekunden zurück will, bin ich plötzlich ganz wo anders. Das passiert wohl, wenn der Puffer einmal voll war und wieder am Anfang geschrieben wird, dann passt der Slider wohl nicht mehr? Wird der Slider-Bereich dann nicht mehr 1:1 auf die zeitliche Videoabfolge abgebildet?

Link to comment
Das passiert wohl, wenn der Puffer einmal voll war und wieder am Anfang geschrieben wird, dann passt der Slider wohl nicht mehr? Wird der Slider-Bereich dann nicht mehr 1:1 auf die zeitliche Videoabfolge abgebildet?

Doch eigentlich schon. Slider ganz links entspricht logischem Anfang (abzüglich des Dummy-Bereiches). Dies ist der älteste aufgezeichnete Zeitpunkt und die Stelle die als erstes wieder verloren geht. Davon noch einige Sekunden zurück geht eigentlich gar nicht. Wenn doch dann ist es wohl ein Bug. Kann sich evt. eingeschlichen haben als ich den Buffer von 1-Chunk auf 2-Chunk verschlimmbessert habe. Werde übers WE mal eine Auge drauf haben. Du hörst von mir.

 

mfg erwin

Link to comment
Davon noch einige Sekunden zurück geht eigentlich gar nicht.

Das waren 2 getrennte Aussagen von mir:

 

-> logischer Anfang ist irgendwann nicht mehr Slider-Position ganz links

-> wenn ich aus Live-Position ein paar Sekunden zurückspringen will, bin ich ebenfalls ganz wo anders, aber halt nicht die paar Sekunden vor Live

 

Das ganze scheint dann nicht mehr zu stimmen, sobald der Puffer einmal voll ist, da kommt dann was durcheinander.

Edited by CiNcH
Link to comment
Das ganze scheint dann nicht mehr zu stimmen, wenn der Puffer einmal voll war, da kommt dann was durcheinander.

Na, ja das hab ich bei einem RINGPUFFER bestimmt als erstes getestet ;-). Wie ist denn Deine Puffergröße und wie lange lief damit das Ding schon? In etwa. Datenrate bzw. Kanal wäre auch gut zu wissen.

 

mfg erwin

Edited by erwin
Link to comment

Puffergröße: 1024 MB

Dummy: 1024 KB

 

Auf RTL (Datenrate weiß ich jetzt spontan nicht auswendig) war mir das als erstes aufgefallen, weil ich da eben mal ein paar Sekunden zurückspringen wollte, das war denn irgendwo bei Slider ganz links. Und der Slider-Abschnitt kurz vor live war weiter in der Vergangenheit, eben nicht kurz vor live. Ich habe es dann mit ORF 1 HD (10-12 Mbit/s) probiert und da dasselbe festgestellt.

 

Keine Ahnung wie lange das da lief, aber beim ORF 1 HD Test habe ich dann ausgerechnet wie lange es dauern dürfte, bis der Puffer einmal voll war. Kann auch sein, dass er schon 2 mal komplett gefüllt wurde.

Edited by CiNcH
Link to comment

Und wie lange lief es schon? Mit diesen Werten könnte man etwa abschätzen wie viele rounds der Puffer schon gemacht hat.

 

HD hatte ich mangels Testmöglichkeit erstmal ausgeschlossen. Seit vorgestern bin ich Besitzer einer S2-Karte. Freut mich zu hören das es doch zumindest prinzipiell geht. Noch ne Frage - XP, Vista? Ich habe bisher nur unter XP getestet.

 

mfg erwin

Link to comment

Sorry, hatte ich im letzten Posting erst vergessen und dann nacheditiert.

 

Keine Ahnung wie lange das da lief, aber beim ORF 1 HD Test habe ich dann ausgerechnet wie lange es dauern dürfte, bis der Puffer einmal voll war. Kann auch sein, dass er schon 2 mal komplett gefüllt wurde. Muss ich mir auch nochmal genauer anschauen...

 

Ich nutze XP.

Edited by CiNcH
Link to comment

Hier nochmal ein paar Infos:

 

ORF 1 HD: 10-12 Mbit/s

Ringpuffer: 1024 MB (1017 MB allocated)

Dummy: 1024 KB

 

-> ~12 Minuten Ringpuffer (mit 11 Mbit/s kalkuliert)

 

Ich habe dann alle 2 Minuten gecheckt, ob der Sliderbereich mit der zeitlichen A/V-Abfolge übereinstimmt. Ab der 2. Runde (ca. 24 Minuten) wirds krumm, dann ist der zeitliche Bereich vor live plötzlich ganz links vom Slider-Bereich.

Edited by CiNcH
Link to comment
Puffergröße: 1024 MB

Dummy: 1024 KB

 

Hier liegt der Hase im Pfeffer. Hatte ich nicht genug kommuniziert. Der Dummybereich ist Teil des Gesamtpuffers. Sind diese wie bei Dir gleich verbleibt 1024-1024=0. Hier noch eine (noch) nicht ausprogrammierte Fehlerbehandlung und schon knallt es. Wenn Du dem Puffer insgesamt 2GB spendieren willst nimm Puffergröße: 2048 MB. Allerdings Dummy: 1024 bewirkt auf Grund eines anderen Bugs auch nicht so ganz das Angestrebte. Bei SD fahre ich mit 64KB ganz gut. Soviel auf die Schnelle. Morgen gibts eine korrigierte Version.

 

mfg erwi

Link to comment
Hier liegt der Hase im Pfeffer. Hatte ich nicht genug kommuniziert. Der Dummybereich ist Teil des Gesamtpuffers. Sind diese wie bei Dir gleich verbleibt 1024-1024=0.

Hm? 1024 MB - 1024 KB ergibt doch nicht 0 :D .

 

Bei diesem Dummy fehlt mir noch so ein bisschen das Gefühl dafür, welche Größe Sinn macht, sprich ein Beispiel unter welchen Bedingungen (Annahme Datenratenänderung zu einem bestimmten Zeitpunkt mit bestimmter Puffer- und Dummygröße) es wann zu einer Kollision kommt. Hast du da ein Rechenmodell parat?

Edited by CiNcH
Link to comment

Ja rechnen müßte ich können ;-)

 

Ich habe eine neue Version bereitgestellt. Denke ist nun gefixed.

 

Mit der Größe des Dummybereiches habe ich noch keine größeren Versuche gemacht was optimal ist. Bei SD fahre ich mit 64KB was wenn man den Slider ganz links läßt doch ab und zu zu den Rucklern führt. Aber die wollte ich ja erstmal im Auge behalten. Da ja im "Einkanal-Betrieb" ("empty buffer on channel change") auch HD funktioniert, ist aufgrund der größeren Varianz der Datenrate sicher ein größerer Wert, z.B Deine 1024KB, angemessen. Auf meiner TODO-Liste steht eine Dynamisierung dieser Größe duch monitoring der Daterate. Aber ich werde wahrscheinlich als Zwischenschritt erstmal die Eingabe zweier Werte - SD + HD - getrennt einbauen.

 

 

mfg erwin

Edited by erwin
Link to comment
Ich habe eine neue Version bereitgestellt. Denke ist nun gefixed.

 

gefixed ? - ja aber auf Kosten der Performance, insbesondere wenn nur wenige Sekunden zurück gesprungen wird.

 

Bitte nicht wundern. Neue Version folgt.

 

mfg erwin

Link to comment
Könnte man machen. Pause bewirkt Rückkehr in den normalen Timeshift-Modus. Ich werd mal drüber nachdenken. Ich verstehe Dein Problem. Bisher waren gepauste Sendungen sicher noch vorhanden. Jetzt könnten sie überschrieben werden. Momentan verfolge ich allerdings einen anderen Ansatz. Unter Nutzung von virtuellem Speicher möchte ich Ringpuffer-Zykluszeiten von mehreren Stunden ermöglichen, was dann Dein Problem relativiert. Hintergrund sind die Datenmengen die bei HD anfallen.

Ich würde das auch nochmal gerne zur Diskussion stellen. Virtueller Speicher ist ja physikalischer Speicher (RAM) + Swap Bereich. Wenn ich nun also einen recht großen Ringpuffer definiere, wie erfolgt dann die Aufteilung auf RAM und Swap? Wenn da nämlich das RAM zugepflastert wird, ist das nicht optimal, da sollten schon noch etwas Reserven für diverse Tasks vorhanden sein, damit auch die Systemantwortzeiten noch erträglich sind. Was spricht gegen HDD-Ringpuffer? Lange Umschaltzeiten?

 

Kann man auch den "DVB-Live Modus" erkennen? Es ist etwas unangenehm, wenn auch bei Dateiwiedergabe usw. die Speicherbereiche immer allokiert sind.

 

Kann man die Aufnahme ab Pufferposition für Instant nun eigentlich verwenden?

Edited by CiNcH
Link to comment
Virtueller Speicher ist ja physikalischer Speicher (RAM) + Swap Bereich. Wenn ich nun also einen recht großen Ringpuffer definiere, wie erfolgt dann die Aufteilung auf RAM und Swap?

In der Option "physikalisch" versucht das Programm möglichst viel Memory (bis zur angegebenen Maximalgröße) ausschließlich im RAM zu allokieren (SET_QUOTA-Rechte vorausgesetzt). Hier kann ich in der Tat den RAM zuplastern und das System lahm legen wenn ich allzuviel anfordere.

 

In der Option "virtuell" wird die Speicherzuzweisung und damit auch die Aufteilung RAM/Pagefile ausschließlich dem System überlassen. Im Plugindialog kann man gut erkennen dass sich das System einen großen Teil des RAM freihält.

 

Was spricht gegen HDD-Ringpuffer?

Die ist im Grunde der virtuelle mode.

 

Kann man auch den "DVB-Live Modus" erkennen?

Du meinst ob das Plugin darüber informiert ist? Ja, THX@Tjod.

 

Es ist etwas unangenehm, wenn auch bei Dateiwiedergabe usw. die Speicherbereiche immer allokiert sind.

Verstehe ich jetzt nicht ganz. Richtig ist dass z.Z keine Speicherfreigabe bei Wechsel in den Nicht-DVB-Modus erfolgt.

 

mfg erwin

Link to comment
In der Option "virtuell" wird die Speicherzuzweisung und damit auch die Aufteilung RAM/Pagefile ausschließlich dem System überlassen. Im Plugindialog kann man gut erkennen dass sich das System einen großen Teil des RAM freihält.

Muss ich mal beobachten, Swap ist ja unter Windows das Pagefile, oder? Ist dieses dynamisch? Wie groß sind die Performanceeinbrüche bei richtig großer Speicherallokation?

 

Kann man auch den "DVB-Live Modus" erkennen?
Du meinst ob das Plugin darüber informiert ist? Ja, THX@Tjod.

Ich meine damit jetzt nicht Pufferposition ganz rechts, sondern die Unterscheidung, ob DVB oder nicht (DVD/File/usw).

 

Richtig ist dass z.Z keine Speicherfreigabe bei Wechsel in den Nicht-DVB-Modus erfolgt.

Genau darauf wollte ich hinaus.

Edited by CiNcH
Link to comment
Muss ich mal beobachten, Swap ist ja unter Windows das Pagefile, oder? Ist dieses dynamisch?

Ob feste Größe oder dynamisch ist unter Systemsteuerung/System/Erweiter/Erweitert.. einstellbar.

 

Wie groß sind die Performanceeinbrüche bei richtig großer Speicherallokation?

Ausprobieren. Ich habe bisher nichts Signifikanntes festgestellt.

 

Ich meine damit jetzt nicht Pufferposition ganz rechts, sondern die Unterscheidung, ob DVB oder nicht (DVD/File/usw).

Genau darauf wollte ich hinaus.

Schau ich mir mal an.

 

mfg erwin

Link to comment

... weil davon gesprochen wurde, einen kompletten HD-Film im Ringpuffer unterzubringen...

 

15 Mbit/s à 2 Stunden sind über 13 GB. d.h. riesiges Pagefile wird benötigt..

 

Weiteres Problem: Wenn ich auf Pause drücke und es in diesen 2 Stunden nicht zurück schaffe, verlier ich den Anfang (bis hin zu alles o:) ). Ein Fallback auf DVBViewer-Timeshift (bei Druck auf Pause, kann dieser Event überhaupt abgefangen werden?) könnte hilfreich sein. Oder man startet in solchen Fällen als Alternative die Aufnahme und beginnt die Wiedergabe, wenn man zurückkommt.

Edited by CiNcH
Link to comment
... weil davon gesprochen wurde, einen kompletten HD-Film im Ringpuffer unterzubringen...

Nein, dies war ein Mißverständnis. Mit mehreren Stunden meinte ich SD. HD war zum Zeitpunkt der Äußerung für mich noch eine Zukunftsoption. War mir aber dessen bewußt dass ich große Puffer brauchen würde, was im Falle SD eben mehrere Stunden ergäbe.

 

SD oder HD egal jetzt. Solch große Puffer gedenke ich durch mehrere Instanzen von RingBuffer.exe (jede bringt 2-3 GB an Adressraum) und deren interne Verkoppelung zu erreichen. Dazu müßte "nur" das Paging-File groß genug angelegt werden. Und hier fehlt mir im Moment etwas an Grundlagenwisssen/Grunderfahrung. Kann man solch große Pagingfiles überhaupt anlegen ohne massive Performanceverluste des (Rest-)Systems zu riskieren. Immerhin wird empfohlen ca 2-3 fache RAM-Größe. Sonst droht Thrashing.

 

Bezüglich des Pause-Problems habe ich bisher noch keine tieferen Versuche unternommen. Sollte aber lösbar sein. Ein par Anregungen hast Du ja schon gegeben.

 

 

mfg erwinbn

Link to comment

Upps, fällt mir gerade auf:

 

erwin

DVBViewer Junkie

 

Wie bin ich denn zu dieser Klasssifizierung gekommen? Hoffentlich bedeutet dies nichts übles ;-)

 

mfg erwin

Link to comment
Muss ich mal beobachten

post-2941-1238501480_thumb.png

 

So arbeite ich z.Z. (ohne Performanceeinbrüche), d.h. ca. 3 GB allocated (das reicht auch bei HD für ne Weile, immerhin ) aber RAM-use nur 45%.

 

mfg erwin

Link to comment

Hast du nun eigentlich diese 'Aufnahme aus Puffer' Sache mit reingezogen? Wenn ich das richtig verstanden habe, läuft das so:

 

Aufnahme kann nur bei Sofortaufnahme über den Timeshift-Puffer erfolgen (wenn ITimerItem > Instant). Time-Aufnahmen handelt der DVBViewer immer selber. DVBViewer Aufnahme-Optionen wie 'Adjust PAT/PMT' im DVBViewer sind bei Sofortaufnahme aus Puffer wirkungslos.

 

Wenn sich der DVBViewer im 'Live-Betrieb' befindet (#TV.Timeshift.remain = 0), wird immer die native DVBViewer-Aufnahme verwendet (somit kann auch problemlos ein Gerätewechsel während der Aufnahme vollzogen werden, welches dann das Timeshift-Plugin und den Puffer bekommt, die Aufnahme läuft auf dem anderen Gerät problemlos über den DVBViewer weiter).

 

Dann braucht man nur noch zu wissen, dass wenn man aus dem Puffer heraus aufzeichnet (mit den Bedingungen nicht live und Sofortaufnahme gestartet), besser nicht umschaltet und so einen Gerätewechsel provoziert, weil das neue Gerät dann das Timeshift-Plugin samt Puffer bekommt.

Edited by CiNcH
Link to comment
Hast du nun eigentlich diese 'Aufnahme aus Puffer' Sache mit reingezogen?

Noch nicht. Macht aber Fortschritte. Vorläufig ist es auf Platz 2 meiner Prioritätenliste gelandet. Ich dachte ich bekomme es relativ schnell hin Slowmotion/FastForward bezüglich der Dauer der Wiedergabe nicht mehr einzuschränken so dass FastForward zum Positionieren benutzt werden kann. Es gibt bei "Vorschläge und Ideen" einen Thread wo sich SPULER und JUMPER in die Haare kriegen ;-). Wär doch was! Aber denkste - geht doch nicht so schnell.

 

Aufnahmen handelt der DVBViewer immer selber.

Richtig.

 

DVBViewer Aufnahme-Optionen wie 'Adjust PAT/PMT' im DVBViewer sind bei Sofortaufnahme aus Puffer wirkungslos.

Jein. Bei der reinen Wiedergabe im Mehrkanalbetrieb ("empty buffer on channel change" unchecked) mache ich

sowas auch. Es ist also bereits inherent vorhanden nur beim Recording bisher aus Performancegründen nicht aktiviert.

Wenn sich der DVBViewer im 'Live-Betrieb' befindet (#TV.Timeshift.remain = 0), wird immer die native DVBViewer-Aufnahme verwendet (somit kann auch problemlos ein Gerätewechsel während der Aufnahme vollzogen werden, welches dann das Timeshift-Plugin und den Puffer bekommt, die Aufnahme läuft auf dem anderen Gerät problemlos über den DVBViewer weiter).

 

Dann braucht man nur noch zu wissen, dass wenn man aus dem Puffer heraus aufzeichnet (mit den Bedingungen nicht live und Sofortaufnahme gestartet), besser nicht umschaltet und so einen Gerätewechsel provoziert, weil das neue Gerät dann das Timeshift-Plugin samt Puffer bekommt.

Jetzt wirds knifflig. Dies könnte eine der Alternativen sein.

Momentan versuche ich Folgendes: Bei Auslösen von Instant-Recording wird die aktuelle Schreibposition festhalten, es wird eine 2. Rinpufferinstanz aufgemacht, in die der Instant-Recording-Stream temporär umgeleitet wird. Dann übernimmt ein separater Thread die Daten ab Auslöseposition bis zur festgehaltenen Schreibposition und setzt dann im zweiten Rinpuffer fort. Dies sollte es ermöglichen nach Auslösen von Instant-Recording den Rinpuffer freizugeben z.B durch Kanal-/Gerätewechsel. Problemzone: die ruckelfreie Verkopplung dieser beiden Teilstreams in den zwei Ringpuffern (am idealsten ohne TS-Packetverlust).

 

mfg erwin

Edited by erwin
Link to comment

Hmmm, also ich habe jetzt 'virtual' eingestellt, Puffergröße 2048 MB. Irgendwann ist mein Arbeitsspeicher beinahe zu 100% vollgepflastert (2GB RAM).

 

Die RingBuffer.exe beansprucht zu Beginn nur wenig Speicher, wächst also mit der Zeit, hier wird also nicht gleich der komplett benötigte Speicher allokiert? Oder doch? Weil wenn das TimeshiftPlus-Plugin geladen wird, vergrößert Windows bei mir die Auslagerungsdatei von 300MB auf 3.3GB. Dennoch gehen die Daten wohl nicht in die Auslagerungsdatei, sondern in den Hauptspeicher. Die Antwortzeiten des Systems sind dann irgendwann natürlich katastrophal. OSD-Navigation ist praktisch unmöglich.

Edited by CiNcH
Link to comment
Hmmm, also ich habe jetzt 'virtual' eingestellt, Puffergröße 2048 MB. Irgendwann ist mein Arbeitsspeicher beinahe zu 100% vollgepflastert (2GB RAM).

 

Die RingBuffer.exe beansprucht zu Beginn nur wenig Speicher, wächst also mit der Zeit, hier wird also nicht gleich der komplett benötigte Speicher allokiert? Oder doch? Weil wenn das TimeshiftPlus-Plugin geladen wird, vergrößert Windows bei mir die Auslagerungsdatei von 300MB auf 3.3GB. Dennoch gehen die Daten wohl nicht in die Auslagerungsdatei, sondern in den Hauptspeicher. Die Antwortzeiten des Systems sind dann irgendwann natürlich katastrophal. OSD-Navigation ist praktisch unmöglich.

"Oder doch", ist richtig. Wie gesagt, bei virtuell wird das komplette Speichermanagement dem System komplett überlassen. Die konkrete Paging-Strategie dürfte Windows-Betriebsgeheimnis sein. Aus der Beobachtung würde ich Folgendes vermuten: Wenn Speicher konkret beschrieben wird (nicht schon beim allokieren) versucht Windows diesen in Form von 4 KB Pages zur Verfügung zu stellen, zunächst aus dem RAM. Die RAM-Auslastung steigt bis auf 100%. Jetzt beginnt das Swapping. Pages (vernutlich die am längsten nicht benutzten) werden auf Platte geschrieben und im RAM wird Speicher frei. Dasselbe passiert wenn andere Prozesse incl der DVBViewer/OSD selbst Speicher anfassen. Die Folge beim OSD-Aufruf rüttelt erstmal die Platte. Ich würde Deinen letzten Satz allerdings relativieren. Beim ersten OSD-Aufruf nach längerer Zeit gibts den Performance-Einbruch, dann aber bleibt der OSD-Speicher aber erstmal für längere Zeit wieder im RAM. Dennoch, es wäre besser das DVBViewer-Speicher erst gar nicht geswapt wird. Jemand ne Idee? Irgendwie den DVBV periodisch zu Aktionen veranlassen, die ihn zwingen im RAM zu verbleiben ohne das dies den Nutzer stört. Aber wie? Oder das System zu veranlassen den Ringpuffer-Speicher von vorn herein in das Paging-File zu swappen.

 

PS. Stelle heute noch den Fix zum Positionierungs-Bug bereit.

 

mfg erwin

Link to comment

Ich bin mir nicht sicher, ob diese Methode für so große Datenmengen noch angemessen ist. Und wieder die Frage, was gegen File spricht?

 

Ich dimensioniere den Ringpuffer im Moment so, dass immer noch etwas RAM für andere Tasks frei bleibt.

Link to comment
  • 1 month later...
PS. Stelle heute noch den Fix zum Positionierungs-Bug bereit.

*mal hoch schieb*

 

Vergessen? Oder gibt es noch Probleme?

Link to comment
*mal hoch schieb*

 

Vergessen? Oder gibt es noch Probleme?

Beides: Wollte hochschieben, dann doch wieder Bug entdeckt und momentan sehr wenig Zeit. Leider tritt dieser Bug erst bei großen Puffergrößen auf, d.h. jeder Testlauf braucht über eine Stunde. Bin aber noch dran.

Dein Vorschlag Datei anstatt Paging-File habe ich aufgegriffen bin aber in letzter Zeit nicht allzuoft zum proggen gekommen.

 

bis später erwin

Link to comment

Erst mal Respekt & vielen Dank, dass sich hier jemand dieser Problematik widmet. Allerdings komme ich nicht auf'n grünen Zweig. Nach dem Start des Viewers bleibt dieser im Startbildschirm bei "Create plugin menus" hängen und genau dahinter, und deshalb nicht auf den ersten Blick zu sehen, poppt ein kleines Fenster mit "kann Ringpuffer nicht starten" auf. Klickt man das weg läuft der Viewerstart zwar bis zum Ende durch - hängt sich aber auf wenn man den ersten Sender tunt.

Was habe ich alles probiert: 1. Alle anderen plugins entfernt 2. So ziemlich alle Optionen im Dialog (sogar abgeschaltet funzt es nicht). Was mache ich nur falsch??? Woran kann's noch liegen?

 

mfg tc

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...