(Very) slow channel change

[sdf]

Hi sub,
sent you a PM
thank you,
sdf

[sub]

sdf, can you see if this patch makes any difference?

[sdf]

Hi sub,
tried your patch.
No difference.
It seems to me like a tuning problem, like npvr is waiting for signal from the dvb adapter.
But this affects npvr only, and not other software.
Maybe it waits for a certain signal/quality level before passing .ts flux to reader/decoder?
Do you create the .ts file as soon as the is a tuning request, and then wait for signal?
Otherwise I have no ideas, cause sometimes tuning is instant, and other waits for 6-7 secs, others 15-20, and sometimes stalls (tuner is required for recording).
Thank you,
sdf

[sub]

Hi sub,
tried your patch.
No difference.

I'll send you a link to a further thing to try.

[sdf]

It's better.
Sent you a PM
Thank you,
sdf

[sdf]

Hi, had a look at the logs, because i've noticed that the second .ts in kodi is rendered instantly (video appears as soon the .ts is created), and in nextpvr only when the .ts of the first channel is deleted.
I've noticed there's a main point in which npvr stalls:

2015-09-08 07:31:30.838 [DEBUG][1] StartLiveTV@5 (servicetype=1)
2015-09-08 07:31:30.838 [DEBUG][1] SwitchToStream@1
2015-09-08 07:31:30.839 [DEBUG][1] Unmapping all pids from pin Video
2015-09-08 07:31:30.839 [DEBUG][1] Unmapping all pids from pin Audio
2015-09-08 07:31:30.839 [DEBUG][1] SwitchToStream@2
2015-09-08 07:31:30.839 [DEBUG][1] SwitchToStream@3
2015-09-08 07:31:40.054 [DEBUG][1] SwitchToStream@4
2015-09-08 07:31:40.334 [DEBUG][1] SwitchToStream@5
2015-09-08 07:31:40.561 [DEBUG][1] StartLiveTV@6
2015-09-08 07:31:40.561 [DEBUG][1] StartLiveTV@6
2015-09-08 07:31:40.562 [DEBUG][1] StartLiveTV@7
2015-09-08 07:31:40.563 [DEBUG][1] StartLiveTV@done
2015-09-08 07:31:40.564 [DEBUG][1] GetEventCode() returned: 0x8100
2015-09-08 07:31:40.564 [DEBUG][1] GetEventCode() returned: 0x000e
2015-09-08 07:31:40.564 [DEBUG][1] audio renderer now MPEG1
2015-09-08 07:31:40.564 [DEBUG][1] Audio renderer not found. Warning user...
2015-09-08 07:31:40.564 [DEBUG][1] GetEventCode() returned: 0x8102
2015-09-08 07:31:40.564 [DEBUG][1] Aspect ratio now: 16x9
2015-09-08 07:31:40.564 [DEBUG][1] Resolution is now: 704x576
2015-09-08 07:31:40.564 [DEBUG][1] Source Aspect Ratio: 16x9
2015-09-08 07:31:40.564 [DEBUG][1] Setting display rect: 0.000934,0.000000,1.000000,1.000000
2015-09-08 07:31:40.564 [DEBUG][1] GetEventCode() returned: 0x8101
2015-09-08 07:31:40.835 [DEBUG][1] Client about to request renewal of handle: 180018
2015-09-08 07:31:44.665 [DEBUG][1] Updating OSD.
2015-09-08 07:31:46.747 [DEBUG][1] Updating OSD.
2015-09-08 07:31:47.509 [DEBUG][1] Updating OSD.

There are nearly 10 secs between SwitchToStream@3 and SwitchToStream@4.
Noticed 3 secs also in "updating OSD".
Don't know what SwitchToStream@ is for, but maybe it can be of help?
Thank you,
sdf

[sub]

There are nearly 10 secs between SwitchToStream@3 and SwitchToStream@4.

If you can provide remote access to a machine with this problem, I can try to find out where (in the many steps that happen between @3 and @4), where your machine is having this problem.

Noticed 3 secs also in "updating OSD".

Nah, the logging doesn't show any problems there. It's not in the direct sequence of events. It's called later.

[sdf]

If you can, sending TV login
Bye,
sdf