MeGUI Bug-Report Thread [Archive] - Page 25

berrinam

19th June 2006, 22:13

Weird.... I also can't get DivXMux to produce valid video files (the audio is fine, but the video reports 0 frames). I think we are getting problems from the fact that DivXMux is designed only for DivX muxing.... perhaps DivX muxing should be removed from the stable version, and we'll see ffmpeg muxing in the next few versions....

bratao

20th June 2006, 00:59

What is wrong with xvid_encraw that makes you not want to use it?
The xvid_encraw, produce a non-valid video for my vibratto II based dvd.
I don´t know the problem, but is releated to random n-vop that xvid_encraw put in file, even if i use b frames and no packed stream.
And xvid_encraw even produces complete non playable files !!! using a simple avs script(directShowSource(video)) the output is only a gray image(on vcl is green)

The xvid_encraw is so unstable, i can crash it so easy..

But none of my hundreds encodes crashes on mencoder, and it is substantially faster than encraw !

Cantello

20th June 2006, 07:40

There's something up on your end with DirectShow which is causing problems. All I can really do is let MeGUI provide a more standard error message in that situation.

EDIT: That's what I've done in 0.2.3.2170. Can you test it to find out if it does just give a DirectShow error message instead of a crash? Since I can't reproduce the crash, i can't test it.

Okay, I tried it and it told me that I had DirectShow problems, which I did solve afterwards (with some trial and error) by re-installing ffdshow. Everything works fine now, thanks a lot!

:-)

quake74

20th June 2006, 08:54

maybe it's the same as the "Profiles don't save changes" but to set the bitrate of a clip it's only possible to do it through the bitrate calculator and clicking apply. If it change the bitrate using the config button on the main megui, if I close and click config again, the bitrate is still the old one (and the old one is the one used when i start the encoder).

Gentle reminder since this has not been fixed yet. Or maybe it's not a bug but a feature? ;)

berrinam

20th June 2006, 08:58

Gentle reminder since this has not been fixed yet.That's not true -- it works fine for me on 0.2.3.2172.

0.2.3.2167
Commit by berrinam:
- Fix some profile bugs was (I think) where it was fixed

quake74

20th June 2006, 10:16

That's not true -- it works fine for me on 0.2.3.2172.

0.2.3.2167
Commit by berrinam:
- Fix some profile bugs was (I think) where it was fixed

I just checked in 0.2.3.2173 and it's still there.
Let me describe it:
1) Open MeGUI
2) Click on config button in the video part (right now it's set on x264 and 1p-intermediate)
3) Change the bitrate from 1000 to 999 in the x264 encoder configuration window
4) click ok in the lower right corner and the window disappear
5) click again config in the main megui window for the video part
6) note that the bitrate is still 1000

If I open the bitrate calculator, choose an avarage bitrate and click apply, then clicking config for the video shows the new bitrate.

berrinam

20th June 2006, 11:54

I just checked in 0.2.3.2173 and it's still there.
Let me describe it:
1) Open MeGUI
2) Click on config button in the video part (right now it's set on x264 and 1p-intermediate)
3) Change the bitrate from 1000 to 999 in the x264 encoder configuration window
4) click ok in the lower right corner and the window disappear
5) click again config in the main megui window for the video part
6) note that the bitrate is still 1000

If I open the bitrate calculator, choose an avarage bitrate and click apply, then clicking config for the video shows the new bitrate.
I don't know what's up, because I simply cannot get it to break like that. I do exactly the steps you say, and it works.

Doom9

20th June 2006, 12:39

I'm afraid I have the same news as berrinam.. I can't reproduce it either.

check

20th June 2006, 13:05

Could this be related to the "safe profile alteration" feature perhaps?

bkman

20th June 2006, 13:10

Profiles still don't save for me either. Just between restarts of MeGUI, that is.

berrinam

20th June 2006, 13:14

@check: GENIUS! Absolutely correct.

quake74

20th June 2006, 13:19

Could this be related to the "safe profile alteration" feature perhaps?

Yep, I can confirm that. Good call! :thanks:

Edit: So it IS a feature and not a bug! :)

Sharktooth

20th June 2006, 14:06

No. It's a bug.
Steps:
1) Open MeGUI
2) Click on config button in the video part (right now it's set on x264 and 1p-intermediate)
3) Change the bitrate from 1000 to 999 in the x264 encoder configuration window
4) click ok in the lower right corner and the window disappear
5) Close and restart MeGUI
6) click again config in the main megui window for the video part
7) note that the bitrate is still 1000 even if Safe profile alteration is disabled.

However IMHO bitrate shouldnt be included into profiles...

check

20th June 2006, 14:45

A few things I've noticed:
-AVS creator has an incorrect title (AviSynth Script Generator -> AviSynth Script Creator) according to the menu item
-Clear jobs has no confirm button, which could turn out nasty
-Does the shutdown on finish have a countdown so it's possible to avert it if you are still using the comp? Easiest way is if you are calling shutdown.exe is to use "shutdown -s -t 60 -c "MeGUI is shutting the computer down. If you wish to cancel this shutdown type shutdown -a into the start->run box".
None life threatening, but interface niggles I've discovered today (along with a zillion other hidden powers I didn't even know MeGUI had! :D)

Sharktooth

20th June 2006, 14:57

we already include a message box library that we can use to create timed (countdown) messageboxes.

Doom9

20th June 2006, 14:58

@Sharktooth: you are mistaken. Absent safe profile alteration (a feature I never used and never will), you need to switch from profile A to profile B for changes to be taken into account. There are two completely separate codec settings.. one in the profile, and one in the IVideoSettingsProvider that's attached to the codec dropdown in the main window. The latter is updated when you press Ok, the former is updated when you switch to another profile, or press the New button to create a new profile in the codec configuration window.

Easiest way is if you are calling shutdown.exe is to use "shutdown -s -t 60 -cIt's not done like that at all.. I'm using the W32 API. The only way to prevent shutdown would be megui bringing up a warning screen with a timer and if the timer runs out, the command is sent.. otherwise the window would be closed and nothing else would happen.

which could turn out nastyI'd call that learning the hard way.. it works quite well for me.. you're not likely to make the same mistake again if it hurts a little ;)

check

20th June 2006, 15:16

Well, I think the shutdown countdown would be a nice user friendly addition, I went through about a week of encoding scratching my head at why my computer was shutting down so much - but mybe this just reflects on me rather than the program n_n

Sharktooth

20th June 2006, 15:34

2174 adds some of your suggestions (except the timed shutdown coz i should have a look at messageboxexlib).

check

20th June 2006, 15:51

hehe, I think you got the naming the wrong way around. The d2v and chapter dialogue are both "creators", shouldn't you swap it the other way?

Sharktooth

20th June 2006, 15:55

Uhm... you're right... going to fix...

EDIT: fixed in 2175

check

20th June 2006, 16:18

'nother thought. If a video is upside down, and vertical flip is checked, will this affect field order detection? I don't have anything to test it on unfortunately.

Sharktooth

20th June 2006, 16:19

Dunno, you should wait for berrinam answer coz he coded the deinterlacing stuff.

berrinam

20th June 2006, 21:57

It could affect field order, you're right. I didn't think of that. There are two solutions: tell the user to check Flip Vertical before doing the analysis, and rewrite a bit of the code for a special exception. I think the first should be done now, and the second should eventually be done.

check

21st June 2006, 01:41

Resetting deinterlacing after changing the state of the flip checkbox (and notifying the user of course) is the only way I can think of that will handle this problem. To make this more user friendy you could move the flip box to the top of the first page (bottom right of the first section?).

berrinam

21st June 2006, 08:10

Tima

21st June 2006, 20:17

Cosmetic bug in bitrate calculator:

To reproduce:
- in Bitrate Calculator choosе any non-integer ramefate
- then choose it again
- and (optionally) again and again :)

after each choice the properties of the video length/total_length/nummber_of_frames change..

quake74

22nd June 2006, 12:08

Sharktooth

22nd June 2006, 22:06

that's a wanted behaviour (http://forum.doom9.org/showthread.php?p=842699#post842699), but we really should add a SAVE button...

unskinnyboy

24th June 2006, 02:05

MeGUI replaced my LAME 4.0a with 3.8a via auto-updater. So much for recognizing the latest version. :mad:

I was using the same lame.exe for my MP3 backups and realized this when I opened my latest backup in EncSpot. My mistake was that when I mass updated everything the first time when auto-updater came out, I didn't check every single one to see if the proposed "new" version was really newer than my current one. But that onus shouldn't have been on me anyway.

How does autoupdater query lame.exe to get the version?

berrinam

24th June 2006, 02:07

It doesn't yet. It will be implemented, though.

unskinnyboy

24th June 2006, 02:11

It doesn't yet. It will be implemented, though.
It doesn't yet what? Recognize which is the latest version? Then on what basis is it updating?

berrinam

24th June 2006, 02:17

Well, I don't know the specifics of what is happening to you, but what it does right now is remembers which version it installed, and assume you haven't changed it, so that is then your current version. If it hasn't installed the files itself, then it doesn't know what version the files are, so assumes they are out-of-date.

unskinnyboy

24th June 2006, 02:24

To be very specific: When the very first time someone uses auto-updater, how does it check for the version of any particular component (for e.g: lame.exe)?

berrinam

24th June 2006, 02:28

It doesn't. I thought I said that.

foxyshadis

24th June 2006, 02:28

The existence of an entry in the AutoUpdate.xml. It doesn't care if the file's there or not yet (avisynth filters and probably most other items have this happen). I just let it update and then replace the files, otherwise I have to uncheck it every time.

unskinnyboy

24th June 2006, 02:47

It doesn't. I thought I said that.
OK. What happened in my case was that I had the program path of lame.exe set to C:\Program Files\LAME even before the age of auto-updater and this was the same lame.exe (4.0 alpha) which I was using for all purposes. When I updated MeGUI to the build which introduced the autoupdater, it "updated" my lame.exe to 3.8 alpha. This came across as quite annoying for me since I was using this LAME build for special purposes. I am not sure why auto-updater thought that 3.8a was the latest version, because it isn't. 4.0a is the latest, albeit experimental (of course so is 3.8a).

The LAME version can be obtained by a simple commandline "lame.exe", but not sure how autoupdater can read it out.

Which brings me to my request: when someone uses auto-updater for the first time, it would be nice to flash a warning message/disclaimer saying that the updater may not necessarily be updating to the bleeding edge build. Had I seen such a message, I would have eyeballed every single proposed new versions before letting the auto-updater update. This isn't applicable in my case anymore, but would be useful for people new to MeGUI. Thanks.

Sharktooth

24th June 2006, 02:57

That happened coz you're not supposed to mess with MeGUI tools folder.
Autoupdate was made to auto-download the SUPPORTED and TESTED software.
If you replace any tools in that folder there is no guarantee MeGUI will continue to work as expected.

unskinnyboy

24th June 2006, 03:06

hmm, I see your point about using supported software, but I had my lame.exe way before I even had my first version of MeGUI. When I started using MeGUI for the first time, I just pointed it to my existing lame.exe. I didn't replace anything. So it is only fair that I expected a warning when it replaced it with a lower build.

But its fine, no biggie. Just consider that warning message suggestion of mine, if possible.

Sharktooth

24th June 2006, 03:36

Yes, auto-update needs improvements, but keep in mind every program has it's own way to show its version number (if it does it at all) and it may change in future versions... so it's not an easy task.
My suggestion is to install megui and let it download the softwares in its own tools dir so it wont mess with your actual installed software.
Keep in mind we had to remove the nero aac encoder from the auto-update server and it needs to be extracted manually until we manage to get it directly from the nero FTP.

Sharktooth

24th June 2006, 03:49

another bug in bitrate calc. (not verified): http://sourceforge.net/tracker/index.php?func=detail&aid=1509066&group_id=156112&atid=798476

foxyshadis

24th June 2006, 04:14

unskinnyboy, you do know that 4.0a is a broken alpha and that 3.98a is the main current branch? (Though even 3.98 had minor quality bugs as of last month.) 4.0 has several known bugs and missing features that reduce quality at equivalent bitrates. 3.97 is the only version HA recommends, having been cleaned of all known bugs.

I presume you mean 3.98a instead of 3.8a, which is... ancient.

I just wanted to let you know so that you don't end up watching the backup a year from now and freaking out about audio blips. >.> If the speed is important enough, then it doesn't matter, I suppose.

unskinnyboy

24th June 2006, 04:56

Sorry for the big-fat typo. Yes, I meant 3.98a and not 3.8a. HA recommended version is 3.97b2 to be precise, which I am aware of.

While I know that 4.0a is experimental and several things could be broken, I cannot see how it could be any more broken than 3.98a, or is it? As per here (http://www.hydrogenaudio.org/forums/index.php?showtopic=28125), all builds >= 3.98a are disclaimed. Nothing specific mentioned about 4.0a. But there could be other threads, I don't visit HA that much. If you know, please link me.

This makes me wonder, should MeGUI update LAME to 3.98a even? Considering HA recommended version is only 3.97b2? Was there a separate testing performed which determined that 3.98a was OK and usable? Are the test results available? Sharktooth did mention that auto-updater updated to only versions which were supported and tested.

Limobar

24th June 2006, 05:04

Was there a separate testing performed which determined that 3.98a was OK and usable? [...] Sharktooth did mention that auto-updater updated to only versions which were supported and tested.

That's no fun. Asking questions and giving the answers right away. ;)

unskinnyboy

24th June 2006, 05:10

That's no fun. Asking questions and giving the answers right away. ;)
Why did you snip away the important middle part? --> "Are the test results available?" ;)

Limobar

24th June 2006, 06:35

Why did you snip away the important middle part? --> "Are the test results available?" ;)

I did it, because it was not important for the point I was making, that you answered your own question. :D

I don't think that every update is fully tested. There are only a few developers, while there are hundreds of users that are provided with the latest version of the software. I strongly believe that when it comes to open source software, it is the users' task to find out whether there are problems with updates and report these, so the developers can fix these problems.

unskinnyboy

24th June 2006, 07:09

Oh, for sure I agree, and if you had read the whole chain of posts, you would have seen that I wasn't thinking any differently - including my usage of the very very alpha version of LAME, [along with my usual usage of a slew of alphas and betas of every software]. I am using it mainly to test and report bugs.

What I was attempting was to get some clarification as to why MeGUI updated LAME to 3.98a since there is nothing special about it as far as I can see. If it updated to 3.98a, it might as well have updated to 4.0a, unless 4.0a is totally unusable & 3.98a is reasonably OK to use. It might be very true, but just wanted to know what the basis of the updates are, especially since Sharktooth said that all the components are tested. If 3.98a is tested and found OK, then why HA disclaims it? If HA recommends only 3.97b2, then why doesn't MeGUI adhere to it?

Everything will have very plausible answers, I am sure, but I just want to hear them out if possible.

EDIT: Oh, 3.98a is the current branch - foxyshadis already said that. Problem solved!

bkman

24th June 2006, 12:37

Profile bug is indeed fixed, but I found another.

When a job errors out (like with an incorrect commandline arg), the log stalls and won't print any new output after that.

shon3i

24th June 2006, 21:58

When doing 3pass encoding with clever TM, in second pass --sar x:y are not included in comandline, and i get very streched output, can i just fix this in mkvmerge or i must encode again because i lost in commpresion because picture is bigger than normal??

foxyshadis

25th June 2006, 03:46

Well, I could only find 4.0 bug reports on quite earlier prereleases, which might well be fixed by now. For 3.98a the problem sample count seems to be about the same as 3.97b so... *shrug* I guess the warning was premature.

Couple threads:
http://www.hydrogenaudio.org/forums/index.php?showtopic=44515
http://www.hydrogenaudio.org/forums/index.php?showtopic=39314

Latexxx

25th June 2006, 20:46

MeGUI wants to update my my Neroaac from 2006-05-08 to 2006-05-26 but

Updating neroaacenc. File 1/1.
Error: neroaacenc could not be found on the server
Update completed.
0 files were completed successfully
1 files had problems.