[mythtv] DVB/ATSC channels.conf import troubles

[Christiaan Lutzer]

Johnny, what are the last two numbers in your channels.conf file,
"209" and "212"?  If you applied the patch that I've submitted, the
format is:

channel name : frequency (Hz) : QAM modulation mode : MPEG-2 TS Program Number

I have Comcast as well (Comcast Digital Cambridge, MA) and I've never
seen an MPEG Program Number exceed 20 or so.  It's almost like you are
specifying the video/audio PID instead.

The parsing code would ignore the "212" in the ATSC case, and use 209
as the program number.  I would suspect that mythbackend would not be
able to find any program with that PN, and give you black video.

Just some thoughts.

C.

On 7/16/05, Johnny Graettinger <johnny531 at gmail.com> wrote:
> I'm running a recent svn copy patched with the changes Christiaan
> discusses for importing channels.conf in cases of DVB/ATSC cards. To
> that end, I've constructed a channels.conf via azap  & dvbtraffic
> containing pid's for each in-the-clear channel, eg:
> 
> CBS:625781200:QAM_256:209:212
> 
> On a perhaps related tangent, you'll notice that the frequencies used
> are non-standard. Comcast in baltimore uses HRC (harmonic resonance
> something?) rather than standard cable transmissions, so QAM scanning
> in mythtv has not worked for me, prompting a more manual approach.
> Indeed, I only got this working by using the recently added
> /util/scan/atsc/us-Cable-HRC-center-frequencies-QAM256 file within the
> dvb-apps distribution as a baseline.
> 
> azap -r CBS; dvbtraffic; cat /dev/dvb/adapter0/dvr0 > foo.mpg
> 
> works great, and resulting streams when viewed seem without error.
> 
> Sorry for all the background, now on to myth specifically:
> 
> Following Christiaan's lead, I rearranged channels.conf to follow the
> modulation with just a program number in the transport stream, and
> imported it into mythtv-setup. The import succeeds, but an effect I've
> noticed is that, in a video source containing only the imported
> transports, a full scan of existing transports immediately returns
> with error, and an existing transport scan simply sits indefinetly
> with the progress bar at 3%
> 
> However, not to be deterred, I gave mythbackend a try. Lo and behold,
> it gets a lock on the default channel for my HD-3000 tuner. But
> watching tv simply sits in a black screen for a while.
> 
> As a test, while it was sitting in such state I cat'd dvr0 to an mpg.
> The resultant mpg did increase in size, indicating the tuner was tuned
> to particular video and audio pid's, however was not playable (mpeg
> header not found).
> 
> One last strange issue. Another experiment I've performed is to start
> mythbackend so that it gets an initial signal lock on the default
> channel for the tuner. I then run dvbtraffic to confirm the tune.
> What I've found is that, per update, dvb traffic does occasionally
> print the pid's and bitrates I'd expect for the stream, but most of
> the time it prints out a large number of 1-4 kbit pid's, which I
> understand to be indicitave of a dirty or poorly locked signal.
> Further, if I leave the same instance of dvbtraffic running, and then
> kill the mythbackend instance, dvbtraffic immediately sorts itself out
> and prints the correct pid's/bitrates (no re-locking via azap
> necessary).
> 
> Is it because the lock in mythtv is poor that it's having trouble
> picking correct pid's for the stream? Or are these two completely
> seperate issues? And of course, any idea what could be causing the
> strange locking/dvbtraffic behavior? Or alternatively, how I might
> mangle the code in order to fix QAM scanning so myth finds these
> channels for itself?
> 
> Any help *much* appreciated
> 
> Johnny
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>