On Thu, 16 Oct 2014 11:33:25 +0100, Paul Gardiner wrote:
> > Just an observation: asking for 14 days data every day is a bit overkill IMO. I usually get 'today' + the next 3 days to catch any last minute changes to schedules, plus the 'new' day in the future (e.g. day 14). The schedule in between rarely changes and you risk being chastised by MetaBroadcast if you fetch too much data for too many channels too often.
>
> Yes, I see the sense in that. How do you do it? I'd guess, call twice,
> once with --days 4, and again with --days 1 --offset 13, concatenating
> the data. Is that right?
>
> The only worry, is I thought I had noticed changes fairly often, not
> so much changed times, as details filled in as the time of airing
> comes closer. Maybe I imagined it.
Yes you could generate two xml files and use tv_cat to combine them.
Different channels have different quality of data. As you go further out in time the quality becomes less reliable (or more prone to change depending on your POV ;) ). Sometimes only the series is known initially with the episode being filled in closer to broadcast (e.g. Big Bang Theory on C4). Occasionally the description is initially blank and filled in a couple of days later. Some channels are just consistently wrong (e.g. TCM).
So I usually only fetch data for max 10 days ahead as that seems to provide the best balance between a full schedule vs. lots of corrections. (Consider that most listing services (i.e. newspapers etc) are only interested in the next 7 days so that is where the data publishers concentrate their effort.)
The daily fetch of "today+3" ensures I have the most up-to-date info for things actually being broadcast, plus ensures my PVR can juggle its auto-records if necessary (i.e. allows it to workaround new programme conflicts etc)
YMMV
Rgds,
Geoff
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.