Reply to thread

Message

<blockquote data-quote="mm1352000" data-source="post: 802201" data-attributes="member: 82144">Hi again DjangoPeople have said the same to me in the past. Recently somebody had such errors in a system that had been reliable for years. Turned out to be the new &quot;high quality&quot; flylead they had bought a couple of weeks ago. I still think you should at least check using the feed from the TBS tuners and/or remove the splitter entirely if possible. Removing the splitter would increase the signal strength seen by the tuner - this would tell you whether the signal strength is borderline. You must not assume that all tuners behave the same with the same signal - they don't. In other words, just because the TBS tuners aren't affected does *not* mean that it is not a signal problem for the KNC tuner.Excellent - I *think* that rules out the HDD. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />No. The KNC card could be slightly less sensitive than the TBS one if that is the case. I guess we will see.I look forward to the results.You have the discontinuity counters already in the manual control section of TV Server configuration. Making the changes to remove the writing to file etc. just for debugging seems like a lot of effort. When the CAM is decrypting, we don't get access to the signal before it is decrypted. Signal path is something like:Tuner ==&gt; demodulator ==&gt; CAM ==&gt; TsWriter ==&gt; file...not...Tuner ==&gt; demodulator ==&gt; TsWriter ==&gt; CAM ==&gt; file(Tuner and demodulator are hardware controlled by the tuner driver.)Communication with the CAM is mostly kept in the tuner driver. TV Server only says &quot;decrypt that channel&quot; to the tuner driver and it happens. So if I have understood what you're asking for correctly, it is not possible to isolate whether the CAM is at fault *except* if you're not viewing an encrypted channel and you remove the CAM, in which case you can be sure that the CAM is not involved.mm</blockquote>

[QUOTE="mm1352000, post: 802201, member: 82144"] Hi again Django People have said the same to me in the past. Recently somebody had such errors in a system that had been reliable for years. Turned out to be the new "high quality" flylead they had bought a couple of weeks ago. I still think you should at least check using the feed from the TBS tuners and/or remove the splitter entirely if possible. Removing the splitter would increase the signal strength seen by the tuner - this would tell you whether the signal strength is borderline. You must not assume that all tuners behave the same with the same signal - they don't. In other words, just because the TBS tuners aren't affected does *not* mean that it is not a signal problem for the KNC tuner. Excellent - I *think* that rules out the HDD. :) No. The KNC card could be slightly less sensitive than the TBS one if that is the case. I guess we will see. I look forward to the results. You have the discontinuity counters already in the manual control section of TV Server configuration. Making the changes to remove the writing to file etc. just for debugging seems like a lot of effort. When the CAM is decrypting, we don't get access to the signal before it is decrypted. Signal path is something like: Tuner ==> demodulator ==> CAM ==> TsWriter ==> file ...not... Tuner ==> demodulator ==> TsWriter ==> CAM ==> file (Tuner and demodulator are hardware controlled by the tuner driver.) Communication with the CAM is mostly kept in the tuner driver. TV Server only says "decrypt that channel" to the tuner driver and it happens. So if I have understood what you're asking for correctly, it is not possible to isolate whether the CAM is at fault *except* if you're not viewing an encrypted channel and you remove the CAM, in which case you can be sure that the CAM is not involved. mm [/QUOTE]

Verification