[confirm] Wrong detection of FTA disables watching channel (2 Viewers)

[georgius]

First report of this problem you can find in this post (also logs are attached). My very short analysis you can find in this post.

Descritpion of problem: Wrong detection of FTA changes channel information stored in CardAllocationCache class. When user tries to change channel to another, everything is OK. But when tries to change channel to already seen channel, channel information is get from cache (with wrong FTA state) and TV Server not tune to channel because no CAM is installed.

 

[mm1352000]

Hi georgius

If the TV service has started to cache channel details then that could definitely cause problems. As far as I'm aware it never used to do this (?). Channels are not always only free-to-air or only encrypted - they can be mixed. It is true that TV Server is not 100% accurate on detection of FTA/encrypted. However the TV service really needs to allow for dynamic detection of FTA/encrypted status...

Are the channels that chrik is trying to tune actually encrypted, not encrypted, or sometimes encrypted?

mm

 

[georgius]

I ask him for dump file which we can analyze.

 

[Mr.Blade]

can you use this ?

 

[georgius]

can you use this ?

Thanks, it's exactly what we need ... FTA channel detected as non-FTA.

 

[georgius]

I analysed stream and found that in PMT is CA descriptor but in whole stream isn't CAT and all packets are not marked as scrambled. Can anybody fix TS writer?

 

[mm1352000]

I analysed stream and found that in PMT is CA descriptor but in whole stream isn't CAT and all packets are not marked as scrambled. Can anybody fix TS writer?

Well, TsWriter already has an analyser that checks whether the scrambling bit is set in the TS packet header... but it is limited, because it only supports one video stream and one audio stream. Further, this analyser is not used until after all tuning and PMT parsing etc. is complete, so it is too late to tell a CAM that it needs to descramble the service. Further, the analyser does not handle elementary stream level scrambling. I imagine that to properly detect encrypted status would require a completely new interface or a very large rework of the PMT grabber. There is no quick solution here...

But even then, my understanding is that the issue here is caused by the interaction between the new TV service tuner allocation and TV library - we did not have such bad problems in MP 1.2.x... or am I wrong?

 

[georgius]

In MP 1.2.3 isn't this problem because there isn't card allocation cache and all channels' tunning details are always get from database.

 

[chrik]

Sorry georgius about the dealy :-(.
23 sec. TS dump and logs

 

[georgius]

I created patch for this issue. It allows you to turn off tuning channel cache which results to that channel can be watched or recorded. Patch is based on tag Release_1.3.0_Alpha.