TimeshiftPlus Plugin, erweiterte Timeshift Funktionalität (Ringpuffer)

[CiNcH]

ich gehe mal vom selben Sender aus

Ich habe auf 'RTL Television' getestet.

 

Ü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).

Auch beim Umschalten (bei Speicherreallokation durch das Plugin) stockt hier das Bild kurzzeitig (durch die 100% Auslastung wohl) und der DVBViewer reagiert in dieser Zeit nicht mehr wirklich, aber wirklich problematisch ist nur das Starten mit automatischem Timeshift-Start. Ich bin mir ziemlich sicher, dass dieses Phänomen beim manuellen verzögerten Timeshift-Start nicht auftritt. Das dürfte ein Timing-Problem beim Hochfahren des kompletten Systems sein (DVBViewer+DVBSource+Dekoder+TimeshiftPlus).

 

Ich werde am Abend mal die MS DTV Decoder probieren. Welchen Video-Dekoder verwendest du? Ich nehme an auch mit DXVA?

Edited November 19, 2009 by CiNcH

[erwin]

Ich werde am Abend mal die MS DTV Decoder probieren. Welchen Video-Dekoder verwendest du? Ich nehme an auch mit DXVA?

Bisher eben diesen. Werde mal Cyberlink installieren.

 

Ich bin mir ziemlich sicher, dass dieses Phänomen beim manuellen verzögerten Timeshift-Start nicht auftritt. Das dürfte ein Timing-Problem beim Hochfahren des kompletten Systems sein (DVBViewer+DVBSource+Dekoder+TimeshiftPlus).

Verzögerter Timeshift-Start müßte doch über die DVBV-Scripte machbar sein. Als Work-Around sozusagen.

 

erwin

[CiNcH]

Bisher eben diesen. Werde mal Cyberlink installieren.

Lass mich das erst probieren. Wenn ich den CyberLink/TerraTec-Dekoder als Übeltäter identifizieren kann, lass ich dir diesen zukommen.

 

Auch werde ich es noch mit Standard EVR probieren. Ich gehe davon aus, dass du das im Einsatz hast.

Edited November 19, 2009 by CiNcH

[erwin]

So. Jetzt auch bei mir reproduzierbar. Guter Riecher CiNcH! EVR Custom!!!

 

erwin

[CiNcH]

Na dann hab ich den Abend wohl frei .

[erwin]

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..

Genau so ist es. Nach längerer Laufzeit bereitet das Deallokieren die beschriebenen Probleme. Es ist also tatsächlich das "VirtualFree" und nicht das "VirtualUnlock" wie ich weiter oben vermutet habe. Auch hängt die CPU-Auslastung von der allokierten Größe ab. Es ist fast so als ob das Win-7 System jede 4K-Speicherpage einzeln anfasst im Gegensatz zu XP wo dies in einem Rutsch passiert. Möglicherweise dieser FTH-Fault Tolerant Heap. Ich hab versucht es abzuschalten aber ich habe dennoch im Debug-Log immer diese Meldungen:

 

FTH: (3636): *** Fault tolerant heap shim applied to current process. This is usually due to previous crashes. ***

 

 

Konkret habe ich folgendes getan:

 

To disable Fault Tolerant Heap entirely on a system, set the REG_DWORD value HKLM\Software\Microsoft\FTH\Enabled to 0.

 

After changing this value, restart the system. FTH will no longer activate for new applications.

 

Resetting the list of applications tracked by FTH

 

Fault Tolerant heap is self-managing and will autonomously stop applying in the case that mitigations are not effective for a given application. However, if you need to reset the list of applications for which FTH is mitigating problems (for example, if you are testing an application and need to reproduce a crash that FTH is mitigating), you can run the following command from an elevated command prompt:

 

Rundll32.exe fthsvc.dll,FthSysprepSpecialize

 

 

erwin

Edited November 20, 2009 by erwin

[erwin]

Also FTH wars nicht. Konnte es abschalten. Wie es aussieht laufen Apps die im Kompatibilitätsmodus XP laufen IMMER unter FTH shim

 

erwin

[CiNcH]

Dann muss man halt die Deallokation beim Umschalten loswerden . Ehrlich gesagt hat es mich eh gewundert, dass das unter XP bei mir so schnell ging. Rein vom Gefühl her hätte ich schon gedacht, dass das was kosten würde. Bei R@lf scheint das auch der Fall zu sein.

 

Die, die halt komplett auf den RAM setzen, haben halt immer noch das Problem beim Starten und EVR Custom.

Edited November 20, 2009 by CiNcH

[erwin]

Dann muss man halt die Deallokation beim Umschalten loswerden .

Wird die (evt. temporäre) Lösung sein, wenns nicht doch anders geht. Ich werde mal ein Progrämmchen aufs wesentliche reduziert erstellen und sehen was dann passiert. Läufts glatt habe ich in meiner Programmierung die Ursache zu suchen (aber warum unter XP anderes Verhalten als unter Win7?). Bleibts bei der hohen Auslastung (die ist auf jeden Fall nicht normal) gehe ich mal mit diesem Demo in ein MS-Entwickler-Forum. Vielleicht kommt ja auch ein ServicePack. Übrigens die Probleme hat man nicht nur beim Umschalten. Wechsel zu Medienwiedergabe, Ende DVBV etc.

 

Ehrlich gesagt hat es mich eh gewundert, dass das unter XP bei mir so schnell ging. Rein vom Gefühl her hätte ich schon gedacht, dass das was kosten würde.

Sonst schon mal schlechte Erfahrung in diesem Zusammenhang gehabt?

 

Die, die halt komplett auf den RAM setzen, haben halt immer noch das Problem beim Starten und EVR Custom.

Da kann ich ja was einbauen.

 

erwin

[CiNcH]

Sonst schon mal schlechte Erfahrung in diesem Zusammenhang gehabt?

Nein, ich arbeite hauptsächlich unter Linux . Ich bin zwar in der Embedded-Welt zuhause, wo jeder Takt oder jedes Byte zu viel für eine Berechnung eine Rolle spielt, aber solche Datenmengen fassen wir halt meist nicht an und unter Linux ist das Verhalten halt etwas vorhersehbarer .

[erwin]

wo jeder Takt oder jedes Byte zu viel für eine Berechnung eine Rolle spielt

Oh das kenne ich. Unter CP/M mit seinen 64KB oberhalb des Speichers den dBase belegt hat, in diesen 12 KB noch einen halbwegs performanten on-the-fly Datenbankformatübersetzer in Form eines Spezial-Diskettendrivers unterzubringen - da war Byte- und Taktzählen angesagt. Unter diesem Gesichtspunkt mußte man erst mal darauf kommen daß z.B 2 * 128 nicht dasselbe wie 128 * 2 ist.

Oh Mann das waren noch Zeiten!

Dies prägt natürlich eine ganz bestimmte Programmierweise die man nicht mehr verlernt.

 

aber solche Datenmengen fassen wir halt meist nicht an

Meiner Kenntnis nach werden ja auch nicht die Datenmengen, sondern nur die den Container beschreibenden Variablen angefasst, d.h. es sollte eigentlich egal sein welche Größe im Spiel ist.

 

Dein Vorschlag mit dem Timeout steht auf der TODO. Auch ohne das konkret vorliegende Problem macht es ja Sinn nicht bei jedem Kanalwechsel den Speicher komplett zu verwerfen um ihn in Sekundenbruchteilen danach wieder neu aufzubauen.

 

erwin

[erwin]

Hier meine Erkenntnisse vom Wochenenden bezüglich dieses Problems.

 

.., 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).

 

Wie bereits gepostet passiert dies bei Verwendung von "EVR Custom." Test haben ergeben dass dies auch unter XP/EVR-Custom passiert. Bei mir sogar bei _jedem_ neuen Graphen-Aufbau. Auch hatte ich mindestens einen Fall wo dies passierte ohne dass TimeshiftPlus aktiv war - ließ sich dann aber nicht mehr reproduzieren, offenbar dann sehr selten.

 

Zweites Problem war, dass beim Freigeben des Puffers unter Win-7 eine extreme CPU-Belastung auftritt - im Unterschied zu XP. Siehe Logs weiter oben. Wer dies selbst nachvollziehen möchte, hier zwei Testprogramme

 

AllocTest:

 

// AllocTest.cpp : Defines the entry point for the console application.
//
#include <windows.h>
#include <stdio.h>

int main(int argc, char * argv[])
{	
 if ( ! SetProcessWorkingSetSize( GetCurrentProcess(), 1024 * 1024 * 1024 * 1.2,  1024 * 1024 * 1024 * 1.2 ) ) {
   return -1;
 }

 void * buffer = VirtualAlloc( NULL,  1024 * 1024 * 1024, MEM_COMMIT, PAGE_READWRITE /*| PAGE_NOCACHE */);
 memset( buffer, 1,  1024 * 1024 * 1024 );

 getchar();

 VirtualFree( buffer, 0, MEM_RELEASE );

 return 0;
}

 

 

AllocTest NoCache:

 

// AllocTest.cpp : Defines the entry point for the console application.
//
#include <windows.h>
#include <stdio.h>

int main(int argc, char * argv[])
{	
 if ( ! SetProcessWorkingSetSize( GetCurrentProcess(), 1024 * 1024 * 1024 * 1.2,  1024 * 1024 * 1024 * 1.2 ) ) {
   return -1;
 }

 void * buffer = VirtualAlloc( NULL,  1024 * 1024 * 1024, MEM_COMMIT, PAGE_READWRITE  |[color="#FF0000"] PAGE_NOCACHE [/color]);
 memset( buffer, 1,  1024 * 1024 * 1024 );

 getchar();

 VirtualFree( buffer, 0, MEM_RELEASE );

 return 0;
}

 

 

Dieses PAGE_NOCACHE hat bei XP beim Freigeben (also nachdem eine Taste gedrückt wurde) so gut wie keine CPU-Auslastungsfolgen, bei Win-7 bei Vorhandensein (AllocTest NoCache) eine gewaltige CPU-Auslastung und bei Nichtvorhandensein (AllocTest) eine moderate aber noch deutlich sichbare. Warum auch immer.

 

Hinsichtlich TimeshifPlus habe ich auf die Version ohne PAGE_NOCACHE mit der gewüschten positiven Wirkung umgestellt. Auch tritt numehr (zumindest bei 10 Versuchen) das EVR-Custom-Problem nicht mehr auf. Im Laufe der Woche stelle ich mal eine neue Beta-Version zur Verfügung (in der die aufgelaufenen Fixes eingearbeitet sind) so dass dies getestet werden kann.

 

 

AllocTest.zip

 

erwin

Edited November 23, 2009 by erwin

[erwin]

Version 1.2.1 Beta gibt's hier:

 

http://www.DVBViewer.info/forum/index.php?...st&id=21268

 

ChangeLog:

 

1.2b->1.2.1b

 

FIX: discontinuities at ringbuffer wrap

FIX: removing expired bookmarks

FIX: crash on exit dvbv

FIX: GUI-bug

 

NEW: support for action editor. The TimshiftPlus actions now available in action editor.

NEW: EXPERIMENTAL! Support for 64 bit. Copy the x64\RingBuffer.exe to the plugin folder (don't forget to backup the 32 bit RingBuffer.exe). It's a native 64 bit version of RingBuffer.exe. Internally RingBuffer.exe uses 64 bit pointers, so there should be a performance benefit.

 

CHANGED: bookmark settings now in absolut time

CHANGED: memory-management to support Custom EVR. With Custom EVR there was a performance problem on releasing the buffer (on channel change for instance)

 

 

erwin

Edited November 27, 2009 by erwin

[CiNcH]

Bei mir kommt es beim Starten immer noch oft zu den Hängern mit anschließendem Buffer Overflow, wenn ich nicht die virtuelle Methode verwende. So wie es aussieht, wird in dieser Version der Speicher nun gar nicht mehr deallokiert. Ich kann also nicht wirklich sagen, ob die Änderung zumindest beim Umschalten Besserung gebracht hat.

Edited November 27, 2009 by CiNcH

[R@lf]

Bei mir unter WinXP steigt beim Umschalten der Programme die CPU-Last immer noch bis auf 60% an (Athlon X2 3800). Wenn ich jedoch die virtuelle Methode verwendet läuft es deutlich besser beim Umschalten, dann habe ich nur noch 11% CPU-Last. Und genau diese Lastspitze verursacht meine in Post#234 beschriebenen Probleme mit der Fernbedienung.

[erwin]

Bei mir kommt es beim Starten immer noch oft zu den Hängern mit anschließendem Buffer Overflow, wenn ich nicht die virtuelle Methode verwende.

Das Timingproblem besteht also immer noch. Da das bis zur Änderung bei mir reproduzierbare Problem dann verschwunden war, hatte ich gehofft, dass sich dies gleich mit erledigt hätte. Werd wohl dann doch eine Verzögerung einbauen.

 

So wie es aussieht, wird in dieser Version der Speicher nun gar nicht mehr deallokiert.

Doch, die Änderung ist nur die wie oben im PAGE_NOCACHE Beispiel. Ein Aussetzen der Deallokierung bei Kanalwechsel steht allerdings auf TODO.

 

Ich kann also nicht wirklich sagen, ob die Änderung zumindest beim Umschalten Besserung gebracht hat.

Wie jetzt? Du hast beim Umschalten keine Besserung bemerkt? Kannst Du nochmal die CPU-Auslastung aufzeichnen?

 

erwin

Edited November 30, 2009 by erwin

[erwin]

Bei mir unter WinXP steigt beim Umschalten der Programme die CPU-Last immer noch bis auf 60% an (Athlon X2 3800). Wenn ich jedoch die virtuelle Methode verwendet läuft es deutlich besser beim Umschalten, dann habe ich nur noch 11% CPU-Last. Und genau diese Lastspitze verursacht meine in Post#234 beschriebenen Probleme mit der Fernbedienung.

60% erscheint mir wirklich zu hoch. Kannst Du mal deinen Graphen (Dekoder/Renderer) beschreiben. Zeichne bitte auch mal die CPU-Auslastung beim UMschalten auf und poste sie hier. Bestehen die anderen im Post#234 beschriebenen Probleme noch?

 

erwin

[CiNcH]

Hmmm, bei mir wurde wie gesagt der Speicher nie Deallokiert. Keine Deallokation bzw. Reallokation -> keine Probleme...

[R@lf]

60% erscheint mir wirklich zu hoch. Kannst Du mal deinen Graphen (Dekoder/Renderer) beschreiben. Zeichne bitte auch mal die CPU-Auslastung beim UMschalten auf und poste sie hier. Bestehen die anderen im Post#234 beschriebenen Probleme noch?

 

erwin

 

Ich verwende den Overlay-Renderer und als Dekoder den Cybelink PowerDVD7.3 für Video und für Audio den AC3Filter.

 

Die Probleme von Post#234 treten leider immer noch auf. Ich habe die Sache aber etwas abgemildert in dem ich RMClock etwas eher den CPU-Takt hochschalten lasse und die Repeatdelay im WinLirc-Plugin auf 800ms erhöht habe. Beim Testen ist mir aufgefallen daß sich das Problem mit der neuen Version verschlechtert hat.

 

Auch habe ich mal mit der virtuellen Methode getestet, da funktioniert das Umschalten richig gut. Aber die die Aufnahmen aus dem Puffer sind ab Übergang zu LiveTV mit Fehlern bis zum Ende der Aufnahme übersäht. Auch wenn im Logfile 0 Fehler steht.

 

Hier noch die Aufzeichnung der CPU-Last beim Umschalten, wobei jeder Peak ein Schaltvorgang ist.

Edited November 30, 2009 by R@lf

[erwin]

Hier noch die Aufzeichnung der CPU-Last beim Umschalten, wobei jeder Peak ein Schaltvorgang ist.

Und die sieht eigentlich gut aus, so wie die auch bei mir. Nicht jeder Schaltvorgang hinterläßt im "Verlauf der Auslagerungsdateiauslastung" ein Echo. Hierzu folgendes:

 

1. ) Dieser Begriff "Verlauf der Auslagerungsdateiauslastung" ist unter XP eine Fehlbenennung - gemeint ist virtueller Speicher. Also nicht irreführen lassen. Auch bei Option RAM in TimeshiftPlus ist hier ein Anstieg zu verzeichnen, was _nicht_ heißt, das wirklich ins Pagefile geschrieben wird.

 

2.) Die Sequenz Delloc/Alloc ist teilweise so schnell, dass sie in der zeitlichen Granulität des Leistungsmonitors untergeht.

 

Umso unverständlicher die Auswirkungen auf Deine Umschaltvorgänge. Sagst ja selber, mit Tastaurumschaltung gehts gut. Offenbar läuft hier WinLirc am Rande eines stabilen Zustandes.

 

erwin

[Lars_MQ]

Winlirc ist (über)hochempfindlich, was das timing angeht. Da reichen schon geringste variantionen, um das teil völlig aus dem takt zu bringen...

[CiNcH]

2.) Die Sequenz Delloc/Alloc ist teilweise so schnell, dass sie in der zeitlichen Granulität des Leistungsmonitors untergeht.

Ich werde mir das heute auch noch einmal ansehen, wobei ich der Meinung bin, dass selbst, wenn ich Timeshift über die Stop-Taste beendet habe, der Speicher nicht freigegeben wurde.

[CiNcH]

OK, du hast wohl recht, dass der Performance- bzw. Speicherauslastungsgraph die Reallokation gar nicht mitbekommt weil er nicht gut genug auflöst. Die Auslastung ist tatsächlich sehr viel geringer beim Umschalten, bleibt aber doch eine gewisse Zeit deutlich höher.

 

Bei Timeshift-Stop wurde auch tatsächlich deallokiert. Da habe ich wohl diesmal zu wenig genau getestet.

 

Aber das Problem beim Starten des DVBViewer mit EVR Custom bleibt dennoch. Das habe ich soeben noch ein paar Mal reproduziert. Mir kommt es vor, dass das nur bei 16:9 passiert, wo der Renderer auf das anamorphe Format umschalten will, aber gerade blockiert wird.

[rage76]

Hi,

 

Hab mal die 64bit Variation ausprobiert

Leider kommt bei >2GB RAM Buffer eine Fehlermeldung

"Not enough Memory for Ringbuffer"

 

Gruß

[erwin]

"Not enough Memory for Ringbuffer"

Leider habe ich im Quelltext diesen Fehler nicht genug ausdiffenziert, d.h. diese Meldung kommt u.U. auch wenns mit dem verfübgaren Speicherplatz gar nichts zu tun hat. Ich schau mir das noch mal an.

 

THX und Gruß erwin

[erwin]

@R@lf

Ich bin Dein Problem noch mal gedanklich durchgegangen. Ich stelle mir folgendes Szenario vor:

Du drückst also auf deiner FB die Taste für Kanalwechsel. Es geschieht zunächst nichts (Du sagtest was von "träge" was ich bisher als "zu langsamer Wechsel" fehlinterpretiert habe). Instinktiv hälst Du die Taste weiter gedrückt und es kommt zur verzögerten Doppelauslösung. Die Doppelauslösung ist verständlich da Du ja die Taste länger als sonst üblich gedrückt hast. Warum verzögert? Beim Allokieren und Festlegen des Memory im RAM wurde möglicherweise der WinLirc-Server ins Swapfile gedrückt und muß beim Empfang eines IR-Signals erstmal wieder von der Platte gelesen werden. Es ist also nicht der CPU-Auslastungspeak das Problem.

 

Wie kann man das verifizieren? HD-LED, verschiedene Memory-Indikatoren im Performancemonitor (Perfmon.exe). Dieses Verhalten sollte auch im virtuellem Mode auftreten - nicht gleich, sondern wennn der Ringpuffer gut gefüllt ist (eine Runde abwarten).

 

Workaround: Mehr Speicher übriglassen und dafür sorgen das darin der WinLirc-Server verbleibt, z.B. Timeshift mit FB starten oder irgendeine andere FB-Aktion. Obwohl Microsofts Swap-Strategie mir nicht bekannt ist, gehe ich davon aus, dass was am längsten nicht genutzt wurde, zuerst geswapt wird. Zur Vermeidung des Herausswappens zeitkritischer Komponenten des DVBV wurde eigens die Option "Lock DVBV in RAM" eingebaut. Diese lockt allerdings nur den DVBV selbst, inclusive seiner DLLs, nicht aber den WinLirc-Server. Aber vielleicht bietet er eine ähnliche Option? Oder es gibt im Web Tools die Applikationen im RAM locken können. Oder ich stelle selbst ein solches Tool zur Verfügung indem ich den "Lock DVBV in RAM"-Programmpart verselbständige. Mal sehen

 

erwin

[R@lf]

Beim Allokieren und Festlegen des Memory im RAM wurde möglicherweise der WinLirc-Server ins Swapfile gedrückt und muß beim Empfang eines IR-Signals erstmal wieder von der Platte gelesen werden. Es ist also nicht der CPU-Auslastungspeak das Problem.

 

Ein Swapfile gibt es bei mir nicht, das habe ich auf Null gesetzt. Aber wenn es, wie du schreibst, am Auslagern von WinLirc liegen soll dürfte es doch, wenn ich den Pufferinhalt beim Kanalwechsel behalte auch diese Probleme geben? Was aber nicht der Fall ist.

Die virtuelle Methode werde ich noch mal länger Testen, aber da ist ja genau wie wenn man den Pufferinhalt behält, die Aufnahmen aus dem Puffer nicht zu gebrauchen.

 

Gruß R@lf

[erwin]

aber da ist ja genau wie wenn man den Pufferinhalt behält, die Aufnahmen aus dem Puffer nicht zu gebrauchen.

Lass dies jetzt mal eine andere Baustelle sein ;-)

 

Hmm, versuchen wir mal zu präzisieren.

- Das "träge"-Umschaltverhalten setzt ein wenn Du mit der RAM-Option und "release buffer on timeshift stop" arbeitest. Richtig?

- Bei "release buffer on timeshift stop" = uncheked ist es OK.

- Auch die Virtual-Option mit "release buffer on timeshift stop" ist OK.

- Dies geschieht wenn Du mit der WinLirc-FB umschaltest? Sonst per Tastutatur/Mouse nicht?

- Was heist genau "träge", d.h. wenn Du den FB-key 1 mal kurz (!) drückst.

1) der Umschaltvorhang beginnt sofort, dauert aber übermäßig lange

2) er beginnt verzögert und dauert dann wie lange?

 

erwin

[R@lf]

- Das "träge"-Umschaltverhalten setzt ein wenn Du mit der RAM-Option und "release buffer on timeshift stop" arbeitest. Richtig?

Richtig

- Bei "release buffer on timeshift stop" = uncheked ist es OK.

Ja

- Auch die Virtual-Option mit "release buffer on timeshift stop" ist OK.

Ja

- Dies geschieht wenn Du mit der WinLirc-FB umschaltest? Sonst per Tastutatur/Mouse nicht?

Genau, das Problem habe ich nur wenn ich mit der Fernbedienung umschalte. Per Tastatur klappt alles wie es soll.

- Was heist genau "träge", d.h. wenn Du den FB-key 1 mal kurz (!) drückst.

1) der Umschaltvorhang beginnt sofort, dauert aber übermäßig lange

2) er beginnt verzögert und dauert dann wie lange?

Träge ist vielleicht etwas unglücklich ausgedrückt. Der Schaltvorgang beginnt eigentlich sofort, aber wenn WinLirc "prellt" gibt es eben 2 oder 3 Schaltvorgänge was man nur an der längeren Zeit merkt bis man wieder ein bewegtes Bild hat. Es dauert also genau 2 oder 3 mal so lange als normal. Manchmal hört man auch ganz kurz den Ton des übersprungenen Kanals. Wenns aber mal klappt gibts eigentlich keine wirkliche Verzögerung.

Was noch den Eindruck von "träge" etwas unterstreicht ist dass das Mini-EPG beim Umschalten etwas verzögert erscheint. Das liegt warscheinlich an der kuzzeitigen Auslastung der CPU, da das OSD auch von der CPU gerendert wird.

 

Ich habe auch mal die virtuelle Methode mit "release Buffer..." länger getestet und da schaltet es auch nach mehreren Umläufen richtig flott und sicher nur einen Kanal um.

 

R@lf

Edited December 2, 2009 by R@lf

[erwin]

Träge ist vielleicht etwas unglücklich ausgedrückt. Der Schaltvorgang beginnt eigentlich sofort, aber wenn WinLirc "prellt" gibt es eben 2 oder 3 Schaltvorgänge was man nur an der längeren Zeit merkt bis man wieder ein bewegtes Bild hat. Es dauert also genau 2 oder 3 mal so lange als normal.

In den DVBV-Optionen kann man timeouts für den schnellen Kanalwechsel einstellen, dann dauerts nicht 2 oder 3 mal solange. Aber Du wolltest ja eigentlich nur einen Kanal weiterspringen. Warum WinLirc "prellt" wenn es unter den genannten Bedingungen läuft? Da bin ich im Moment jetzt wirklich überfragt.

 

Und es "prellt" auch, wenn Du die Taste wirklich nur ganz kurz drückst? Oder anders gefragt, drückst Du die Taste objektiv nicht länger als sonst?

 

erwin

Edited December 2, 2009 by erwin

[R@lf]

Oder anders gefragt, drückst Du die Taste objektiv nicht länger als sonst?

 

Eigentlich nicht, ich versuche machmal ganz bewusst besonders kurz zu drücken. Aber ich denke das wie Lars schon geschrieben hat ist WinLirc recht empfindlich. Und bei hoher CPU-Last kommtes dann warscheinlich aus dem Takt und macht dann mehrere Schaltvorgänge. Das Signal wird ja von der Ferhbedienung so lange man drück gesendet, und das warscheinlich so schnell das man es kaum schafft nur eins zu senden. Das muss/sollte dann WinLirc irgend wie filtern.

 

Wäre es denn möglich mal eine Version, wo der Puffer beim umschalten allokiert bleibt, zum testen zu bekommen?

 

R@lf

[erwin]

Und bei hoher CPU-Last kommtes dann warscheinlich aus dem Takt und macht dann mehrere Schaltvorgänge.

Naja so hoch ist die CPU-Last ja nun auch wieder nicht. 60%! Und selbst wenn, hätte ich intuitiv erwartet das Ereignisse verschluckt werden aber doch nicht das noch welche hinzukommen. Seltsam.

 

Wäre es denn möglich mal eine Version, wo der Puffer beim umschalten allokiert bleibt, zum testen zu bekommen?

Wie oben schon gesagt, steht auf der TODO. Und TODO ist immer eine Sache von verfügbarer Zeit und Priorität. Letzteres ist nun natürlich gestiegen. Mal sehen was das Wochenende hergibt.

 

erwin

[CiNcH]

Auch mit der aktuellen Version ist das Umschalten definitiv träger (auch wenn der Performance-Graph deutlich gesünder aussieht). Öffnet mal die UI-Kanalliste und schaltet mit der Maus einmal mit und einmal ohne Speicherallokierung durch die Programme. Der DVBViewer hängt da schon ein bisschen und der Kringel (bzw. die Sanduhr) ist beim Mauszeiger sichtbar.

[Klassikfan]

Hi,

 

Hab mal die 64bit Variation ausprobiert

Leider kommt bei >2GB RAM Buffer eine Fehlermeldung

"Not enough Memory for Ringbuffer"

 

Gruß

Ja, die kommt bei mir auch.

Am RAM kann es nicht liegen, da ich 8 GB stecken habe und Windows davon 7,75 verwenden kann.

[CiNcH]

Geht hier noch was? Bei mir steht TimeshiftPlus wegen diverser Macken weiterhin auf dem Abstellgleis.

 

Ich habe es dennoch reaktiviert, weil mich interessiert hat, wie sich die Spulerei im Pausezustand (mit den Jump-Tasten) der aktuellen Beta-Versionen mit dem TimeshiftPlus-Plugin dazwischen verhält. Hat das schon jemand probiert? Auf den ersten Blick sieht das gut aus, allerdings weiß ich noch nicht, inwieweit das auch nach mehreren Timeshift-Runden noch funktioniert bzw. wie beim Spulen die kleinen Sprünge ausgeführt werden, bzw. ob da Puffergröße und Absolutzeit miteinbezogen werden.

 

[EDIT]

Spulen scheint auch nach mehreren Timeshift-Runden noch zu funktionieren. Damit kann man übrigens schnell und schön sehen, ob die zeitliche Abfolge im Puffer noch stimmt.

Edited January 25, 2010 by CiNcH

[erwin]

Geht hier noch was?

Ja.. Schon.. Doch..

Hast schon recht, da gibts noch was zu tun. Allerdings habe ich in den letzten Wochen bewußt in Sachen TimeshiftPlus eine Auszeit genommen und ein par einfache Sachen geproggt. Ein wenig Abstand gewinnen, neue Ideen sammeln..

 

... die Spulerei im Pausezustand (mit den Jump-Tasten)

Du meinst Timeshift pausiert während Du die (begrenzte) Spulfunktion von Slowmotion/FF nutzt. Oder verstehe ich Dich jetzt falsch?

 

 

erwin

[CiNcH]

Oder verstehe ich Dich jetzt falsch?

Der DVBViewer kann in den aktuellen Betas (Achtung!! Auch DVBSource muss auf aktuellem Stand sein, es ist auch zu empfehlen die Custom Renderer zu verwenden) zumindest im Pausezustand spulen. Also einfach auf Pause und dann die Jump-Taste gedrückt halten (mit X10 geht es, weil es da Key-Down/Up-Events gibt, sonst mit Tastatur).

Edited January 26, 2010 by CiNcH

[CiNcH]

Hab nun auch einmal auf einem HD-Sender zurück- und vorgespult. Geht wunderbar. Hast du es auch schon probiert?

[CiNcH]

Ich will nochmal kurz die gesammelten Bugs und Verbesserungsvorschläge zusammenschreiben:

 

• Keine Speicher-Realloktion bei Timeshift-Close/Open, stattdessen Timeout für erneutes Open nach Close.. falls überschritten -> Speicher freigeben
  
• Option Buffer-Reset beim Umschalten (anstatt Realloc)
  
• Aufnahme aus virtuellem Speicher funktioniert nicht korrekt
  
• EVR Custom wird durch Initialisierung des Plugins scheinbar blockiert, wobei ich nicht sicher bin, ob es was bringt, die Initialisierung zu verschieben, weil der EVR Custom allgemein etwas störanfällig ist, siehe auch hier
  
• DataManager-Komponente:
  - wo befindet sich der Read-Pointer prozentuell zwischen logischem Anfang und logischem Ende
  
• Ebenfalls interessante DataManager-Komponenten, welche aber auf Grund variabler Datenraten spätestens ab Timeshift-Runde 2 schwer sind zu berechnen:
  - wieviel ist zeitlich gepuffert im Format hh:mm:ss
  - wo befindet man sich mit dem Read-Pointer zeitlich im Puffer
  
• Falls die Sliderkontrolle (siehe Problem) und die eigene Jump-Verwaltung kommen sollten, hoffe ich, dass die DVBViewer Jump-Verwaltung kompatibel bleibt (wegen spulen, was auch nichts anderes als kleine Sprünge sind)
  
• File-Support für größere Ringpuffer und Entlastung des Hauptspeichers (kann man dann natürlich auch auf ein USB-Speichermedium machen), löst wahrscheinlich auch das EVR Custom Problem, beim Hardcore-Zapping ist mir die RingBuffer.exe auch schon ab und zu mal weggeknickt...
  

Edited February 1, 2010 by CiNcH

[erwin]

Du hast dir jetzt ja wirklich Mühe gemacht. Da muss ich dann wohl auch mal wieder. Um zeitnah eine Zwischenversion liefern zu können - was sind die zwei/drei Punkte mit der höchsten Priorität deiner Meinung nach.

 

erwin