View Full Version : AUTOGK not finding all VOB files
heinz57g
23rd October 2004, 15:36
have tried for 5 days now, deinstalled/reinstalled decrypter/xvid/AGK
in all versions that made sense, same problem remains:
decrypter produces set of files, 1 IFO, 1 stream info TXT, and 4
VOB files numbered 1 thru 4. as always and 100 times before.
running AGK then only sees one of those VOB files, strangely
enough nbr 4, and ignores 1, 2 and 3.
already (in the log) the line after DEMUXING AND INDEXING shows
PROCESSING FILE: R:\Film\VTS_03_PGC_02_4.VOB o n l y, and
then continues normally. with only a quarter of the movie ...
does it make sense to post an entire log, or is this a known
problem? the logs are on another computer, but i sure could
post one if it helps. i have dozens of them showing the same
effect.
desperate - heinz -
jggimi
23rd October 2004, 15:46
If the following guesses doesn't solve your problem, then yes, post your log, the names of all files in the .vob directory, and the contents of the streams information file.
Guesses:[list=1] You are not decrypting in IFO mode. File mode is the default for DVD Decrypter.
You must decrypt in IFO mode in order to use AGK. This is a frequent mistake of the new user.
You are not running AGK in DVD mode. It is possible to run it in File mode and select a single VOB. This one is unlikely, but it's the only other explanation that comes to mind.[/list=1]
heinz57g
23rd October 2004, 18:06
tks for the quick reply, appreciated. unfortunately, NO to both
points: IFO mode for sure, and AGK in DVD mode too. but let me
get the files details and the log copied over from the other
computer, and pls pls pls, whoever has the time, have a look at it.
i guess you know how it feels to stand in front a problem totally
dumbfounded? previously thinking i knew everything about computers?
one more thing i found out looking at several of the logs: it does
not ALWAYS select the last of the VOB files. mostly #2, sometimes
#4, and sometimes #2 and #3 together, but never all 4 together as
it should be.
greetings - heinz -
heinz57g
23rd October 2004, 19:13
so, here the actual DECRYPTER files and the log. this time i was lucky:
it did choose #4, the shortest, so i did not have to wait long. the
compression figures naturally turn out nonsense on such a short file,
which was just the very end of the movie. but is clear (see the <<<<<<<
in the log) that the other three VOB files were ignored.
and once more: i tried DECRYPTER from 3.2.2.0 thru the latest from
a few days ago, AGK from 1.60 and 1.70, removed all, cleaned registry,
renewed whatever i could, same.
greetings - heinz -
R:\Before\
VTS_03_0.IFO 59,392 22-10-2004 23:55 -a--
VTS_03_PGC_02 - Stream Information.txt 886 23-10-2004 00:04 -a--
VTS_03_PGC_02_1.VOB 1,073,479,680 22-10-2004 23:59 -a--
VTS_03_PGC_02_2.VOB 1,073,604,608 23-10-2004 00:01 -a--
VTS_03_PGC_02_3.VOB 1,073,541,120 23-10-2004 00:03 -a--
VTS_03_PGC_02_4.VOB 262,719,488 23-10-2004 00:04 -a--
log:
[23-10-04 19:24:55] AutoGK 1.60
[23-10-04 19:24:55] OS: Win98SE (4.10.67766446).1
[23-10-04 19:24:55] Job started.
[23-10-04 19:24:55] Input dir: R:\Before
[23-10-04 19:24:55] Output file: Q:\CompressedVid\BeforeTheRain.avi
[23-10-04 19:24:55] Audio: Unknown language
[23-10-04 19:24:55] Subtitles: none
[23-10-04 19:24:55] Codec: XviD
[23-10-04 19:24:55] Target size: 1120Mb
[23-10-04 19:24:55] Started encoding.
[23-10-04 19:24:55] Demuxing and indexing.
[23-10-04 19:25:17] Processing file: R:\Before\VTS_03_PGC_02_4.VOB <<<<<<<<<<<<<<<<<<<<<<<<<<<
[23-10-04 19:25:17] Source aspect ratio: 4:3
[23-10-04 19:25:17] Source resolution: 720x576
[23-10-04 19:25:17] Found PAL source.
[23-10-04 19:25:17] Analyzing source.
[23-10-04 19:26:21] Source has percentage of interlacing in motion areas: 0.00
[23-10-04 19:26:21] Source is considered to be progressive.
[23-10-04 19:26:21] Found 11523 frames
[23-10-04 19:26:21] Audio size: 11,063,808 bytes (10.55 Mb)
[23-10-04 19:26:21] Overhead: 136,832 bytes (0.13 Mb)
[23-10-04 19:26:21] Video size: 1,163,204,480 bytes (1109.32 Mb)
[23-10-04 19:26:21] Running compressibility test.
[23-10-04 19:26:21] Writing the following script to Q:\CompressedVid\agk_tmp\BeforeTheRain_comptest.avs
===========================================================
LoadPlugin("C:\PROGRA~1\AUTOGK\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\AUTOGK\filters\autocrop.dll")
LoadPlugin("C:\PROGRA~1\AUTOGK\filters\undot.dll")
movie = mpeg2source("Q:\CompressedVid\agk_tmp\BeforeTheRain.d2v")
cropclip = autocrop(movie,mode=0,wmultof=4,hmultof=4,samples=10,aspect=0,threshold=34,samplestartframe=0)
fixed_aspect = 1.06666666666667
c_width = width(cropclip)
c_height = round(height(cropclip) / fixed_aspect)
input_par = float(c_width)/float(c_height)
input_par = input_par > 1.4 ? input_par : (4.0/3.0)
out_width = 704
out_height = round(float(out_width) / input_par)
hmod = out_height - (floor(out_height / 16 ) * 16)
out_height = (hmod > 4) ? (out_height + (16 - hmod)) : (out_height - hmod)
new_aspect = (float(out_width) / float(out_height)) / fixed_aspect
autocrop(movie,mode=0,wmultof=4,hmultof=4,samples=10,aspect=new_aspect,threshold=34,samplestartframe=0)
Undot()
LanczosResize(out_width,out_height)
SelectRangeEvery(83,15)
===========================================================
[23-10-04 19:30:00] Duration was: 3 minutes 38 seconds
[23-10-04 19:30:00] Speed was: 2.64 fps.
[23-10-04 19:30:00] Compressibility percentage is: 756.26
[23-10-04 19:30:00] Switching b-frames off
[23-10-04 19:30:00] Chosen resolution is: 720x400 ( AR: 1.80 )
[23-10-04 19:30:00] Predicted comptest value is: 527.44
[23-10-04 19:30:00] Running first pass.
[23-10-04 19:30:00] Writing the following script to Q:\CompressedVid\agk_tmp\BeforeTheRain_movie.avs
===========================================================
LoadPlugin("C:\PROGRA~1\AUTOGK\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\AUTOGK\filters\autocrop.dll")
LoadPlugin("C:\PROGRA~1\AUTOGK\filters\undot.dll")
movie = mpeg2source("Q:\CompressedVid\agk_tmp\BeforeTheRain.d2v")
cropclip = autocrop(movie,mode=0,wmultof=4,hmultof=4,samples=10,aspect=0,threshold=34,samplestartframe=0)
fixed_aspect = 1.06666666666667
c_width = width(cropclip)
c_height = round(height(cropclip) / fixed_aspect)
input_par = float(c_width)/float(c_height)
input_par = input_par > 1.4 ? input_par : (4.0/3.0)
out_width = 720
out_height = round(float(out_width) / input_par)
hmod = out_height - (floor(out_height / 16 ) * 16)
out_height = (hmod > 4) ? (out_height + (16 - hmod)) : (out_height - hmod)
new_aspect = (float(out_width) / float(out_height)) / fixed_aspect
autocrop(movie,mode=0,wmultof=4,hmultof=4,samples=10,aspect=new_aspect,threshold=34,samplestartframe=0)
Undot()
LanczosResize(out_width,out_height)
===========================================================
[23-10-04 19:40:52] Duration was: 10 minutes 52 seconds
[23-10-04 19:40:52] Speed was: 17.67 fps.
[23-10-04 19:40:52] Expected quality of first pass size: 510.26
[23-10-04 19:40:52] Warning: final AVI will likely be undersized.
[23-10-04 19:40:52] Running second pass.
[23-10-04 19:58:29] Duration was: 17 minutes 36 seconds
[23-10-04 19:58:29] Speed was: 10.90 fps.
[23-10-04 19:58:29] Job finished.
len0x
23rd October 2004, 19:23
That is puzzling!
Just to make sure - does final avi reflect what AutoGK shows in the logs (i.e. its not a full movie)? There might be just parsing error in the logs. To make sure AutoGK is doing evrything right you can examine header of D2V file which can be found in agk_tmp dir. It will show you wich files were indexed by DGIndex.
heinz57g
23rd October 2004, 19:57
puzzling? ask my wife: she keeps wondering why i mumble
about gordian knots in my sleep.
yes, the resulting AVI is really only the last ten minutes
of the movie (in this case), or the middle one, or or or.
and yes again, the D2V file shows (again in this case) the
VOB file #4 only.
question: does AGK or its associated background progs create
any r e a l l y large files that maybe later get erased
again so they not show up anymore? presently i have 4.2gb free
on the source drive, and 1.8gb on the dest drive.
i guess i am just fishing now ...
greetings - heinz -
len0x
24th October 2004, 13:02
Try this: start DGIndex -> F3 (increment option) -> select first vob and see how many of them got picked up. Then try saving project. If that works OK then you can do something like described in FAQ (Q6.6 and 6.10) to use your saved D2V.
P.S. I assume it only this DVD?
heinz57g
24th October 2004, 16:38
tried DGIndex, it shows all four files, and afterward
also gos thru all 4 of them. and in the D2V file all
4 show up (unlike when done with AGK). so what do i do
manually different that AGK fould up?
>> do something like described in FAQ (Q6.6 and 6.10)
>> to use your saved D2V
this i need to read myself into first. will report back.
but even if i can correct in manually, still remains the
question what does AGK do wrong?
>> I assume it only this DVD?
no, not at all. several unrelated, mixed. no trace here
that they might be similar.
greetings - heinz -
len0x
24th October 2004, 16:44
Originally posted by heinz57g
but even if i can correct in manually, still remains the
question what does AGK do wrong?
AutoGK does nothing wrong, but DGIndex seems to have some problems when launched from command line on your PC. Its pretty much out of my control... What kind of PC do you have? (hardware/OS)
heinz57g
24th October 2004, 16:59
how do i stop DGIndex? it says just to press ESC, but as often
as i do that, it will not stop, but goes over to the next step.
>> AutoGK does nothing wrong, but DGIndex seems to have some
>> problems when launched from command line on your PC
fair enough, and i sure want to believe it, but is that not
what AGK excells in? to coordinate those various progs?
comp: 2400 CELERON 512mb WIN98se
greetings - heinz -
heinz57g
24th October 2004, 17:48
OK, it worked. really.
stopping DVIndex was a time problem: since AGK had selected
VOB file 4, the very shortest, that one only ran 4 seconds.
and in this time i couldnt figure out how to stop it.
renamed VOB4 into *.VVV. then AGK chose the longer VOB3. was
then able to figure out how to stop DVIndex: right click on it
in the task bar, then resize, then ESC.
then renamed VOB4 back to normal.
started second copy of DVIndex, let it finish. closed it.
replaced sound and D2V files of the initial one with the
newly created ones.
closed first DVIndex. and BINGO, AGK took over, sees entire
movie now, and is presently busy doing its job.
will report back if movie looks right (in abt 2 hours).
well well well ...
greetings - heinz -
len0x
25th October 2004, 18:17
Originally posted by heinz57g
comp: 2400 CELERON 512mb WIN98se
That is quite unusual combination these days. DGIndex I bet was never tested in a such combination (although win98 is probably the factor here). But as I said - not only DGIndex is on its own with vob processing, but author is not around these days, so we can't really start investigating it...
heinz57g
26th October 2004, 07:27
i see plenty of WIN98se users here on the board, and since
99% of all similar progs work with goods success, i just hope
that alone is not the issue.
what comes to mind now: DVIndex started alone (under WIN)
finds all VOB files fine. DVIndex started from the command
line finds all VOB files. but DVIndex started from within AGK
only finds > o n e < of the four VOB files.
any clues in this?
greetings, a more relaxed now - heinz -
len0x
26th October 2004, 10:48
May be its the processor then. For sure very old celerons, and dual PII and PIII has issues with DGIndex started from CLI (because different initiliaziation routines are used for GUI and CLI).
heinz57g
26th October 2004, 10:55
i know this is not really the most modern computer, but in
some corners of the world it still counts as one: it was only
bought brandnew 6 months ago.
the M/B accepts proper pentiums, so let me see if i can borrow
one and test then again. give me a few days pls.
but: you pointed this out, i confirmed: when i start DVIndex
manually from the command line (CLI), it is fine. only when
started from within AGK, it misreads.
greetings - heinz -
len0x
26th October 2004, 10:59
Originally posted by heinz57g
the M/B accepts proper pentiums, so let me see if i can borrow
one and test then again. give me a few days pls.
that would be very useful test
Originally posted by heinz57g
but: you pointed this out, i confirmed: when i start DVIndex
manually from the command line (CLI), it is fine. only when
started from within AGK, it misreads.
You're not starting it from CLI, AutoGK does. CLI allows you to supply all the parameters, so that DGIndex starts does the job and automatically closes without you having to see the GUI.
bschulz
28th October 2004, 06:51
I don't know if anyone is watching this thread anymore but I'm having a similar problem. I set up a job in the AutoGK interface and click start, the first application that is kicked off is dgindex... On both of the computers I have access to, dgindex fails to open the vobs and begin processing so the job just eventually times out and fails. If I wait for AutoGK to kick off dgindex and I manually do the Autoincrement Open, it will complete as it should. This is a problem because I cannot use the job queue since I have to be there for each DVD... Both PCs I have run Win XP Pro, one is a dual p4 xeon 2.8 ghz and the other is a notebook with a 1.6 ghz pentium M. I know you are on the right track with the fact that dgindex isn't respecting the CLI options sent to it by AutoGK. How can we fix it? I'm tired now so I'm not going to bother with trying to find the code for dgindex on the net, but if I can I should be able to track down the problem. Let me know if you already have a workaround for this problem. Thanks!
len0x
28th October 2004, 16:01
Originally posted by bschulz
On both of the computers I have access to, dgindex fails to open the vobs and begin processing so the job just eventually times out and fails.
This is not CPU related problem - I used to have it from time to time (that's why timeout for DGindex was introduced). It is something related to not ability of DGindex to open input/output files/directories. Fot instance if I had problems i usually had to restart AutoGK and make sure explorer is not opened with input/output directories.
bschulz
29th October 2004, 05:12
I got the source code from neuron2's website and stepped through it with the Visual C++ debugger. I found that my problem was that I was always putting my DVD IFOs in a directory called dvd-ifo and since DGIndex first changes the command line parameters to upper-case and then searches for the command line options (one of which is -IF) it always was finding a '-IF' in my 'DVD-IFO' and since it's in an "if...else if" block with the "-AIF", the auto open never occurs... just thought you might like to know my findings.
It may help to add this file path limitation to the AutoGK readme or something so that others can find an answer to this problem more easily that I did.
In case the search engines scan this forum, the following should help more people find this entry:
DGIndex auto increment open file path problem
heinz57g
30th October 2004, 18:04
i am back, having tried a P4/2200 in the same motherboard
all day today, with three of the DVDs that had the same
problem: and it remained the same even with the faster CPU
(by the way not THAT much faster, some 25%-30% only).
so it is not CPU related.
>> You're not starting it from CLI, AutoGK does.
for the trials only, i > d i d < start it from the
command line, and it did find all 4 VOBs (after F3).
if AGK starts it from the CLI internally, it doesnt.
thats where we were, thats where we still are.
greetings, and a nice weekend to all - heinz -
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.