Support forum for DG Tools

Maybe you have a slow hard drive and it is masking the code improvements.

How big is the file that took 56 seconds and what is the video type?

File size: 3.87 GB
#Frames: 61'729
Video type: AVC

My PC does a 4.2GB AVC M2TS in 18 seconds. So I guess your disk IO is seriously deficient. You may want to look into that.

Exactly. Benchmark testing with my conventional HD indicates 70.....80 MB/s read or write transfer rates.
So this seems to be the bottleneck in my case.
Anyway, I am happy that v2048 works with my GeForce 9600 GS.

I have a fast spinning mechanical drive with a very large cache interfaced with SATA 600 (not an SSD). HDTune gives me a read benchmark of 190 MB/s.

That's about 2.5 times of what I am getting with my HD. It is clear now why I am not getting more speed gain with v2048. But as long as it works with my system, I am fine.

I never announced the changes for 2048, so here they are. Note that the last two were slipstreamed
today, so if you want them, please re-download and update DGIndexNV and DGDecodeNV.

* Greatly improved the indexing speed (almost twice as fast for transport streams).
Note that you need relatively fast disk I/O to see these improvements. CPU optimizations
can be swamped by slow I/O.

* Updated to CUDA version 6.5 and built with VS2013 Express (Update 3 RC). Note that CUDA architecture
sm_10 support was dropped by nVidia. That means really old slow cards are no longer
supported.

* Made fixes so that alternate languages set via the system locale setting are now properly
handled. This is a "poor man's" substitute for full Unicode support. Full Unicode support
is not possible because it is not supported by Avisynth.

admin wrote:...Note that CUDA architecture sm_10 support was dropped by nVidia. That means really old slow cards are no longer
supported.

The "really old slow" part describes me pretty well!

I suspect your readme is done already but for next time you might want to add some more clues as to what this means 'zackly i.e. I recall that I looked-up my 9600GT (which she's a no work) but don't remember the conditions i.e. what sm_10 translates to in the world of non-techies.

But maybe anudder cuppa coffee and I'll recall...

Good morning, laserfan. Search for sm_10 in that "Search this topic..." box at the top and you will find everything you need to know.

I've added the relevant link to the readme. Thanks for the suggestion.

Build 2049 is now available.

* Added support for 4K/UHD resolutions (but no HEVC yet).

* Added a bunch of cards to the GPU information lookup table.

admin wrote:* Added support for 4K/UHD resolutions (but no HEVC yet).

Excellent! I wasn't sure about this feature.
I've got a bunch of trailers in 2K/4K that I've been using FFMS2.
I just thought they were encoded differently.

Thanks for the update.

I'm happy that you find it useful, sparktank. Thank you for the feedback and good luck for your projects.

I slipstreamed a fix for DGDecodeNV.dll 64-bit that caused it to fail in StaxRip and elsewhere. The 32-bit version is not affected. Please re-download 2049 and update dgdecodenv.dll if you need this fix.

Thanks to staxrip76 for helping me to identify and fix this issue.

I slipstreamed a fix for DGIndexNV.exe that caused it to not properly clean up when the CLI exits using the -e option. This could cause subsequent starts to fail. This may affect 3rd-party GUIs and so users of those apps should consider re-downloading and updating DGIndexNV if they are experiencing any issues.

Build 2050 is now available.

* Added cards to the GPU information lookup table.

* Changed the licensing scheme so that it is now stable across Windows updates. The only thing that will change the machine ID now is a change of motherboard.

* For MKV files the FPS value is now taken from the container and not the elementary stream.

* The CL interface with -h now no longer generates a pop-up for a bad license but prints a console error message instead. Also, the CLI now returns values as follows:

0: everything OK
1: input file cannot be opened
2: bad license

admin wrote:Build 2050 is now available.

Does it include support for Windows 10 as the version you compiled recently?

The release includes all previous slipstreams. It is still based on CUDA 6.5. There is no official statement from nVidia that 7.5 is required to support Windows 10. You seem to be the only person having any issues in that regard, and only for use of KNLMeansCL. Also, you reported that the test build with CUDA 7.5 did not change anything.

I slipstreamed into 2050 a licensing fix. It now properly uses only the motherboard serial number. You will need to make a new license when you grab this, theoretically the last you'll ever need for your specific motherboard.

There are some other changes to licensing. The license generator now detects duplicate machine IDs and won't increment the count if you re-enter a machine ID you already licensed. You can use that to query the license keys you already made. If you put a new machine ID, however, you will get incremented. Next, the maximum number of licenses was increased to 16. Finally, VBVChecker licensing was made the same as the other DG tools. Now all the tools should generate the same machine ID (except DGAVCDecDI, which I plan to kill very soon).

These changes make the licensing much more user-friendly. With these changes, going forward, I am less receptive to license count reset requests, as 16 unique machine IDs per donation is fair. Eliminating the reset also simplifies maintenance.

admin wrote:except DGAVCDecDI, which I plan to kill very soon

That is bad.

It's the only working decoder with KNLMeansCL.

Everything works for me. And I thought you were using DGDecIM?

admin wrote:Everything works for me. And I thought you were using DGDecIM?

You are right. Too much work in these days.

Slipstreamed some more changes for 2050:

* For MKV files the FPS value is now taken from the container and not the elementary stream.

* The CLI interface with -h now no longer generates a pop-up for a bad license but prints a console error message instead. Also, the CLI now returns values as follows:

0: everything OK
1: input file cannot be opened
2: bad license

Hmmm. I think maybe even including the date into the zipped archives might help distinguish the slipstreams from each other.
As I like to archive downloads, it would help to ensure that I have used latest slipstream possible.

When I access the site to get to the tools for slipstreams, I kind of forget the date when I go to download the slipstream and then have to wonder which one I actually have set to go. (as they are all given the same name)

dgdecnv2050_2015-10-01.zip
(or whatever date format you use)
would help when people have something to report. It would be a quick reference as to what slipstream they've used.
(or archived)

I forgot which slipstream we're on for this one, so I added "ss1" to the end.
Looking through the thread, it's the second slip stream.

The extraction process I do manually to the load location.

Updated and appreciate the continual updates!