Where do timers go in Hades

[Tkr001]

Before installing Hades I copied my timers from /enigma2. However in Hades the directory does not exist so where do I restore the timers to?

[abu baniaz]

It has always been /etc/enigma2/

[Tkr001]

Doh. Knew I should have done this after morning :coffee:

[Larry-G]

Ideally you should not be copying timers or autotimers from a earlier image to Hades, there has been quite a bit of code change to timers for the new naming protocol which will not work with timers created with a older image, you really need to set them up again for best results.

[Rob van der Does]

No issues to be expected. All my boxes are running Hades and all on Apollo backups. I haven't had one single issue.

The formats of the timer.xml & autotimer.xml haven't been changed at all (although the processing behind it may have changed a bit).

[Larry-G]

No issues to be expected. All my boxes are running Hades and all on Apollo backups. I haven't had one single issue.

The formats of the timer.xml & autotimer.xml haven't been changed at all (although the processing behind it may have changed a bit).

If you read the threads in the dev room you will see that the new naming format requires that you re-setup your timers as timers made from older images are not compatible with the new code, and you should know your self it is not wise to use settings backups from one image to another when there has been a change to the OE-A core.

[Tkr001]

I didn't restore in then end but recreated them anyway :p

[Stanman]

Timers are not backed up so if you use a restore they will be recreated. AFAIK it's the timers that have changed and not AT.

Done it on all boxes and bar having to add services again for Atlantic and Living all work spot on.

[birdman]

Ideally you should not be copying timers or autotimers from a earlier image to Hades, there has been quite a bit of code change to timers for the new naming protocol...What new naming protocol? Since when did timers have names?

...which will not work with timers created with a older image, you really need to set them up again for best results.Well, AutoTimer.py and RecordTimer.py both check the file (autotimer.xml and timers.xml respectively) when loading it. Also, these source files actually write out the file again as well, and since neither has changed anything in that area cf Apollo the file data structures must be the same.

[Rob van der Does]

Let's have a look at the factual situation:

In all the years ViX has created Pli-based images it has happened exactly 1 (ONE) time that old settings did break the image (that was network related).
Apart from that specific case, I've always used settings from one image to another, also across boxes: I never had any issue with that (including Apollo --> Hades).
And I'm glad with that: setting up a box from scratch takes me 20-30 minutes (depending on which box), while I can do that almost blindfolded. If I also have to re-create timers and autotimers it costs me an additional hour.

Plugin restore is a different case.
Plugins can be divided in two different categories: those that you see in the pluginbrowser (and you can (de)install them yourself), and systemplugins that you don't normally see.
Using a plugin restore both types will be re-installed (if available on the feeds and compatible). The 'invisible' plugins can be a culprit.
We have one security measure in place: if the backup stems from a different linux-kernel the backupmanager will skip the plugin restore.

So if you want to be 100% sure you should do a settings restore and no plugin restore.
And tbh: restoring plugins yourself is neither difficult nor time consuming

Back to the actual situation, where most users will be on Apollo and will flash Hades.
For all my tests (months before the public release) I used settings and plugin restores for all my boxes that used to run Apollo. Atm my mainbox on the public Hades-004 also has a settings and plugin restore from Apollo. My testboxes running Hades-005-DEV all have an Apollo settings and plugin restore. None of those boxes have any issue.

So the proof is in the eating of the pudding; I can't see any reason to scare our users by saying 'don't restore' after flashing Hades.
And for those who have been scared already: restore the settings and install plugins yourself.

[Rob van der Does]

One additional remark: after a flash & restore it's always wise to go through all the settings on the box, as new settings may have been born, defaults may have been changed or old settings may not be applicable anymore.
An example of the latter is 'PowerTimers': they have been changed quite a lot in Hades, and as a result the restore for them will not work (but they do no harm either; you simply have to create them again).

[birdman]

In all the years ViX has created Pli-based images it has happened exactly 1 (ONE) time that old settings did break the image (that was network related).Given that it is a data structure all that you need to do is put a version stamp in it and only change this if there is a change which you cannot make backwards compatible (after you've explained why it can't be...). The code can then check the version and refuse to use any it can't handle.

But for some reason I've found that there seems to be an aversion to version stamps amongst software engineers (OO programmers at work were appalled at the thought).

[Rob van der Does]

The version stamp is there (see backup in /tmp), as well as the name of the series the backup stems from.
And before releasing a new version, we decide which backups can be restored via the backup manager.

[birdman]

One additional remark: after a flash & restore it's always wise to go through all the settings on the box, as new settings may have been born, defaults may have been changed or old settings may not be applicable anymore.
An example of the latter is 'PowerTimers': they have been changed quite a lot in Hades, and as a result the restore for them will not work (but they do no harm either; you simply have to create them again).I copied mine across and they seem to be working. The box was in Deep Standby this morning.

[birdman]

The version stamp is there (see backup in /tmp), There's a version stamp in autotimer.xml ("7"), but not in pm_timer.xml or timers.xml.

[Rob van der Does]

The version stamp is there (see in backup in /tmp)

[John57]

Rob,

Just read your thread with interest and not wishing to hijack this thread, Would you say its possible to perform a new software flash update from my existing Apollo 144 to the new Hades operating system following your tips about plugins (So if you want to be 100% sure you should do a settings restore and no plugin restore.)

Kind Regards
John.

[Rob van der Does]

Sure; I just did one from Apollo 71.

[John57]

Rob

Thank you.

[birdman]

The version stamp is there (see in backup in /tmp)There is no backup in /tmp. At least not on my system.
But that would be irrelevant, as the image uses the copies in /etc/enigma2/, and only one of the three timer files has a version on the data structure (they all have an xml version - but that is also irrelevant).


root@mbtwin:/etc/enigma2# grep -i version= *timer*
autotimer.xml:<?xml version="1.0" ?>
autotimer.xml:<autotimer version="7">
pm_timers.xml:<?xml version="1.0" ?>
timers.xml:<?xml version="1.0" ?>

[Rob van der Does]

There is no backup in /tmp, but there is a /tmp in the backup :)

That holds 3 files:
1- the kernel version (on which is decided if plugins can be re-installed),
2- the backup image version (on which is decided if the settings can be restored), and
3- the extra installed plugins.

[birdman]

There is no backup in /tmp, but there is a /tmp in the backup :)Yes.
But the backup image version just says "Hades", so would (presumably_ prevent you restoring an Apollo backup on Hades. We are discussing the version-stamping of timers data files.