Talk:Australian TV Listings

From MythTV Official Wiki
Jump to: navigation, search

Can these Icons be automatically downloaded using the 0.21 download channel icons?

Shepherd Warning!

Hello! I'm a Shepherd dev and noticed that user GBee added this to the "Shepherd" section of "Australian TV Listings":

Warning.png Warning: Please note that Shepherd is completely unsupported by the MythTV project. It is not an XMLTV compliant grabber and operates directly on your database. It does not allow MythTV to schedule listings updates like supported grabbers. This will only change if you lobby the developers to change their stance.

I don't really understand this, since:

  • All of the grabbers on this page are "completely unsupported by the MythTV project," but don't have this warning on them.
  • Shepherd is fully XMLTV compliant and has been for a long time.
  • During setup, Shepherd offers the ability to integrate itself with MythTV via the --configure-mythtv option, but during normal operation does not modify MythTV's database.
  • Shepherd does allow MythTV to schedule listings if the user wants. We don't recommend that by default, but it is certainly possible, just like any other grabber.
  • "Lobby the developers"... to do what? And if you want us to change something, why not post a request to our mailing list? It sounds like we are refusing to do something when in fact we have never been asked.

Aside from being factually incorrect, I feel the warning implies there's some danger to users from using Shepherd, like loss of data or a corrupted database or something.

It is perplexing that this page lists grabbers that flat out don't work, while warning users away from Shepherd.

-- Max Barry, user mbarry 15 Nov 2013.

Update: I notice the same warning about Shepherd was also added to XMLTV.

Shepherd follows the XMLTV data format, but does not follow the XMLTV behavioral format. XMLTV grabbers are intended to be a slave to the client application, called when the client application wants data, and outputting the data to stdout for the client to receive. Shepherd functions backwards, installing itself in cron, running when it wants to, and force feeding the data into the client application. wagnerrp 00:17, 15 November 2013 (UTC)
If you think Shepherd shouldn't be invoked by a cron job, okay, but how does that make it non-compliant with XMLTV? I see no part of any XMLTV spec that mentions this.
That aside, Shepherd *does* run as a slave to MythTV, being called whenever MythTV likes, if the user says "no" when asked, during setup, if they want the cron job. What you're referring to is part of an extended and optional configuration routine that we added because MythTV's default scheduler isn't very friendly to Australian conditions. It's simply wrong to tell users their only option is to "lobby the developers" when in fact they can easily decline the part in question during setup. Mbarry
It's great that Shepherd has made steps towards xmltv compliance, this hasn't always been the case hence the warnings. However there are still things that Shepherd is doing which appear nowhere in the xmltv spec - operating directly on the MythTV database, invoking mythfilldatabase from a cron job and downloading channel icons instead of putting the URLs in the guide data as defined in the XMLTV spec. Yes, as you point out all these things are optional, but they are the recommended defaults - which is made clear by both the configuration itself and the installation instructions (http://svn.whuffy.com/wiki/Installation). Shepherd also appears not to support the --config-file argument, which IS in the spec. Instead of working with the MythTV and XMLTV devs to extend XMLTV to do what you need (We both have mailing lists too!) the Shepherd devs have inexplicably gone it alone and put in a lot of work to do things their own way. I'd be happy to include support in MythTV for a <suggestednextruntime> value in the xmltv data eliminating the 'need' for cron - we already support this for Schedules Direct, I'd even be willing to do it before it gets accepted into the xmltv spec, although I'd ask that you at least make that effort. As for the rest, please do join the xmltv mailing list and discuss your ideas/concerns with the wider xmltv community. Participate in the process like the majority of other grabber developers do (http://www.crustynet.org.uk/~xmltv-tester/squeeze/nightly/). You could even work towards getting your grabber into the official xmltv package if you wanted. --GBee 11:01, 15 November 2013 (UTC)
Shepherd actually started on the MythTV mailing list in 2007 and that's where all our devs come from. Personally I've made dozens of posts to mythtv-users and mythtv-dev. Here is the most recent. Notice it peters out when MythTV devs stop posting. Years earlier, Australian devs spent much time banging their heads against the blank wall of mythtv-dev. That's why we stopped posting (and submitting patches); they never went anywhere.
And look, this is totally fine. MythTV is written by volunteers, who can craft it however they like. When a niche group of users have unusual requirements, it's perfectly reasonable to ignore them. You can't cater for everyone. And nor should you; it would be inefficient for MythTV devs to have to care about the nitty-gritty of EPG collection in Australia. You should just define a standard and let countries figure out the most logical way to supply data. Then users win: They get your expertise in HTPC software, and our expertise in wringing Australian guide data from a hostile TV industry.
I don't understand your argument that Shepherd is non-compliant because it offers some additional features that "appear nowhere in the [XmltvCapabilities standard]"... most programs offer features beyond a minimum set defined by a standard. My browser can bookmark pages; that doesn't make it non-compliant with HTTP, despite bookmarks appearing nowhere in the HTTP standard. When Shepherd was found to be non-compliant with a part of "XmltvCapabilities", that was only out of ignorance and we moved to correct it.
I will post again on mythtv-dev, if you like, or on the XMLTV mailing list (which I was unaware of). We don't maintain this extended feature set of Shepherd for fun; I would be happy to get rid of it. And I can believe that day will come: MythTV's grabber setup has improved a lot since 2007, and some problems we had to work around back then, like how users would run out of data if their machines powered off overnight, don't seem to exist in MythTV today. But I don't have any faith in my ability to convince MythTV devs to make changes.
Anyway, I'm not asking for changes: I'm just objecting to the warning on this wiki, since it is incorrect. It's a mixture of untruth and hyperbole, and much of it applies to all grabbers, not just Shepherd. Whatever you believe about Shepherd devs, if you're interested in the accuracy of this wiki, the warning needs to be removed or corrected.
May I suggest: "Warning: During setup, Shepherd offers users the option of auto-configuring MythTV on your behalf. Users should decline this option because it will cause Shepherd to register itself directly in the MythTV database." It would probably help users if it linked to instructions for manually configuring grabbers, too. Mbarry 00:02, 18 November 2013 (UTC)
If there are grabbers listed on this page that do not work, identify them as such. wagnerrp 00:17, 15 November 2013 (UTC)
None of the grabbers listed work except Shepherd. One (written by me in 2006) leads to a page saying it's dead, one leads to an error page, and one is a page of links that hasn't been updated in four years. As a Shepherd dev, though, I don't want to go and delete all the grabbers but Shepherd; that seems presumptuous. Mbarry