DGDecNV + Avisynth verursachen Totalabsturz

Gunnar

Hallo,

Jetzt hat es mich auch erwischt:

[Blockierte Grafik: http://s13.directupload.net/images/100924/67zq2k5u.jpg]

Beim Wiedergeben von einem Avisynthscript/DGDecNV2026 mit dem MPC, stürzt mein Rechner ab. Und nur dann. Virtualdub läd das Script ohne Probleme.

LoadPlugin("c:\DGDecNV\DGDecodeNV.dll")
DGSource("k:\0000.dgi")
ConvertToYUY2
---

Computer:
DualCore Intel Core 2 Duo E8600, 3333 MHz
2x Corsair XMS2 CM2X2048-8500C5 2 GB DDR2-800
Asus P5Q (aktuelles Bios)
GeForce GT 240 - 1024 MB (aktuelle Treiber)
WinXP-SP3

Habe mal mit Google nach Infos gesucht ..... dieses "nv4_disp - Problem" haben schon etliche User gehabt. Eine echte Lösung gibt es wohl nicht. Eine Hardwareunverträglichkeit Board/Speicher/GT240 könnte es sein. Habe auch schon mal an den Biossettings geschraubt, Treiber neu installiert usw ... hat nix gebracht.

Wenn jemand noch einen Tip für mich, ich wäre sehr dankbar dafür.

Gruß Gunnar

Didée

Vielleicht kollidiert ein Hardware-basierter (oder -mitbenutzender) Video-Renderer mit der Hardware-Dekodierung. Welcher Video-Renderer ist im MPC eingestellt? Einfach mal wechseln, vielleicht hilft's.

Gunnar

Hab ich auch gemacht (Overlay Mixer, System Standard, VMR) ... gleiches Resultat. Es kann Ein zwei Mal gut gehen, aber dann stürzt der Rechner beim Öffnen des Scripts oder kurz danach ab.

Mit DGDecodeNV hab ich auch noch andere Probleme.
Scripts mit DGDecodeNV lassen sich weder mit Procoder noch mit CCE-Basic (skaliert auf SD) laden. Nur mit MeGUI klappt es einigermaßen. Manchmal hängt das Programm aber auch. Dieser CUDA-Kram scheint bei mir nicht vernünftig zu laufen. Dabei habe ich mir die NVidia GT240 auch gekauft um mit DGDecodeNV arbeiten zu können. Hatte vorher immer ATI-Karten und nie Probleme mit denen.

Komisch nur ist, das PowerDVD10 und auch CoreAVC 2.0, beide mit CUDA-Unterstützung, einwandfrei bei mir laufen. Warum DGDecodeNV nicht ?
Ich hätte nächste Woche die Möglichkeit die GT240 in einem anderen Rechner zu testen. Blöd nur das ich dafür eine zusätzliche Lizenz (DGDecodeNV) brauche.

Gruß Gunnar

LigH

Ich glaube, ein Nutzer hat bis zu 8 Lizenzen frei...

Aber es wäre sicher nicht falsch, mal im englischen doom9-Forum zu fragen, welche möglichen Ursachen es gibt.

Etwas ähnliches kenne ich auch - mit Sound: Nur ein bestimmtes Spiel schafft es, meinen PC mit Bluescreen in der nvmcp.sys zu crashen (nForce4 Onboard Audio-Treiber).

Gunnar

Zitat von LigH

Ich glaube, ein Nutzer hat bis zu 8 Lizenzen frei...

Aber es wäre sicher nicht falsch, mal im englischen doom9-Forum zu fragen, welche möglichen Ursachen es gibt.

Hätte ich längst gemacht, aber mein Englisch-Kauderwelsch verstehen die nicht.

LigH

Na ja, ich werd's mal erwähnen... Post im englischen doom9-Board

Melde bitte auch mal die exakte Version des MPC, sowie exakte Fehlermeldungen aus ProCoder und CCE-Basic - auch beim AppCrash.
__

P.S.:

Groucho2004 meint:

Du sollst sicherstellen, dass du wirklich (mindestens) Build 2026 von DGDecNV verwendest -- es gab bei früheren Versionen eher Abstürze und Probleme mit Encodern, v.a. wenn diese nur mal kurz das Skript öffnen, um Videoattribute abzufragen, ohne ein Frame Video abzuholen.

Außerdem wäre es sehr empfehlenswert, WHQL-Grafiktreiber zu verwenden.

Gunnar

Erst mal vielen herzlichen Dank für deine Mühe, LigH.

Es ist mir sehr wichtig dieses DGDECNV - Problem in den Griff zu bekommen.

Ich verwende Build 2026 von DGDecNV. Der MPC (HomeCinema v1.3.1249.0) crasht also mit genau dieser Version.

Die Procoder und CCE-Basicabstürze traten ohne Fehlermeldung auf. Die beiden Encoder haben sich einfach beendet. Allerdings verwendete ich da noch DGDECNV 2024. Ich werde in Kürze das auf der anderen Partition noch mal testen mit der 2026er Version.

Der installierte Nvidiatreiber hat die Version 258.96 WHQL, und ist aktuell.

Gruß Gunnar

Didée

Gunnar, irgend etwas stimmt bei Deinem System nicht. Bei soweit identischen Komponenten: Nvidia GT240 / 258.96 WHQL, DGDecNV 2026, MPC-HC 1.3.1249.0 treten bei mir keine Probleme auf. Habe zwei verschiedene Quellen (40-Minuten-Serie) von Anfang bis Ende im MPC durchlaufen lassen.

CCE und Procoder kann ich nicht testen ... aber es könnte mit der Version 2024 zusammenhängen. Da gab's noch den Bug, wenn eine Anwendung ein Avisynth Script einliest, ohne einen Frame anzufordern ... das hat öfter mal Probleme gemacht. Soll in 2026 behoben worden sein.

Gunnar

Mhhmm ... aber mal abgesehen vom CCE und Procoder, was könnte denn die Ursache für den DGDECNV-Crash sein, und warum funktioniert alles andere bei mir ?

Heute abend sitze ich wieder vor meinem PC und teste CCE und Procoder mit der 2026er Version. Der zweite PC steht mir morgen zur Verfügung, und dort ist ein frisch installiertes XP drauf. Mal sehen ob der DGDECNV-Decoder auch ohne Lizenz funktioniert und nur DGIndexNV von der Lizensierung betroffen ist.

Gruß Gunnar

LigH

Warum sollten DGIndexNV.exe und DGDecodeNV.dll nicht auf die selbe Lizenz zugreifen? Das Indexieren ist doch eine Kleinigkeit - das Decoder-Plugin ist eigentlich der wichtige Kern des Paketes. DGIndexNV ist nur deshalb zum Ermitteln des Maschinencodes geeigneter, weil es eine EXE mit eigener Oberfläche ist. Neue Maschinen-ID, gleiche Nutzer-ID -- zusätzliche Lizenz als license.txt, die von beiden gelesen wird.

Didée

Moment mal ... wie ist das eigentlich: wenn eine DLL von Avisynth geladen wird, kann die DLL dann "wissen", aus welchem Verzeichnis sie geladen wurde? Bei DGIndex ist der Zusammenhang ja einfach: *exe und license.txt müssen im gleichen Verzeichnis liegen.

Gerade probiert: aus dem Verzeichnis die license.txt entfernt, und ein Avisynth-script mit DGsource geladen (*.dgi existierte bereits). Die Source lädt erfolgreich, und wird korrekt abgespielt.

Macht ja irgendwie auch Sinn ... wer keine Lizenz hat, kann keine Videos indizieren. Und wenn keine Indexfiles erstellt werden können, dann braucht die DLL auch keine Lizenzdaten zu kontrollieren ...

Tom Keller

War auch zu erwarten. DGIndexNV legt ja keine Pfadangaben in der Registry oder sonst wo ab, auf die die DLL zugreifen könnte (was mir z.B. aufgefallen wäre, da ich multiple Instanzen der DGDecodeNV.dll in verschiedenen Verzeichnissen habe). Also "weiß" die DLL auch nicht, wo sich die Lizenz befindet und wird sie daher nicht überprüfen. Außerdem wäre das (wie Didée schon schreibt) sowieso überflüssig...

Groucho2004

Zitat von Didée

Moment mal ... wie ist das eigentlich: wenn eine DLL von Avisynth geladen wird, kann die DLL dann "wissen", aus welchem Verzeichnis sie geladen wurde?

Natürlich, dafür gibt es GetModuleFileName() in der Win32 API.

Gunnar

So, mein Problem ist gelößt.

Procoder und CCE-Basic arbeiten tatsächlich einwandfrei mit der 2026er Version. Wunderbar !
Der MPC läd nun auch das Script ohne abzustürzen. Ich habe mir aber die Mühe machen müssen ein altes XP-Backup zu nehmen, und alles auf den neusten Stand bringen zu müssen. Weiß der Deibel welcher Fehler sich im Laufe der Zeit eingeschlichen hatte.

Danke nochmals für die Mühe und die Tips.

Gruß Gunnar

LigH

@ Groucho2004: :welcome:
__

Dann könnte man also, wenn man genau weiß wie, die Indexdatei mit einem fremden Tool erzeugen, und den Decoder ohne Lizenz benutzen?! -- Glaube nicht, dass Donald Graft derartiges nicht vorausgesehen hätte.

Interessantes Gedankenspiel. Na gut. Genaues weiß ich nicht. Den gesamten Beitrag zu DGDecNV im englischen Board habe ich nicht mehr im Kopf, aber ich kann mich erinnern, dass da viel diskutiert wurde, was wie geschützt wird oder nicht. Und geändert hatte sich das mehrfach.
__

@ Gunnar: Prima.

Ich hoffe, DGAVCDecDI wird dann auch mal in gleicher Weise korrigiert...

Groucho2004

Zitat von LigH

Dann könnte man also, wenn man genau weiß wie, die Indexdatei mit einem fremden Tool erzeugen, und den Decoder ohne Lizenz benutzen?!

Genau. Allerdings lohnt es sich der Zeitaufwand wohl kaum nur um 12 Euro Registrierungsgebühr einzusparen.

Jetzt mitmachen!