Auto-update feature

[ioannis-e]

• download setup file from www.sourceforge.net depending on architecture
• verify embedded signature
• run setup file
• close mpc-hc instance
• implement update for portable instances (ie not installed) - download and save 7z archive
• decide download location
• implement updating to nightlies
• internationalization of new strings

[ioannis-e]

if nightlies build script can output a version.txt file containing the version of the latest nightly, then we can also implement automatic updates to nightlies.

[XhmikosR]

Thanks for the patch!

It already does; that's how it skips rebuilding the same nightly, but one thing at a time.

/CC @Underground78 since we were discussing about this the other day.

[XhmikosR]

Please move this in the project file.

[XhmikosR]

We need to consider some things, before getting this in, like the fact that we'll no longer be able to be part of the SF accelerator program. Which in that case, I need to see about other solutions like a CDN.

[Underground78]

What about people not using the installer?

[XhmikosR]

Also, mb should be MB etc. Another thing, where is that icon taken from?

[Underground78]

Also I think people should be able to download the file without installing immediately.

[XhmikosR]

You mean there should be an option for that too? IMO auto update should mean auto update, download and install the new version automatically.

[Underground78]

Well maybe just a button to open the browser but maybe you're right. Anyway the most important is to find a solution for people who aren't using the installer.

[ioannis-e]

I dont know does the installer perform any library registration, or other tasks ?
On the other hand if we do in-place replacement of files by unpacking the 7z file then we will need a 7z unpacker.

As far as i tried the installer does not run properly with the commandline paramemter supplied in the comment (ie. to run silently).

[XhmikosR]

@ioannis-e: it should run fine as long as you have killed the running process. I will have a look at this later today and let you know.

As for the non installer instances, I don't think we should unpack anything; we should just ask the user where to place the 7z/zip file and let them do the remaining stuff themselves.

[ioannis-e]

Is there a way to detect wether the current instance is running from an installed instance or portable ?

[XhmikosR]

Yes. HKCU, 'Software\MPC-HC\MPC-HC', 'ExePath' or IS's own reg key

x64:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{2ACBF1FA-F5C3-4B19-A774-B22A31F231B9}_is1

x86:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{2624B969-7135-4EB1-B0F6-2D8C397B45F7}_is1

https://github.com/mpc-hc/mpc-hc/blob/master/distrib/mpc-hc_setup.iss#L118

The installer is using the above 2 to detect if we are already installed.

[ioannis-e]

Also should the installer run silently or normally ?
I cant find the commandline option to execute the app after install.

[CrossVR]

Is there a way to detect wether the current instance is running from an installed instance or portable?

I think you're looking for CMPlayerCApp::IsIniValid(), which checks if the an ini file exists which indicates whether MPC-HC is portable.

https://github.com/mpc-hc/mpc-hc/blob/master/src/mpc-hc/mplayerc.cpp#L771

Yes. HKCU, 'Software\MPC-HC\MPC-HC', 'ExePath' or IS's own reg key

You shouldn't rely on the registry keys, since they may be present even though MPC-HC is set up to be portable.

[Underground78]

You can use the registry without using the installer so just checking for the ini isn't enough I think.

[XhmikosR]

@ioannis-e: I will check out the installer issues later and let you know. Or you can check http://www.jrsoftware.org/ishelp/topic_setupcmdline.htm

@Armada651: you need to rely on registry keys.

[ioannis-e]

Well all i want to know I think is whether i am running from an installed location, to download installer else to download 7z file...

[CrossVR]

@XhmikosR It still wouldn't be reliable, since I can have an installed and a portable instance.

[Underground78]

You should just check for the uninstaller path I think.

[CrossVR]

It wouldn't catch the case where you switch to an INI file after installing it, but I guess it's okay to use an installer in that case.

[Underground78]

INI vs registry shouldn't be a problem here. The question is just to know if we have an existing install.

[CrossVR]

We need to consider some things, before getting this in, like the fact that we'll no longer be able to be part of the SF accelerator program. Which in that case, I need to see about other solutions like a CDN.

Are you sure the SF accelerator program prohibits direct downloads? It doesn't seem to affect FileZilla at all who also have an auto-updater that downloads directly from SF.

But the real question is whether we can accept the drop in revenue.

Also, we might want to use some kind of redirect URL from mpc-hc.org or something similar. Since we could switch to another hosting solution for our releases in the future and we don't want our old builds to keep attempting to update from SF in that case.

[ioannis-e]

Testing with:
/SILENT /SP- /NORESTART /CLOSEAPPLICATIONS /RESTARTAPPLICATIONS /NOCANCEL

Runs installer and starts installation automatically showing progress.
Closeapplications just prompts user to close (does not attempt to close application)
Restartapplications does nothing...

I'll be checking the following, for installed path
x86

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{2624B969-7135-4EB1-B0F6-2D8C397B45F7}_is1

x64

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{2ACBF1FA-F5C3-4B19-A774-B22A31F231B9}_is1

[XhmikosR]

@Armada651: The installer itself is using those registry keys. If one messes up those it's their fault.

[alexmarsev]

My vision of this auto-update thing:

1. We should query mpc-hc.org for latest version info. And that info should include exact version, maybe date, download url(s), execution flags, maybe checksums, maybe signer signature. I would prefer to use json for it, also there's nice tool for parsing json here https://github.com/kazuho/picojson.
2. Simply downloading .7z for portable setups is not enough. We should automate the update. Otherwise we will add another feature into our "works, kind of" list.

[ioannis-e]

@alexmarsev: Well thats why i put a consept down for discussion.

You are discussing it off the record for a long time and no action is being taken.

In my opinion auto update should only apply for installed versions.

[alexmarsev]

That's why I'm partaking in the discussion.

In my opinion auto update should only apply for installed versions.

Why? I can't find any reasons besides "we're too lazy to implement it right".

[ioannis-e]

Well in my mind when i choose to go portable its because i found a version that is stable on my system(s), and i want it unchanged, thats why i said in my opinion :)

[alexmarsev]

@Underground78 Execution flags is for when the installer changes, it's not exactly impossible.

[alexmarsev]

It would be nice if we could avoid adding a new dependency for the non-installed version so I would try to stick to something we can decompress using Windows tools.

We can do it without much hassle, Inno Setup can do this:

[Setup]
Uninstallable=not IsTaskSelected('portablemode')

[Tasks]
Name: portablemode; Description: "Portable Mode"

A bit more for shortcuts and stuff, but it's doable.

[Underground78]

I guess that would make things easier indeed.

[alexmarsev]

What I'm worried about now though, portable versions will collect outdated files that way. And there's no easy way around it.

Maybe it makes sense to limit auto-update only to installed versions after all. And show something similar to our current dialog for portable versions (I don't think we can organize "download .7z" thing nicely).

[Underground78]

Maybe we could just ask the user where to download the zip but it might not be that useful I don't know.

[ioannis-e]

Current implementation:
if installation -> download exe to tmp and verify signature then execute then close mpc-hc;
if not installation -> download 7z to tmp and popup save dialog for user to select location then move the file

[Underground78]

Why not ask before downloading? Anyway wait for other opinions since I'm not exactly sure what should be done for the not installed case.

[ioannis-e]

We could ask before, it doesn't matter, i was commenting on current code in PR.

Thought i'd agree with @alexmarsev on this that it should unpack and replace the files automatically, without user involvment. If it is done, it should be done right.

[Underground78]

You might end up doing something bad by trying cleaning up automagically. :/

[ioannis-e]

So consensus upto now:

1. mpc-hc.org should serve links for latest stable/nightly, x86/x64 that will redirect to the actual download locations, based on input url.
   eg. http://www.mpc-hc.org/download/ [release/nightly] / [x86/x64]
2. installer should run silently on installations as it will use the previous install selections.
3. after installation the installer should restart teh application.

Points for further discussion:

1. where should the downloader save the file for installations? temp folder / downloads folder ?

Regarding non-installations:

1. Installer can be run with commandline to override installation path. This can be set to path of the running executable.
2. can the installer be run from command line and install portable? ie, do not generate icons and uninstaller, then it can be run silently. If yes then we should need to download compressed archives ?

[XhmikosR]

I totally disagree with automating portable installs updates. If one is using a portable install they know how to extract a zip file themselves.

That being said, @Armada651 yes we will lose any gains we get by using autoupdates since we won't have any visits.

It's impossible to keep up with the amount of emails I get (I received like 130 emails in the last 6 hours) so if someone needs my feedback CC me.

[ssc19940105]

Temp as download location is ok.

[Stanzilla]

FileZilla for example uses the default Download dir for it's auto-updates, I always hated that because I don't really use it and I clear my TMP dir regulary.

About the flow, I think nothing should happen completly automatically. So there should always be a prompt that asks the user if he wants to update now, or (might be done in a future step) after he closes MPC-HC so the updates still happen but don't interrupt what the user was about to do any longer than necessary.

I don't think portable installations should be treated any different from normally installed ones, if the updater detects portable, just download the zip and extract it instead of running the installer and restart/close MPC accordingly.

[XhmikosR]

@ioannis-e: care to rebase this and sort a couple of things in order to get this in?

[ioannis-e]

@XhmikosR wow just to note that @Stanzilla last post was exactly 2 years ago :D

This pr was initially based on mpc-hc:master, should i rebase on mpc-hc:master or mpc-hc:develop ?

If i remember correctly (i need to go through the discussion again) certain changes to the installer were previously discussed that need to be addressed as well.

[XhmikosR]

Yeah, I know, things were slow. Just trying to clean up the PRs and get things going. You can close this and make a new one against develop if you find it easier.

[kasper93]

You can close this and make a new one against develop if you find it easier.

No. I changed base branch to develop. Github added this feature finally.

[kasper93]

1. mpc-hc.org should serve links for latest stable/nightly, x86/x64 that will redirect to the actual download locations, based on input url.
   eg. http://www.mpc-hc.org/download/ [release/nightly] / [x86/x64]

Fine, with additional 7z/portable variant. I think if someone haven't used installer to install MPC-HC we should ask where to download new package. Possibly with automation to extract files in current working dir.

1. installer should run silently on installations as it will use the previous install selections.

Yes, and auto update should be only triggered from MPC-HC instance which matches install directory in register. Otherwise we fall into portable case.

Points for further discussion:

1. where should the downloader save the file for installations? temp folder / downloads folder ?

In temp. https://msdn.microsoft.com/en-us/library/windows/desktop/aa364992.aspx

Regarding non-installations:

1. Installer can be run with commandline to override installation path. This can be set to path of the running executable.

If so installer should be modified to use portable mode. So don't modify registry and stuff like that. It is possible to do without much hassle. I'd agree in portable case only 7z package is downloaded for user, but installer solution will be more convenient for fast update.

Ok. What is done and what remain to be done? Is the checklist at top valid?

[Stanzilla]

Not sure if it fits mpc-hc but https://github.com/Squirrel/Squirrel.Windows is quite cool.