https://bugs.kde.org/show_bug.cgi?id=371579

Mauro Carvalho Chehab <mchehab+...@kernel.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Mauro Carvalho Chehab <mchehab+...@kernel.org> ---
(In reply to Mauro Carvalho Chehab from comment #2)
> (In reply to Stefan Huebner from comment #0)
> > It seems, the issue is caused by the big amount of EPG data on these
> > channels, because when commenting out the loop that checks for existing EPG
> > entries in  dvbepg.cpp - DvbEpgModel::addEntry(), the issue is not present.
> 
> Not sure how to fix it. We could try to optimize the EPG code in Kaffeine,
> for example using some hash table in order to avoid the Iterator loop on it.
> Not sure if this would be enough, though.
> 
> Another option would be to have an option that would disable EPG parsing,
> but that would remove an interesting functionality from Kaffeine.
> 
> (In reply to knossos456 from comment #1)
> > Same problem here.
> > Seems to be a AGC problem, I have problems with lowests C/N and v 2.05 , was
> > ok with 1.22
> 
> Yeah, a low C/N could be the root cause, as it may start creating duplicated
> entries.

I was able to reproduce the bug here with a new DVB-S2 provider.

The issue seems to happen even with high C/N signal. The problem is that the
algorithm that detects duplicated entries is O(n). So, on providers with a
big amount of entries, it becomes very slow, making Kaffeine irresponsible,
specially when the program guide window is opened.

That was causing frame loss and an overload on one of the CPUs:

top - 09:25:05 up 8 days, 16:44,  4 users,  load average: 0,62, 0,25, 0,21
Tasks: 343 total,   3 running, 340 sleeping,   0 stopped,   0 zombie
%Cpu0  :  8,3 us,  0,7 sy,  0,0 ni, 90,0 id,  0,0 wa,  0,0 hi,  1,0 si,  0,0 st
%Cpu1  :  6,6 us,  1,7 sy,  0,0 ni, 91,0 id,  0,0 wa,  0,0 hi,  0,7 si,  0,0 st
%Cpu2  : 99,0 us,  0,3 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,7 hi,  0,0 si,  0,0 st
%Cpu3  :  5,3 us,  1,0 sy,  0,0 ni, 93,0 id,  0,0 wa,  0,3 hi,  0,3 si,  0,0 st
%Cpu4  :  7,0 us,  1,3 sy,  0,0 ni, 91,0 id,  0,0 wa,  0,3 hi,  0,3 si,  0,0 st
%Cpu5  :  7,0 us,  0,7 sy,  0,0 ni, 92,3 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu6  :  1,3 us,  0,0 sy,  0,0 ni, 96,0 id,  0,0 wa,  2,7 hi,  0,0 si,  0,0 st
%Cpu7  :  6,3 us,  1,3 sy,  0,0 ni, 92,0 id,  0,0 wa,  0,3 hi,  0,0 si,  0,0 st

I changed the logic to use a O(log n) algorithm, and simplified the logic
that detects duplicated entries. With that, on my machine, the CPU workload 
reduced a lot. With the program guide window opened, I'm now getting:

top - 09:13:42 up 8 days, 16:32,  4 users,  load average: 0,93, 0,54, 0,29
Tasks: 342 total,   1 running, 341 sleeping,   0 stopped,   0 zombie
%Cpu0  : 11,6 us,  0,7 sy,  0,0 ni, 87,1 id,  0,0 wa,  0,0 hi,  0,7 si,  0,0 st
%Cpu1  :  7,3 us,  1,0 sy,  0,0 ni, 91,0 id,  0,0 wa,  0,0 hi,  0,7 si,  0,0 st
%Cpu2  :  7,6 us,  1,0 sy,  0,0 ni, 90,7 id,  0,0 wa,  0,7 hi,  0,0 si,  0,0 st
%Cpu3  :  6,6 us,  1,0 sy,  0,0 ni, 92,1 id,  0,0 wa,  0,3 hi,  0,0 si,  0,0 st
%Cpu4  :  8,4 us,  1,3 sy,  0,0 ni, 89,3 id,  0,0 wa,  0,3 hi,  0,7 si,  0,0 st
%Cpu5  :  8,6 us,  1,3 sy,  0,0 ni, 89,4 id,  0,0 wa,  0,3 hi,  0,3 si,  0,0 st
%Cpu6  :  8,0 us,  1,3 sy,  0,0 ni, 87,0 id,  0,0 wa,  3,7 hi,  0,0 si,  0,0 st
%Cpu7  : 10,6 us,  1,0 sy,  0,0 ni, 87,4 id,  0,0 wa,  0,3 hi,  0,7 si,  0,0 st

With sounds reasonable.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to