VDR Streamdev Plugin

the patch vdr-2.2.0-clear-pids.diff.gz is outdated. Please try this patch
http://www.vdr-portal.de/board17-developer/board97-vdr-core/p1252658-zu-viele-pids/#post1252658

Hi Zabrimus,

thanks for your efforts and for fixing the duplicate PIDs thing in VDR.

I finally found some time to take a closer look at the streamdev-channelchange patch:

The patch drops the "re-tune only if CA IDs changed" part. I hesitate to drop that part as there had been considerable problems before someone sent me that patch. Of course these problem might have been caused by something different which might have been fixed in the meantime. Does the presence of this part make any different? If not I'd prefer to keep it.

What's the purpose of the "NumUsableSlots" part? Unless I've overlooked something it is part of cDevice::GetDevice(...) which is called right after that part anyway. So except for the more specific error message, it could be dropped.

The remaining difference is the call to cDevice::GetDevice(...). IMHO the ChannelChange callback just indicates an update of PIDs, not the loss of the device. So is it really necessary to call cDevice::GetDevice(...) here? (Note that I'm not familiar with CAMs and how they handle things). If it is necessary, then the priority argument must be "m_Priority" instead of "LIVEPRIORITY".

BR,
Frank

Hi,

i did not understand the caid-change-thing, because my smartcard can only decrypt exactly one CAID, independent of the desired channel. If someone has more than one card, it could be possible that the CAID changes if another channel is selected. But i think, the handling of the CAID should be done by the VDR or the plugin, which are able to handle this type of requirement.

I have taken the numUsableSlots-code from the xvdr implementation. This part is only necessary if the plugin wants to present another (log-)message as VDR. But the default message from VDR if encrypting is not possible is sufficient.

The desired behaviour is to get a device for this channel. In my opinion the PID changes in two cases: A real channel switch or changed PID from the television provider for the same channel. The second case often happens for channels with regional programs (like WDR, 3. Program).
In the second case the device is already tuned to the transponder and the only necessity is to request the changed PID. But in the first case it is necessary to request a device which is currently tuned to the desired transponder or is able (free) to tune to.
Think of 2 clients requesting the same transponder. If one clients wants to change the transponder a change of only the PID will not achieve the objective.

And the priority should really be changed. I did not pay attention.

Zabrimus

test

Okay. After some sleep i'm not really sure why a new device is needed. But i had read the discussion between KLS and the author of xvdr about channelChange. And the result was, that the plugin should ensure or try to do the very best to provide the channel. I will check a stripped down version of the patch.

Zabrimus