MeGUI Bug-Report Thread

[charleski]

There are older .NET 1.1 versions of megui on the SourceForge Files page
https://sourceforge.net/project/show...d=156112#files.
The ones compiled for 1.1 are 0.2.3.1029a and before.

[stax76]

I know what's up with the native error dialog on startup because I learned it the hard way recently. If you run a .NET application and it crashes with the native error dialog while startup then you got a exception somewhere in the ctor of the startup form, simply use a try catch block and add some logic to handle the exception.

[MetalPhreak]

Problem can be seen in the screenshot here: http://img65.imageshack.us/img65/4308/progress0ql.jpg

The time remaining and time elapsed are both completely wrong.
This is using Sharktooths' r399 build.

[berrinam]

Me too. A fix will come soon. For the time being, turn off Autostart Queue.

[Doom9]

@lexor: you can build your own megui-x264 build.. it should be compilable under 1.1 with no changes except for the compile.bat file.. it has links to the 2.0 compiler (%windir%\Microsoft.NET\Framework\v2.0.50727\csc), replace the v2.0 directory with the name of your 1.1 directory and you should be fine. The full release however will not compile under 1.1. That way, you know you have the same code for both builds and the only thing different is the runtime.

[de66ka]

Since I've updated Megui from 02.3.1b to 02.3.2017 the Avisynth Generator doesn't work anymore. It gaves me the error "DGIndex reported......" (see snap1.jpg) when i load the *.d2v file into the generator. When I downgrad again to 02.3.1b all work fine.

[berrinam]

A fix will come soon.

Fixed

[Mutant_Fruit]

When using the AviSynth script creator and choosing an AVI file, a dodgy avs file is generated. The resulting file that is saved is loading up the "temp.avs" file as opposed to the actual video file selected. This means that if i make a few avs files with the generator, they'll all point to teh same temp.avs file, and if i delete the temp.avs file, none of em will work at all.

Gonna make a fix now assuming i can spot the error

[lexor]

I'm at a loss at the apathy towards this issue. I mean don't you guys share your computer with other family members? An encode that takes 12 hours for first pass and 15 hours for second, bound to conflict with your family's desire to use the mahcine. Doom I know you have win xp installed, don't you get this problem with user switching? I mean it's so easy to check, just start some job, switch users and switch back again. What's this suddent need for me to be a compiler and debugger? Someone must have old sharktooth's build lying around (sharktooth for one), I'm willing to put up time for testing an reporting, but I have neither energy nor time to pretend like I'm one of the developers.

[Sharktooth]

Another bug (MeGUI-x264):


Menues vanished and same problem as the previous bug.

[Mutant_Fruit]

@lexor: I'll try to take a look at it, but i'm really new to MeGUI, so i spend a lot of time just browsing the code trying to get a feel for it. Webpages are no bother to me, they're simple as compared to Windows applications

[Doom9]

I'm at a loss at the apathy towards this issue.

Apathy? Why did I waste my time explaining to you then how you can compile on your own (without any programming knowledge whatsoever..) can create a .NET 1.1 build based on the latest build for your tests? Oh wait, you expect me to do that for you, including reinstalling .NET 1.1 which I already eliminated from my machine. Am I on the right track?

In addition, wouldn't it be reasonable that YOU would first try on another box before pointing the finger at us? While I'm very possessive of my box and would never let anybody else us it, just for you I created another user account. Then I started encoding on my primary account (an admin account), switched to the second one.. encoding kept going. Then I aborted, went to the second account (one with limited privileges), started megui there (the latest CVS checkout.. done just 10 minutes ago, built with the compile script that comes with it), then switched back to the account I'm typing this from. I see from the CPU usage that encoding is still going strong, in fact, it hardly takes a performance hit at all since I only have a few resource-friendly apps running. By the way the job I'm encoding is a standard x264 one with all the default settings, and my x264 build is revision 389 from Sharktooth. Bottom line, I can't reproduce it.. it works as it's supposed to.

[Mutant_Fruit]

Originally Posted by Doom9

can create a .NET 1.1 build based on the latest build

That won't work afaik. There are a good few .net 2.0 specific items in the code now, so its now impossible to compile the current source against .Net1.0 without changing the source code.

[Doom9]

That won't work afaik. There are a good few .net 2.0 specific items in the code now, so its now impossible to compile the current source against .Net1.0 without changing the source code.

I tried and indeed.. but the thing is.. all errors come from classes that should be inside an #if directive and not be compiled anyway in the x264 mode..
However, the point is now moot because the problem seems unreproducible.. perhaps you can make the same experiment I did (MeGUI is still encoding on the secondary account and has been throughout my dinner).

[lexor]

Well I'll be damned, it is fft3dgpu that's incompatible with user switching, but I did test it without that filter before though, and it would still break, now it does not. I reinstalled Std package since then though. Perhaps that first time it crashed it corrupted some files while writing to them? Dunno, anyway sorry for the inconvenience.

And for the record I never asked anyone to compile anything for anyone at any point, all I wanted was old .7z or Sharktooth's, that's all.

I'll go bug fft3d dev now

[Pasqui]

Since a few versions (0.2.3.2017 if I remember correctly) I do not get the FPS displayed in the Progress Status window when encoding with x264. All the other parameters (current video frame, video data, projected filesize, time elapsed and time remaining) are correctly displayed with version 0.2.3.2022.

[Mutant_Fruit]

what exactly is the problem, it seems to show up fine for me.

Are you using the full version, or x264 specific version? Show a screenshot of the problem if you can.

[Doom9]

@Pasqui: they use a comma as decimal separator in your country, correct?

[Pasqui]

I'm facing the fps bug with the complete megui version on a French WinXP (where the separator between digits is a comma and not a dot).
Here is the picture:

[Doom9]

Do you remember the old problem where you never got a status update? This is the same.. the fps parser chokes because I forget to force the neutral locale that uses the dot as decimal separator. But I set up all line parsing to catch all errors and just return 0.. that's why you get the rest of the updates. The progress is directly calculated by MeGUI and not taken from the x264 commandline.. that's why you have that.