[mythtv-users] Ceton Infinitv ETH 6 configuration

Thu Sep 5 13:45:29 UTC 2013

I've made the suggested changes and deployed them to my system. Once they
have run for the day, I'll post the revised patch to Trac.

   --Matt

     --Matt

On Wed, Sep 4, 2013 at 8:02 PM, Greg Thompson <gthompson20 at gmail.com> wrote:

> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/20130905/ab1ac9eb/attachment.html>