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
DGDecNV Latest Build 2050
Re: DGDecNV Latest Build 2050
Does it include support for Windows 10 as the version you compiled recently?admin wrote:Build 2050 is now available.
Re: DGDecNV Latest Build 2050
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.
Re: DGDecNV Latest Build 2050
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.
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.
Re: DGDecNV Latest Build 2050
That is bad.admin wrote:except DGAVCDecDI, which I plan to kill very soon
It's the only working decoder with KNLMeansCL.
Re: DGDecNV Latest Build 2050
Everything works for me. And I thought you were using DGDecIM?
Re: DGDecNV Latest Build 2050
You are right. Too much work in these days.admin wrote:Everything works for me. And I thought you were using DGDecIM?
Re: DGDecNV Latest Build 2050
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
* 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
Re: DGDecNV Latest Build 2050
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!
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!