WARNING: Next x264 builds from me will be without MeGUI.

[Sharktooth]

As the title says i will remove MeGUI from my x264 builds packages.
The reason is MeGUI got an autoupdate function and it is able to get all the necessary files (including x264) from the net.
At this point there is no reason to include it in my builds.
Just get MeGUI and it will be able to download x264 from the autoupdate function.
I think i'll return to the old distribution method: x264-CLI and x264-VFW packages.
The x264 "standard" package will be dropped and any further information and changes will be posted in the x264 daily builds thread.

[DryFire]

the version it auto updates to is your version? or bob0r's?

[Audionut]

I just downloaded your package rev525, and megui is trying to update x264 to version 523.

[berrinam]

MeGUI AutoUpdates to the latest version on the MeGUI server. This needs to be uploaded by me, which explains the delay between Sharktooth publishing a build and me putting it on the megui server.

This delay may be fixed in the future either by MeGUI parsing x264.nl, looking for new versions, or by Sharktooth directly uploading his builds to megui.org.

@DryFire: I put Sharktooth's on the MeGUI server. The current AutoUpdate architecture only allows for one series of builds, but supporting multiple series (eg P4/P3/AMD, Sharktooth/bob0r, etc) is something I am considering.

[Shinjite]

1 thing though, everytime I updated the Megui core for example to 2.1.2147 to 2.1.2149, it updates and restarts but then it is still 2.1.2147 instead and the auto update prompt me to update it again,.....whats wrong?

[Sharktooth]

2147 autoupdate doesnt update the megui core.
manually update to 2148 or newer and it will work.

[Sharktooth]

This delay may be fixed in the future either by MeGUI parsing x264.nl, looking for new versions, or by Sharktooth directly uploading his builds to megui.org.
im waiting for richard berg to set up a ftp account for me.
The current AutoUpdate architecture only allows for one series of builds, but supporting multiple series (eg P4/P3/AMD, Sharktooth/bob0r, etc) is something I am considering.
i was providing SSE, SSE2, SSE3 builds in the past but i decided to drop them coz x264 uses mainly integer math and automatically chooses what instruction sets to use (it's done in asm).
i didnt find any advantage optimizing the c code with SSEx instructions...

[AlexB17]

I download 525 & install on top megui 2148, when i run it, it shows autoupdate window for a moment, then closing. And do it every time, when i try to run it. When i block inet to megui, and cancel update - then i may work with it.

Sorry for crappy english

[bob0r]

Hmm good good idea.... i think i will follow Sharktooth's idea.
I will make a seperate part for guis on my page and people can download/update themself.

All guis using SVN can be updated automatically.

Let's go to work......

[DeadRinga]

The autoupdate feature for megui will not let me close megui. whenever it tries to update megui core files it gives me this when trying to close: http://img392.imageshack.us/img392/6821/error5jk.jpg (http://imageshack.us)

[berrinam]

The autoupdate feature for megui will not let me close megui.
Hahaaa! Gotcha!

Anyway, you'll have to kill it with Task Manager. The problem is that updatecopier.exe was not properly installed, and it can't find that file.




bob0r: I just realised that megui.exe is not enough. MessageBoxEx.dll and ICSharpCode.SharpZipLib.dll are also required. The compile.bat file creates a dist\mindist folder which contains what should really be the minimum distribution package: megui.exe, those two dlls, and the changelog and gpl.

[b9AcE]

Please keep in mind that not all computers used for encoding are directly connected to the Internet.
Implementing autoupdating is nice for those who are connected, but unless implemented with those who are not connected in mind, it will make it impossible for them to use the program.

What I am trying to get to is that there has to be an option somewhere to download the components, and the main application, manually.
Could be handled for example by having a webpage with "what you are supposed to be using right now and the latest change date" or by a continous changelog for the contents of the autoupdater.

[dimzon]

Please keep in mind that not all computers used for encoding are directly connected to the Internet.
Implementing autoupdating is nice for those who are connected, but unless implemented with those who are not connected in mind, it will make it impossible for them to use the program.

What I am trying to get to is that there has to be an option somewhere to download the components, and the main application, manually.
Could be handled for example by having a webpage with "what you are supposed to be using right now and the latest change date" or by a continous changelog for the contents of the autoupdater.
Yeah, 100% argeed!

[asdfsauce]

Please keep in mind that not all computers used for encoding are directly connected to the Internet.
Implementing autoupdating is nice for those who are connected, but unless implemented with those who are not connected in mind, it will make it impossible for them to use the program.

What I am trying to get to is that there has to be an option somewhere to download the components, and the main application, manually.
Could be handled for example by having a webpage with "what you are supposed to be using right now and the latest change date" or by a continous changelog for the contents of the autoupdater.

Why can't you just update on a PC that's connected to the net, and then transfer over? Seems a lot easier to me.

[buzzqw]

@asdfsauce

the world is very big... and varius.... not all people have broadband connection... or even dial-up.

Sometimes there isn't choice: simply NO INTERNET

(p.s. i am glad of my 4mb adsl)

BHH

[b9AcE]

That would be possible, if I could be sure that all files were updated inside a known directory structure only,
and not put inside another application's directories (such as AVISynth-plugins).
If the autoupdate-feature puts files in other locations, registers filters or needs to run installation-programs (as it should)
I would definately prefer being told what to get myself.

If I can not be sure about which files get updated and what might be changed otherwise,
then I would need to transfer not only a couple of kB of installation data,
but keep track of changes to the whole filesystem and the registry.

Also, if updating manually you can also choose to use versions other than the ones in the autoupdate-feature,
such if a bugfix gets released or you simply prefer an older version.
So not using autoupdate could actually be preferrable even when you are connected.
That is how I configure all my autoupdating programs anyway. ;)

Don't get me wrong, I'm sure this is a nice feature for a lot of people, I just wanted to make sure that the developers didn't
unintentionally build our sweet MeGUI to require Internet to function without meaning to do so...

[asdfsauce]

@asdfsauce

the world is very big... and varius.... not all people have broadband connection... or even dial-up.

Sometimes there isn't choice: simply NO INTERNET

(p.s. i am glad of my 4mb adsl)

BHH

Huh? He's going to get the files from the net one way or another. I don't think Doom9 is mailing out MeGUI update CDs.

b9AcE-

I suggest you familiarize yourself with MeGUI's auto-update feature and directory structure. The internal update is the best way to update, hands down.

[berrinam]

There are a few possible solutions for offline computers:

You can turn off autoupdate and get all the files manually, a la the good old days. My MeGUI Guide still has all the files you need to download (I hope it's up to date....)
In the future, there will be multiple sources for autoupdate, including a local repository. This means you can choose a zip file you downloaded earlier, and MeGUI will set itself up from the contents of that file. Thus, an offline installation would mean downloading MeGUI and that offline repository.

[bob0r]

I am going to be honest here:
If you don't have an (fast) internet connection: too bad.

Really, if its such a problem, just have a friend burn you all updated files once a month.

(If you don't have internet ignore this message :p)

[b9AcE]

Speed is not the issue really.
For my own part I work at one of the world top three computer companies, so I have plenty of Internet.
However, I, and I know several others with me, feel uneasy about having to open up a computer by using automatic updates of any form from the Internet these days.
In some environments, such as DataCenters, this is not even an option.

I didn't think it would be so hard to convert upgrade.xml into HTML for manual usage and list just which is the expected version to have.
If you don't want to, I respect that, just wanted to remind you that you are making it uncessecarily hard for some environments...

[fields_g]

If you don't like it, don't use it. Just turn it off. (Tools -> Settings -> Uncheck 'Use AutoUpdate'). You can still manually update. (Tools -> Update)

If this doesn't seem too bizarre, the only thing I'll miss is seeing the changelogs right before downloading. Any way to all a button to the update list that links to a up-to-date changelog download to the computer or somewhere on the net? I love seeing these programs mature and it will let the users see (and hopefully appreciate) all the work going into this collection of software.

This way Sharktooth's sticky "x264 win32 daily builds" will rarely be accessed by me instead of multiple times a day. 553,372 hits are quite enough. BTW.... this is also a great measure of how useful Sharktooth's compiling efforts are!