A bug in "Abort/Pause" and "Continue" function ?

[djan]

Hi jdobbs,

I think there is a bug (I don't know if we can call this a bug) when you want to continue an encode. I'm talking about a specific case. There it is : When you cancel an encode and you want to continue it again, RB will continue the encode at the last not finished encode. But there is a problem when you cancel and you let continue the next encodes. If you cancel again after some encodes and want to continue again, it'll continue at the last cancel and will not take care about the first cancel. I think it would be necessary to control all encodes to see if they are all finished and continue the encode at the first cancel and not the last. What do you think about ? I hope I'm clear even my english is not top :)

[erdoke]

I use this option very often, but to be honest, have never observed the issue you had. It can be because I've never examined which m2v is under encoding after the restart, or it can be that everything goes just fine with my RB. :confused:

Edit: Hmm, I just re-read your post and this time I understood it right hte opposite way. I think RB is working correctly and join jdobbs in not understanding wht you want it to do.
It is a very useful feature of Rebuilder.

[jdobbs]

I don't think I understand. If you cancel once, continue, and then cancel again -- it will continue following the last point that resulted in a complete M2V output. I don't understand why you'd want to redo the M2V files that were done between the first and second cancel???

[djan]

Oh yes, I think I'm not clear. When I'm talking about cancel, I'm talking about CCE. You know you can cancel while it's encoding and it continues the next encode. If you cancel many times (what can happen accidentely), when you stop RB and ask to continue the encodes, it starts at the lastest cancel you did and not the first. Tell me if it's not clear and I'll give an example.

[Sir Didymus]

@djan
Respectfully speaking, what you are pointing out as a bug, is simply the misusage of a good application, IMHO.

The right way of stopping a running encode is to hit the cancel button of DVD-RB and wait until the encode of the running segment finish.

If you interrupt (by mistake of by intention) the encoding of a given cell through the cancel button of CCE, you simply are not properly using the application.

I mean, the same is if you terminate the CCE task using the task manager; there is no check that could be performed by DVD-RB, and there is no point about doing this check; it's just your fault.

On the contrary (in the form of suggestion to jdobbs for adding some code in order to verify that every encoded cell exist and have the same number of frames of the original cell) something could be proposed for improving the application robustness; but again IMHO, I think that actually the priority should be towards other things, i.e. the removal of the few remaining bugs and the completion of the beta testing stage...

By the way, at the actual level of development, I am using this feature (i.e. the brutal possibility of interrupting the CCE encoding) for rebuilding titles with Tmpgenc or Procoder instead of CCE with DVD-RB...

And the results are very nice, even if I continue preferring CCE as a reference encoding engine...

All the best,
SD

[wmansir]

I think I understand the problem djan is describing, and it can be avoided.

Let's say you start an encode and want to cancel it immediatly on segment 00. You hit cancel, but CCE still continues encoding segment 00. Then you hit Continue and DVD-RB tries to encode segment 00 again, but there can only be one instance of EclCCE, so the new instance of EclCCE pops up an error box. You click OK to the error, the second instance of EclCCE closes and DVD-RB thinks the segment has finished encoding so it moves on to segment 01, and you get another EclCCE error message. And if you close that error box, DVD-RB moves on to segment 02. and so on. Eventually you figure it out and leave the error box up, Pause DVD-RB, then cancel the EclCCE error. The only problem is DVD-RB now thinks several segments have been encoded, but they haven't.

Of course, the way to avoid this error is to manually cancel the CCE job before resuming. Or, failing that, NEVER cancel the EclCCE error message without pausing DVD-RB first. This should go for any encoding errors actually, though with most CCE errors you have to OK the error message and then close CCE manually before DVD-RB moves on.


@jdobbs

Does EclCCE give a return value you can check?

[jdobbs]

The secret is to push the "Abort" button in DVD-RB first, then cancel encoding in CCE, and exit it. It will always exit gracefully that way.

[djan]

I know the using of the program, that's not the matter. Sir Didymus, you well understood the problem. But I'm talking about hitting cancel by mistake and not voluntary. Like you say it could be better if RB checks each segment to see if it's fully encoded. But like you say too, there are other priorities.

[wmansir]

If your using EclCCE (and as long as your not using Basic you can) add the line:

HideCancel=1

to your EclCCE.ini file and it will hide the Cancel button. To cancel a job hit Alt-F4 instead. Makes it much more difficult to accidentally cancel an encoding job.

[djan]

Yes you're right, I'll try this option.

[djan]

Thank you, it works very well and now no more cancelling accidentely.

[johnnyquid]

FYI,

To have Rebuilder start encoding for particular file you can modify the Encode_Progress= line in the Rebuilder.inf file.

[djan]

Well saw ! The number to put is the segment from wich to start the encode.