[mythtv-users] Ceton Infinitv ETH 6 configuration

Thu Sep 5 00:02:31 UTC 2013

I have compiled Myth with Matt's patch tonight, and can confirm that I can
now receive the signal from the Tuner! Everything is working great
.26/Fixes... Will this make it in to .27 soon?

On Wed, Sep 4, 2013 at 7:37 AM, Greg Thompson <gthompson20 at gmail.com> wrote:

> 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/c348302d/attachment.html>