CapFrameX - Capture und Analyse Tool

[Taxxor]

kein Fehler bis dato bei ca. 25 60s-Aufnahmen (ich kann BF5 schon nicht mehr sehen )

Ich glaube nicht, dass die Aufnahmelänge damit zusammenhängt, deine anderen Fehler traten ja vorher auch bei den 20s Aufnahmen auf, also du musst dir keine 60s antun^^
Du musst nur mehr aufpassen, weil ja jetzt die Aufnahmen nach einem Fehler wieder funktionieren sollten und es jetzt eher sein kann, dass du evtl mal verpasst, wenn eine einzelne nicht gespeichert wurde.

was mir aufgefallen ist, dass nach dem uninstall bzw install meine Einstellungen erhalten blieben/wiederhergestellt wurden (auch der Archivordner),
bei den vorherigen Neuinstallationen wurden immer Defaulteinstellungen geladen

Ja, das ist so gewollt, damit die Leute ihre Settings nicht immer wieder neu einstellen müssen.
Sollten da mal Probleme auftreten, kannst du die Settings auch manuell wiederherstellen, indem du den CX Ordner unter AppData/Local löschst, dann wird beim näcshten Start wieder die Standardconfig geschrieben.

Einen "Archivordner" gibt es aber nicht, das Archiv läuft komplett in der Anwendung, das wird nirgends abgespeichert. ( Außer in der neusten Version die ich dir gepostet habe, wo es in den Logs Ordner gespeichert wird und das ist auch nur zum testen^^)

Spoiler: Was ist das Archiv?

Da sind einfach die letzten 500 Zeilen von PresentMon, die immer flüchtig geschrieben werden solange CX läuft, also auch außerhalb einer laufenden Aufnahme, da PresentMon die Daten nicht gleichmäßig übermittelt und wir zum Zeitpunkt des Hotkeys meist Daten bekommen die schon etwas zu alt sind weil er zum Hotkey Zeitpunkt gerade den Datansatz für einen Frame 200ms vor dem Hotkeyzeitpunkt übermittelt hat.)
Das Archiv wird dann beim Starten einer Aufnahme gestoppt, um die darin vorhandenen Daten später beim Speichern erst mal alle vorne dran zu packen, wobei doppelte entfernt werden indem die Archivwerte mit den aufgenommenen verglichen werden und alle aus Archiv verworfen werden, die jünger oder gleich alt sind.
Danach wird das Archiv gelöscht und wieder freigegeben um die aktuellen PresentMon Zeilen aufzunehmen.
Der Fehler tritt bei dir auf, wenn bei dieser Abfrage rauskam, dass kein einziger Wert aus den Aufnahmedaten älter ist als der letzte Archivwert, was eigentlich nicht sein kann und daher schmeißen wir da einen Fehler aus.

Die Funktion das Archiv wieder zu starten hatte ich in der Version gestern nicht richtig eingebaut, sodass bei einem Fehler zwar das Archiv gelöscht wurde, aber nicht freigegeben wurde, wodurch alle deine folgenden Aufnahmen nicht mehr erstellt werden konnten, weil dafür Daten im Archiv sein müssen(daher auch die Meldung im Logger, dass dort 0 frames drin waren, nachdem der Fehler einmal aufgetreten war, ein Archiv mit 0 Einträgen hat zur folge, dass er abbricht, wodurch er wieder nicht in die Funktion reingekommen ist, das Archiv wieder zu starten^^)

außerdem hat sich gefühlt das Input-Lag erhöht, wenn ich den Hot-Key drücke

Das ist von System zu System unterschiedlich, aber es hat nichts mit dem Input Lag zu tun, die Aufnahme startet immer gleich. Das einzige was variiert, ist der Zeitpunkt, wann du den Sound hörst.
Bei mir kommt der auch manchmal erst 1-2s später, manchmal aber auch direkt. Auf die Aufnahme hat das aber keinen Einfluss.

mal noch ne Frage zur Installation, ich hatte jetzt beim deinstallieren und beim installieren der neuen Version vergessen CX zu beenden, das hat den Installer und Deinstaller aber nicht gejuckt, oder ist ein "how-swap" bzw. analog dazu "hot-un-/install" grundsätzlich möglich/gewollt?

Das ist mir letztens auch aufgefallen und ich hab mich gewundert, wie das denn überhaupt funktionieren kann, dass die Anwendung noch offen sein kann. Ich hab es dann einfach geschlossen und gar nicht probiert, ob man da dann noch irgendwas machen kann, hast du das mal probiert?
Da können wir auch noch mal nachbessern, dass die Anwendung dann schließt bzw zur Deinstallation geschlossen sein muss^^

ich speichere alle Aufnahmen auf einer SSD, darauf ist BF5 jedenfalls nicht installiert oder sollte man besser den Standardordner auf C: eingestellt lassen?

Wie oben schon erwähnt, das Archiv hat nichts mit dem Speicherort der Aufnahmen zu tun und wenn beim Speichern der Aufnahmen ein generelles Problem aufgrund des Speicherorts bestehen würde, würde es nciht sporadisch auftreten sondern nie funktionieren.

Und wir wissen ja nun schon zu 100%, an welcher Stelle der Fehler auftritt und das hat nichts mit dem Speichern der Datei zu tun, es kommt erst gar nicht dazu, dass die Sachen, die in die Datei reinkommen, überhaupt zusammengestellt werden können.

 

[Taxxor]

@Sk3ptizist Nachtrag hierzu

Ja, das ist so gewollt, damit die Leute ihre Settings nicht immer wieder neu einstellen müssen.

Fehler meinerseits, es ist tatsächlich nicht so gewollt, dass das bei dir jetzt passiert, ist nur, weil die Versionsnummern der ganzen Betas, die ich dir gegeben habe, alle gleich sind.
Die Config wird zurückgesetzt, wenn du eine Version installierst, die sich von der vorher installierten unterscheidet, wie es für den normalen Nutzer eigentlich immer der Fall ist^^

 

[Sk3ptizist]

achso, ok

du musst dir keine 60s antun^^

naja, ich mach ein paar Multiplayermessungen beim zocken, um DX11 und DX12 mal vergleichen zu können, ich hab das Gefühl, dass ich mit DX12 mehr stuttering habe, weswegen ich normaler Weise auch mit DX11 zocke

ob man da dann noch irgendwas machen kann, hast du das mal probiert?

aufnehmen hab ich nicht getestet, aber Analysis der Aufnahmen geht noch glaube ich

ich habe jetzt seit den 2 letzten Versionen nicht nochmal Fehler gehabt, mit der neuesten ca. 60+ Aufnahmen ohne Neustart
aber ich geb Dir vielleicht trotzdem mal das log etc.

 

[Taxxor]

aufnehmen hab ich nicht getestet, aber Analysis der Aufnahmen geht noch glaube ich

Ich habs heute mal getestet, es geht tatsächlich alles, scheint komplett im RAM zu laufen dann.

Aber in der nächsten Version wird CX dann wohl beendet, ist besser so^^

ich habe jetzt seit den 2 letzten Versionen nicht nochmal Fehler gehabt, mit der neuesten ca. 60+ Aufnahmen ohne Neustart

Ich sehe da aber einen Fehler im Log, hab doch gesagt du musst jetzt mehr aufpassen, damit dus nicht verpasst
Das entsprechende Archiv wurde ja auch gespeichert, und damit haben wir das Problem auch glaube ich identifiziert^^

 

[Taxxor]

So und hier dann die hoffentlich letzte Testversion
https://nexus.cluster.the.mind-blow.../feae91bf87c34a43dee521ebabedec9aa99350ff.zip

 

[ZeroStrat]

@Sk3ptizist Danke für Unterstützung und Geduld. Ist ja nicht selbstverständlich.

Ich denke aber, dass @Taxxor und ich heute das Problem grundsätzlich gelöst haben.

 

[Sk3ptizist]

Ich sehe da aber einen Fehler im Log

ok Neo, daher hab ichs ja zur Sicherheit trotzdem geschickt
hatte das log gar nicht groß gecheckt, da ich dachte, dass alles aufgenommen wurde

habe jetzt nochmal einige Aufnahmen mit der Run-History+Aggregation gemacht, ohne Probleme
das einzige was mir noch aufgefallen ist, dass die Default-Tastenkombi fürs abbrechen "Alt+R" auch das Radeon-Adrenaline-Menu öffnet, welches standardmäßig auch mit "Alt+R" belegt ist
dann dachte ich mir, mache ich halt "Alt+F12", weil mein Aufnahme-Hotkey "F12" ist, das hatte aber zur Folge, dass beim Versuch damit abzubrechen, die alte Aufnahme zwar abgebrochen wurde, aber gleichzeitig auch eine neue gestartet wurde ^^
habs jetzt auf "Alt+F11" gelegt, das geht soweit...

@Sk3ptizist Danke für Unterstützung und Geduld. Ist ja nicht selbstverständlich.

Ich denke aber, dass @Taxxor und ich heute das Problem grundsätzlich gelöst haben.

sehr schön, ist ja auch nicht ganz uneigennützig, da ich mir so ja zukünftig Fehlaufnahmen erspare ^^
und ich wollte mich eh mal in CX reinfuchsen und mein System messen, nachdem mir Baal Netbeck dazu geraten hat

ich habe noch nicht verstanden, wie der Max-Thread-Wert ermittelt wird, ist es immer der Wert des Kerns mit der aktuell höchsten Auslastung, so dass dieser Wert von verschiedenen Kernen stammen kann?

 

[Taxxor]

ich habe noch nicht verstanden, wie der Max-Thread-Wert ermittelt wird, ist es immer der aktuelle Wert des Kerns mit der höchsten Auslastung, so dass dieser Wert von verschiedenen Kernen stammen kann?

Korrekt, es ist genau das was HWInfo auch als Max Thread Usage ausgibt.

 

[Wolfgang]

@Wolfgang hier kannst du schon mal ein bisschen rumprobieren^^

Das klappt übrigens super und wurde schon gut im kommenden Ryzen-XT-Test eingesetzt

 

[Sk3ptizist]

So und hier dann die hoffentlich letzte Testversion

so habe getestet und glaube einen oder zwei Schreibfehler gehabt und eine defect-CSV-Datei ist auch wieder da?
war beim Nutzen der Run-Time-Aggregation, aber ich bin mit nicht sicher, glaube gestern gegen 15:29 war was komisch, bitte mal checken falls notw.
oder ist ein Test der letzten Beta wegen Eurer grundsätzlichen Problemlösung nicht mehr notwendig?

ich hatte dann mal 3 kurze Aufnahmen als Schreibtest gemacht, bei der Aggregation davon zeigt es komischer Weise kein Diagramm für die FPS, ist das normal bei kurzen Aufnahmen??
und irgendwie erstellt es mir manchmal eine zweite bzw. neue Log-Datei mit dem Namen CapFrameX_001.log


aber sonst keine Probleme

 

[Taxxor]

so habe getestet und glaube einen oder zwei Schreibfehler gehabt und eine defect-CSV-Datei ist auch wieder da?

Das hast du aber nicht mit der letzten Testversion gemacht, die ich dir verlinkt habe? Denn die schreibt keine csv mehr. Klar, dass der Fehler in der vorherigen Testversion noch auftreten kann.

Wenn es wirklich die aus meinem letzten Link war, dann hab ich dir evtl einen falschen Link geschickt, in dem Fall kannst du auch direkt eine frische von heute nehmen^^
https://nexus.cluster.the.mind-blow.../d57b9708a123493e206ce6df41d2e54df801dc35.zip

oder ist ein Test der letzten Beta wegen Eurer grundsätzlichen Problemlösung nicht mehr notwendig?

Es ist grundsätzlich immer gut, zu wissen, dass es funktioniert, egal wie sicher wir uns diesmal sind^^

ich hatte dann mal 3 kurze Aufnahmen als Schreibtest gemacht, bei der Aggregation davon zeigt es komischer Weise kein Diagramm für die FPS, ist das normal bei kurzen Aufnahmen??

Also die Records, die du angehangen hast, zeigen bei mir alle die Graphen an.

Wenn ich mir die Skala in deinem Screenshot ansehe: Kann es sein, dass du mal manuell die Achsen verschoben hast?
Weil die geht bei dir von 130-170, klar dass der gefilterte avg FPS Graph, der von 209-218 geht, da nicht zu sehen ist^^
Doppelklick in den Graphen und er positioniert sich wieder automatisch.

und irgendwie erstellt er mir manchmal eine zweite bzw. neue Log-Datei mit dem Namen CapFrameX_001.log

Die logs werden ab einer gewissen Menge an Zeilen getrennt, damit die einzelnen Dateien nicht so groß und unübersichtlich werden.

 

[Sk3ptizist]

Das hast du aber nicht mit der letzten Testversion gemacht, die ich dir verlinkt habe? Denn die schreibt keine csv mehr. Klar, dass der Fehler in der vorherigen Testversion noch auftreten kann.

komisch, eigentlich doch, ich habe zumindest seit dem keine neue Version installiert, gestern war die CSV anfangs noch nicht da, habe ich gerade erst gecheckt das da eine ist, das Erstelldatum ist ja von gestern 17:52
aber keine Ahnung obs ein alter Fehler ist, ich habe den Archivordner zwischenzeitlich geändert gehabt

 

[Taxxor]

Dann bin ich vielleicht wirklich bei den ganzen Commits, die da in unserem index drin sind, durcheinander gekommen und hab dir eine geschickt, wo es noch nicht drin war, dann nimm bitte die die ich jetzt oben verlinkt hab, die ist auf jeden Fall von heute^^

 

[Sk3ptizist]

ok gut, das ist bei mir dann die v1.5.3_beta6, ich versuche es auseinander zu halten und ein vorbildlicher Betatester zu sein

hilft Dir ein reupload der letzten (beta5) bzw. jetzt noch bei mir installierten Variante um das auszuschließen?

 

[Taxxor]

Nicht wirklich, ich kann aus den exe Dateien leider nicht zurückverfolgen, welcher exakte commit das war^^

 

[Taxxor]

habe ich gerade erst gecheckt das da eine ist, das Erstelldatum ist ja von gestern 17:52
aber keine Ahnung obs ein alter Fehler ist, ich habe den Archivordner zwischenzeitlich geändert gehabt

Nochmal rein zum Verständnis: Die csv wird zusammen mit den Logs imLog Ordner gespeichert, deine Aufnahmen kommen in den Capture Ordner.

Was meinst du mit "Archivordner"?
Die einzigen Ordner, die zu verändern kannst, sind der Cloud Ordner, der Capture Ordner und der Screenshot Ordner.

 

[Sk3ptizist]

Nochmal rein zum Verständnis: Die csv wird zusammen mit den Logs imLog Ordner gespeichert. deine Aufnahmen kommen in den Capture Ordner.

ja, das habe ich verstanden
aber wo wird das eigentlich zwischengespeichert, irgendwo auf c: oder schreibt der direkt in den root capture ordner oder nur RAM?

Was meinst du mit "Archivordner"?
Die einzigen Ordner, die zu verändern kannst, sind der Clod Ordner, der Capture Ordner und der Screenshot Ordner.

ich meinte den root capture Ordner, den ich geändert hatte
ich dachte, dass vielleicht beim neuladen der alten Captures der Fehler auftrat und die CSV-Datei erzeugt wurde, als ich ihn wieder zurück geändert hatte

die vorletzte CSV die ich Dir geschickt hatte war die defect_archive_1533_4 aus meiner CaprameX_beta4
mit der Version:

https://nexus.cluster.the.mind-blow.../1fe92374444f7e2fac8a972d4ada4879120d4cd9.zip

und die CSV von gestern mit der Version (bei mir beta5):

So und hier dann die hoffentlich letzte Testversion
https://nexus.cluster.the.mind-blow.../feae91bf87c34a43dee521ebabedec9aa99350ff.zip

 

[Taxxor]

ja, das habe ich verstanden
aber wo wird das eigentlich zwischengespeichert, irgendwo auf c: oder schreibt der direkt in den root capture ordner oder nur RAM?

Die Daten sind, bevor sie als Datei geschrieben werden, ausschließlich im RAM vorhanden und werden nur innerhalb von CX verwendet.

ich meinte den root capture Ordner, den ich geändert hatte
ich dachte, dass vielleicht beim neuladen der alten Captures der Fehler auftrat und die CSV-Datei erzeugt wurde, als ich ihn wieder zurück geändert hatte

Der Fehler tritt ja nicht beim Laden von bestehenden Dateien auf sondern beim Erzeugen von neuen Dateien aus den Daten, die von PresentMon erhalten wurden und zwar vor dem Speichern(deshalb wird ja nichts gespeichert^^). Insofern hat der ausgewählte Speicherort nichts damit zu tun.

die vorletzte CSV die ich Dir geschickt hatte war die defect_archive_1533_4 aus meiner CaprameX_beta4
mit der Version:

und die CSV von gestern mit der Version (bei mir beta5):

Also wenn du dir sicher bist, dass das mit der "beta5" entstanden ist, dann hab ich dir auf jeden Fall einen falschen Link geschickt und du solltest jetzt mit der "beta6" keine Fehler mehr haben, da der finale Fix und das Entfernen der Funktion, die die csv erstellt, gleichzeitig committed wurde.



Ich bin immer noch erstaunt, dass das bei dir doch so häufig vorkommt, ich hatte dieses Problem wahrscheinlich auch 2mal insgesamt und das letzte mal ist auch schon Monate her. Zumindest hatte ich damals das gleiche Verhalten, dass der Hotkey mal nicht mehr ging.
Aber ich hab der Sache auch nicht weiter Beachtung geschenkt, da es halt so selten war, dass man es nicht reproduzieren konnte, bis du kamst^^

Auf deinem System scheint das Archiv beim Starten einer Aufnahme manchmal so schnell gestoppt zu werden, dass die letze Zeile die dort drin ist, nicht gleichzeitig auch in den simultan gestarteten live Capture Daten drin ist, was aber immer der Fall sein muss.
Wenn ich das mit meinem System beobachte, hab ich immer mindestens 10 Zeilen, die sich überlappen, bei den beiden Fällen in denen du die csv geschickt hast, hätte in deinem Archiv nur eine einzige neuere Zeile drin sein müssen, damit es funktioniert.
Daher ist der Fix, dass wir das Archiv beim Start der Aufnahme einfach so lange weiterlaufen lassen, bis es wirklich mit der ersten aufgenommenen Zeile übereinstimmt.

 

[Sk3ptizist]

ja und komisch, dass es anscheinend nur bei BF5 passiert?
ich hatte mit der Version 1.5.2 mitte Juni angefangen und es da auch nur 2-3 mal gehabt
aber gut, dass ihr da eine logische Erklärung/Lösung gefunden habt, bei mir war das eher schrödingers Katze 🐈

 

[Taxxor]

Ich habe auch lange gerätselt, obwohl ich schon bei deiner ersten Log Abgabe anhand des dort spezifizierten Fehlers drauf gekommen bin, wo der Fehler passiert.
Ich bin dann aber davon ausgegangen, dass bei deinem Archiv einfach was völlig unlogisches an der letzten Stelle reingerutscht sein musste, um den Fehler auszulösen.
Aber wir hatten dann alles abgefangen, was das bewirken könnte und der Fehler kam bei dir immer noch^^

Daher hab ich ja am Ende die Funktion eingebaut, um mir die Archivdaten, mit denen der Fehler passierte, mal anschauen zu können, zusammen mit den Zeitangaben des letzten Archiv Eintrags und des ersten "live" Eintrags, die ich auch noch in den Log habe schreiben lassen.
Und da kam dann raus, dass dein Archiv völlig normal aussieht, aber der erste "live" Eintrag bei dir eben 5-10ms neuer als der letzte Archiveintrag war. Damit das ganze funktioniert und die beiden Datensätze zusammengefügt werden können, muss es aber genau andersrum sein.