[mythtv-users] Ceton Infinitv ETH 6 configuration
Stephen P. Villano
stephen.p.villano at gmail.com
Wed Sep 4 05:47:21 UTC 2013
On 9/3/13 11:01 PM, Ronald Frazier wrote:
>
> On Mon, Sep 2, 2013 at 12:22 PM, Ronald Frazier <ron at ronfrazier.net
> <mailto:ron at ronfrazier.net>> wrote:
>
>
>
>
> On Mon, Sep 2, 2013 at 9:42 AM, Greg Thompson
> <gthompson20 at gmail.com <mailto: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 <mailto: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
> <mailto: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 <http://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 <mailto:mythtv-users at mythtv.org>
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org <mailto: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
Not strictly true. Some of us consider on a daily basis dumping cable,
due to supporting elders. In our instance, we'd be abandoned and forced
to abandon excellent software and its use.
I suggest it be tested, but considered for future development.
Now, please excuse me whilst I deal with my aged father and his dementia
related insomnia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130904/83bcda82/attachment.html>
More information about the mythtv-users
mailing list