Random failures to tune scrambled DVB-S channel (1 Viewer)

[blaudden]

Unfortunately it does not (yet) help to set the timeout values high. As long you are getting the "Twinhan: set pmt failed 0x8..." in your log. It won't work.

We need to find a way that makes that error never appear or retry in the case it happens(like in my suggested patches).

I seem to have a long "jump" in the logs when this error occurs. Wonder if it's the Twinhan driver, the card or something in TVServer that is hoggin the CPU during that time?

Maybe you can post your logs as well so we can have a look?

 

[tourettes]

There is however still a problem when starting to watch a channel without one previously running. Think the best way for now is to return false from Twinhan:endPMT see previous post.

At the same time I would like to add three additional patches. See attached.
1. SignalQuality - a simple copy & paster error. Not critical.
2. THSendPMT_remove_unused_args - Remove unused parameters in Twinhan::sendPMT and the code used to calculate them.
3. ImproveTimeoutLog - write a log message when the wait for PMT has timedout and suggest user to increase the PMT timeout value

I quickly looked thru the patches / changes and those all looked valid ones. I'll ask gemx/gibman to check those (as myself havent been working that much on the C# side of the TVE3).

 

[Ambass]

ced,

Your problem with CANAL+ HIGH-TECH is a CAM related problem. The Aston CAM can decrypt only 2 audio chanels.
I've similar problem with some HD channels.
I should update tuning parameters...and verify. I watch only the C+ HD..
What is your CAM ?

Ambass.

 

[ced007]

Hi Ambass,
Yes my CAM is an Astoncript 2.18.
I'm not sure to understand your suggestion.
What do you mean by "tunning parameters"? What do I need to update exactly?
Thanks

Hi blauden,
I have tried increasing the 2 parameters but it doesn't change anything. Most of all I don't see any logic when increasing this values. I don't have the same thing all the time with the same values... it looks like a random problem.

 

[Ambass]

Ced,

I've also AstonCrypt 2.18 and I've updated my tuning parameters ( I'd old ones on C+HIGH TECH ).
Now I've the right configuration and it's not working ( seen as scrambled ).
The main problem of this channel is the fact that it contains 4 scrambled audio streams and the CAM ( I've discussed with Aston Sw people ) is only able to decrypt the first and the second.

I think the second problem is TvServer that checks the latest audio channel to say scrambled or unscrambled....
I'll try to check a bit deeper on next days.

I'll let you know...

Ambass.

 

[blaudden]

Hi again,

Very encouraging to see my previous patches was accepted so fast.

have continues to test and find a way to avoid the "Twinhan CAM failed 0x8007001F" problem, but since the exist also in the DTV program from Twinhan I think we just have to live with it and do the best possible to handle the error when it occurs.

Would like to suggest the following changes(see attached patch):
1. Keep the graph running if Twinhan with CAM present, by modifying ConditionalAcess::allowedToStopGrah to return false in this case. This way the problem almost never occurs - except for when starting the graph the first time.
2. More agressive retry of send the PMT to CAM insied Twinhan::sendPMT. Altough my previous patch that returned false from that function improved the situation by retrying when the next PMT was received, it was still kind of slow. Thus I'd like to retry the send PMT up to 10 times with a 100 milliseconds sleep in between. This normally takes care of the problem.


BTW: Tried many other different things to find the cause, but no luck. Commenting out the setLNB, sendDiseqC, rewriting part of the code that calls IKsProperty::set etc, just to maybe maybe find another conclusion.

I also suspect that the Channel::_freeToAir property is not properly set, since it will try to send PMT also for non encrypted channels. That would be another task..

/ Magnus