MeGUI development

[berrinam]

I think we should go for the former. We will have to upgrade DGIndex sometime anyway (as the old version simply becomes obsolete) and I would be afraid about .d2v file format discrepancies if we supported a different version of DGIndex and DGDecode.dll.

[Sharktooth]

the former. however i would like to try something first.

[Neillithan]

For some reason when I try to load an Avisynth script into Megui, I get an error.

Here is a picture of the error.

http://img235.imageshack.us/img235/599/strangevistameguierrorpj5.th.png (http://img235.imageshack.us/my.php?image=strangevistameguierrorpj5.png)

Directly following the error, Megui crashes and this is what Windows Vista has to say about it.

Description:
Stopped working

Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: megui.exe
Problem Signature 02: 0.2.6.1049
Problem Signature 03: 485fa856
Problem Signature 04: MeGUI
Problem Signature 05: 0.2.6.1049
Problem Signature 06: 485fa856
Problem Signature 07: 9f4
Problem Signature 08: c
Problem Signature 09: System.BadImageFormatException
OS Version: 6.0.6001.2.1.0.256.1
Locale ID: 1033


I am using Megui version 0.2.6.1049. I have made minimal changes to Vista since I installed it a few hours ago. I have installed CoreAVC. I have installed AviSynth (I admit I don't know if it is the latest version). I tried installing FFDShow Tryouts to see if that would help.

The AviSynth script loads into VirtualDub without fuss, Megui just will not take it.

Oh, and here is the contents of the AviSynth Script:

AviSource("E:\Fraps\vistaTEST.avi")
ConvertToYV12()

The Avi itself is simply fraps footage and fraps "is" installed so AviSource should be working.

Help?

-Neil

[Sharktooth]

check the avs in virtualdub. if it doesnt work you dont have the VFW codec installed.
avisource needs VFW codecs...

[Sharktooth]

@devs: let's proceed removing the audio track selection in the d2v creator so we can update dgindex. i will readd it later if my code works correctly.

[Neillithan]

check the avs in virtualdub. if it doesnt work you dont have the VFW codec installed.
avisource needs VFW codecs...

oO

I said this.

The AviSynth script loads into VirtualDub without fuss, Megui just will not take it.

and this

The Avi itself is simply fraps footage and fraps "is" installed so AviSource should be working.

I'm not trying to denounce your 7000+ post count, but maybe perhaps reading before responding will help.

-Neil

[Sharktooth]

sorry. my short term memory sometimes is really short...
so, let try another thing.
get the megui dev version and give it a try, just dont use zones (seems its buggy). if the problem persists, we should find the cause.

[Kurtnoise]

@devs: let's proceed removing the audio track selection in the d2v creator so we can update dgindex.
done...

[Neillithan]

sorry. my short term memory sometimes is really short...
so, let try another thing.
get the megui dev version and give it a try, just dont use zones (seems its buggy). if the problem persists, we should find the cause.

Don't worry about it. :) At least you didn't lash out at me for my brutality. :X

Your suggestion worked! The Developer version of MeGUI opens the AviSynth script in Megui just fine. Version 0.3.0.1010 opened right up without any problems.

Thanks a lot. :)

Edit: After closer inspection, I think the reason why it didn't work was because there was no path set for "Avisynth Plugins" in the Program Path's area of Megui Settings. lol Oh well! :)

[berrinam]

...just dont use zones (seems its buggy)...

Problem now fixed in rev580.

[Coolpplse]

Don't worry about it. :) At least you didn't lash out at me for my brutality. :X

Your suggestion worked! The Developer version of MeGUI opens the AviSynth script in Megui just fine. Version 0.3.0.1010 opened right up without any problems.

Thanks a lot. :)

Edit: After closer inspection, I think the reason why it didn't work was because there was no path set for "Avisynth Plugins" in the Program Path's area of Megui Settings. lol Oh well! :)

Actually its more than that, The "Current" version v0.2.6.1049 if you check on Task Manager, on Vista 64 is running MeGUI as a 64 bit app, "MEGUI.exe" while with v0.3.0.1010 MeGUI is running as "MEGUI.exe*32"

If you try selecting the AviSynth 32 bit Plugins directory with v0.2.6.1049 it will error and when you try to save the setting it fails....

[Sharktooth]

@devs: at this point, i'd say to move 0.3 into the stable folder in the autoupdate server.
also, next version would be 0.3.1, then 0.3.2, etc. a sort of features implemenation "path" to 0.4... so we can add stuff and quickly move every version (once "stabilized") to the stable folder.
what do you think?

[Sharktooth]

New dev build at sourceforge: https://sourceforge.net/project/showfiles.php?group_id=156112&package_id=244469

recent changes:
0.3.0.1013
- (kurtnoise) cosmetics - Presets instead of Profiles.
- (kurtnoise) removed .net framework checking for vista users during the loading. It should be fine now with all apps updated and frankly it's also to avoid to waste some time to upgrade each number indefinitely...;-)
- (berrinam) Reset zones even when preview window doesn't open (fixes #2007133 - Error when loading "AutoEncode")
- (kurtnoise) removed audio tracks selection from the D2V creator.

0.3.0.1012
- (sharktooth) fix for #2001332 ([0.3.0.1010] AviSynth script creator does not open)

0.3.0.1011 (includes the fixes and additions up to ver. 0.2.6.1050)
- (berrinam) [ProfileExporter] Fixed bug where exporting 2 profiles each with associated files would fail (bug not reported)
- (berrinam) Add ZonesWindow to VS2005 project file (patch by Sean McGovern)
- (kurtnoise) [AviSynthAudioEncoder] better detection of several data streams (AC3, MP3, DTS, etc...) from the wav container. Mainly based on Tebasuna's code.
- (kurtnoise) [LanguageSelectionContainer] added 'Fran�ais'.
- (kurtnoise) 'computed' instead of 'used' in CommandlineVideoEncoder
- (kurtnoise) [CommandlineVideoEncoder] better handling for several Encoding Modes.
- (kurtnoise) updated a missing event for max key Frame interval in the Xvid Configuration Panel. Patch by Underground78.
- (berrinam) Added zones back to main window (outside codec configs)

[Kurtnoise]

@devs: at this point, i'd say to move 0.3 into the stable folder in the autoupdate server.
also, next version would be 0.3.1, then 0.3.2, etc. a sort of features implemenation "path" to 0.4... so we can add stuff and quickly move every version (once "stabilized") to the stable folder.
what do you think?
fine for me...and don't forget also to update some exec (FFmpeg, Mencoder, LAME, DGindex, etc...). :)

[Sharktooth]

dgindex is up to date.
about the other packages, ill see if i can update them later.

[Sharktooth]

@devs: divx is probably going the CLI way for the next divx avc codec.
should we consider implementing it (assuming they make a cli encoder?)

[berrinam]

Definitely. CLI encoders are very easy to add.

[Sharktooth]

@berrinam: could you please change the link in the first line of the megui guide thread from http://x264.nl in http://www.sourceforge.net/projects/megui ?

[berrinam]

Done.

[berrinam]

@devs: at this point, i'd say to move 0.3 into the stable folder in the autoupdate server.
also, next version would be 0.3.1, then 0.3.2, etc. a sort of features implemenation "path" to 0.4... so we can add stuff and quickly move every version (once "stabilized") to the stable folder.
what do you think?

Sounds good.

How about also doing the SVN shuffle (http://forum.doom9.org/showthread.php?p=1150762#post1150762) now?

[Sharktooth]

rigth now there's a new bug (http://sourceforge.net/tracker/index.php?func=detail&aid=2008276&group_id=156112&atid=798476) in jobqueue.cs ... but im going to sleep (5AM) so i wont fix it right now.
feel free to do it if you want/have time. it should be easy to fix.
after the bug is gone we can shuffle the svn and move 0.3.0 to stable in the autoupdate.

[berrinam]

Fixed.

[Kurtnoise]

too bad...the one click encoder is broken now due to the remove of audio tracks selection from the d2v creator. :s

So, we need to go back by rebuilding this part or find an other solution asap...

[berrinam]

I've fixed that bug now, too. It was also simple.

If it's ok, I'll start reorganising the SVN folders now. Is that fine?

[Kurtnoise]

WoW...you're fast. :p

go ahead for the shuffle.


edit: I'm testing megui stuff on x64 right now...

[berrinam]

NB: I'd actually already started doing the shuffle, since I discovered I could start copying folders without causing disruptions. Getting SVN to behave right is a bit annoying though...

[berrinam]

As of svn rev590, I have moved everything out of /trunk and have moved the files into folders like /megui/trunk, /neroraw/trunk, etc. I have moved compile-all.bat and compile-all-msbuild.bat to /, but they almost certainly will not work located where they currently are. We will have to consider what we do with these; my thought is that there is no need for compile-all.bat files -- it should be enough if every subproject (megui, neroraw, ...) has its own compile(-msbuild).bat file.

The megui trunk should be buildable, once got from /megui/trunk. I will, soon, complete the reorganisation by moving the tags and branches to the appropriate places.

[Kurtnoise]

there is still a problem with the one click encoder : when we select the 1st or the 2nd audio tracks from the list, an error occurs at the end of the d2v creation...

I'll try it asap.

[berrinam]

I reproduced that problem, and thought I had fixed it. Hmmm....

[berrinam]

SVN reorganisation completed in svn rev594.

[Sharktooth]

compile-msbuild.bat is only strictly necessary for megui. csc can be used for the rest.
however i updated the paths in the scripts so they should work again.

EDIT: i also updated the installer script to reflect the paths changes.

[Sharktooth]

0.3.0.1014
- (berrinam) Fixed #2008444 (crash using One Click Encoder). The One Click Encoder uses the "Demux all audio" mode.
- (berrinam) Fix #2008276 (Fatal Error On Queue Tab With 0.3.0.1013)

1014 is the new stable version. im starting moving files in the autoupdate server.

edit: kurt, can you please add the UAC stuff to the NSIS script? I dont have Vista to test if the script works or not...
(should i get version 0.7 or 0.8?)

[Kurtnoise]

fact is, we doesn't need it...;)



btw, why not putting this latest version in the tags branch (as 0_3_x_x_) ? you said that it's stable now...

[Sharktooth]

IMHO we dont need tags anymore.
if we follow a strict version numbering that follows features implementation (new feature, new version... etc), we can just release one or more stable versions/month.
in practice we plan features for the next major version (0.4) and we do progressive releases along a feature implementation path. so at every new implemented feature will correspont a new version (3.1, 3.2, 3.3...) then there will be the obvious bug-fixing and then the stable release. however implementing 1 feature at a time, there will be fewer bugs... so we can accelerate the release cycle... and we'll always have a working and up to date stable version.

[Kurtnoise]

you mean that only the trunk should be used ? someone needs to clean up the tree then...

[berrinam]

IMHO we dont need tags anymore.
if we follow a strict version numbering that follows features implementation (new feature, new version... etc), we can just release one or more stable versions/month.
in practice we plan features for the next major version (0.4) and we do progressive releases along a feature implementation path. so at every new implemented feature will correspont a new version (3.1, 3.2, 3.3...) then there will be the obvious bug-fixing and then the stable release. however implementing 1 feature at a time, there will be fewer bugs... so we can accelerate the release cycle... and we'll always have a working and up to date stable version.

The thing is, bugs do not always surface immediately. Suppose we have added a feature, and then release 3.1. We wait a little while, fix the bugs that appear, and then continue to add features. Then, while we're still working on the new feature, another bug appears. We have no way of fixing that bug until we have finished the feature we are working on.

Tags, on the other hand, would solve that problem. Also, you can tag version 3.1 almost as soon as you have added the new feature. At that stage you can start working on the new feature immediately, without having to wait for a reasonable number of bugs to have appeared and been fixed.

However, I do agree that a short release cycle would be nice.

[berrinam]

So, what is the plan for MeGUI now? Is here a convenient place to talk, or maybe IRC?

[Sharktooth]

ok, let's keep the tags then.
plans? well, i would like to estabilish some priorities, or better, guidelines for development.
this is what i think:
1 - whenever a bug appears the fix must be the highest priority
2 - if a package needs updating the megui code (ie. new or changed encoder parameters) it must be as high as bugfixing in the priorities list
3 - evaluate feature requests (accept/reject) and place them in a list in order of importance. new ideas for next versions should be treated as feature requests and evaluated as well. so we have a common list of features we could work on.

do you agree?

regarding the place to talk, we have several options but since we live in different places, i doubt we'll have much time to talk.
the forum seems good to me but it's not "real time". we could even setup a private devs forum on megui project page on SF.

[Kurtnoise]

plans? well, i would like to estabilish some priorities, or better, guidelines for development.
this is what i think:
1 - whenever a bug appears the fix must be the highest priority
2 - if a package needs updating the megui code (ie. new or changed encoder parameters) it must be as high as bugfixing in the priorities list
3 - evaluate feature requests (accept/reject) and place them in a list in order of importance. new ideas for next versions should be treated as feature requests and evaluated as well. so we have a common list of features we could work on.

do you agree?
sounds good to me...:)

regarding the place to talk, we have several options but since we live in different places, i doubt we'll have much time to talk.
the forum seems good to me but it's not "real time". we could even setup a private devs forum on megui project page on SF.
that would be great...:) as I asked few months ago.


btw, did you have errors to access to the different links ? (Help Menu). I asked this because a user has reported bugs with those links and I can't reproduce here...

[check]

So, what is the plan for MeGUI now? Is here a convenient place to talk, or maybe IRC?Just another note if you'd like a non SF-hosted forum, I'm happy to host and maintain one (seeing a trend here? :)).

[stax76]

The updater changes the the last write date of AviSynth plugins, this can potentially break other applications and confuse users. It does break StaxRip which verifies the correct version on the last write day with a tolerance of two days (due to timezones). I hope this can be changed.

[Sharktooth]

that's why it "updates" (overwrites) the plugins to ensure the version installed is compatible with megui. however we can find a solution together.

@check: what can i say? thank you so much :)

@devs: when we tought we did it... other bugs appear... http://sourceforge.net/tracker/?atid=798476&group_id=156112&func=browse
#2009656: that means megui isnt correctly closed before the shutdown. it may cause other problems too.
#2009428: now that the problems with preview and vista has been sorted out we can remove the option for disabling the preview.
#2008801: the log shows it was probably something with x264. the user is making some more tests after i updated the x264 build.
#2008444: wasnt it already fixed?

[stax76]

Why does MeGUI change the last write day?

[Sharktooth]

it just overwrites the file when there is an update in the auto-update.
in practice, megui doesnt check the local file, but it just logs if the update was done or not. at every start, it checks the upgrade.xml file on the auto-update server. if the file has changed remotely (it checks the log, not the local file), it will download it and extract the zip content overwriting any existing local file. it makes backups though.

[stax76]

So MeGUI does not need to change the last write date, it's just a bug in the unpacking? Before using 7z I was using SharpZipLib too, this is the code I was using:


Public Shared Sub Unpack(ByVal source As String, ByVal destination As String)
Using inStream As New ZipInputStream(File.OpenRead(source))
Do
Dim name = ""
Dim entry = inStream.GetNextEntry

If Not entry Is Nothing Then
name = entry.Name
name = DirPath.FixSeperator(name)
name = DirPath.AppendSeparator(destination) + name

If Not name.EndsWith(DirPath.Separator) Then
Dim dir = name.LeftLast("\")

If Not Directory.Exists(dir) Then
Directory.CreateDirectory(dir)
End If
End If

If Not name.EndsWith("\") Then
Dim writer = File.Create(name)
Dim data = New Byte(2048) {}

Do
Dim size = inStream.Read(data, 0, data.Length)

If size > 0 Then
writer.Write(data, 0, size)
Else
Exit Do
End If
Loop

writer.Close()

Dim fi As New FileInfo(name)
fi.LastWriteTime = entry.DateTime
End If
Else
Exit Do
End If
Loop
End Using
End Sub

[Sharktooth]

@stax: megui uses sharpziplib too. is it buggy? or do you mean the bug may be in the megui code?

@devs: 2 new forums are up on SF. "developers" is for discussing development in general and "new features" is for evaluating, discussing and planning features for the next versions

[stax76]

The bug is in the method 'ExtractZipFile', you need to set the last write date:

Dim fi As New FileInfo(filepath)
fi.LastWriteTime = zipEntry.DateTime

[Sharktooth]

we have public static void ExtractZipFile(string file, string extractFolder)
{
ExtractZipFile(File.OpenRead(file), extractFolder);
}

public static void ExtractZipFile(Stream s, string extractFolder)
{
using (ZipFile inputFile = new ZipFile(s))
{
foreach (ZipEntry entry in inputFile)
{
string pathname = Path.Combine(extractFolder, entry.Name);
if (entry.IsDirectory)
{
Directory.CreateDirectory(pathname);
}
else // entry.isFile
{
System.Diagnostics.Debug.Assert(entry.IsFile);
FileUtil.ensureDirectoryExists(Path.GetDirectoryName(pathname));
Stream outputStream = File.OpenWrite(pathname);
FileUtil.copyData(inputFile.GetInputStream(entry), outputStream);
outputStream.Close();
}
}
}
}
ill see what i can do... later.

[Kurtnoise]

@devs: when we tought we did it... other bugs appear... http://sourceforge.net/tracker/?atid=798476&group_id=156112&func=browse

:scared:

#2009656: that means megui isnt correctly closed before the shutdown. it may cause other problems too.
really strange...

#2009428: now that the problems with preview and vista has been sorted out we can remove the option for disabling the preview.
:confused: it's more complicate than that I think...

#2008444: wasnt it already fixed?
unfortunately no...


btw, thanks for the new forums.

[Sharktooth]

1st post in the SF forum... ;) it's about... "future plans".