channel retune issue

[9000h]

I do have reduced the test to 2 channels, 1 good and a second bad (RTL7) channel.
If I switch back and for multiple times I end up with no picture on the good channel.

Das Erste HD;ARD:11493:HC23M5O35P0S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0
RTL7;CANALDIGITAAL:12343:hC34S0:S19.2E:27500:518+8190=2:90=dut@4:38:1817,100:2006:53:1097:0

vdr.log.gz

Feb 3 19:11:23 localhost minisatip[3710]: [03/02 19:11:23.490 main]: PLAY rtsp://192.168.178.129/stream=1?pids=5101,5102,5103,5105,5106 RTSP/1.0

Feb  3 19:11:15 localhost vdr: [27669] femon receiver thread started (pid=27576, tid=27669, prio=high)
Feb  3 19:11:15 localhost vdr: [27670] femon osd thread started (pid=27576, tid=27670, prio=high)
Feb  3 19:11:23 localhost vdr: [27580] SATIP-ERROR: Tuning timeout - retuning [device 0]
Feb  3 19:11:43 localhost vdr: [27580] SATIP-ERROR: Tuning timeout - retuning [device 0]
Feb  3 19:11:44 localhost vdr: [27670] femon osd thread ended (pid=27576, tid=27670)
Feb  3 19:11:44 localhost vdr: [27669] femon receiver thread ended (pid=27576, tid=27669)

this seem to be the point where it's going wrong, vdr satip did only request the pids for the good channel but there is no tune.

if I comment this line out, it works as expected.

vdr-plugin-satip/tuner.c

Line 226 in 826dea4

return true;

it's happen with minisatip and also with a IDL-400s aka Digibit R1 with original firmware
the issue also not limited to dvb-s it also happens with dvb-c

[9000h]

did the check in case of a retune make sense here?

vdr-plugin-satip/tuner.c

Lines 224 to 227 in 826dea4

	if (!strcmp(*streamParamM, *lastParamM)) {
	debug1("%s Identical parameters [device %d]", __PRETTY_FUNCTION__, deviceIdM);
	return true;
	}

[9000h]

there is another issue in tsSet the UpdatePids is not needed here as it's done later on in tsLocked

vdr-plugin-satip/tuner.c

Line 126 in 826dea4

UpdatePids(true);

vdr-plugin-satip/tuner.c

Line 156 in 826dea4

if (!UpdatePids()) {

[9000h]

I see one of the issues come from the latest commit, so may @REELcoder can explain how this makes sense in case of re-tune as it did not work here with as single server dvb-s2/c/t2.

vdr-plugin-satip/tuner.c

Lines 224 to 227 in 826dea4

	if (!strcmp(*streamParamM, *lastParamM)) {
	debug1("%s Identical parameters [device %d]", __PRETTY_FUNCTION__, deviceIdM);
	return true;
	}

[REELcoder]

The idea is, that no re-tuning is needed, if you switch from to channel on the same transponder/frequency. But the two channels you mention, are not on the same transponder.

Please activate more satip loging.

[9000h]

if I comment this part out all is fine, as it's happen with minisatip and digibit r1 it should be also happen on a octonet. Can you please try as written in the first post.

[REELcoder]

Same effect here. Only with fast switches. If you wait on the 20s tuning timeout on the invalid channel, the valid will be tuned.

Seems to be a limitation on the ::Action() state machine. Can have a lock into that. Does it happen only with invalid channels?

[9000h]

I do only notice this with invalid channels, and with multiple sat pos. and VDR you have every time some in the channels.conf. I may heart also the background eit/epg scan but the logs are grow so fast with a higher level.
But as I wrote the code is may not needed and I see no drawback without.

[REELcoder]

It was intended to prevent from unnecessary retuning if you switch between channels on the same transponder. But I see no problem to remove this in the meantime. I will check what is missing that it works with invalid channel as well.

[REELcoder]

My commit 8d84938 should fix this.

The problem was, that that lastParamM was not updated when you switch to crypted invalid channel.

[9000h]

thanks, still testing but looks like without it's still better

[REELcoder]

Does ist work? If you see problems, please send a TRAC 0x0009 log.

[9000h]

unfortunately not, on the last switch to chan 1 there is no picture
sorry was the wrong log before
syslog.txt

[REELcoder]

Strange. It is hanging in tsTunned at 22:45:34 when you switch the channel. In tsTunned hasLockM should be false and the "Identical parameters" branch should not get hit in Connect(). But it's happening in your case. Cann you try to add more debug code in Connect() to find out what is happening with hasLockM

[9000h]

it a matter of time here, if you switch with in vdr with key 0 you should be able to reproduce it.

[9000h]

I like to bring this up again as with vdr-2.5.1 and git from today the issue is still happen here
I do have to comment out the "return true" to fix it.

vdr-plugin-satip/tuner.c

Line 228 in 43b60b1

return true;

[rofafor]

Could you try the latest master commit whether it helps?

[9000h]

will do

[9000h]

looks like if frontend reuse is disabled it works as expected, but not with frontend reuse enabled (also not with comment the return mentioned above)

[9000h]

need to correct me
looks like if frontend reuse is disabled it works as expected when the "return" is commented, with frontend reuse the issue is still there

[rofafor]

When looking at your latest log, there's no Identical parameters within the last zap, so commenting the return true; shouldn't have any effect as that code block isn't even executed. IMO, channel switches and retuning goes as it should. There's one identical parameters message when properly re-tuning the channel 1 at 21:11:25.

Please, run the satip plugin with one device only and remove all additional plugins like hbbtv that affects devices. Mark into logs when channel isn't visible although it should. Also capture (e.g. tcpdump) port 544 traffic from the same time duration. Running the plugin with one device only makes debugging much easier.