C.Y.M wrote:
Udo Richter wrote:
C.Y.M wrote:
Isn't a "start day" set when a single event timer is created? The original timer that is created is just set to a single day event. Then I edit that timer to recur every Monday.
When the timer changes to repeated, the start day (in seconds-since-epoch) is set to 0 at the same moment. A good hint: Repeated timers with start day != 0 will have a '!' in front of the timer. This would also indicate weired things stored into that field.
The edit dialog operates on a copy, and the copy overwrites the actual timer in one big copy operation.
After I accept the timer modification to recur every Monday, thats when VDR freezes. Hm, I wonder what is different.
One thing you can try: When VDR freezes, connect gdb to it with --pid=xxx and do the usual thread apply all bt. That way we should at least see where it is frozen.
Udo, I was wrong about the skin not making a difference. When I am in Enigma, thats when it crashes. If I just use the default STNG skin, its fine. There is some schedule checking in the Enigma skin, I'm sure thats what is causing it. It crashes when I go into the main menu (I think editing the timer was just a coincidence). So, it appears that Enigma needs the fix.
The problem I am experiencing with this starttime patch has to do with a new function in the text2skin plugin that was introduced by Enigma.
struct tEvent : public cListObject
This is added to text2skin by the following patch: text2skin_extensions-0.8.diff
Enigma will list the upcoming timers in the main menu and thats what sends vdr into a lockup.
Best Regards.