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?
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?
It has always been /etc/enigma2/
Doh. Knew I should have done this after morning
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.
My posts contain my own personal thoughts and opinions, they do not represent those of any organisation or group but my own.
If you don't like what I post, Don't read it.
SIMPLES.
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).
Help asked via PM will be ignored.
The forum is there for help and all will benefit from your questions.
NO CARD SHARING TALK WILL BE TOLERATED, LAN OR WAN, IN OPEN FORUM OR PM !
English is not my native tongue.
I apologise for all my grammar, spelling and idiom errors.
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.
My posts contain my own personal thoughts and opinions, they do not represent those of any organisation or group but my own.
If you don't like what I post, Don't read it.
SIMPLES.
I didn't restore in then end but recreated them anyway
Larry-G (02-05-15)
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.
Support The Sponsor - Buy from the best HERE
Please abide by the rules - have a read HERE
VIX manual & guides >>HERE
Download images from >> HERE
New Box Setup Guide >>HERE
D I S C L A I M E R
My right to post information is protected under the rights for freedom act. In all instances, information discussed here on my posts are either hypothetical in nature, out of general curiosity, common knowledge, public knowledge, or role-play. Any use of the collective descriptions and shared knowledge from any of my posts are at the sole discretion of the reader. I am not responsible for what you do with it!
PM HELP WILL BE IGNORED PLEASE POST HERE IN FORUM AS IT BENEFITS EVERYONE
Follow us on Twitter
NO CARD SHARING TALK WILL BE TOLERATED, LAN OR WAN! IN OPEN FORUM OR PM
IF THE POSTS HELP PLEASE CLICK THANKS OR ADD TO REP ?
What new naming protocol? Since when did timers have names?
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....which will not work with timers created with a older image, you really need to set them up again for best results.
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
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.
Help asked via PM will be ignored.
The forum is there for help and all will benefit from your questions.
NO CARD SHARING TALK WILL BE TOLERATED, LAN OR WAN, IN OPEN FORUM OR PM !
English is not my native tongue.
I apologise for all my grammar, spelling and idiom errors.
John57 (04-05-15)
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).
Help asked via PM will be ignored.
The forum is there for help and all will benefit from your questions.
NO CARD SHARING TALK WILL BE TOLERATED, LAN OR WAN, IN OPEN FORUM OR PM !
English is not my native tongue.
I apologise for all my grammar, spelling and idiom errors.
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).
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
pembo (03-05-15)
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.
Help asked via PM will be ignored.
The forum is there for help and all will benefit from your questions.
NO CARD SHARING TALK WILL BE TOLERATED, LAN OR WAN, IN OPEN FORUM OR PM !
English is not my native tongue.
I apologise for all my grammar, spelling and idiom errors.