Jump to content


Photo

timers.xml symlink problem (PLi / Duo2)

symlink timers

  • Please log in to reply
7 replies to this topic

#1 rtzhjgg0

  • Senior Member
  • 568 posts

+13
Neutral

Posted 29 November 2013 - 08:42

I use to share a central timers.xml between different images. This file is in /media/hdd and is symlinked on each image.
This works perfectly on VTi and BH etc but not on OpenPLi. I can can create the symlink on PLi with

-----------
init 4
rm -rf /etc/enigma2/timers.xml
ln -sfn /media/hdd/timers.xml /etc/enigma2
init 3
-----------

but after a E2-restart PLi overwrites the symlink. Other images don't overwrite the symlink after a E2-restart, but just write correctly the timer differences to /media/hdd/timers.xml
 

How can I avoid overwriting of this symlink in OpenPLi?


Selfsat H50M4
Ultimo4K /2xTwinS2, VTI, PLi, ATV...
NAS: Qnap221

Re: timers.xml symlink problem (PLi / Duo2) #2 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 29 November 2013 - 10:56

We use atomic writes, to ensure you never end up with a corrupted file.
(Instead, you always have either the old unmodified version, or the new version)

This method does not work when the file is a symlink, it will be replaced by the new file.

Re: timers.xml symlink problem (PLi / Duo2) #3 rtzhjgg0

  • Senior Member
  • 568 posts

+13
Neutral

Posted 29 November 2013 - 11:05

Ok, I understand :)


Is there any alternative method/workaround to share timers.xml with other images/boxes?


Selfsat H50M4
Ultimo4K /2xTwinS2, VTI, PLi, ATV...
NAS: Qnap221

Re: timers.xml symlink problem (PLi / Duo2) #4 WanWizard

  • PLi® Core member
  • 56,655 posts

+1,178
Excellent

Posted 29 November 2013 - 12:16

Just curious: why would you want to run timer events on multiple boxes simulaneously? You'll end up with multiple copies of the same recording?


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2+fallback), Octagon SF8008 (S2+T2), Zgemma H9.2H (T2+fallback)

Many answers to your question can be found in our new and improved wiki.

Because to health reasons, I will not be active very often anymore.


Re: timers.xml symlink problem (PLi / Duo2) #5 rtzhjgg0

  • Senior Member
  • 568 posts

+13
Neutral

Posted 29 November 2013 - 12:30

Just curious: why would you want to run timer events on multiple boxes simulaneously? You'll end up with multiple copies of the same recording?

Boxes have in my configuration differnt timers.xml:
-all DM8000 flash and multiboot images share they timers.xml in /media/usb
-all Duo2 flash and multiboot images share they timers.xml in /media/hdd


Selfsat H50M4
Ultimo4K /2xTwinS2, VTI, PLi, ATV...
NAS: Qnap221

Re: timers.xml symlink problem (PLi / Duo2) #6 Pr2

  • PLi® Contributor
  • 4,470 posts

+179
Excellent

Posted 29 November 2013 - 19:25

And since OpenPli doesn't support multiboot...  ;)


NO SUPPORT by PM, it is a forum make your question public so everybody can benefit from the question/answer.
If you think that my answer helps you, you can press the up arrow in bottom right of the answer.

Wanna help with OpenPLi Translation? Please read our Wiki Information for translators

Sat: Hotbird 13.0E, Astra 19.2E, Eutelsat5A 5.0W
VU+ Solo 4K: 2*DVB-S2 + 2*DVB-C/T/T2 (used in DVB-C) & Duo 4K: 2*DVB-S2X + DVB-C (FBC)
Edision OS Mio 4K: 1*DVB-S2X + 1*DVB-C/T/T2
 


Re: timers.xml symlink problem (PLi / Duo2) #7 rtzhjgg0

  • Senior Member
  • 568 posts

+13
Neutral

Posted 29 November 2013 - 20:52

This method does not work when the file is a symlink, it will be replaced by the new file.

...perhaps a E2-plugin that allows the user to choose a different path for his timers.xml ?


Selfsat H50M4
Ultimo4K /2xTwinS2, VTI, PLi, ATV...
NAS: Qnap221

Re: timers.xml symlink problem (PLi / Duo2) #8 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 29 November 2013 - 21:00

That sort of thing cannot be controlled by a plugin.
Same as making a workaround, which detects that timers.xml is a symlink, and decides not to use the atomic write + move operation.

And to be honest, I'd rather not make such workarounds, just for a use case like this. (though I understand why it makes sense in your case)
The main goal is a safe and reliable storage of programmed timers, the last thing you want is a corrupted timers.xml...





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users