svdrpsend CLRE doesn't clear EPG completely if there's active timers

    Thank you for this hint and sorry for the noise. I will now contact the live maintainer to fix that.

    Ups, I am one of them ...

    Like 2

    short interim report:

    kls assumption was correct, Live does copies of timer objects to make his own sorted timer list. Not a very good idee ...

    I have to rewrite the timer handling code without timer object copies and use instead the vdr class cSortedTimers.


    First try was succesful, I can now clre all events. But I have still some invalid lock sequence reports to fix.

    kls

    I have never worked with locks and I need some support: What is wrong with this lock sequence ? There are only timer read locks. Are nested read locks not allowed ?

    Code
    Aug  6 10:15:15 VDR-2004-Dev vdr: [283179] 283179  -  R  -  -  -  -  -  -  -  -  L
Aug  6 10:15:15 VDR-2004-Dev vdr: [283179] 283179  R  *  -  -  -  -  -  -  -  -  L

    You are trying to lock the timers while holding a lock on the channels.

    To implicitly avoid deadlocks when locking more than one of the global lists of VDR at the same time, make sure you always lock Timers, Channels, Recordings and Schedules in this sequence. So you need to give up the lock on the channels, then lock the timers, and, if necessary, lock the channels again.

    kls Thx, this helped me to find the invalid lock sequence.


    -Dis

    Now we can start with the tests from here.

    I had to change many critical lines of code. So we need intensitiv testing before merge into master. Please also take a look in your syslog, if there are any invalid lock sequence reports. Run vdr with -l3.

    Quote from -Dis

    So things to try with live plugin are timers in general (set new timer, delete etc.). CLRE command per channel and whole EPG.

    I think, this are the importent things. But because of the deep changes, watch also normal use of your VDR for lock sequence reports in syslog.

    These messages are probably normal?

    Yes, these are debug messages which should help me to find lock sequence errors.

    They will be removed in the final version.

    I use it now on my productive VDR, it feels there is an improved performance too.

    kfb77 I tried setting timer via live plugin, deleting timer, clearing EPG while timers set, playing channels from VDR and from Kodi with vnsi client. I didn't find any issues using VDR and live and no lock sequence errors in syslog.


    Huge thanks to you for quick fix to this problem :)

    Quote from kfb77

    I use it now on my productive VDR, it feels there is an improved performance too.

    Do believe that this comes mainly from eliminating the for-iterators?
    Or is it rather from using SortedTimers instead of copying?


    Thanks for the nice work, btw!

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

    Quote from davie2000

    Do believe that this comes mainly from eliminating the for-iterators?

    The statement scared me at first but I checked it: No less for loops, only others.


    Quote from davie2000

    Or is it rather from using SortedTimers instead of copying?

    Copy a object takes CPU and memory, it is always better to avoid this. Especially if it brokes VDR functions. ;)

    Edited once, last by kfb77 ().

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login