[mythtv-users] Ceton Infinitv ETH 6 configuration

Greg Thompson gthompson20 at gmail.com
Thu Sep 5 19:34:16 UTC 2013 

Hey Matt,

Just wondering if you have seen this issue with the Tuner and your new
patch... I have 1 tuner setup in mythtv and when I set up Back to Back
recordings for it on the same channel, the first program records ok, but
the second program fails. When I check the Ceton Web Page the tuner no
longer shows as playing and the streaming to Mythbackend has stopped... Now
this could be caused by me or something, haven't checked in detail yet, but
I did notice it last night and that made me wonder if something weird is
happening to the tuner with the timing of the recordings being back to
back... Can you test it out?

Greg


On Thu, Sep 5, 2013 at 9:45 AM, Matt Mossholder <matt at mossholder.com> wrote:

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

More information about the mythtv-users mailing list