Chuck,
I'm at exactly the same point you're at. I've managed to manually pull
together a good number of the QAM PID's for Comcast channels in Boston
(I live just north of the city) and can manually capture the streams.
It looks like myth relies on a transport ID instead of the individual
PID's and I've also managed to collect that using dvbscan - at least I
think I have. Since the PSIP data isn't included dvbscan's output is
pretty generic, and there's no documentation other than the source
code... All attempts I've made to manually insert this information into
the channel & dtv_multiplex tables has failed. myth just keeps
informing me that the channels are off the air.
If you want a copy of the channels.conf I've managed to hack together
let me know. It's pretty ugly (don't have all the channel/station names
set up properly) but it works.
-Bruce
Chuck Lloyd wrote:
Bruce,
I've had a similar problem. I think the cause is that your cable provider
is not providing the standard PSIP data. I have a similar problem
with Comcast here in Boston.
I have been able to find a few stations, but I have not tried putting them
into the Myth database yet.
I noted which channels myth seemed to find a frequency lock on
and then did a little probing.
For example:
Myth found something on channel 84 so I tuned to that channel.
azap -r C84
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 585000000 Hz
video pid 0x0000, audio pid 0x0000
status 1f | signal 0977 | snr fde5 | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 0977 | snr fdfd | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 0394 | snr fdfd | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 0394 | snr fdb3 | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 0977 | snr fdb5 | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
......
Then I ran dvbtraffic to look at the pids:
dvbtraffic
-PID--FREQ-----BANDWIDTH-BANDWIDTH-
0000 3 p/s 0 kb/s 5 kbit
0030 19 p/s 3 kb/s 29 kbit
0031 19 p/s 3 kb/s 29 kbit
0800 9362 p/s 1718 kb/s 14081 kbit
0801 261 p/s 47 kb/s 393 kbit
0802 88 p/s 16 kb/s 133 kbit
0840 11093 p/s 2036 kb/s 16685 kbit
0841 260 p/s 47 kb/s 391 kbit
1fff 4718 p/s 866 kb/s 7096 kbit
2000 25830 p/s 4742 kb/s 38848 kbit
>From above it looks like there is a hi-bitrate signal at PID 800
(2048)and a low
one at 801 & 802. ( 2049 & 2050 )
I leave dvbtraffic running and then I run mplayer:
mplayer -vid 2048 -aid 2050 -vc ffmpeg12mc -vo xvmc /dev/dvb/adapter0/dvr0
Viola, WGBH in HD.
Just need to figure how it all works into the database. (and maybe
automate it.)
On 5/28/05, *Bruce Pennypacker* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi all,
I've been unable to tune QAM channels on my HD-3000 with mythtv despite
being able to extract it using the azap, dtvscan, etc. tools. In
searching around I've come across many similar reports of problems with
this combination. I've tried both the 0.18.1 release and the CVS tree
from yesterday with the same results - doing a channel scan simply
results in all of the channels resulting in "Timeout Scanning Channel"
when it's able to lock onto a channel.
I was wondering if anybody knows about this problem and/or may be
working on it. It's been years since I've done any serious c/c++
development/debugging and I know next to nothing about DTV, QAM, etc.
but I was thinking of firing up gdb to see if I could figure out why
this may be happening. Of course I don't want to expend the effort if
somebody else is already looking into it, hence my query here before I
take the plunge.
-Bruce
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
