Ed Avis (ed@xxxxxxxxxxx):
> >http://129.173.67.12/~bbiggs/coolosd.png
> Ouch! That's quite a hefty download. Ever heard of JPEG? ;-(
Sorry. That is an old debug snapshot that was handy. png is
lossless, useful when debugging the alpha compositing.
> > Of course, I'm just trying to offer suggestions to steer development
> > of the new DTD.
>
> Do you still want the two patches you sent earlier?
Of course I am not yet decided in my opinions. The first patch
advised that if call letters are available, to only specify them as a
callsign instead of both a display name and a callsign. You suggested
that if the callsign was used as a name, it should be listed as one.
I think now there are potentially more cases:
1. Cable channels which use callsigns that are just acronyms for
their channel: TLC/The Learning Channel, HGTV/Home and Garden
Television.
2. Cable channels which use their callsign as their primary name:
CNN, A&E, TNN
3. Channels which have a network callsign and a local callsign:
WGBH is the Boston(?) feed of CBS. Do we put CBS or WGBH?
4. Channels which have a network callsign distinct from the callsign
they use: Many CTV feeds in Ontario call themselves "The New VR"
when their callsign is CHVR.
And I think that your general statement that display-name should be
used whenever it is a name someone would refer to the channel as is
probably a good way to distinguish these, and just put multiple names
where appropriate. That said, given how there are all these different
cases, maybe it's best to ditch the <callsign> tag altogether.
The other patch was to make sure that providers don't use names like
S8 or M12 in the <number> section. This is because I believe the
<number> should only be used in North American or Japanese systems where
it makes sense to automatically map like this. Frequency names such as
S8 or SE8 or M8 are ambiguous and provider-dependent and I would rather
see that solved separately if necessary.
> > My goal is to have less ambiguity for the two things I need: a way
> > to map channels found by my TV app to channels in the XMLTV file,
>
> Out of interest what channel identification does your app have?
Our system is described here: http://tvtime.net/xmltv.html but I will
summarize.
The user can give a name to each channel, and optionally an xmltv ID.
If they don't give an xmltv ID, we search for a channel with a
display-name that matches the channel name. By default, the name is the
channel number for North American systems, and the position of the
channel in the station list for European users.
We don't currently get the name from teletext, but we could. There is
no teletext in North America so it's not something I can code.
Using the channel number works for matching with tv_grab_na since it
gives channel entries like this and we match the second entry:
<channel id="C18cnn.zap2it.com">
<display-name>18 CNN</display-name>
<display-name>18</display-name>
</channel>
> > and also to be able to know what information is appropriate to be
> > displayed on my OSD.
>
> I think that in countries where the listings data includes number or
> call-sign that information will be recognized by users. So if it's
> there you should probably display it. No need to display all the
> different display-names though, just the first (or the first in a
> language the user understands).
Sure but we already have a problem with tv_grab_na that we are working
around. The first <display-name> with this grabber looks like this:
"36 TLC"
This is not the name, nor is it how you refer to the channel. It
should say just "TLC" if anything. Having two separate and distinct
names together like that makes my OSD redundant, since I would display
something like this:
36(big) 36 TLC 09:34:15
And users complained that our OSD was messy and redundant.
> > Having a <number> entry, even if it's redundant, would at least let
> > me more reliably map channels for all North American users, at
> > least.
>
> A <number> entry cannot be redundant because it doesn't convey the
> same information as anything else in the file format. You could have
> a channel whose display-name was '5' but the channel number was
> different. This does happen in some countries. It's really just
> coincidence if the number used for tuning happens to match a name that
> people use for the channel, and in this case you can put the same
> string as both.
It will always be redundant for North American systems, since one of
the display-name entries must be the number of the channel. I admit
that there will be cases like my channel 36 which is a Fox feed from
Boston and locally in boston is transmitted on channel 9, so sometimes
they call themselves "Channel 9".
> As I've mentioned in earlier messages to this list, I'm not that
> interested in developing elaborate systems for specifying tuning
> information. Channel number is intended to be the simplest thing
> needed for setting a television or doing channel mapping in a PVR
> app. That said, if it's inadequate I could add something more (not
> sure what). Hopefully the 'system' attribute of <number> should be a
> good catch-all and people can work out some informal conventions.
Sounds reasonable. In my opinion you should avoid adding tags unless
they are actually useful. <number> I believe to be only useful in North
America (and Japan), and would solve some ambiguity here, and so I like
it. I would also like it restricted to that.
-Billy
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
|
