MeGUI: bug reports and feature requests

[AMED]

@cybersharky
Sometimes that happens when you randomly seek through the video when using FFMS, it doesn't affect the final encode since you won't be randomly seeking when encoding.

If you go forward a few frames and then back a few frames the blocks usually go away.

I wouldn't call this a MeGUI bug.

[XMEN3]

Clever anamorphic DAR error over 0,5%.
Calculeted SAR wrong in some cases.
With non standard input DAR 2.341 (1920x820 I Robot Bluray) aproximate the value to 2,35 and uses
global MEGUI_darx = 47
global MEGUI_dary = 20
The resulting sar is 1269:1280 (par 0.993) but, with 1920x820 it should be --sar 81:82 (par 0.988) istead.
also standard input like 1920x1040 (1.846) is wrongly rounded to 1.85 and resizing to 848x464 will result a DAR error of 0,2%...handbrake calculate sar better

thanks

[Lighto]

Is it time to ditch NeroAAC for FhG?
http://forum.doom9.org/showthread.php?t=161957

[Zathor]

Is it time to ditch NeroAAC for FhG?
http://forum.doom9.org/showthread.php?t=161957

I have no idea. Has someone investigated the legal situation? Are we allowed to put everything needed for FhG on our FTP?

[Zathor]

2076 [Video Player] fixed a crash when using non seekable scripts
in order to display such scripts the default start position is now the beginning
2075 [AVS Script Creator] improve input DAR detection when using no index files
2074 [AVS Script Creator] + [OneClick] improve input DAR detection when using index files
2073 [Settings] added option to select if ITU Aspect Ratio should be used by default (enabled by default). Feature request #3057378
2072 [Audio Encoder] added handling of channel count mismatch
2071 [MediaInfo] added default/forced track info to the MediaInfo wrapper (requires mediainfo revision 0.7.51+)

[cybersharky]

Some frames are ending up distorted after some white noise("snowing" picture)

LoadPlugin("D:\megui\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("C:\Users\me\Documents\DVDrips\B5_M5_A_CALL_TO_ARMS\VIDEO_TS\VTS_01_1.d2v", info=3)
LoadPlugin("D:\megui\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, interlaced=true, threads=0)
LoadPlugin("D:\megui\tools\avisynth_plugin\TIVTC.dll")
tfm(order=1).tdecimate()
crop( 0, 0, 0, 0)

LanczosResize(640,368) # Lanczos (Sharp)
#denoise

__film = last
__t0 = __film.trim(0, 1035)
__t0

Using X264(2021) DXVA-standard-def, abr 1024
Result: http://dl.dropbox.com/u/47490038/megui.mkv

Encoded the same frames in Ripbot 1.17, result is fine:
http://dl.dropbox.com/u/47490038/ripbot.mkv

Source: http://dl.dropbox.com/u/47490038/VTS.demuxed.m2v

[Zathor]

Please post the source file (or a short sample) and the log.
Edit: As you already added the source please upload also the complete log.

[cybersharky]

Please post the source file (or a short sample) and the log.
Edit: As you already added the source please upload also the complete log.

[Information] Log for job42 (video, VTS_01_1.avs -> 1036.264)
-[Information] [2012/01/03 2:28:16 PM] Started handling job
-[Information] [2012/01/03 2:28:16 PM] Preprocessing
-[Information] [2012/01/03 2:28:16 PM] Avisynth input script
--[NoImage] LoadPlugin("D:\megui\tools\dgindex\DGDecode.dll")
--[NoImage] DGDecode_mpeg2source("C:\Users\me\Documents\DVDrips\B5_M5_A_CALL_TO_ARMS\VIDEO_TS\VTS_01_1.d2v", info=3)
--[NoImage] LoadPlugin("D:\megui\tools\avisynth_plugin\ColorMatrix.dll")
--[NoImage] ColorMatrix(hints=true, interlaced=true, threads=0)
--[NoImage] LoadPlugin("D:\megui\tools\avisynth_plugin\TIVTC.dll")
--[NoImage] tfm(order=1).tdecimate()
--[NoImage] crop( 0, 0, 0, 0)
--[NoImage] LanczosResize(640,368) # Lanczos (Sharp)
--[NoImage] #denoise
--[NoImage] __film = last
--[NoImage] __t0 = __film.trim(0, 1035)
--[NoImage] __t0
-[Information] [2012/01/03 2:28:16 PM] Job commandline: "D:\megui\tools\x264\x264.exe" --level 3.1 --bitrate 1024 --vbv-bufsize 14000 --vbv-maxrate 17500 --sar 1:1 --output "C:\Users\me\Documents\DVDrips\B5_M5_A_CALL_TO_ARMS\VIDEO_TS\1036.264" "C:\Users\me\Documents\DVDrips\B5_M5_A_CALL_TO_ARMS\VIDEO_TS\VTS_01_1.avs"
-[Information] [2012/01/03 2:28:16 PM] Encoding started
-[Information] [2012/01/03 2:28:26 PM] Standard output stream
-[Information] [2012/01/03 2:28:26 PM] Standard error stream
--[NoImage] avs [info]: 640x368p 1:1 @ 24000/1001 fps (cfr)
--[NoImage] x264 [info]: using SAR=1/1
--[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
--[NoImage] x264 [info]: profile High, level 3.1
--[NoImage]
--[NoImage] x264 [info]: frame I:8 Avg QP:19.17 size: 27720
--[NoImage] x264 [info]: frame P:452 Avg QP:24.37 size: 12421
--[NoImage] x264 [info]: frame B:576 Avg QP:20.68 size: 2127
--[NoImage] x264 [info]: consecutive B-frames: 11.4% 42.3% 3.5% 42.9%
--[NoImage] x264 [info]: mb I I16..4: 11.2% 72.6% 16.3%
--[NoImage] x264 [info]: mb P I16..4: 0.6% 12.5% 3.0% P16..4: 30.3% 15.5% 10.9% 0.0% 0.0% skip:27.1%
--[NoImage] x264 [info]: mb B I16..4: 0.1% 0.4% 0.1% B16..8: 31.4% 4.9% 1.0% direct: 4.5% skip:57.7% L0:39.7% L1:52.3% BI: 8.0%
--[NoImage] x264 [info]: final ratefactor: 21.86
--[NoImage] x264 [info]: 8x8 transform intra:76.7% inter:66.6%
--[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 89.8% 32.1% 21.1% inter: 20.7% 27.4% 12.5%
--[NoImage] x264 [info]: i16 v,h,dc,p: 46% 32% 15% 8%
--[NoImage] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 23% 24% 5% 7% 6% 9% 6% 11%
--[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 22% 10% 7% 10% 8% 11% 8% 13%
--[NoImage] x264 [info]: i8c dc,h,v,p: 80% 8% 10% 2%
--[NoImage] x264 [info]: Weighted P-Frames: Y:6.4% UV:2.2%
--[NoImage] x264 [info]: ref P L0: 55.0% 9.4% 22.5% 12.6% 0.5%
--[NoImage] x264 [info]: ref B L0: 76.0% 19.7% 4.2%
--[NoImage] x264 [info]: ref B L1: 93.8% 6.2%
--[NoImage] x264 [info]: kb/s:1307.35
--[NoImage] encoded 1036 frames, 102.41 fps, 1307.35 kb/s
-[Information] Final statistics
--[Information] [2012/01/03 2:28:26 PM] Video Bitrate Desired: 1024 kbit/s
--[Information] [2012/01/03 2:28:26 PM] Video Bitrate Obtained (approximate): 1307 kbit/s
-[Information] [2012/01/03 2:28:26 PM] MediaInfo
--[Information] File: C:\Users\me\Documents\DVDrips\B5_M5_A_CALL_TO_ARMS\VIDEO_TS\1036.264
--[Information] General
---[Information] Format: AVC
---[Information] FormatString: AVC
---[Information] FileSize: 7061287
---[Information] PlayTime:
--[Information] Video
---[Information] ID:
---[Information] Width: 640
---[Information] Height: 368
---[Information] FrameCount:
---[Information] FrameRate: 23.976
---[Information] ScanType: Progressive
---[Information] Codec: AVC
---[Information] CodecString: AVC
---[Information] Format: AVC
---[Information] AspectRatio: 1.739
---[Information] AspectRatioString: 16:9
---[Information] Delay:
---[Information] Title:
---[Information] Language:
---[Information] LanguageString:
-[Information] [2012/01/03 2:28:26 PM] Postprocessing
--[Information] Deleting intermediate files
-[Information] [2012/01/03 2:28:26 PM] Job completed

[Zathor]

2080 [AVS] if an AVS script cannot be opened the old method to open such files is used during the session.
the option can be completly disabled in the settings ("Improved AVS opening", enabled by default). Bug #3437874
2079 [MKV Demuxer] adjusted demuxer to the recent mkvextract changes (requires mkvmerge revision 5.2.1+)
2078 [Progress Window] changed priority will be kept during the whole application session. Feature request #3445179
2077 [Progress Window] lower also I/O and memory priority when priority below normal (requires Windows Vista or newer). Feature request #3468249

[rapscallion]

@zathor

Update keeps going back and forth between 2080 and 2076....endless loop if you let it. Are you reverting back t0 76 intentionally?

[Zathor]

[Information] Log for job42 (video, VTS_01_1.avs -> 1036.264)
-[Information] [2012/01/03 2:28:16 PM] Job commandline: "D:\megui\tools\x264\x264.exe" --level 3.1 --bitrate 1024 --vbv-bufsize 14000 --vbv-maxrate 17500 --sar 1:1 --output "C:\Users\me\Documents\DVDrips\B5_M5_A_CALL_TO_ARMS\VIDEO_TS\1036.264" "C:\Users\me\Documents\DVDrips\B5_M5_A_CALL_TO_ARMS\VIDEO_TS\VTS_01_1.avs"

Consider using --crf (e.g. 20 to be in your bitrange) or doing 2 passes with your desired bitrate.

[Zathor]

@zathor

Update keeps going back and forth between 2080 and 2076....endless loop if you let it. Are you reverting back t0 76 intentionally?

There are two update servers which will be synced every ~15mins or so. The update server where I have no direct access to has the old builds available and therefore you are "forced" to downgrade. Just ignore it for now. Should be hopefully fixed soon. There is nothing I can do at the moment.

[rapscallion]

Thanks, fine...just wanted to be sure it wasn't an intentional downgrade.

Happy New Year !!

[kalehrl]

Please have a look at problems I reported here:

http://forum.doom9.org/showpost.php?p=1548782&postcount=14

@Zathor

I will send you my logs on pm.
Thank you for your support.

[Zathor]

2087 [FFMS] remove AssumeFPS() as it is causing problems with hybrid/telecined input
2086 [AVS Script Creator] improve input DAR detection when using AVS input files
2085 [OneClick] fixed long delay during processing when adding more than 4 tracks (part III)
2084 [AVS Script Creator] resize value will only be added to the script if necessary
fixed button checked states after loading avisynth profiles
2083 [OneClick] fixed long delay during processing when adding more than 4 tracks (part II)
2082 [Audio Encoder] DTS-MA decoding is blocked with NicAudio to avoid problems
2081 [OneClick] fixed long delay during processing when adding more than 4 tracks

[Audionut]

keyint=250 / keyint_min=23 /qpmin=10

These settings need to be fixed.

For 24fps content, they should be keyint 240 / keyint-min 24

qpmin has been a default of 0 for awhile now.

[Zathor]

keyint=250 / keyint_min=23 /qpmin=10
These settings need to be fixed.
For 24fps content, they should be keyint 240 / keyint-min 24
qpmin has been a default of 0 for awhile now.

0.3.5.27 [x264] changed default value of --qpmin to 0 (requires x264 rev 1795+)
But that is only valid for new presets. Existing ones will not be changed.

The keyint values will only be changed based upon the source fps if the BluRay/AVCHD/DivX-HD target playback device is selected. For other devices you have to change the keyint values in the preset on your own.

Please have a look at problems I reported here:

http://forum.doom9.org/showpost.php?p=1548782&postcount=14
Sadly I cannot reproduce your problem. Does this happen for you every time you use the OneClick mode? Please clear your queue (delete all jobs) and start with one OC job from scratch. Does that case the problem also?

[kalehrl]

Sadly I cannot reproduce your problem. Does this happen for you every time you use the OneClick mode? Please clear your queue (delete all jobs) and start with one OC job from scratch. Does that case the problem also?

It doesn't happen every time I use it.
It happens only when I add several jobs in a oneclick queue.
When there is only one, no problem.
The reason I use oneclick is that it is possible to queue a lot of files which is, I believe, the main purpose of oneclick.
I didn't get these errors with earlier versions.
The problems started from 2080 I believe.
Did you have a look at those logs I sent you on pm?

[Zathor]

It doesn't happen every time I use it.
It happens only when I add several jobs in a oneclick queue.
When there is only one, no problem.
The reason I use oneclick is that it is possible to queue a lot of files which is, I believe, the main purpose of oneclick.
I didn't get these errors with earlier versions.
The problems started from 2080 I believe.
Did you have a look at those logs I sent you on pm?
Yes, I had a look at your log but that one error message is unspecific. Please download the new build with the improved OC mode (http://forum.doom9.org/showthread.php?t=163399) and try to reproduce the problem. If it is not possible to reproduce the problem there it has been fixed and if the problem is still there the debug version should generate a better error message.

[Audionut]

0.3.5.27 [x264] changed default value of --qpmin to 0 (requires x264 rev 1795+)
But that is only valid for new presets. Existing ones will not be changed.

Cheers.


The keyint values will only be changed based upon the source fps if the BluRay/AVCHD/DivX-HD target playback device is selected. For other devices you have to change the keyint values in the preset on your own.


It makes sense to me to adjust the keyint values to match the framerate (ie: keyint 240 for 24fps content) as a general rule of thumb, rather then just for specific devices.

[Zathor]

it makes sense to me to adjust the keyint values to match the framerate (ie: keyint 240 for 24fps content) as a general rule of thumb, rather then just for specific devices.
For some device a specific keyint value is required and will be forced (or lowered to be in spec). For all other devices you are free to choose whatever you like. But in one point you are right. It may be better to remove the direct keyint values in the settings and replace them with a factor. E.g. keyint factor 10 = fps * 10, minkeyint factor 1 = fps * 1.

[hello_hello]

This is carried over from a different thread but I thought I'd reply here for Zathor's attention. Just a minor thing:

If you want you can disable ITU by disabling "Options\Settings\Use ITU Aspect Ratio". It is available since a few builds. ITU values are used for 720x576/720x480 sources only.

Awesome!! Thank you. No more forgetting to change the resize method!
I'd not looked in MeGUI's options for a while so I'd not noticed that.

When disabling the "use ITU aspect ratio" checkbox though, I did notice an erroneous tooltip you may wish to remove. The tooltip for "use ITU aspect ratio" says "Error: No update available."

[hello_hello]

No doubt this isn't an MeGUI bug, but as I let MeGUI update ffms2 today and immediately started having problems I thought I'd post about it here in case you might want to remove the update until the problem is fixed.

I posted a bug report in the FFmpegSource thread and someone else has previously reported the same problem.
http://forum.doom9.org/showthread.php?p=1550855#post1550855
My post also contains a link to a sample of the problem video.

[Zathor]

I'd not looked in MeGUI's options for a while so I'd not noticed that. It has also been mentioned in the changelog ;)

When disabling the "use ITU aspect ratio" checkbox though, I did notice an erroneous tooltip you may wish to remove. The tooltip for "use ITU aspect ratio" says "Error: No update available."
Thanks, I prepared to add the context help and need only to update the external data file.

No doubt this isn't an MeGUI bug, but as I let MeGUI update ffms2 today and immediately started having problems I thought I'd post about it here in case you might want to remove the update until the problem is fixed. Thanks. I will downgrade to r588 later - currently I have no access to the server.

[alter4]

Guys
looks like the bug is fixed in source code.
http://forum.doom9.org/showthread.php?p=1550950#post1550950

[Zathor]

Yes, but at the moment no new binary is available and therefore MeGUI dev still uses r588.

[Zathor]

2098 [x264] added option to adjust GOP size based on the FPS of the source (enabled by default)
changed --weightp and --min-keyint default value calculation
2097 [Bitrate Calculator] improved M2TS calculation assumption. Warning: it is better but also not correct
2096 [Update] changed recommended path for neroaacenc to tools\eac3to
2095 [Log] changed resource lock behavior. Bug #3466426
2094 [MP4 Muxer] use ISO 639-2/T language codes when muxing. Bug #3201829
2093 [Update] if a component is missing a warning message will appear at startup
2092 [MainForm] offer to install AviSynth if AviSynth is not found but the installer is availabe (x86 only)
2091 [Settings] changed default value of "Autostart Queue" to enabled
2090 [Audio Encoder] do not abort downmix anymore if input avs file has no channel position information
2089 [HD Streams Extractor] defaulting to English if the track language can not be indentified (MKV only)
2088 [Audio Encoder] cosmetics

[SacredCultivator]

Anyone else happen to have the Updates on Loop?

As currently for:
core
mediainfo

They keep appearing as updates for me, even when trying to update them again they still appear on an endless loop.

[QBhd]

Anyone else happen to have the Updates on Loop?

As currently for:
core
mediainfo

They keep appearing as updates for me, even when trying to update them again they still appear on an endless loop.

Nope... worked fine for me.

QB

[rapscallion]

2097 [Bitrate Calculator] improved M2TS calculation assumption.
Warning: it is better but also not correct


I find it ~1,700 kbit/s high for a bd-25 (over 100% on ImgBurn)

The calculator, on core 1888, for the same bd-25, I add 375 kbit/s to the calculation, with a result of 98% in ImgBurn. A bd-9, adding nothing, results in 98% as well.

I've been using 1888 soley for that purpose and the results have been VERY consistent. (BTW, it was Zathor's advice, way back in the thread, to revert to that build, in response to my query re the newer overshoot results)

[hello_hello]

I just updated MeGUI on two different computers running XP SP3 (.Net Framework 2.1.21022). I was running core version 2087 and it appears the update took it to 2098. In both cases MeGUI would not run after the update. Instead I got a popup message saying MeGUI has encountered an error and needs to close. In both cases deleting the MeGUI.exe file and restoring the backup allowed MeGUI to run again.
Sorry, but I don't know if there's any way to supply more details regarding the problem.

[alexVS]

Hi All!
I used megui version 0.3.5.0 for some time. (x264.exe x32 core 114 r1924 08d04a4)
Now new available version is 2050
I'm confused about the version numbers.
Does megui changed so drastically? Seriously.
And why all the dots gone? :)

I haven't bluray yet, but I have videos encoded with megui (bluray profile) on my HDD. Are those videos (encoded with 0.3.5.0) still compatible with bluray or there can be some troubles? Shoud I immediately switch to 2050?

[Shevek]

Hi All!
I used megui version 0.3.5.0 for some time. (x264.exe x32 core 114 r1924 08d04a4)
Now new available version is 2050
I'm confused about the version numbers.
Does megui changed so drastically? Seriously.
And why all the dots gone? :)

There has been a change in numbering convention.

Nothing to worry about :)

[Zathor]

I replaced in the current x264 package the vfw4x264.exe with this one:
http://forum.doom9.org/showthread.php?t=162656
As it is only a test at the moment I have not changed the source so vfw4x264 is still being called therefore I have renamed avs4x264mod.exe to vfw4x264.exe.

I find it ~1,700 kbit/s high for a bd-25 (over 100% on ImgBurn). The calculator, on core 1888, for the same bd-25, I add 375 kbit/s to the calculation, with a result of 98% in ImgBurn. A bd-9, adding nothing, results in 98% as well. I've been using 1888 soley for that purpose and the results have been VERY consistent.
Sadly the specs for muxing MT2S (with tsmuxer) are not known and therefore there are no correct open sourcebitrate calculators available. Also the old bitrate calc changed in 1898 was not correct as it just added an overhead of 6% to all values resulting in way wrong values in several calculations. If you are able to do a correct calculation - please share it. The only other option is to add an option to switch between both wrong calculations in MeGUI if this is required by someone.

I just updated MeGUI on two different computers running XP SP3 (.Net Framework 2.1.21022). I was running core version 2087 and it appears the update took it to 2098. In both cases MeGUI would not run after the update. Instead I got a popup message saying MeGUI has encountered an error and needs to close. In both cases deleting the MeGUI.exe file and restoring the backup allowed MeGUI to run again.
Sorry, but I don't know if there's any way to supply more details regarding the problem.
I can not reproduce the problem. Are you able to upload your whole MeGUI directory (exclude update_cache)? I would like to test it with your data.

[disklib]

MeGUI 2098 just updated x264 to version 2145. In the x264 config dialog - "load defaults" now creates the following:

program --crf 20 --min-keyint 25 --output "output" "input"

Am I correct in thinking the "min-keyint 25" component shouldn't be there?

[hello_hello]

I can not reproduce the problem. Are you able to upload your whole MeGUI directory (exclude update_cache)? I would like to test it with your data.

I've been keeping an eye on this thread for other reports of the same problem but so far it does seem unique to me, only it happens using 2 different computers. Admittedly though the two computers are about as close to being a single computer as two computers can get. Aside from the CPU they have identical hardware and the Windows/Programs installation from one was originally imaged and installed on the other.

I just updated MeGUI on one PC again. This time it also updated x264 and ffms (although I'd already reverted to the previous ffms version manually) and MeGUI still won't run. Here's the entire MeGUI folder excluding the update cache (after it's been updated so it's not working). MeGUI.rar (http://wikisend.com/download/232934/MeGUI.rar) (97.8MB)

[Zathor]

Here's the entire MeGUI folder excluding the update cache (after it's been updated so it's not working).
Thanks! I will have a look at it but likely not before tomorrow.

Am I correct in thinking the "min-keyint 25" component shouldn't be there?
Yes, it should only be applied to the final command line as then the FPS of the source is known.

[kalehrl]

I've noticed that when I use 1.3.2 xvid_encraw with MeGUI, the speed of encoding is much slower than when using the default one.

This is the encoding speed using default xvid_encraw:

http://i40.tinypic.com/5mg4so.png

The same file encoded using the command line gives the same speed:

Tot: enctime(ms) =142663.00, length(bytes) = 40368645
Avg: enctime(ms) = 12.01, fps = 83.25, length(bytes) = 3399
I frames: 44 frames, size = 12101/ 532456, quants = 3 / 3.23 / 4
P frames: 4203 frames, size = 5910/ 24842104, quants = 3 / 3.31 / 4
B frames: 7627 frames, size = 1965/ 14994085, quants = 5 / 5.60 / 6

Everything is fine here. The speeds match.

However, when I use 1.3.2 xvid_encraw the speed is like this:

http://i44.tinypic.com/2mwuix4.png

The same file encoded using the command line pointing to the 1.3.2 xvid_encraw in MeGUI folder gives this info:

Tot: enctime(ms) =94058.00, length(bytes) = 42714577
Avg: enctime(ms) = 7.92, fps = 126.24, length(bytes) = 3597
I frames: 44 frames, size = 12993/ 571724, quants = 3 / 3.23 / 4
P frames: 4203 frames, size = 6522/27412859, quants = 3 / 3.30 / 4
B frames: 7627 frames, size = 1931/14729994, quants = 5 / 5.60 / 6

Instead of giving me around 125fps, MeGUI encodes in 56fps.

Could you please look into this and try to make MeGUI more friendly for users who want to encode using the latest xvid?
Latest xvid is much faster as you can see from the logs (126.24 compared with 83.25)

Thank you

[Zathor]

I've been keeping an eye on this thread for other reports of the same problem but so far it does seem unique to me, only it happens using 2 different computers.

Thank you very much for your report and the upload of your MeGUI folder. I was able to reproduce it. The reason for the crash is that I am using a function in 2095 which is causing the crash when .NET 2.0 SP1 (or older) is installed. It does not crash with .NET 2.0 SP2 or 3.x/4.x. I already fixed the problem and it will be in the next update (should be available in the next days). As a workaround you can update your .NET installation.

[Zathor]

Could you please look into this and try to make MeGUI more friendly for users who want to encode using the latest xvid?
As long as there is no xvid_enraw which can output AVI files > 2GB I will not change anything there.

[hello_hello]

Thank you very much for your report and the upload of your MeGUI folder. I was able to reproduce it. The reason for the crash is that I am using a function in 2095 which is causing the crash when .NET 2.0 SP1 (or older) is installed. It does not crash with .NET 2.0 SP2 or 3.x/4.x. I already fixed the problem and it will be in the next update (should be available in the next days). As a workaround you can update your .NET installation.

Thanks for the quick fix. It makes using MeGUI even more of a pleasure.
The only reason I install .NET at all is in order to use MeGUI but I didn't realize there was a .NET 2.0 SP2. I'll try to overcome my .NET aversion and look at upgrading it. I guess sooner or later I won't have a choice.....

[Zathor]

Currently I am not able to upload stuff to megui.org and therefore I cannot update the build there. I try since more than one day to get in contact with the owner but I had no luck yet.

But maybe you can try that build here:
http://forum.doom9.org/showthread.php?t=163399

It should hopefully fix your problem.

[tebasuna51]

MeGUI core 2098 crash also here.

Seems work replacing MeGUI.exe from my last update in ...\megui\update_cache\megui-core_2087.zip

[Zathor]

Did also this one work?
http://forum.doom9.org/showthread.php?t=163399
http://www.mediafire.com/?j2i0d38p0z5noui

[hello_hello]

Currently I am not able to upload stuff to megui.org and therefore I cannot update the build there. I try since more than one day to get in contact with the owner but I had no luck yet.

But maybe you can try that build here:
http://forum.doom9.org/showthread.php?t=163399

It should hopefully fix your problem.

It seems to have fixed it. Thanks.

[tebasuna51]

Did also this one work?
http://forum.doom9.org/showthread.php?t=163399
http://www.mediafire.com/?j2i0d38p0z5noui

MeGUI OneClick Preview crash when "Updating data. File 1/43." with a Fatal error:
"MeGUI encountered a fatal error and may not be able to proceed. Reason: Could not load file or assembly 'ICSharpCode.SharpZipLib, Version=0.85.5.452, Culture=neutral, PublicKeyToken=1b03e6acf1164f73' or one of its dependencies. El sistema no puede hallar el archivo especificado."

Work with:
[23/01/2012 16:18:57] MeGUI Version : 2087 (svn)
[23/01/2012 16:18:57] OS : Windows XP Professional x86 SP3 (5.1.196608.2600)
[23/01/2012 16:18:57] Latest .Net Framework installed : unknown
[23/01/2012 16:18:57] Avisynth Version : 2.5.8.5 (21/12/2008 21:46:54)

Last time MeGUI show my .Net installed:
MeGUI Version : 0.3.1.1056
Latest .Net Framework installed : 2.0 (2.0.50727.0)

[hello_hello]

A minor feature request, or a minor bug, whichever way you want to look at it.....

When opening a file (in my case an MKV) using MeGUI it offers to index it using ffms and gives you a choice whether or not to demux the audio. If however, the file contains no audio it's necessary to select the "no audio" option when indexing or MeGUI will fail to index the file as it first tries to attempt to demux the non-existent audio.
No big deal, admittedly, it's just necessary to remember to select "no audio" manually, but it'd be nice if MeGUI could be smarter than I am. :)

[Zathor]

When opening a file (in my case an MKV) using MeGUI it offers to index it using ffms and gives you a choice whether or not to demux the audio. If however, the file contains no audio it's necessary to select the "no audio" option ... Are you sure? I just tested this and for me with a video only MKV file the "no audio" option is preselected. Please upload the whole file indexer log file (as there is the media info of the file included).

[Zathor]

MeGUI OneClick Preview crash when "Updating data. File 1/43." with a Fatal error:
"MeGUI encountered a fatal error and may not be able to proceed. Reason: Could not load file or assembly 'ICSharpCode.SharpZipLib, Version=0.85.5.452, Culture=neutral, PublicKeyToken=1b03e6acf1164f73' or one of its dependencies. El sistema no puede hallar el archivo especificado."


Yes, you need to overwrite an existing MeGUI installation otherwise vital files are missing. But 2101 should already fix your problem.

[tebasuna51]

Thanks, yes, the 2101 update works fine now.