(2012-12-20, 21:26)mockingbirdblue Wrote: updated to 0.3.0 and the restore feature just vanished....... all fine within 0.1.8, but I don't even see the option at all.......and I cannot convert back at all. Please let me know what to do here as its confusing with the updated version. thanks.

(2012-12-20, 22:55)mockingbirdblue Wrote: It automatically seems to be set on backup but I will retry, at work atm but will report back later. Thanks

(2012-12-21, 01:45)gerardjm Wrote: Hi, where I have to change that value "You can keep a set number of backups by setting the integer value of the Backups to Keep setting greater than 0" I only whant 3 older backups.

And other thing, why the addon on my XBMC said versión 0.1.8, not is 0.3.0 the last one?

Best Regards,

(2012-12-15, 01:41)SFX Group Wrote: UPDATE

System settings are not being restored (Raspberry PI 512 with openELEC), it has backed them up, i can see it in the guisettings.xml, however on restoring them, these are not being taken into the system, even after a restart...

Results in having to set the whole system up (and it not able to talk on a network), how do we restore the settings?

This is with version 2.3 and 3.0

(2012-12-21, 05:16)Droid4Life Wrote:

(2012-12-15, 01:41)SFX Group Wrote: UPDATE

System settings are not being restored (Raspberry PI 512 with openELEC), it has backed them up, i can see it in the guisettings.xml, however on restoring them, these are not being taken into the system, even after a restart...

Results in having to set the whole system up (and it not able to talk on a network), how do we restore the settings?

This is with version 2.3 and 3.0

So I'm also having the same issue with system settings such as "Region" "Timezone Country" "Timezone" "Zoom" etc. not being restored with the Backup file created.

The one thing I read somewhere was to do a reboot after the restore. Unfortunately the only thing this helped with (or only thing I noticed) was that it restored the source "Fusion" which previously I thought wasn't being restored either.

Until reading this post I thought it was normal but would really appreciate the help if I could get this working.

I'm using the XIOS DS (Linux) and just recently updated the device to the newest firmware. I really appreciate this addon as it has saved me a lot of time. If i could get the "System Settings" restored it would just make it that much easier the next time around.

Thanks again for any help in advance.

(2012-12-21, 17:32)robweber Wrote: I've spent a few days recreating, and attempting to fix, this problem. The results are not going to be what people want to hear.

Guisettings.xml - this file is written to by XBMC all the time. It includes your customized view information, region/local information, even screen resolution info. It appears that XBMC reads this file almost immediately upon starting, and does a complete dump to it right before closing. As you might already be starting to realize - it does not re-read from this file after the initial load. What is happening when trying to overwrite it with this addon is that the addon moves your old guisettings.xml to the correct place. Then, the next time XBMC triggers a write operation to this file it is overwritten with whatever settings are in memory. Even restarting XBMC doesn't help because it does a write to the file before closing. The only way to get your old settings file to take affect, is to move it into the correct place manually when XBMC is not running (for OpenELEC users this may not even be possible, except with some OS level scripting during the boot sequence).

(2012-12-21, 17:32)robweber Wrote:

(2012-12-21, 05:16)Droid4Life Wrote:

(2012-12-15, 01:41)SFX Group Wrote: UPDATE

System settings are not being restored (Raspberry PI 512 with openELEC), it has backed them up, i can see it in the guisettings.xml, however on restoring them, these are not being taken into the system, even after a restart...

Results in having to set the whole system up (and it not able to talk on a network), how do we restore the settings?

This is with version 2.3 and 3.0

So I'm also having the same issue with system settings such as "Region" "Timezone Country" "Timezone" "Zoom" etc. not being restored with the Backup file created.

The one thing I read somewhere was to do a reboot after the restore. Unfortunately the only thing this helped with (or only thing I noticed) was that it restored the source "Fusion" which previously I thought wasn't being restored either.

Until reading this post I thought it was normal but would really appreciate the help if I could get this working.

I'm using the XIOS DS (Linux) and just recently updated the device to the newest firmware. I really appreciate this addon as it has saved me a lot of time. If i could get the "System Settings" restored it would just make it that much easier the next time around.

Thanks again for any help in advance.

I've spent a few days recreating, and attempting to fix, this problem. The results are not going to be what people want to hear.

Guisettings.xml - this file is written to by XBMC all the time. It includes your customized view information, region/local information, even screen resolution info. It appears that XBMC reads this file almost immediately upon starting, and does a complete dump to it right before closing. As you might already be starting to realize - it does not re-read from this file after the initial load. What is happening when trying to overwrite it with this addon is that the addon moves your old guisettings.xml to the correct place. Then, the next time XBMC triggers a write operation to this file it is overwritten with whatever settings are in memory. Even restarting XBMC doesn't help because it does a write to the file before closing. The only way to get your old settings file to take affect, is to move it into the correct place manually when XBMC is not running (for OpenELEC users this may not even be possible, except with some OS level scripting during the boot sequence).

I've tried numerous ways to get around this. My thought process was if the file could be copied over right before XBMC closes, maybe it would read in the correct file when it boots back up. Unfortunately file locks during the shutdown sequence, and the fact that addons are "unregistered" from the system pretty early in the shutdown sequence made this impossible. Trying to write the file before XBMC loads is similarly troublesome because guisettings.xml is one of the first files it reads (it has screen size and locale info after all).

What does this mean? It means that restoring this particular file via the addon is never really going to work. You can manually move it from a backup, but that's about it. One suggestion I have for people losing regional type settings is to think about moving them to the advancedsettings file - this file will work when being restored.

http://wiki.xbmc.org/index.php?title=Advancedsettings.xml#How_to_include_GUI_settings

You can move any settings located in the guisettings.xml file to the advancedsettings.xml file, as long as you will not need to change them again while XBMC is running. For regional type stuff this is probably a safe move. I haven't given up on making this work, but because of how the system is interacting with this file it is unlikely to have a fix in the short term.

(2012-12-21, 18:32)mockingbirdblue Wrote: thanks rob - you were right, I was scared to press the button to receive the options of restore thinking that it would automatically backup (nothing as it was a fresh install\upgrade). All working fine and restored without a hitch!! You don't understand how much time you have saved me with this app - what do you need for Christmas - gift on me!!!

(2012-12-22, 00:34)SFX Group Wrote:

(2012-12-21, 17:32)robweber Wrote: I've spent a few days recreating, and attempting to fix, this problem. The results are not going to be what people want to hear.

Guisettings.xml - this file is written to by XBMC all the time. It includes your customized view information, region/local information, even screen resolution info. It appears that XBMC reads this file almost immediately upon starting, and does a complete dump to it right before closing. As you might already be starting to realize - it does not re-read from this file after the initial load. What is happening when trying to overwrite it with this addon is that the addon moves your old guisettings.xml to the correct place. Then, the next time XBMC triggers a write operation to this file it is overwritten with whatever settings are in memory. Even restarting XBMC doesn't help because it does a write to the file before closing. The only way to get your old settings file to take affect, is to move it into the correct place manually when XBMC is not running (for OpenELEC users this may not even be possible, except with some OS level scripting during the boot sequence).

Hi

Thanks for confirming these details. Is there a way of bringing this to the attention of the XBMC guys, allowing a script would be better i think (looking for a restore settings, if there is one then load them and replace whats in the system).

Ive not looked at the advanced settings yet..

(2012-12-27, 21:07)robweber Wrote: Dropbox update -

After much thought and internal debating I have decided to change the way the Dropbox file system works. Since this is open source software and is not distributed as a compiled binary there is no way I can comply with Dropbox's request that the key be "unreadable" by users getting copies of the addon.

In order to keep this functionality I'm going to change the settings to allow for each users to setup their own Dropbox Developer API keycode to insert into the settings area. Is this a pain in the ass? 100% it is. It will require an extra piece of setup for everyone using the Dropbox option, essentially making it useless for 75% of users. I don't want to remove it completely though as it is a great idea for people willing to do the work. I apologize to everyone waiting on this, I had no idea when developing it that Dropbox would throw these restrictions at me when applying for the production code.

I plan to update everything in GIT and push out the update as soon as possible. Hopefully before Jan 1.