[mythtv] Re: DVB/ATSC channels.conf import troubles
johnny531 at gmail.com
Sat Jul 16 13:48:32 EDT 2005
Thank you both for your quick responses.
Christiaan - Right, I should have been more clear. The actual
channels.conf I'm importing is a modified version of the one
constructed through playing with azap (which does include audio/video
pid's). The imported version is:
Where for each station I have verified that the trailing number is the
correct program number (which, I assume, enumerates video/audio pid
pairs counting from 0).
Yep, poking around in the database reveals my dtv_multiplex is quite
similar. I don't pretend to understand all of it, in particular the
meanings of these defaults, but I've included it for inspection:
On 7/16/05, Christiaan Lutzer <mythtv.lutzer at gmail.com> wrote:
> 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
> 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.
> 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
More information about the mythtv-dev