From: Andy B. <and...@ar...> - 2002-06-14 12:07:42
|
Hi All, As I mentioned in my previous email to Robert, I ultimately want to be able to configure the xmltv grabbers from within FreeGuide so the user doesn't have to use the commandline at all. Ideally, this would be non-interactive, with all channels being chosen, so the user can unselect the ones s/he doesn't want within FreeGuide. I think this would be fairly simple to do in tv_grab_uk. Am I right? I know that you can run tv_grab_na non-interactively, but you need to provide info e.g. provider ID that I'd have to extract from somewhere first. Any thoughts on whether this could be made simpler, so the user could choose a couple of options, and then just click a "configure" button and watch it work? Andy |
From: Edward A. <ep...@do...> - 2002-06-14 16:31:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 14 Jun 2002, Andy Balaam wrote: >As I mentioned in my previous email to Robert, I ultimately want to be >able to configure the xmltv grabbers from within FreeGuide so the user >doesn't have to use the commandline at all. > >Ideally, this would be non-interactive, with all channels being chosen, >so the user can unselect the ones s/he doesn't want within FreeGuide. Are you sure about that? It's a lot of channels. It wouldn't be much fun for the first-time user to get a list of a thousand obscure channels to select from before being able to do anything. However, if you really do want that feature, perhaps we should add a - --list-channels option to the grabbers, so you can find out about channels without waiting for the listings themselves to download. >I think this would be fairly simple to do in tv_grab_uk. Well you can give the --config-file option, and the configuration files are fairly simple to write. The same is true of tv_grab_na. And tv_grab_de does not have a configuration file. However, in order to write the config file you'd need to know what the channel ids were. >I know that you can run tv_grab_na non-interactively, You can run all the grabbers non-interactively. It's just the - --configure stage that requires user input. >but you need to provide info e.g. provider ID that I'd have to extract >from somewhere first. Any thoughts on whether this could be made >simpler, so the user could choose a couple of options, and then just >click a "configure" button and watch it work? One possible answer springs to mind, although it might not be ideal. Have a look at the XMLTV::Ask module. All questions asked during configuration are done using that library. It would be fairly simple to build a Tk frontend so that the user can click on options rather than typing them in. - -- Ed Avis <ep...@do...> Finger for PGP key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9ChphIMp73jhGogoRAul3AJ9l1X2WBcK8HFFgw+VdpZD1HmxNcACaAmMw bbY64pHxFpTEPKy0cTEkfNo= =4Mei -----END PGP SIGNATURE----- |
From: Jerry V. <je...@ma...> - 2002-06-14 17:13:23
|
--On Friday, June 14, 2002 17:31:28 +0100 Edward Avis wrote: > On Fri, 14 Jun 2002, Andy Balaam wrote: > >> As I mentioned in my previous email to Robert, I ultimately want to be >> able to configure the xmltv grabbers from within FreeGuide so the user >> doesn't have to use the commandline at all. >> >> Ideally, this would be non-interactive, with all channels being chosen, >> so the user can unselect the ones s/he doesn't want within FreeGuide. > > Are you sure about that? It's a lot of channels. It wouldn't be much > fun for the first-time user to get a list of a thousand obscure channels > to select from before being able to do anything. > In NA, you get a list of channels the provider provides. The list is rarely over 200. Even then the descriptions are short (channel # and call letters), so any simple multi-pick window could be used. I'd suggest 'unselect all' and 'select all' buttons someplace for convience though. > However, if you really do want that feature, perhaps we should add a > - --list-channels option to the grabbers, so you can find out about > channels without waiting for the listings themselves to download. > I've added --list-providers and --list-channels to tv_grab_na this morning. The --list-channels still requires a pretty big query of the zap2it site (ie ~5-10 seconds for the page), but still it does produce the list you want. The output is compatible with what you'd need to fill in the config file. >> I think this would be fairly simple to do in tv_grab_uk. > > Well you can give the --config-file option, and the configuration files > are fairly simple to write. The same is true of tv_grab_na. And > tv_grab_de does not have a configuration file. > > However, in order to write the config file you'd need to know what the > channel ids were. > Its hard not to get around having to create your own config file. Hopefully we can minimize the format changes and the chances or things breaking. >> I know that you can run tv_grab_na non-interactively, > > You can run all the grabbers non-interactively. It's just the > - --configure stage that requires user input. > >> but you need to provide info e.g. provider ID that I'd have to extract >> from somewhere first. Any thoughts on whether this could be made >> simpler, so the user could choose a couple of options, and then just >> click a "configure" button and watch it work? > > One possible answer springs to mind, although it might not be ideal. > Have a look at the XMLTV::Ask module. All questions asked during > configuration are done using that library. It would be fairly simple to > build a Tk frontend so that the user can click on options rather than > typing them in. > This isn't as simple as chaning the XMLTV::Ask module to put up a popup and ask a question. We'd need to have entry points to provide error messages w.r.t. invalid answers etc. Certainly I don't want yet another requirement (for perl::Tk) to run tv_grab_na, it would need to be completely optional. jerry |
From: Edward A. <ep...@do...> - 2002-06-14 17:29:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 14 Jun 2002, Jerry Veldhuis wrote: >>Have a look at the XMLTV::Ask module. All questions asked during >>configuration are done using that library. It would be fairly simple to >>build a Tk frontend so that the user can click on options rather than >>typing them in. > >This isn't as simple as chaning the XMLTV::Ask module to put up a popup >and ask a question. That's exactly what I mean. The module provides a very simple interface; currently the implementation uses text questions; we could easily write another implementation to pop up windows. >We'd need to have entry points to provide error messages w.r.t. invalid >answers etc. The way the module works is to take a question and a *list of legal answers*, and allow the user to select from them. Any prompting such as 'no such choice' is done within the module itself. There's no need for callbacks or anything sophisticated. The exception is the free-text search for channels in tv_grab_uk (and maybe _na has some equivalent), where you type in an arbitrary string. For that, yes I can see that it could get more complex. But not actually _difficult_ in any way. It would not be hard to extend XMLTV::Ask to support this kind of question (which is again choosing from a list of allowable values, just a rather large list which can't be shown all at once). I might do that anyway at some point, just to keep things cleaner. >Certainly I don't want yet another requirement (for perl::Tk) to run >tv_grab_na, it would need to be completely optional. Yup. I'm imagining we keep the existing text-mode question asking code but add a GUI version as well. - -- Ed Avis <ep...@do...> Finger for PGP key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9CigOIMp73jhGogoRAnv+AJ9J5XSx52lhJ98+hesObOrIT6azHQCfXGMx T5yYfcMQQwWvl1pon7UGy/U= =+bMU -----END PGP SIGNATURE----- |
From: Jerry V. <je...@ma...> - 2002-06-14 18:13:36
|
--On Friday, June 14, 2002 18:29:48 +0100 Edward Avis wrote: > On Fri, 14 Jun 2002, Jerry Veldhuis wrote: > >>> Have a look at the XMLTV::Ask module. All questions asked during >>> configuration are done using that library. It would be fairly simple to >>> build a Tk frontend so that the user can click on options rather than >>> typing them in. >> >> This isn't as simple as chaning the XMLTV::Ask module to put up a popup >> and ask a question. > > That's exactly what I mean. The module provides a very simple > interface; currently the implementation uses text questions; we could > easily write another implementation to pop up windows. > probably. >> We'd need to have entry points to provide error messages w.r.t. invalid >> answers etc. > > The way the module works is to take a question and a *list of legal > answers*, and allow the user to select from them. Any prompting such as > 'no such choice' is done within the module itself. There's no need for > callbacks or anything sophisticated. > Yes and no. I know this is the way the module works, but the implementation doesn't cover all the ways it gets used. For instance, when prompting for value of 'retry-limit' and 'retry-delay' after the users answer comes back, the fact a numerical value is the result isn't in the Ask interface. For postal codes, we verify it is valid (alpha, digit, alpha...) the ask interface doesn't have a 'ask for a postal code' or 'ask for a numerical response'. That's all I'm saying. What I meant was that the result of simply putting a gui option in the 'Ask' module may look choppy, for instance: - put up window and 'Ask for postal code' - pull down window when user hits 'Okay' - put up error message 'invalid postal code, try again' - repeat Not that this is bad, it just isn't ideal. > The exception is the free-text search for channels in tv_grab_uk (and > maybe _na has some equivalent), where you type in an arbitrary string. > For that, yes I can see that it could get more complex. But not > actually _difficult_ in any way. It would not be hard to extend > XMLTV::Ask to support this kind of question (which is again choosing > from a list of allowable values, just a rather large list which can't > be shown all at once). I might do that anyway at some point, just to > keep things cleaner. > right. >> Certainly I don't want yet another requirement (for perl::Tk) to run >> tv_grab_na, it would need to be completely optional. > > Yup. I'm imagining we keep the existing text-mode question asking code > but add a GUI version as well. > the GUI version must be completely optional. If I don't want gui mode, the grabber should run without the Tk module installed. jerry |
From: Edward A. <ep...@do...> - 2002-06-14 19:59:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 14 Jun 2002, Jerry Veldhuis wrote: >>>>Have a look at the XMLTV::Ask module. >>The way the module works is to take a question and a *list of legal >>answers*, and allow the user to select from them. >Yes and no. I know this is the way the module works, but the >implementation doesn't cover all the ways it gets used. For instance, >when prompting for value of 'retry-limit' and 'retry-delay' after the >users answer comes back, the fact a numerical value is the result isn't >in the Ask interface. Hmm. So maybe a richer interface is needed - probably a callback to check whether the answer is valid. > - put up window and 'Ask for postal code' > - pull down window when user hits 'Okay' > - put up error message 'invalid postal code, try again' > - repeat > >Not that this is bad, it just isn't ideal. I think we can avoid that. Even with the current interface it could be avoided, by having the Ask module maintain some state. >the GUI version must be completely optional. If I don't want gui mode, >the grabber should run without the Tk module installed. Absolutely. Something for me to do is fix the warning from Makefile.PL, so that Tk doesn't appear to be required unless you plan to run tv_choose. - -- Ed Avis <ep...@do...> Finger for PGP key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9CksiIMp73jhGogoRApyuAKCG7bhB+ZMRFQDGAb04PI1A/ru2EQCeMTJs PZRS2BgORpvTvKi+aY6nuCI= =Ezg2 -----END PGP SIGNATURE----- |
From: Jerry V. <je...@ma...> - 2002-06-14 21:21:17
|
I'm not sure if putting an optional Tk interface in 'Ask' is really worth the time. The current configure approach and command line prompts works fine, except for situations like the FreeGuide gui. Certainly the recent enhancements to tv_grab_na (I think) is sufficiant for Andy to configure the grabber without having to resort to the user manually running tv_grab_na --configure in a window. feel free though jerry |
From: Andy B. <and...@ar...> - 2002-06-17 01:20:17
|
Agreed. Andy On Fri, 14 Jun 2002 15:20:52 -0600 Jerry Veldhuis <je...@ma...> wrote: > > I'm not sure if putting an optional Tk interface in 'Ask' is > really worth the time. The current configure approach and > command line prompts works fine, except for situations like > the FreeGuide gui. > > Certainly the recent enhancements to tv_grab_na (I think) is sufficiant > for Andy to configure the grabber without having to resort to > the user manually running tv_grab_na --configure in a window. > > feel free though > jerry > > |
From: Edward A. <ep...@do...> - 2002-06-17 09:29:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If Andy's happy to work with the non-interactive configure mode added to tv_grab_na then that'll be fine. But what happens with the two other grabbers (or new grabbers that may be added in future)? - -- Ed Avis <ep...@do...> Finger for PGP key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9Dav9IMp73jhGogoRAivjAJsHZM5a9MT9AxNXHrE81LHs14WxLACeL+zR oTEvRerqU+POTG7oLjzdx48= =e6ro -----END PGP SIGNATURE----- |
From: Andy B. <and...@ar...> - 2002-06-17 01:19:31
|
On Fri, 14 Jun 2002 20:59:28 +0100 (BST) Edward Avis <ep...@do...> wrote: > Something for me to do is fix the warning from Makefile.PL, so that Tk > doesn't appear to be required unless you plan to run tv_choose. Excellent idea - are there any other dependencies we could do a similar thing for? Andy |
From: Andy B. <and...@ar...> - 2002-06-17 01:24:18
|
On Fri, 14 Jun 2002 11:12:59 -0600 Jerry Veldhuis <je...@ma...> wrote: > In NA, you get a list of channels the provider provides. The list is > rarely over 200. Even then the descriptions are short (channel # and > call letters), so any simple multi-pick window could be used. I'd > suggest 'unselect all' and 'select all' buttons someplace for convience > though. Sounds perfect. > > However, if you really do want that feature, perhaps we should add a > > - --list-channels option to the grabbers, so you can find out about > > channels without waiting for the listings themselves to download. > > > I've added --list-providers and --list-channels to tv_grab_na this > morning. The --list-channels still requires a pretty big query of > the zap2it site (ie ~5-10 seconds for the page), but still it > does produce the list you want. The output is compatible with what > you'd need to fill in the config file. Yes, this is exactly the kind of thing I was thinking of - fast work! So, to be clear, would FreeGuide need to use --list-providers to get the providers, then ask the user what provider, and then use --list-channels to get the channels and make a config file? Any ideas on how to make this general so I don't have to write specific code for each grabber? Can I still use --output on both these options? How about giving default values for the other options in the output too? (Obviously then the name --list-channels becomes wrong - maybe --configure --non-interactive as I said in the other email?) > Its hard not to get around having to create your own config file. > Hopefully we can minimize the format changes and the chances or > things breaking. The above would solve this though wouldn't it? > This isn't as simple as chaning the XMLTV::Ask module to put up > a popup and ask a question. We'd need to have entry points to > provide error messages w.r.t. invalid answers etc. Certainly > I don't want yet another requirement (for perl::Tk) to run > tv_grab_na, it would need to be completely optional. Thinking about this, I don't think it's right. I don't want my program to interact with the grabbers except using commandline arguments. The reason for this is that I want the user to be able to plug in any other grabber that gets written without needing major rewrites of my code or requiring loads of specific things from the grabber writer. In summary, the ability to dump all the possible channels from tv_grab_uk would solve my problem (and I can submit a patch to do this when I get a chance), and the providers problem in tv_grab_na is causing me headaches at the moment because I can't see how to get round it without writing specific code in FreeGuide. I'll think on... Andy Andy |
From: Edward A. <ep...@do...> - 2002-06-17 09:34:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 17 Jun 2002, Andy Balaam wrote: >>This isn't as simple as chaning the XMLTV::Ask module to put up >>a popup and ask a question. We'd need to have entry points to >>provide error messages w.r.t. invalid answers etc. >Thinking about this, I don't think it's right. I don't want my program >to interact with the grabbers except using commandline arguments. Just to clarify: the suggestion I made of GUI-ifying --configure wouldn't require any special interaction between tv_check and the grabber. Some code changes would be needed to the grabbers themselves, but from tv_check's point of view it would be just running the program once with a single --configure argument. >The reason for this is that I want the user to be able to plug in any >other grabber that gets written without needing major rewrites of my >code or requiring loads of specific things from the grabber writer. That's why I think that moving too much complexity into tv_check is not the best way. Future grabbers might have additional configuration options - for example, I have a Radio Times grabber I'm planning to incorporate at some point, and it lets you choose 'slow but detailed' or 'fast' grabbing modes. Either you have the grabber itself asking those questions, or else you need to add new command-line options to configure these features noninteractively, and code to tv_check to cope with these new choices. I think that --list-channels and noninteractive configuration could be useful feature to have anyway, but it seems like a too-complicated interface to become the standard way of configuring grabbers from a frontend like tv_check. - -- Ed Avis <ep...@do...> Finger for PGP key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9Da0zIMp73jhGogoRAlZjAJ434R0pZ2ues15ionYtgCsyQ9aTIgCfWPZL g6NRZR4i3bHWSV458lJEsm0= =eydD -----END PGP SIGNATURE----- |
From: Andy B. <and...@ar...> - 2002-06-17 11:19:40
|
Thinking about all this, I think my short term answer will be to incorporate a command line terminal type thing into my program, so the user can interact with the grabbers from within FreeGuide. This won't require any changes in the grabbers at all! Andy On Mon, 17 Jun 2002 10:34:42 +0100 (BST) Edward Avis <ep...@do...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 17 Jun 2002, Andy Balaam wrote: > > >>This isn't as simple as chaning the XMLTV::Ask module to put up > >>a popup and ask a question. We'd need to have entry points to > >>provide error messages w.r.t. invalid answers etc. > > >Thinking about this, I don't think it's right. I don't want my program > >to interact with the grabbers except using commandline arguments. > > Just to clarify: the suggestion I made of GUI-ifying --configure > wouldn't require any special interaction between tv_check and the > grabber. Some code changes would be needed to the grabbers themselves, > but from tv_check's point of view it would be just running the program > once with a single --configure argument. > > >The reason for this is that I want the user to be able to plug in any > >other grabber that gets written without needing major rewrites of my > >code or requiring loads of specific things from the grabber writer. > > That's why I think that moving too much complexity into tv_check is not > the best way. Future grabbers might have additional configuration > options - for example, I have a Radio Times grabber I'm planning to > incorporate at some point, and it lets you choose 'slow but detailed' or > 'fast' grabbing modes. Either you have the grabber itself asking those > questions, or else you need to add new command-line options to configure > these features noninteractively, and code to tv_check to cope with these > new choices. > > I think that --list-channels and noninteractive configuration could be > useful feature to have anyway, but it seems like a too-complicated > interface to become the standard way of configuring grabbers from a > frontend like tv_check. > > - -- > Ed Avis <ep...@do...> > Finger for PGP key > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE9Da0zIMp73jhGogoRAlZjAJ434R0pZ2ues15ionYtgCsyQ9aTIgCfWPZL > g6NRZR4i3bHWSV458lJEsm0= > =eydD > -----END PGP SIGNATURE----- > > |
From: Andy B. <and...@ar...> - 2002-06-17 01:19:45
|
On Fri, 14 Jun 2002 17:31:28 +0100 (BST) Edward Avis <ep...@do...> wrote: > On Fri, 14 Jun 2002, Andy Balaam wrote: > >As I mentioned in my previous email to Robert, I ultimately want to be > >able to configure the xmltv grabbers from within FreeGuide so the user > >doesn't have to use the commandline at all. > > > >Ideally, this would be non-interactive, with all channels being chosen, > >so the user can unselect the ones s/he doesn't want within FreeGuide. > > Are you sure about that? It's a lot of channels. It wouldn't be much > fun for the first-time user to get a list of a thousand obscure channels > to select from before being able to do anything. Well, I want some way of allowing the user to configure the grabber without needing them to see a DOS or terminal window. I welcome any suggestions. Perhaps I could write a second bit that will provide a GUI to the user to make cutting that list down again easier. All that this would require to be added to tv_grab_uk would be an extra option like so: tv_grab_uk --configure --non-interactive that added every available channel to the config file. I would use that info from within my Java prog. > However, in order to write the config file you'd need to know what the > channel ids were. Which is why I'd like to do it from within tv_grab_uk instead of in my own program. > >I know that you can run tv_grab_na non-interactively, > > You can run all the grabbers non-interactively. It's just the > - --configure stage that requires user input. Sorry yes, that's what I meant. > One possible answer springs to mind, although it might not be ideal. > Have a look at the XMLTV::Ask module. All questions asked during > configuration are done using that library. It would be fairly simple to > build a Tk frontend so that the user can click on options rather than > typing them in. Would this be possible in Java? (i.e. is Tk specifically easier to integrate with Perl?) I don't want to require people (especially Windows people) to have any more prerequisites. I'll have a look, but advice would be appreciated. Andy |
From: Edward A. <ep...@do...> - 2002-06-17 09:28:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think we are discussing two different ways to make the configuration more user-friendly: - - Alter the XMLTV::Ask module, and the grabbers that use it, so that the current --configure mode has a graphical interface. Or, - - Have some way of configuring noninteractively so that the questions can be asked from a Java application or anywhere else, and passed in. I think that the first option is simpler, because with the second, tv_check (or whatever application) would have to *know about* the particular details of the configuration file for each grabber it wants to run. It's simpler to keep that complexity hidden inside the grabber. The downside is two slightly different-looking GUIs - the Tk/Perl one and the Java one - but since the configuration stage is only occasional that shouldn't matter too much. - -- Ed Avis <ep...@do...> Finger for PGP key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9DauZIMp73jhGogoRAgLCAJ9p2XZ6DxoaRy76/r+PHkGz/WCTuACdE7yo a7euQRwbISSdkRl/EJp26hs= =+g9K -----END PGP SIGNATURE----- |
From: Jerry V. <je...@ma...> - 2002-06-14 16:40:12
|
Andy, This is a good idea, and to support it, I added some good code :0 the current cvs version of tv_grab_na supports: --configure --list-providers --postalcode XXXXX and --configure --list-providers --zipcode YYYYY This puts tv_grab_na into a non-interactive mode that dumps the available providers, one per line. Here's an example. bash$ tv_grab_na --configure --list-providers T8n4z9 296047:Local Broadcast Listings 287710:Shaw Cablesystems - Edmonton (West) 294637:Shaw Cablesystems - Edmonton (West) - Digital 294571:Bell ExpressVu - Canada (East) - Digital 294470:Bell ExpressVu - Canada (French) - Digital 294666:Bell ExpressVu - Canada (West) - Digital 293899:C-BAND 294572:Star Choice - Canada (East) - Digital 294472:Star Choice - Canada (French) - Digital 294710:Star Choice - Canada (West) - Digital Obviously the first token is compatible with the --provider command line option. This by no means you can always guarentee being able to cleanly run tv_grab_na in configure mode without other possible problems (for instance www related, invalid --provider id causes interactive mode to be enabled, etc), but its a start. enjoy jerry --On Friday, June 14, 2002 13:08:13 +0100 Andy Balaam <and...@ar...> wrote: > Hi All, > > As I mentioned in my previous email to Robert, I ultimately want to be > able to configure the xmltv grabbers from within FreeGuide so the user > doesn't have to use the commandline at all. > > Ideally, this would be non-interactive, with all channels being chosen, > so the user can unselect the ones s/he doesn't want within FreeGuide. > > I think this would be fairly simple to do in tv_grab_uk. Am I right? > > I know that you can run tv_grab_na non-interactively, but you need to > provide info e.g. provider ID that I'd have to extract from somewhere > first. Any thoughts on whether this could be made simpler, so the user > could choose a couple of options, and then just click a "configure" > button and watch it work? > > Andy > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Xmltv-devel mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmltv-devel > |
From: Jerry V. <je...@ma...> - 2002-06-14 16:57:20
|
I also added a similar --list-channels command line option to tv_grab_na. Usage is similar: tv_grab_na --configure --list-channels --provider XXXX --postalcode YYY or tv_grab_na --configure --list-channels --provider XXXX --zipcode ZZZ produces a newline separated list of available channels for a given provider in a postal or zip code. jerry --On Friday, June 14, 2002 10:39:42 -0600 Jerry Veldhuis <je...@ma...> wrote: > > Andy, > This is a good idea, and to support it, I added some good code :0 > the current cvs version of tv_grab_na supports: > --configure --list-providers --postalcode XXXXX > and > --configure --list-providers --zipcode YYYYY > > This puts tv_grab_na into a non-interactive mode that dumps > the available providers, one per line. Here's an example. > > bash$ tv_grab_na --configure --list-providers T8n4z9 > 296047:Local Broadcast Listings > 287710:Shaw Cablesystems - Edmonton (West) > 294637:Shaw Cablesystems - Edmonton (West) - Digital > 294571:Bell ExpressVu - Canada (East) - Digital > 294470:Bell ExpressVu - Canada (French) - Digital > 294666:Bell ExpressVu - Canada (West) - Digital > 293899:C-BAND > 294572:Star Choice - Canada (East) - Digital > 294472:Star Choice - Canada (French) - Digital > 294710:Star Choice - Canada (West) - Digital > > Obviously the first token is compatible with the --provider > command line option. > > This by no means you can always guarentee being able to cleanly > run tv_grab_na in configure mode without other possible problems > (for instance www related, invalid --provider id causes interactive > mode to be enabled, etc), but its a start. > > enjoy > jerry > > --On Friday, June 14, 2002 13:08:13 +0100 Andy Balaam > <and...@ar...> wrote: > >> Hi All, >> >> As I mentioned in my previous email to Robert, I ultimately want to be >> able to configure the xmltv grabbers from within FreeGuide so the user >> doesn't have to use the commandline at all. >> >> Ideally, this would be non-interactive, with all channels being chosen, >> so the user can unselect the ones s/he doesn't want within FreeGuide. >> >> I think this would be fairly simple to do in tv_grab_uk. Am I right? >> >> I know that you can run tv_grab_na non-interactively, but you need to >> provide info e.g. provider ID that I'd have to extract from somewhere >> first. Any thoughts on whether this could be made simpler, so the user >> could choose a couple of options, and then just click a "configure" >> button and watch it work? >> >> Andy >> >> _______________________________________________________________ >> >> Don't miss the 2002 Sprint PCS Application Developer's Conference >> August 25-28 in Las Vegas - >> http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink >> >> _______________________________________________ >> Xmltv-devel mailing list >> Xml...@li... >> https://lists.sourceforge.net/lists/listinfo/xmltv-devel >> > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Xmltv-devel mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmltv-devel > |
From: Andy B. <and...@ar...> - 2002-06-17 01:19:56
|
ok cool this is even more like what I wanted that I first thought! Andy On Fri, 14 Jun 2002 10:39:42 -0600 Jerry Veldhuis <je...@ma...> wrote: > > Andy, > This is a good idea, and to support it, I added some good code :0 > the current cvs version of tv_grab_na supports: > --configure --list-providers --postalcode XXXXX > and > --configure --list-providers --zipcode YYYYY > > This puts tv_grab_na into a non-interactive mode that dumps > the available providers, one per line. Here's an example. > > bash$ tv_grab_na --configure --list-providers T8n4z9 > 296047:Local Broadcast Listings > 287710:Shaw Cablesystems - Edmonton (West) > 294637:Shaw Cablesystems - Edmonton (West) - Digital > 294571:Bell ExpressVu - Canada (East) - Digital > 294470:Bell ExpressVu - Canada (French) - Digital > 294666:Bell ExpressVu - Canada (West) - Digital > 293899:C-BAND > 294572:Star Choice - Canada (East) - Digital > 294472:Star Choice - Canada (French) - Digital > 294710:Star Choice - Canada (West) - Digital > > Obviously the first token is compatible with the --provider > command line option. > > This by no means you can always guarentee being able to cleanly > run tv_grab_na in configure mode without other possible problems > (for instance www related, invalid --provider id causes interactive > mode to be enabled, etc), but its a start. > > enjoy > jerry > > --On Friday, June 14, 2002 13:08:13 +0100 Andy Balaam > <and...@ar...> wrote: > > > Hi All, > > > > As I mentioned in my previous email to Robert, I ultimately want to be > > able to configure the xmltv grabbers from within FreeGuide so the user > > doesn't have to use the commandline at all. > > > > Ideally, this would be non-interactive, with all channels being > > chosen, so the user can unselect the ones s/he doesn't want within > > FreeGuide. > > > > I think this would be fairly simple to do in tv_grab_uk. Am I right? > > > > I know that you can run tv_grab_na non-interactively, but you need to > > provide info e.g. provider ID that I'd have to extract from somewhere > > first. Any thoughts on whether this could be made simpler, so the > > user could choose a couple of options, and then just click a > > "configure" button and watch it work? > > > > Andy > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas - > > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > > > _______________________________________________ > > Xmltv-devel mailing list > > Xml...@li... > > https://lists.sourceforge.net/lists/listinfo/xmltv-devel > > > > > |