auto kill, upgrade, and relaunch

[GoogleCodeExporter]

envision the following:

1) Scheduled updates is enabled
2) the scheduled time comes, the updater sees a new version is available
3) the updater sees theres no video currently being played (through api or
whatever method was discussed in the thread)
4) the updater cleanly ends the xbmc.exe process
5) update occurrs
6) xbmc.exe is auto-executed with the new code.

Related tangents:
have the updater check if music is currently playing, not just video (not
sure if this is a different api call or whatever)

if it sees no video or music is playing, have it also make sure there have
been no button presses in x-amount of time - it would suck if there was no
video playing because the user was, say, updating the library or watching a
slide show of pictures or something

using a local rss feed to notify the user of an available update was
mentioned in the thread - use the same method for the inverse, notify the
user that xbmc had successfully been upgraded to revision xxxxx.

Original issue reported on code.google.com by sickica...@gmail.com on 11 Apr 2009 at 12:22

[GoogleCodeExporter]

Original comment by kay....@gmail.com on 11 Apr 2009 at 2:57

• Changed state: Accepted
• Removed labels: New

[GoogleCodeExporter]

I would ask that the auto-restart check whether you were using the -p option on 
startup 
(this could be set in a configuration file for XBMCUpdate since it is likely 
always 
either true or false). The one downside to an auto-restart (a great addition) 
would be 
restarting in the incorrect mode. This addition would let the update run on 
schedule 
overnight and the no technical user would never be the wiser since the 
interface would 
be restarted.

Original comment by sletsc...@gmail.com on 11 Apr 2009 at 3:27

[GoogleCodeExporter]

good thinking sletschin!
i don't know how difficult it would be to implement, but if it could be done 
maybe it
would be possible to auto-detect the presence of the -p switch?

maybe have the updater check for the presence of one of the subfolders of the
userdata folder in the xbmc installation path.

for instance, when you first launch the updater, you have to point it to your 
xbmc
installation folder - mine is "X:\Program Files (x86)\XBMC"
if the -p flag is not set, my userdata information resides in "C:\Users\Media
Center\AppData\Roaming\XBMC\userdata"
as such, a userdata folder exists in the main installation path - "X:\Program 
Files
(x86)\XBMC\userdata" - but since all the information is stored in 
appdata\roaming,
the userdata folder within the xbmc installation path does not include 
subfolders
such as cache, scripts, plugins, etc.
so if the updater checks the installation path's userdata folder and does not 
see
those subfolders, it knows the -p flag is not set. if it does see those 
fodlers, it
knows -p is set.

Original comment by sickica...@gmail.com on 11 Apr 2009 at 8:34

[GoogleCodeExporter]

This is what i was thinking, xbmcupdate could look through your start menu, 
desktop
and quick launch to see if it can find a shortcut for XBMC and use whatever 
parameter
is being used in that shortcut.

another benefit that this provides is i could use that data to detect the
installation path in the first place.

Original comment by kay....@gmail.com on 11 Apr 2009 at 8:42

[GoogleCodeExporter]

thats an even better idea!
it could also detect and use the presence of any other flags, such as -fs.

Original comment by sickica...@gmail.com on 11 Apr 2009 at 8:44

[GoogleCodeExporter]

Original comment by kay....@gmail.com on 8 Jun 2009 at 9:54

• Added labels: Priority-Low
• Removed labels: Priority-Medium