[mythtv-users] Ceton Infinitv ETH 6 configuration

Wed Sep 4 03:01:41 UTC 2013

On Mon, Sep 2, 2013 at 12:22 PM, Ronald Frazier <ron at ronfrazier.net> wrote:

>
>
>
> On Mon, Sep 2, 2013 at 9:42 AM, Greg Thompson <gthompson20 at gmail.com>wrote:
>
>> Mind sharing your patch? I started looking at the Ceton source and I was
>> just going to remove the code on the define functions.
>>
>> Greg
>> —
>> Sent from Mailbox <https://www.dropbox.com/mailbox> for iPhone
>>
>>
>> On Mon, Sep 2, 2013 at 9:36 AM, Matt Mossholder <matt at mossholder.com>wrote:
>>
>>> This is exactly the situation I'm seeing. Looks like I might want to
>>> submit my patch. I had been holding off, thinking I needed to make detuning
>>> optional, but it if it is going to start hitting all the tuners, then it
>>> making it an option probably isn't needed.
>>> On Aug 30, 2013 2:38 PM, <gthompson20 at gmail.com> wrote:
>>>
>>>>  Hey Ron,
>>>>
>>>> I wanted to give your some info on this issue... as I am having it as
>>>> well with an Network Connected USB Tuner.... I can also send manua requests
>>>> to stream to the VLC from the Web Page, However when I try and use Myth I
>>>> get a Partial Lock... Tracing the logs like you asked give the following
>>>> results...
>>>>
>>>> The web page still appears to give the correct JSON when watching with
>>>> Firebig, However the issues appears to maybe be this command when
>>>> Mythbackend Starts:
>>>>
>>>> CetonSH (IP of Ceton) ClearProgramNumber()
>>>> Which shows the following in the Ceton LOGfile....
>>>>
>>>>  libcetonrtsp: object cetonmpeg0
>>>> Jan  1 00:04:25 ocur[21]: ocur: [0] rtp setup for client
>>>> 192.168.1.189:44778
>>>> Jan  1 00:04:26 ocur[21]: libcetontune: ERROR: Failed to set frequency
>>>> on instance 0
>>>> Jan  1 00:04:26 ocur[21]: ocur: WARNING: [0] Frequency set did not
>>>> take. Freq: 747000 Std 9
>>>> Jan  1 00:04:26 ocur[21]: ocur: WARNING: [0] Channel change failed
>>>> Jan  1 00:04:26 ocur[21]: ocur: [0] Getting pmt for program 3
>>>> Jan  1 00:04:30 ocur[21]: ocur: [0] Attempting to SetChannel
>>>> (Channel=0  SourceId=0  Mode=0)
>>>> Jan  1 00:04:30 ocur[21]: ocur: WARNING: [0] Set channel in progress,
>>>> saving channel number request 0
>>>> Jan  1 00:04:31 ocur[21]: mpeg: WARNING: [ID-0] Failed to get pat
>>>> Jan  1 00:04:31 ocur[21]: ocur: ERROR: [0] No pat returned
>>>> Jan  1 00:04:31 ocur[21]: ocur: [0] PCR Lock: 0
>>>> Jan  1 00:04:31 ocur[21]: ocur: [0] Packets: 0 (0 - 0) Data Ready 0
>>>> Jan  1 00:04:31 ocur[21]: mpeg: [ID-0] ready 00000100 pkts 00000101
>>>> filter 00000001 sections 00000101 no_filters 00000001 zero_pid 00000035
>>>> Jan  1 00:04:31 ocur[21]: libctn91xx: 0.6 read 00000101 comp 00000101
>>>> Jan  1 00:04:31 ocur[21]: mpeg: [ID-0] ready 00000100 pkts 00000101
>>>> filter 00000001 sections 00000101 no_filters 00000001 zero_pid 00000035
>>>> Jan  1 00:04:31 ocur[21]: libctn91xx: 0.6 read 00000101 comp 00000101
>>>> One the Tuner gets hit with that command I no longer see any program
>>>> ID’s in the Tuner Page. Only way to return the tuner to normal operation is
>>>> to power cycle the tuner.
>>>>
>>>> I am using the latest Firmware, so I am guessing they have changed
>>>> something on you...
>>>>
>>>> Can you look into this?
>>>>
>>>> Greg Thomson
>>>>
>>>> Sent from Windows Mail
>>>>
>>>>
>>>> _______________________________________________
>>>> mythtv-users mailing list
>>>> mythtv-users at mythtv.org
>>>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>>>
>>>>
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>
>>
> Just so you guys know, I've sent an email off to austin at ceton for
> advice on a better way to deal with this, or to see if he can fix it. I'll
> keep you updated on what I hear.
>
>
> --
> Ron Frazier
>

As I suspected, I got a better response from Austin directly (and within a
few hours, even though it was a holiday). First, he confirms that he's
experienced the same issue working with the ETH, so we can say that it's
not just a case of you guys having defective hardware. Second, it sounds
like simply setting the tuner to frequency zero would have minimal effect.
As he said:

"there's not much power consumption from tracking the program numbers,
the processor would be running regardless. The real win would come
from being able to shut off the tuner chips completely, but that's
more complicated."

So I see no reason why we need to set the frequency to zero, and if both of
you are seeing good results with that one change, that's a good sign. The
only side effects of that change I can see is that the lock flags will
still be set to 1, and the program list will still be populated, but the
program number itself will be set to zero by the call to TuneVChannel(0). I
cannot foresee any negative effects of these differences.

My only concern would be for QAM mode. Your patch only changes what happens
in cablecard mode. For QAM mode, the call to TuneFrequency(0) still takes
place with your patch. I wonder if the ETH would freak out the same way in
QAM mode. If so, then there is a potential problem. Without setting the
frequency to zero, we would never be clearing out the program list. The
subsequent call to TuneProgram verifies that the requested program number
is in that list, and by virtue of the way it functions, that verification
will not complete until after the call to TuneFrequency has completed and
fully loaded the program list. If we remove the TuneFrequency(0), then a
later call to TuneProgram could potentially proceed before the previous
call to TuneFrequency has update the program list, and we could get
unreliable behavior.

Thus fixing QAM mode (if it is broken) could be a bit more problematic.
That said, I'm only aware of a few people using QAM on a PCI 4-tuner card.
The number using it on a 6-tuner ETH would probably be tiny (especially
since QAM tuning is becoming less useful each year as cable providers lock
things down more, and now I believe they've even got permission to do it
for local stations). So my thinking is, your patch might not fix QAM for
the ETH model, but it also wouldn't break it for the PCI model.

So, I'd say we should go ahead with the change. My only comment on your
modification is the following:

if (!_using_cablecard ) {
    result = TuneFrequency(0, "qam_256");
    if (result && _using_cablecard)
    result = TuneVChannel("0");
}
....

if you think about it, that inner "if" statement can NEVER be true, because
the outer "if" guarantees that _using_cablecard is false. That, and the
fact that setting the vchannel to 0 makes no sense if there's no cablecard
installed. So really, you can just simplify it to an "if, then clear
frequency, else clear vchannel".

Make that change, and (once I verify on my system that it's fine for the
PCI, just to be sure I'm not overlooking something obvious) I'll recommend
to daniel to commit it.

-- 
Ron Frazier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130903/55ce74a0/attachment.html>