MeGUI Bug-Report Thread

[berrinam]

Fixed both of cc979's bugs in 0.2.3.2017.

[Sharktooth]

Originally Posted by berrinam

MeGUI forces the mp4 extension on the raw aac files that faac creates
Description: See http://forum.doom9.org/showthread.ph...640#post793640
Status: Not yet solved.

Uhm, that happens only with besweed mode. Avisynth encoding works as expected, so, since besweet mode should be removed it's not worth fixing it.

[max-holz]

I want to signal this problem again.
When I press the pause button the job continues, seems that pause only the displyed percentage not the x264 process that continues (I wait for 10 minutes).

I have a gigabyte GA-8AENXP-D motherboard with dual channel memory and P4 3.4 with hyperthreading.

[cc979]

Originally Posted by berrinam

Fixed both of cc979's bugs in 0.2.3.2017.

using 0.2.3.2106 bugs still there

[Sharktooth]

he meant 2107 not 2017
get it here: http://prdownloads.sourceforge.net/m...7.zip?download

[Doom9]

@max-holz: you're the only one that has this problem and we cannot reproduce it.. it's kinda hard to fix something that cannot be reproduced, wouldn't you agree?

[dimzon]

Originally Posted by max-holz

I want to signal this problem again.
When I press the pause button the job continues, seems that pause only the displyed percentage not the x264 process that continues (I wait for 10 minutes).

I have a gigabyte GA-8AENXP-D motherboard with dual channel memory and P4 3.4 with hyperthreading.

Does you have EXTREME slow script or x264 settings in this case?
Can You reproduce this bug using something like

Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version()

[max-holz]

Originally Posted by dimzon

Does you have EXTREME slow script or x264 settings in this case?
Can You reproduce this bug using something like

Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version() + Version()

I have done this discussion long time ago. The answer is with every version, settings and scripts.

I have tried to debug without success, simply the thread doesn't suspend.

[shon3i]

Originally Posted by max-holz

I want to signal this problem again.
When I press the pause button the job continues, seems that pause only the displyed percentage not the x264 process that continues (I wait for 10 minutes).

That is true. Encoding won't stop. Just continue but litle slower.

[max-holz]

Originally Posted by shon3i

That is true. Encoding won't stop. Just continue but litle slower.

I already know the answer. Doom9 said that the problem is our machine cos he has no problem.
I don't want to criticize but perhaps thread syncronization is not managed in the proper way
I know is dfficult but perhaps using a queue and a thread pool is better than the process class only.

P.S.
Seems that I'am not the only person

[Doom9]

I have tried to debug without success, simply the thread doesn't suspend.

That's not correct.. I recall you telling that you see that the mre is set properly and that nothing is executed in megui anymore. What happens if you run megui in the debugger and press the pause button? that will effectively freeze the megui process so you can be 101% sure megui is not doing anything anymore. And I am using the code pattern you can download from MSDN to run commandline executable, and MRE's are suggested in the MSDN documentation to synchronize threads.. and there's nothing more to keep from working than the stdout and stderr reader.. keep in mind no threads are started anywhere.. it's all implicit using the mechanism Microsoft suggests to dispatch stdout and stderr output.

Also, have you ever tried if you disable HyperuselessThreading? (it's gonna die btw: http://www.theinquirer.net/?article=30087).

[max-holz]

Originally Posted by Doom9

That's not correct.. I recall you telling that you see that the mre is set properly and that nothing is executed in megui anymore. What happens if you run megui in the debugger and press the pause button? that will effectively freeze the megui process so you can be 101% sure megui is not doing anything anymore. And I am using the code pattern you can download from MSDN to run commandline executable, and MRE's are suggested in the MSDN documentation to synchronize threads.. and there's nothing more to keep from working than the stdout and stderr reader.. keep in mind no threads are started anywhere.. it's all implicit using the mechanism Microsoft suggests to dispatch stdout and stderr output.

Also, have you ever tried if you disable HyperuselessThreading? (it's gonna die btw: http://www.theinquirer.net/?article=30087).

AND I TOLD YOU that I have done the debug and the result is that your beautiful ManualResetEvent.Reset() affects only the MEGui process but not x264, and the code doesn't brush your stdout and stderr. Finally it's not the fisrt time that uncle Bill suggests shit.

[Doom9]

Well, if you wanna be like that..

[cc979]

this i have not tried till just now

on the avisynth script creator

if you retain anamorphic resolution and set SAR

then choose your width say 320, the autocrop just crops the preview screen but does not resize, so close the preview to see what it looks like small

but you change your mind and increase the width then hit autocrop

you get a fatal error

is that normal ? or a bug ?

[Doom9]

you get a fatal error

is that normal ? or a bug ?

That very much sounds like a bug. Could you post the first few lines of the error message for reference?

[cc979]

Originally Posted by Doom9

That very much sounds like a bug. Could you post the first few lines of the error message for reference?

as image, ok

[cc979]

just noticed on playback of small 320width anamorphic test

it did'nt stretch out as it should, had mux it with yamp using PAR 16/9

[ChronoCross]

EDIT: Nevermind I fixed the problem. it seems for some reasona fter my reformat I suddenly need a new dll in my audio folder (MFC71.dll) like the guide says. Figured it out about 10 mins after this posting lol

[berrinam]

Originally Posted by cc979

just noticed on playback of small 320width anamorphic test

it did'nt stretch out as it should, had mux it with yamp using PAR 16/9

AR signalling is another one of those issues which has been changed and changed and changed. It is a real pain, but it worked for me in all situations last time I tried, except for XviD, as there is a limitation/bug in mencoder. Can you give specific details and make sure that the error is not actually on your end, please?

[Doom9]

except for XviD, as there is a limitation/bug in mencoder.

The good news there is that encraw supports custom ARs and I already make it use them in all situations I found.. we can thus get rid of the ar recalculation routines by the time the next stable build is ready.