[mythtvnz] http://epg.org.nz/freeview.xml.gz

Stephen Worthington stephen_agent at jsw.gen.nz
Sun Mar 24 14:08:17 GMT 2013


On Sun, 24 Mar 2013 22:51:08 +1300, you wrote:

>On 24/03/13 22:27, Stephen Worthington wrote:
>> So if epg.org.nz is using mhegepgsnoop, it will be getting bad data.
>
>It seems to be a local issue for you.
>
>hads

I have run mhegepgsnoop.py (0.5.1) with the -v (verbose) option, and
it seems that my problem is caused by its fuzzy channel matching - it
is picking up the wrong channels from my MythTV database when it
matches them against my channels.  Having all the Sky versions of the
Freeview channels in my database is what is triggering the problem.  I
will have a look tomorrow to see if I can make a modification to the
channel lookups so that it will only match against DVB-T channels.

It is also crashing when I try to get it to tune using the -t option
on my no. 3 DVB-T tuner (AVerMedia DVB-T Volar).  On the other two
tuners (Pinnacle PCTV Nano stick), it is fine.  It looks as though
when it is checking the returned values after tuning, the AVerMedia
tuner is returning a value that is out of range for one parameter.
Here is what I get for tuning to channel 3 (TV3) using a Pinnacle
tuner:

root at mypvr:~/temp# mhegepgsnoop.py -zp -d /dev/dvb/adapter1/demux0 -v
-t 3
[snip]
Getting tuning info for channel 3
inversion: 0
transmission_mode: 8
guard_interval: 1/16
hierarchy: n
hp_code_rate: 3/4
bandwidth: 8
frequency: 562000000
lp_code_rate: 3/4
constellation: qam_64

Tuning /dev/dvb/adapter1/frontend0 to channel 3
Frontend name: DiBcom 7000PC
Frontend type: FE_OFDM

Parameters to be sent to /dev/dvb/adapter1/frontend0:
Frequency = 562000000
Inversion = 0 = INVERSION_OFF
Bandwidth = 0 = BANDWIDTH_8_MHZ
Transmission mode = 1 = TRANSMISSION_MODE_8K
HP code rate = 3 = FEC_3_4
LP code rate = 3 = FEC_3_4
Constellation = 3 = QAM_64
Guard interval = 1 = GUARD_INTERVAL_1_16
Hierarchy = 0 = HIERARCHY_NONE
Waiting for frontend to lock
Frontend has lock

Parameters read back from device. Might not be accurate?
Frequency = 562000000
Inversion = 2 = INVERSION_AUTO
Bandwidth = 0 = BANDWIDTH_8_MHZ
Transmission mode = 1 = TRANSMISSION_MODE_8K
HP code rate = 3 = FEC_3_4
LP code rate = 1 = FEC_1_2
Constellation = 3 = QAM_64
Guard interval = 1 = GUARD_INTERVAL_1_16
Hierarchy = 0 = HIERARCHY_NONE

Opening read from device /dev/dvb/adapter1/demux0 to collect data

And this is what happens when I use the AVerMedia tuner:

root at mypvr:~/temp# mhegepgsnoop.py -zp -d /dev/dvb/adapter2/demux0 -v
-t 3
[snip]
Getting tuning info for channel 3
inversion: 0
transmission_mode: 8
guard_interval: 1/16
hierarchy: n
hp_code_rate: 3/4
bandwidth: 8
frequency: 562000000
lp_code_rate: 3/4
constellation: qam_64

Tuning /dev/dvb/adapter2/frontend0 to channel 3
Frontend name: DiBcom 7000MA/MB/PA/PB/MC
Frontend type: FE_OFDM

Parameters to be sent to /dev/dvb/adapter2/frontend0:
Frequency = 562000000
Inversion = 0 = INVERSION_OFF
Bandwidth = 0 = BANDWIDTH_8_MHZ
Transmission mode = 1 = TRANSMISSION_MODE_8K
HP code rate = 3 = FEC_3_4
LP code rate = 3 = FEC_3_4
Constellation = 3 = QAM_64
Guard interval = 1 = GUARD_INTERVAL_1_16
Hierarchy = 0 = HIERARCHY_NONE
Waiting for frontend to lock
Frontend has lock

Parameters read back from device. Might not be accurate?
Frequency = 562000000
Inversion = 2 = INVERSION_AUTO
list index out of range
Unable to tune /dev/dvb/adapter2/frontend0 . Exiting

After adding a bit of debug code, I can see that the returned value
for the Bandwidth parameter (feparams.u.ofdm.bandwidth) is actually
8000, so it is well out of range.  Probably a driver bug.



More information about the mythtvnz mailing list