Fehler: "Could_not_add_TS_Doctor_source_filter_to_graph"

[Xa89]

Auf dem Rechner ist nur Windows 10 mit Windows Defender Antivirus ohne ein fremdes Antivirus-Tool.
Im AC3-Modus funktioniert es ja und der Fehler ist auch nicht wichtig.

Die kleine Aufnahme (5 MB) timeshift.ts ist allein unter C:/Strong_Video/Timeshifts.
Erster Versuch
- TS Doctor gestartet.
- Das erste Mal (Öffnen über das Fenster Aufnahme Auswählen):
- das Fenster der Analyse ist nur für einen Augenblick zu sehen und wird geschlossen.
- Klick auf "Nur Überprüfen" und nach der Überprüfung klicke ich auf "OK".

- Die Aufnahme nochmals über das Fenster "Aufnahme Auswählen" geöffnet:
- Videoanalxse startet und dann kommt der Fehler: Could not add TS Doctor source filter to graph [0xFFFFEFFC].

- Die Aufnahme nochmals öffnen über "Zuletzt geöffnet":
- Videoanalyse startet (Bilder sind zu sehen) und bringt etwas später die Meldung "Keien Werbung gefunden".

Zweiter Versuch:
- TS Doctor gestartet.
- Aufnahme über Datei/Öffnen ausgewählt.
- das Fenster der Analyse ist nur für einen Augenblick zu sehen und wird geschlossen.
- Aufnahme nochmals über Datei/Öffnen ausgewählt.
- Videoanalxse startet und dann kommt der andere Fehler: Could not add TS Doctor source filter to graph [0x80004005]
- Aufnahme nochmals über Datei/Öffnen ausgewählt.
- Videoanalxse startet und dann kommt der andere Fehler: Could not add TS Doctor source filter to graph [0x80004005]
- Aufnahme nochmals über Datei/Zuletzt geöffnet ausgewählt.
- Videoanalxse startet und dann kommt der andere Fehler: Could not add TS Doctor source filter to graph [0x80004005]
- kann ich beliebig oft wiederholen

[Cypheros]

Hab das mit Aufnahmen verschiedener Receiver getestet und kann den Fehler nicht mehr reproduzieren.

Nachdem ich den TS-Doctor 2.0.99 neu installiert hatte, hatte ich den Fehler bei den ersten beiden Aufnahmen auch. Als ich versucht habe den Fehler mit dem Debugger zu analysieren, war das Problem verschwunden und ist seither nicht wieder aufgetreten.

Zu Fehler 0x80004005 findet man im Internet die verschiedensten Ursachen. Scheint irgendwie mit Rechten oder Zertifikaten oder sowas zu tun zu haben. Taucht oft im Zusammenhang mit Windows 10 Updates auf.
Welche Windows 10 Version? Ist Dein Rechner mit dem Internet verbunden?

Video-Analyse liefert mit den LAVFiltern bei H.265 kein brauchbares Ergebnis, da die Sprünge von den LAVFiltern bei H.265 sehr unsauber sind und die ersten Sekunden kein brauchbares Bild liefern. Das ist aber eine andere Baustelle.

Es wird in naher Zukunft eine TS-Doctor-Version geben, die den Windows 10 HEVC-Decoder verwenden kann und damit eine bessere H.265-Decodierung liefert.

[wurzel]

2.0.99 zeigte nach Update auch den Fehler.

Drag&Drop von Receiverplatte auf Fenster.
Mpeg2-Filter stand auf LAV => Dieser Fehler erschien wieder.

Umgestellt auf AUTO:
Mpeg2-Filter= AUTO => funktioniert

Wieder Zurück auf LAV umgestellt
Nun funktioniert LAV auch.

Zwischendurch kam wieder der Effekt - Forschrittsbalken 1 bis Ende - Steht (aber kein crash)
Dazu hatte ich von der Receiverplatte via Dateidialog geöffnet - nicht drag&drop.

Tritt wohl nur auf, wenn von der Receiverplatte geladen wird. dort sind es mehrere Dateien, die die genannte Datei erfordern.

Welche Dateien sollen blockiert sein?
Hab bislang Windows 8.1 ... Siehe Signatur

[Xa89]

Auf meinem Rechner ist Windows 10 Home, Version 1703.
Der Fehler hat eher was mit der Aufnahme zu tun, denn die reparierte kleine Aufnahme im gleichen Ordner verhält sich anders beim Öffnen (über Fenster Aufnahme Auswählen funktioniert es).
Wenn ich die raparierte Aufnahme (H.265) aber in das Fenster ziehe kommt der Fehler egal wie ich sie nochmals und nochmals öffne.

[Xa89]

Beim Rechner mit Windows Vista Prof. und Version 2.0.97 kam kein Fehler und nach dem Update auf die 2.0.99 auch keiner.
Nach dem Update schließt sich aber die Videoanalyse sofort nach dem Öffnen der gleichen Aufnahme.
Beim zweiten Öffnen (Zuletzt geöffnet oder Datei/Öffnen) funktioniert es mit der Videoanalyse.
Nach dem Reparieren und nochmals Öffnen der Aufnahme im Fenster kommt aber ein Fehler.

TS-Doctor video analysis log
demuxer: LAV Splitter
video filter: LAV Video Decoder

file: C:\ProgramData\Cypheros\TsDoctor2\Temp\MultiFile.lst
start: 01:14
Could not add TS Doctor source filter to graph [0xFFFFEFFC]
"C:\ProgramData\Cypheros\TsDoctor2\Temp\MultiFile.lst"

end of scan
duration: 08:40

[Mam]

Arrrrhh! 

Scheffe! Du sollst Fehler WECH machen, nich von Usah zu Usah weiterschicken!


(mal son kleiner Tipp: es gibt einen neuen AMD Treiber, den man braucht, um bestimmte moderne Spiele machen zu können (sonst sind sie sooo traurig, sie starten dann gar nicht erst). Seit der Version (17.7.2) spuckt dann der Doc nur noch Gift und Galle.)

Nachtrag: Ist nachvollziehbar ein Timing Problem. Hat der (flotte) Rechner nix zu tun, fährt er den Doc gegen die Wand. Ist die CPU zu 100% mit was Anderem beschäftigt, dann geht die Videoanalyse auf einmal... DU SOLLST NICHT NUR FÜR DIE LAHMEN KRÜCKEN PROGRAMMIEREN!!! Kauf Dir mal n ordentlichen Rechner, dann kriegst Du solche Probleme auch mal eindringlich am eigenen Leib zu spüren!

[Cypheros]

Naja, würde ich gerne aber sobald ich einen Debugger aktiviere, ist der Fehler fort. Ist das mal wieder so ein tolles neues Sicherheits-Feature von Windows 10?
Hab das Timeout von 1,5 auf 4 Sekunden erhöht.

Versuch mal die Test-Version: http://www.cypheros.de/download.php?f=TSDoctor2_Ger_2.0.100.exe

Ist das Problem immer noch vorhanden?

[Mam]

Naja, würde ich gerne aber sobald ich einen Debugger aktiviere, ist der Fehler fort. Ist das mal wieder so ein tolles neues Sicherheits-Feature von Windows 10?
Hab das Timeout von 1,5 auf 4 Sekunden erhöht.

Äääh, wie wärs mit LESEN ? ? ?
Du kannst es auch auf 60s erhöhen, das Problem wirst Du damit nicht beseitigen.

Es liegt ja in der anderen Richtung, bei schnellen Rechnern ist irgendwas schon lange passiert, nur der Doc kriegt es nicht mit.
Also geht wohl Deine Quittung "ich bin nun der Connecte-te" in den Orkus und Du wartest ab dann auf Godot.

Ich sagte doch: WENN DER RECHNER LAHMER IST, dann kriegt der Doc die Msg mit und alles ist gut.

Nachtrag: hab die 100 probiert, ging diesmal. Aber das muß gar nix heißen. Warum zeigt die VA nun meistens Klötzchen an? da scheinen die Dekoder nicht mehr richtig zu funktionieren...

Irgendwie gehst Du zu spät auf Empfang. Oder Du startest einen Thread zu spät. Vergiß nicht, Locks zu verwenden, wenn Du solche Konstrukte verwendest:

• VideoFenster=CreateNewFenster(...)
• CreateThread(LauereAufNachrichten, VideoFenster)

Das geht meistens in die Hose bei Multithreads und Multicores.
Richtig ist dann:

• NewThread=CreateThread(WarteaufNachrichten, NULL, THREADSUSPENDED)
• VideoFenster=CreateNewFenster(...)
• SendMessage(HIERISTDEINPARAMETER,NewThread,VideoFenster)
• ChangeThreadState(NewThread,THREADRUNNING)

Also, ERST Thread erzeugen (damit seine Msgqueue angelegt wird), Thread schlafen legen.
DANN VideoFenster erzeugen.
DANN dem Thread mit einer benutzerdefinierten Msg den Parameter senden (oder ganz braun eine globale Variable benutzen).
ENDLICH den Thread loslaufen lassen.

Der Unterschied liegt darin, dass Nachrichten für einen schlafenden Thread schon in dessen Queue eingereiht werden, somit nicht verloren gehen können (solange die Queue nicht überläuft).

Und klar geht das dann mit dem Debugger, der macht ja nach jedem Aufruf Pausen, damit klappt es immer!

[Cypheros]

An der Stelle, wo der Fehler passiert, werden noch keine Daten verarbeitet. Noch keine Videodecoder oder sonstwas vorhanden.

Es wurde gerade eben der Graph erstellt und dann soll als allererstes der "TS-Doctor file source" Filter erstellt und initialisiert werden. Dazu gehört auch Load vom ICyAsyncControl-Interface um die Datei/Dateien der Aufnahme zu öffnen.

Beim Öffnen der Datei/Dateien geht was schief obwohl die gleichen Routinen verwendet werden, die bei der Analyse und im Vorschaufenster tadellos funktionieren.

Da die Dateizugriffe aus Geschwindigkeitsgründen in eigenen Threads ablaufen, vermute ich, dass der vorherige Analyse-Thread die Dateien noch nicht vollständig freigegeben hat, wenn die VA startet oder eine Windowskomponente wie Defender noch den Daumen drauf hat.

Ich konnte das Problem nur reproduzieren wenn ich mit einem schnellen Rechner auf ein lahmes Netzwerklaufwerk(Synology DS112+) per UNC zugegriffen habe. Zugriff über zugeordneten Laufwerksbuchstaben produzierte erstaunlicherweise keinen Fehler.

Ist schon sehr eigenartig.

Hab die Routinen aber auch mit zusätzlichen Fehlermeldungen ausgestattet, so dass nun genauer spezifiziert wird, bei welchem Schritt was schief läuft.

Mal sehen, ob wir die tatsächliche Ursache finden können.

[Mam]

An der Stelle, wo der Fehler passiert, werden noch keine Daten verarbeitet. Noch keine Videodecoder oder sonstwas vorhanden.

Ja, iss klaaah 
Meine Vermutung geht ja nicht umsonst in die Richtung, dass Du da gerade etwas derartiges anlegen willst, aber die Liste im Speicher zur Aufnahme des Ergebnisses existiert noch gar nicht, weil ein Async Aufruf VORHER irgendwo noch gar nicht beendet ist. So a la "thread#2 überholt thread#1"

Dazu gehört auch Load vom ICyAsyncControl-Interface um die Datei/Dateien der Aufnahme zu öffnen.

Das Inteface kennen MAM und Google leider überhaupt nicht, bzw. es gibt völlig unterschiedliche Treffer, die auf verschiedene Produkte verweisen.
Welches konkrete Schweinerl hättens denn gerne?

Da die Dateizugriffe aus Geschwindigkeitsgründen in eigenen Threads ablaufen, vermute ich, dass der vorherige Analyse-Thread die Dateien noch nicht vollständig freigegeben hat, wenn die VA startet oder eine Windowskomponente wie Defender noch den Daumen drauf hat.

Teil A mag sein, den Defender würde ich aber erstmal als unbeteiligt betrachten. Wenn der zuschlägt, blockiert er erstmal ALLE Threads Deines Prozesses. Wenn Du also keine fiesen Tricks (separater Hintergrundtask in eigener Prozessgruppe, dem die neu angelegten Threads "geschenkt" werden) auf Lager hast (was ich bei der gegebenen Programmiersprache als quasi unmöglich betrachte), stört der Defender Deine Kreise nicht.

Ich konnte das Problem nur reproduzieren wenn ich mit einem schnellen Rechner auf ein lahmes Netzwerklaufwerk(Synology DS112+) per UNC zugegriffen habe. Zugriff über zugeordneten Laufwerksbuchstaben produzierte erstaunlicherweise keinen Fehler.

Nicht wirklich erstaunlich, aber die Erklärungen dafür würden vom Thema wegführen und wären nicht zielführend für Dich.

Ist schon sehr eigenartig.
Hab die Routinen aber auch mit zusätzlichen Fehlermeldungen ausgestattet, so dass nun genauer spezifiziert wird, bei welchem Schritt was schief läuft.
Mal sehen, ob wir die tatsächliche Ursache finden können.

Ohne penetrant wirken zu wollen 
Ein "richtiges" 64 Bit Programm hätte jetzt schon mal ein paar Emulationsebenen weniger zu debuggen...


(Ansonsten kommt jedes Programm mal an die Grenze, wo es anfängt mystisch zu werden. Man sollte dann aufhören, einen Schritt zurück gehen und über eine Neuentwicklung V3.0 von Grund auf nachdenken.)
Hatte ich eigentlich schon gratuliert? Laut C'T Ranking benutzt Du ja die zweitgehasste Programmiersprache der Welt  (nicht aufgeben, kommst sicherlich nochmal auf Platz 1!)

[Cypheros]

Sorry, ich meinte IFileSourceFilter, darüber läuft das Load: https://msdn.microsoft.com/de-de/library/windows/desktop/dd389981(v=vs.85).aspx



Hey Xa89, wie sieht es bei Dir aus mit der Version 2.0.100? Ist der Fehler bei Dir weg oder immer noch da?

[Mam]

Sorry, ich meinte IFileSourceFilter, darüber läuft das Load:

Urks! 
Hmm, der Kram war vor 20 Jahren schon Sch#++!%, ich dachte, der Mist wäre schon lange abgeschafft und inzwischen gar nicht mehr verfügbar?

(Alles, was mit IUnknown zu tun hat, ist krankes Hexenwerk!)

Machst Du den Load() Aufruf mit einem NULL-Typ, oder übergibst Du da eine Structure mit Wunschkandidaten?

[Xa89]

Ich hab zuvor noch eine 16 Stunden Aufnahme geschnitten mit der 2.0.99 und der Fehler kam immer beim erneuten Öffnen im Fenster "Aufnahme auswählen". Mit der 2.0.100 kommt der Fehler nicht mehr bei dieser Aufnahme (Tele5 HD, HEVC).
Bei meiner kleinen 5 MB Testaufnahme (Prosieben HD, HEVC) hat sich freilich nichts geändert.
Also: beim ersten Öffnen schließt sich sofort das VA-Fenster, beim mehrmaligen erneuten Öffnen funktioniert die Videoanalyse. Klicke ich aber auf "Nur Überprüfen" und öffne wieder, dann steht lange "Initialisiere" und kommt der Fehler:
TS-Doctor video analysis log
demuxer: LAV Splitter
video filter: LAV Video Decoder

file: C:\ProgramData\Cypheros\TsDoctor2\Temp\MultiFile.lst
start: 48:25
Could not open file [0xFFFFEFFC]
"C:\ProgramData\Cypheros\TsDoctor2\Temp\MultiFile.lst"

end of scan
duration: 00:14

[Xa89]

Beim Schließen der Anwendung (2.0.100) bekommme ich einen Runtime error.

[Xa89]

Bei der 2 GB Aufnahme von Tele 5 HD hat sich auch mit Version 2.0.102 nichts geändert, [0xFFFFEFFC] kommt noch immer. Vermutlich hat es mit der Größe der Aufnahme zu tun.
Die vorige Version 2.0.101 hat mich zweifeln lassen an der Zuverlässigkeit des Receivers Strong SRT 8540 bei Aufnahmen.
Beim Schnitt der Nachtaufnahme Vox HD entstanden nur kurze Filme und zum Teil verschlüsselt:
z.B. File sizes: E:\HEVC\Thor – The Dark Kingdom.ts 396.703 KB [CRC=57063D1B]

Mit Version 2.0.102 wird der Schnittbereich 11 (Film ist ohne Werbung) richtig als Film erstellt:
File sizes: E:\_CUT\Thor – The Dark Kingdom.ts 1.415.350 KB [CRC=A39FE932]
PID stream sizes
$0161:   1.220.024 KB
$0162:     195.044 KB