cccam: emm match only checks for last used caid of cccam reader

On actual Trunk 8625 there is still a old newcamd-problem with proxy-emm for remote-newcamd/newcamd and cccam-ext/cccam-ext oscam/oscam connections:

Basic-Config:

ACamd/newcamd (Windows) -> oscam-proxy <-cccam-ext-proto-> oscam-master-server with some local cards

When the proxy-server is initialy cold started, AND then firing up Acamd on Windows and made the "initial connection" with newcamd to the proxy-server, there are always HEX and ProviderID "000000/000000" for all connections made from this client.

Shutting down Acamd and make a new restart, this time HEX-Serial and ProviderIDs are transfered correctly to the client, but only for the actual "last" channel. By zapping to another channel with different CAID and different remote-port which was never used before firing up dvbviewer, its the same problem: HEX/ProviderIDs gets 000000/00000 from proxy-server. Shuting down Acamd and restart on this channel again, gets the correct EMM-data at the second time.

This is true under the following conditions:

1.) on the proxy-server "conectoninit" is NOT set on the remote reader, in case the proxy is connected via newcamd/newcamd to a master-oscam-server. (So a typical "late opening"/connect on demand config)

2.) When the proxy is connected via cccam-ext proto to another oscam-server and there is MORE then ONE(!) card imported from the master-server.

So i asume something unusual is wrong with the array/variables that holds the EMM-remote-data. Or get overwritten internaly or NULLed by mistake, or similiar others. Or a clientID/Packet-Checksum-Counter or similar is not set/wrong when a newcamd-client initialy connect to oscam. So the "first Packet" or "First Request" is mostly dropped ?

On the ECM-side there was a similar problem, that was fixed by "manu" before few weeks. Here the first packet was always dropped on oscam, which resulted in a "Not found" for the very first remote newcamd-connection.