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

[David Moore]

On 26/03/13 03:56, Stephen Worthington wrote:
> On Mon, 25 Mar 2013 20:50:20 +1300, you wrote:
>
>> On 25/03/13 15:48, Stephen Worthington wrote:
>>> On Mon, 25 Mar 2013 15:24:36 +1300, you wrote:
>>>
>>>> On 25/03/13 03:08, Stephen Worthington wrote:
>>>>> 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.
>>>> I have just discovered a related problem with the fuzzy channel matching
>>>> on my system. I'm getting Canterbury Television matched against
>>>> fv-maoritelevision. And I'm in Auckland. :) Not sure if there is a bug
>>>> in how I use the fuzzy matching lib or I'm just unlucky with channel
>>>> names. I'm thinking about adding another option to exclude specific
>>>> channels discovered in the MHEG data. Or try and improve fuzzy matching.
>>>> Or both. Don't hold your breath waiting for a fix from me...
>>> It seems that the correct spelling of Maori with a macron over the o
>>> character in the MHEG5 data is confusing things.  I am working on a
>>> possible fix for that at the moment.  I think I already have a fix
>>> that makes the fuzzy matching only work on the DVB-T channels, which
>>> is to change the select query used to get the MythTV channel data to:
>>>
>>> select callsign, name, xmltvid from channel c, dtv_multiplex d where
>>> c.mplexid is not NULL and c.mplexid = d.mplexid and d.mod_sys !=
>>> 'DVB-S'
>>>
>>> (This is in two places in the mhegepgsnoop.py file).  This fix needs
>>> testing on databases other than mine that have satellite Freeview
>>> channels and/or Sky channels, to make sure the database fields all
>>> work the way I thing they do.
>>>
>>>
>>> I also have a crude fix for the drivers returning invalid values, by
>>> catching the IndexError exception:
>>>
>>> 	verbose('\nParameters read back from device. Might not be
>>> accurate?\n') # Why are some of these values wrong? Driver/firmware
>>> bugs?
>>> 	verbose('Frequency = ' + str(feparams.frequency) + '\n')
>>> 	try:
>>> 		verbose('Inversion = ' + str(feparams.inversion) + ' =
>>> ' + fe_spectral_inversion[feparams.inversion] + '\n')
>>> 	except IndexError:
>>> 		verbose('Inversion = ' + str(feparams.inversion) + ' =
>>> ***IndexError***\n')
>>> 	try:
>>> 		verbose('Bandwidth = ' +
>>> str(feparams.u.ofdm.bandwidth) + ' = ' +
>>> fe_bandwidth[feparams.u.ofdm.bandwidth] + '\n')
>>> 	except IndexError:
>>> 		verbose('Bandwidth = ' +
>>> str(feparams.u.ofdm.bandwidth) + ' = ***IndexError***\n')
>>> 	try:
>>> 		verbose('Transmission mode = ' +
>>> str(feparams.u.ofdm.transmission_mode) + ' = ' +
>>> fe_transmit_mode[feparams.u.ofdm.transmission_mode] + '\n')
>>> 	except IndexError:
>>> 		verbose('Transmission mode = ' +
>>> str(feparams.u.ofdm.transmission_mode) + ' = ***IndexError***\n')
>>> 	try:
>>> 		verbose('HP code rate = ' +
>>> str(feparams.u.ofdm.code_rate_HP) + ' = ' +
>>> fe_code_rate[feparams.u.ofdm.code_rate_HP] + '\n')
>>> 	except IndexError:
>>> 		verbose('HP code rate = ' +
>>> str(feparams.u.ofdm.code_rate_HP) + ' = ***IndexError***\n')
>>> 	try:
>>> 		verbose('LP code rate = ' +
>>> str(feparams.u.ofdm.code_rate_LP) + ' = ' +
>>> fe_code_rate[feparams.u.ofdm.code_rate_LP] + '\n')
>>> 	except IndexError:
>>> 		verbose('LP code rate = ' +
>>> str(feparams.u.ofdm.code_rate_LP) + ' = ***IndexError***\n')
>>> 	try:
>>> 		verbose('Constellation = ' +
>>> str(feparams.u.ofdm.constellation) + ' = ' +
>>> fe_modulation[feparams.u.ofdm.constellation] + '\n')
>>> 	except IndexError:
>>> 		verbose('Constellation = ' +
>>> str(feparams.u.ofdm.constellation) + ' = ***IndexError***\n')
>>> 	try:
>>> 		verbose('Guard interval = ' +
>>> str(feparams.u.ofdm.guard_interval) + ' = ' +
>>> fe_guard_interval[feparams.u.ofdm.guard_interval] + '\n')
>>> 	except IndexError:
>>> 		verbose('Guard interval = ' +
>>> str(feparams.u.ofdm.guard_interval) + ' = ***IndexError***\n')
>>> 	try:
>>> 		verbose('Hierarchy = ' +
>>> str(feparams.u.ofdm.hierarchy_information) + ' = ' +
>>> fe_hierarchy[feparams.u.ofdm.hierarchy_information] + '\n')
>>> 	except IndexError:
>>> 		verbose('Hierarchy = ' +
>>> str(feparams.u.ofdm.hierarchy_information) + ' = ***IndexError***\n')
>>>
>>>
>> Well I decided to have a crack at it and found a bug in the fuzzy
>> channel matching. Should be fixed now. I made a mistake with sorting the
>> matching results. Seems to work properly now and has no problem
>> correctly matching the funny character in "Maori..".
>>
>> Also added a trap for the index error in the tuning function. Haven't
>> tested this on real data.
>>
>> Version 0.5.2 download is ready at
>> http://sourceforge.net/projects/mhegepgsnooppy/
> The trap for the index error is working, but the fuzzy matching is
> not.  I am now getting multiple channel id entries in the output file
> for the same channel:
>
> ....
Yes, I see what your problem is. I only have DVB-T so I missed the point 
that you have many non-DVB-T channels in your mythtv setup. The fuzzy 
matching does do correct matches now. This was the bug I fixed 
yesterday. The problem is that it doesn't (yet) filter out non-DVB-T 
channels. Maybe your modified select query is the way to go or maybe 
filter on source id? I'm not sure and I can't test or inspect the 
database because I don't have anything except DVB-T. I suppose the quick 
fix is to add your query as a command line option so it can be turned 
off if it doesn't work for someone else.