I think the first point is that one shouldn't shoot too high here. I
see this as a "get you started" system. ie eliminate much of the hard
work in setup. I don't think it's worth coding a super AI system to try
and get it perfect.
xmtvids. Do we need multiple id's dependent on which grabber you are
using. E.g tv_grab_uk_rt and tv_grab_uk_bleb both use different ids.
Yes, I guess one could simulate this by having two "countries" and then
putting the data in twice.
To be honest I think the issue is really with bleb using non standard
codes... I'm not really a fan of the bleb data to be honest.
Channel matching/finding. I think that we should key it of the
"channel ident", which could return several results, then using the
grabber, network id and service id try to narrow down the result. So a
search for "BBC One" could initially return 10 or more matches, an
additional pass with the grabber might narrow this down to 5, and the
network,service id would hopefully just get you one. If it fails at
any point we just take the first one out of the list.
Sure, but lets code this in the local app. I guess it might be
sufficient if it tries an exact match against all non-blank entries in
the table with highest up entry being the default. (Then gradually
strip fields from the right of the table and keep trying the match or
just give up..?)
So imagine this as the raw data source
ChannelName, ServiceId, Region
BBC One,
BBC One, 6234, scotland
BBC One, 3345, London
BBC One, 3344, Wales
etc, etc
Perhaps region is needed, perhaps it isn't, but you see the idea. the
data fields would also be in this same table, and it might also have a
country field to split the table by country (or use multiple data
tables... implementation detail)
Processing. Do we keep the processing on the client or on the wiki/web
server ?
Definitely local.
Lets just have a file available somewhere on the web that you download
and parse. An old copy can be distributed with myth and there is an
option to pull down the latest version
If it breaks then tough. This is just supposed to help prime the
fields, not guarantee perfection (IMHO)
The key issue is having a really easy to edit table on the server so
updates can be added simply. The wiki would have been good because you
could just to a request, filter out the junk to get to the table, then
in wiki speak you do a table with a bunch of "||" characters breaking up
the text, so it's dead easy to parse.
If we make it a text file on the server then we need to send in patches
to update it and I can see this not happening...
What do you think in order to get this off the ground soon ish..?
Ed W
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
