[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TV] Hi



> I dunno, I'd have thought it would be better if you could download the
> data as XMLTV-compliant straight from bleb.org, rather than having to
> download and then process before using it in your XMLTV-using
> applications.

Absolutely true.  However, in my case, the application wraps xmltv, this
itself knows that it should call xmlgrab_uk.  To avoid hacking the code, we
would write a wrapper called xmlgrab_uk2 which calls wget
http://www.bleb.org/blah.cgi??etc.etc and returns the results

The point is to preserve the old interface, however, if all the work
actually gets done at your end, then this is brilliant.

Actually I have just grabbed a copy of xmltv to look at, and I *do* think
there is a point to having a xmltv_uk_bleb script in here.  XMLTv has some
parameters you can use to retrieve only certain days, or get film info from
IMDB, etc.  Anyway, ignoring all that, I guess that whilst it is pretty easy
to transform XML from A to B, why introduce another DTD, just use that
one...?  Minor detail anyway

>
> > I think the main thing which I am missing from myth that the US users
get is
> > colour coding of films, serials, etc.  I think this is supported on the
> > xmltv syntax? and your website also seems to do some of this kind of
rather
> > cool stuff.  Could we get it in the XML file though???  (Pretty
please...)
>
> Some of the channels provide a '<genre>' tag - ideally all films will
> have '<genre>Film</genre>', other types aren't so guaranteed. How an
> individual application renders that genre is up to them - on my site I'm
> hoping to make it customisable on a per-user basis.

Well, the site seems to be down at the moment (this seems to be happening a
lot? Is it going to be an ongoing issue?),  but I'm sure that you pick out
films on most channels in the web version, but I didn't notice any such tags
in the XML?  Perhaps I just didn't look correctly.

But still, there is lots of extra info in the links you helpfully attach to
each program, if you happen to be already downloading that, then perhaps you
could stick it in the XML as well (if there aren't copyright issues?), ie
actors, etc - Just a thought

> > Bearing in mind that there could be a script retrieving the file, you
could
> > also consider having a switch which compresses the data before
transmitting,
> > it can then be expanded quite easily by the script.  I suggest zlib so
that
> > we have windows compatibility, but bzip will be very much more efficient
for
> > XML I think...
>
> Good idea. It might be worth only providing
> data/listings/0.{tar.bz2,zip}, 1.{tar.bz2,zip}, ... rather than the
> directories (if the directories are still available noone will download
> the tarballs or zips!).

I would suggest that you only provide compressed files for download.  BZip
is a bit of a pain for windows users, but might get a bit more compression
(depending on how large the files are).  Basically if the whole lot is less
than a few tens of Kb then I think zlib will be just as effective.  If the
files are really quite small then you will probably find it more efficient
to provide quite large batches rather than people downloading individual
files!  The compression ratio should really rise when you put several files
together, compared with the overhead required to negotiate the download,
etc...

I think that your hypothetical cgi script should also offer compression
though.  Also, you will get a big speedup for your normal web pages if you
enable mod_gzip I think

> > Thanks for creating this.  It looks really good!
>
> My pleasure - believe it or not, positive feedback is all I want (oh,
> and a decent TV website for myself to save having to buy the Radio Times
> or whatever... ;-))

OK, well re-reading what I wrote it sounds like a moan.  It was intended to
be a tough set of suggestions as to how you could change it.  Please feel
free to disregard them completely!  The site is great as it is.  Sorry if it
comes over that way

I like your goals.  I suggest that you have two main audiences.  a) people
who want to use their own Java viewer thing, freevo, myth, etc.  b) People
who are too mean to pay digiguide £5.  Now personally I would be happy to
pay digiguide (and in fact I do), but I want the data for my MythTv box and
this doesn't seem possible with digiguide (boo).

Now if I am an a) person then I think I just want all the data and I want it
in an easy download.  Perhaps make me register to get it so you can make
people realise that it doesn't appear from thin air - ie your hardwork was
involved

If I am a b) type person, then I think I want your website.  If I want a
local app which sits on the desktop, then there seem to be lots of those
already, so just provide a link to a good one, and make sure that your data
works with that app.  Get indexed on google (you are), also get your name
added to the xmltv page and all the other tv app/epg gui pages.  Your
terrestrial view is very nice (especially on a big screen), but I guess I
also want a view of all my favourite channels (I think at the moment, it is
"all" or "terrestrial".).  Also consider lining time periods up so I can
scan left to right and see what is on at a given time - it may make more
sense to have "time" running across the page rather than down (more space
for words)?

www.mydigiguide.com is a very nice example of the lining up of the time
periods.  However, I often get frustrated scanning forward and backwards to
see the whole evening.  There is something quite nice about your current
"terrestrial" view which is easier to do this.

Anyway, enough rambling.  I hope you can consider adding in as many of those
extra fields as possible to the XML.  I look forward to putting together a
quick replacement script for my xmltv feed.  Thanks for this!

Ed