[mythtv-users] Ceton Infinitv ETH 6 configuration

Wed Sep 4 11:37:18 UTC 2013

Just to be 100% clear... I am using the USB tuner in Ethernet Bridged mode.
While not the ETH tuner it is using the SAME firmware that the Ethernet
Tuner uses, so I believe this issue is more related to the Firmware than
the actual device itself (Ethernet or USB or PCI). I have not had time to
compile Myth with Matt's Patch just yet but I will and report back soon. My
gut tells me it will work fine after the patch since it was that call that
seemed to hose the tuner!

On Tue, Sep 3, 2013 at 11:01 PM, Ronald Frazier <ron at ronfrazier.net> wrote:

>
> 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
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130904/12f0830b/attachment.html>