Branch: plugin-rewrite - Initial channel is not available for a few seconds

[CReimer]

VDR complains "Channel not available", but after a few seconds the channel shows up as expected.

[manio]

Can you provide me the vdr log with verbose plugin output?

[CReimer]

Of course: Here --> http://pastebin.com/Fx0cNSCA

[manio]

Thank you for your log and testing :)

I can see that there are two things: first of all the channel can be descrambled after CAM init. So VDR has to ask a CAM for the second time (it was not ready for the first time). Besides there was a change in channel configuration:

retuning due to modification of channel 1

After this it seems that it was recording fine.

Can you check if the master branch is doing the same?

Is the plugin-rewrite branch working fine for you beside this issue?

[CReimer]

Can you check if the master branch is doing the same?

Nope. Master Branch works fine. Channel is viewable immediately.

Is the plugin-rewrite branch working fine for you beside this issue?

Yes. No other problems.

[manio]

ok, can you try this patch? http://pastebin.com/raw.php?i=3KKF2ttc

[CReimer]

Yes. I think the problem is gone with your patch. Thanks.

[manio]

Thank you for testing. Please leave this issue open. I'll close when it's ready.

[CReimer]

Commit 7c28099 doesn't fix this issue.

Here's the log of the newest plugin-rewrite branch. http://pastebin.com/4URgV8zT BTW: There are only two DVB-S cards in my system. In the Settings --> CAM menu are three CAMs listed. Shouldn't there be two, too?

[manio]

Please apply the patch I mentioned here: https://github.com/manio/vdr-plugin-dvbapi/commit/e5e59ed61176d60891fb8e68f773b5b9eed941f4#commitcomment-5047043

About the CAMs - indeed there should be two - I have to investigate it...

[CReimer]

I've already applied that patch. But thanks for the hint.

[manio]

Thank you for report and testing. I've just updated that patch to cover your case (when vdr starts). It should work better now.

[manio]

About your devices: I can see you have two frontends (found 2 DVB devices) but just after this a new device appear: 'new device number 3'. Isn't it because of some plugin, eg softhddev?

[CReimer]

The new patch doesn't help. New log: http://pastebin.com/y4iS50Ne

Isn't it because of some plugin, eg softhddev?

Yes, but softhddevice doesn't provide CAMs.

[manio]

According to the log all is fine. Can you specify what is really wrong?

It doesn't matter if softhddevice provides a CAM or not. The plugin just creates a CAMSlot for every VDR device, so it's OK in this case.

[CReimer]

Hmm. Let's say my inital channel is channel 5 (Prosieben HD, crypted). The first thing I see after VDR started is a message dialog with "Kanal nicht verfügbar" (German for: "channel not available") Then it takes 1 second or two and then channel 1 (ORF1 HD, crypted) appears. After that everything works fine. Also channel 5 is viewable.

Edit: In the above log it's channel 13 (Nick/CC HD, also crypted) instead of channel 5.

And this happens after every restart of vdr. Even if oscam is up for hours. Therefore i think it's no connection problem with oscam.

[manio]

Ok, but in your above log I cannot see this 'Kanal nicht verfügbar'. This also should be in the log, right?

[manio]

What if you pass the plugin as the first to load with -Pdvbapi in the VDR commandline?

[CReimer]

Yes that's more or less my fault. Wrong parameters for journalctl. The message is hidden in these "blob data" blocks.

Here's an uncesored log, with only dvbapi and softhddevice loaded. http://pastebin.com/uPe6Pi7g

[manio]

What if you try this: http://skyboo.net/init.diff

[CReimer]

Nope. Doesn't help. More logs?

[manio]

Hmmm. I'm out of ideas which commit broke it. Yes, please provide a log...

[manio]

Chris, please do the following: you need VDR with my patch (http://skyboo.net/vdr2.1.3-cadescr.diff)

1. first please schedule a recording (which would start with VDR).
2. please temporary disable not necessary plugins, enable only the relevant (I would like to get rid of noise in the log).
3. checkout and build my staging branch (it's the older plugin-rewrite + patch which you confirmed as fix to the issue)
4. give me a log
5. checkout and build my plugin-rewrite branch
6. give me a log

I'd like to compare these logs - as according to you - it should differ - and in first case all is fine, while in 2nd case there should be a problem with 'channel not available'. Maybe from the logs analysis I'll be able to see what commit broke it...

Thank you in advance.

[CReimer]

Unfortunately it also happens with the staging branch. I don't know why I thought it is fixed. Here's a log with master: http://pastebin.com/cWwCKmr0 staging: http://pastebin.com/ty6rQ6gN plugin-rewrite: http://pastebin.com/rNGVBppm

Without the new interface vdr start also takes about 2 seconds longer.

1. first please schedule a recording (which would start with VDR).

Ermm, sorry I missed that part. I'm currently not at home. So the above logs must be enough for now.

[manio]

Thank you for your logs. Ok. I have a theory for this problem. But as It's now not easy to fix it without deeper VDR changes, I'd like to prove it a little differently: Instead of fixing plugin-rewrite I'll broke master - to see if my theory is correct :)

So please use master and apply this patch: http://pastebin.com/ueJw2Y8u And please compare if it behaves like staging/plugin-rewrite - I mean if it is the same problem and if it starts also 2 seconds longer.

[CReimer]

Yes. That's it.

With your patch against master it behaves exactly like staging and plugin-rewrite. And you misunderstood me. master takes longer to start. staging and plugin-rewrite are starting faster.

[manio]

Ah I see, and in fact it confirms that in this case less and simpler code is better and faster :)

And about the clue: The point is that in previous way (master) the plugin was not allowing to make a device ready until a CAM was created. It was delaying it. When using new interface, the VDR is just a bit faster when switching to a channel (and in fact my plugin has not finished CAM init) - and this is the cause of 'channel not available'. Now this check is besides me - it could be done only in VDR. But generally I think that it maybe not a good solution: think about initial FTA channel, this would only increase the VDR start time.

Fact is - that even with this small glitch, the VDR is starting decryption after a while, and after this all is working fine. So a quick question: Can you live with it?

[CReimer]

To be honest..., eerm, no :smile:

I could live with the channel not available message. But not with the initial channel stuff. I don't watch FTA channels at all and I'm use to vdr's behaviour to jump back to the last watched channel.

That feature would totally disappear.

What about real CAMs. Aren't there situations where the CAM isn't ready, too?

[CReimer]

After a short search in VDR's source I found this.

virtual bool Ready(void); ///< Returns 'true' if the CAM in this slot is ready to decrypt.

Isn't that exactly what's necessary here?

[manio]

No, this Ready() function is for different purpose - it's for a CAMSlot, and at that time a CAMSlot is even not assigned to a channel.

So the problem is that it is then switched to FTA after this problem and you cannot go back with '0' ? I am asking because I am not using VDR that way since I replaced my old TT1.3 with newer cards :)

About real CAMs - I don't know but it's possible...

[CReimer]

No the feature I'm referring to is.

When I shutdown vdr and the last channel is ProSieben HD, I will have Prosieben HD as inital channel next time I start vdr. If that channel is not available vdr tries all channels for a working one.

If you want I can talk to Klaus Schmidinger.

What we need is a way to delay switching to any channel before your plugin is ready.

[manio]

OK, as I have an outlook on this, I'll ask Klaus what could be done...

[manio]

@CReimer I've sent you an email with the patch

[CReimer]

Hmm, I haven't received a mail from you.

Did you use github@creimer.net?

Edit: Found it. Where did you find this Freenet e-mail address? :smile: I don't check that mailbox regularily.

[CReimer]

At the moment it seems to work.

But now I have these error messages in log. http://pastebin.com/0R4xVdTq

switching to channel 9 [...] DVBAPI-Error: FATAL: VDR doesn't provide CA desriptors, cannot continue [...] retuning due to modification of channel 9 switching to channel 9

[manio]

Ok, but the problem you mentioned is probably because you don't have http://skyboo.net/vdr2.1.3-cadescr.diff applied, do you? It will also be a part of vdr.

[CReimer]

Ahh. OK. This patch is still necessary. OK.

[manio]

Ok, thank you for testing and reporting this problem. As the fix is ready and will be a part of new VDR - Closing the issue.

[CReimer]

What about the waitcam patch? Can I use it publicly in my vdr4arch project?

[manio]

No, please just wait for new VDR developer version. It will be included.