Tweet
Spoon - I'll start with a somewhat esoteric suggestion of allowing the disc recognition timeout in the batch ripper to be end user controllable either via a config setting ...or a "pseudo" command line option in the loader configuration screen.
There seems to be a hardcoded timeout of xx seconds that starts from the time a load.exe exits normally to the time the batch ripper assumes no disc was inserted. In this time, it presumably asks the drive to spin up the disc and return several types of information.
I've noticed that some drives naturally take a short amount of time to do this, while others drives can take a long amount of time (and the time can be dependent on external factors).
In addition, some filter drivers (AnyDVD comes to mind), when active, can significantly add to the recognition delay.
Under some combinations of more than one of a) a slow-to-ready drive, b) certain filter drivers, and c) the drive state that the load.exe left the drive in when exiting...the time-to-readiness can exceed the hardcoded timeout in the batch ripper.
This can be mitigated by disabling filter drivers, etc., but I am finding, as I optimize some of my drive handling routines in the ULCLI and build some througput optimized versions of my drivers...I end up having to insert some manual time delays under certain circumstances, delays which may be drive specific. E.g. such as when I asynchronously ask for the drive to close/disc to spin up and immediately exit the load.exe.
It'd be nicer if I could just tell end users to increase their disc recognition time vs. having to make script adjustments that vary from drive to drive.
-brendan
PS - while testing, accuraterip has, yet again, paused a robotic batch session with a dialog asking me to submit my accuraterip results. Can this be somehow avoided in the middle of batch sessions other than disabling submission reminders entirely? An answer of RTFM is acceptable if it is likely to work.
There seems to be a hardcoded timeout of xx seconds that starts from the time a load.exe exits normally to the time the batch ripper assumes no disc was inserted. In this time, it presumably asks the drive to spin up the disc and return several types of information.
I've noticed that some drives naturally take a short amount of time to do this, while others drives can take a long amount of time (and the time can be dependent on external factors).
In addition, some filter drivers (AnyDVD comes to mind), when active, can significantly add to the recognition delay.
Under some combinations of more than one of a) a slow-to-ready drive, b) certain filter drivers, and c) the drive state that the load.exe left the drive in when exiting...the time-to-readiness can exceed the hardcoded timeout in the batch ripper.
This can be mitigated by disabling filter drivers, etc., but I am finding, as I optimize some of my drive handling routines in the ULCLI and build some througput optimized versions of my drivers...I end up having to insert some manual time delays under certain circumstances, delays which may be drive specific. E.g. such as when I asynchronously ask for the drive to close/disc to spin up and immediately exit the load.exe.
It'd be nicer if I could just tell end users to increase their disc recognition time vs. having to make script adjustments that vary from drive to drive.
-brendan
PS - while testing, accuraterip has, yet again, paused a robotic batch session with a dialog asking me to submit my accuraterip results. Can this be somehow avoided in the middle of batch sessions other than disabling submission reminders entirely? An answer of RTFM is acceptable if it is likely to work.
Comment