Norfolk
25th April 2004, 03:34
hi!
I'm using koepis XviD-1.0-RC4 05.04.2004 and virtualdubmod 1.5.10.1, 2-pass-encoding.
for the stats-file, i would have expected the codec to take care of the filehandling (deleting old ones when doing first-pass), so i just left it default.
but doing many jobs in queue - always alternating first- and second-pass, with the pc being shutdown overnight, the filesystem shows me, that the stats-file is only updated on the first day. on the next day, file properties tell me that there is no further updating of that stats file (always says "last changed: <first day, evening>"), which i can only interpret as eighter the file system tells me jokes, or the codec does not change the old stats-file, therefore using an old, not fitting file for the 2nd-pass-runs and discarding all results from the 1st-pass-runs. i noticed that problem at least twice by now.
is there anything known about that?
since the stats-file does not include anything like a header, is there any way to determine to which encoding-job it belongs? with counting the lines and interpreting it as frames did not help, maybe because of necessary ivtc. (yes, i did calculate the frames times 0.8, which is an approximation, but doesnt seem acurate enough to tell the stats-files origin)
btw: i wanted to check existing bug-lists as hinted in the postings, but couldnt find a list or something. maybe it's too late at night :)
I'm using koepis XviD-1.0-RC4 05.04.2004 and virtualdubmod 1.5.10.1, 2-pass-encoding.
for the stats-file, i would have expected the codec to take care of the filehandling (deleting old ones when doing first-pass), so i just left it default.
but doing many jobs in queue - always alternating first- and second-pass, with the pc being shutdown overnight, the filesystem shows me, that the stats-file is only updated on the first day. on the next day, file properties tell me that there is no further updating of that stats file (always says "last changed: <first day, evening>"), which i can only interpret as eighter the file system tells me jokes, or the codec does not change the old stats-file, therefore using an old, not fitting file for the 2nd-pass-runs and discarding all results from the 1st-pass-runs. i noticed that problem at least twice by now.
is there anything known about that?
since the stats-file does not include anything like a header, is there any way to determine to which encoding-job it belongs? with counting the lines and interpreting it as frames did not help, maybe because of necessary ivtc. (yes, i did calculate the frames times 0.8, which is an approximation, but doesnt seem acurate enough to tell the stats-files origin)
btw: i wanted to check existing bug-lists as hinted in the postings, but couldnt find a list or something. maybe it's too late at night :)