icebox-devel Mailing List for icebox
Brought to you by:
purbanec
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(2) |
Nov
(7) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Fredrick M. <fr...@sp...> - 2006-02-06 12:11:09
|
On 23/11/2005, at 0:23, Fredrick Meunier wrote: > OK, I've built ice_guide_daemon on OS X, though without the > filesystem set up for ini files and /etc/version it doesn't get too > far. I think I'll start by making a custom version that just > retrieves and unpacks the EPG and TAP files for manual upload (in > the absence of puppy). Stage 2 might be to talk to Nathan to see > about integrating file upload etc. ala puppy. OK, I've put together a simple python downloader for the Topfield data at <http://home.exetel.com.au/fredm/ TopfieldICEGuideFetcher.html> as the daemon was heavily geared around regularly streaming updates, and I am using a laptop that is only occasionally connected to the Toppy. It's pretty basic, requiring you to upload the files yourself, but it is good enough for what I require, and should also work on e.g. Linux as long as python is installed. Fred |
From: Fredrick M. <fr...@sp...> - 2005-11-22 13:23:46
|
On 22/11/2005, at 12:13, Peter Urbanec wrote: > Fred wrote: >> I must admit I hadn't considered this, and it should be fairly >> straightforward >> as you say. I'll download the source to ice_daemon tonight and >> have a look to >> see how much work it would be to port. >> > > I'm not intimate with the code, but I believe it's a classic case > of a POSIX/BSD daemon coding. With the exception of the commands > used for the actual transfer of data to the Toppy, it should be > straight forward to get it going on OSX. Assuming MacTF is > scriptable, the changes should be minimal. Perhaps your effort > would benefit from Nathan's input. Feel free to invite him to join > this list if he is interested. OK, I've built ice_guide_daemon on OS X, though without the filesystem set up for ini files and /etc/version it doesn't get too far. I think I'll start by making a custom version that just retrieves and unpacks the EPG and TAP files for manual upload (in the absence of puppy). Stage 2 might be to talk to Nathan to see about integrating file upload etc. ala puppy. I expect a Mac Mini would make a nice Topfield controller with a full icebox port :) Next update likely in a couple of weeks... Fred |
From: Peter U. <ice...@ur...> - 2005-11-22 02:26:41
|
Fred wrote: >I had hoped that some of the work done for the JavaXMLTV to TGD stuff would be >useful, and that XML parsing wouldn't be too much work in Java (which has >proven to be great for cross-platform Toppy apps). > > The JavaXMLTV stuff and TGD specification I did was a one night quick hack to put together a proof of concept. I just wanted to get some data as quickly as possible so that Tony H. could get the EIT insertion TAP going. I have never intended for it to become the defacto standard for the Toppy. The code I wrote does not parse the XML at all, it just dumps the serialised data structures used for persistent storage of the EPG. >What are the complications in doing an IceTV XML parser? Is it just a comment on >how hard the c XML libraries are to use? > > No, not really a difficulty issue, more of a time issue. First, I'd need to choose a library (probably expat), then I'd have to learn it's API, then I'd have to understand the finer points of the iceguide XML data, then actually write the parser and the code to dump out the TGD. Frankly, I'm too lazy/busy to get started on that, given that there are alternatives. >I must admit I hadn't considered this, and it should be fairly straightforward >as you say. I'll download the source to ice_daemon tonight and have a look to >see how much work it would be to port. > > I'm not intimate with the code, but I believe it's a classic case of a POSIX/BSD daemon coding. With the exception of the commands used for the actual transfer of data to the Toppy, it should be straight forward to get it going on OSX. Assuming MacTF is scriptable, the changes should be minimal. Perhaps your effort would benefit from Nathan's input. Feel free to invite him to join this list if he is interested. >Where would the ICE EPG files be obtained from? Do IceTV provide those directly >as well as the XML feed? (Aplogies if these are basic questions, I've gone over >the IceTV website in some detail, but have not yet downloaded the sourceforge >source code). > I don't believe the flat file format is advertised or the specification published anywhere, however the code should be readable enough to figure out how to construct the URL. Look for the retrieveEPG() function and look in the corresponding header file for the base URL. Hint: If you want to avoid downloading the TAP, send a TAP version time stamp that is in the future. Warning: Be careful about what the daemon does when there are excessive failures. First time I ran into it's way of recovering from persistent errors, I ended up cursing for hours! |
From: Daniel D. <dan...@ic...> - 2005-11-22 01:10:43
|
fr...@sp... wrote: > Quoting Peter Urbanec <ice...@ur...>: > >> Fredrick Meunier wrote: >> >>> Is there any interest in producing a converter from IceTV XML to TGD >>> files? It would provide an inexpensive way to take advantage of the >>> IceTV service as a Mac user. >>> >> I am sure that there would be interest in a light-weight Open Source >> IceTV XML parser, but am not aware of any work being done on that. It's >> a lot of work. I wanted one to use on the SLUG. >> > > I had hoped that some of the work done for the JavaXMLTV to TGD stuff would be > useful, and that XML parsing wouldn't be too much work in Java (which has > proven to be great for cross-platform Toppy apps). > > What are the complications in doing an IceTV XML parser? Is it just a comment on > how hard the c XML libraries are to use? > Parsing XML into memory and then writing it out in a new format can be a pain in the arse... I would only do it if I couldn't get the data in the format I want to start off with. > >> A better approach to get a Toppy solution for the Mac would be to port >> the existing ice_daemon to OSX. After that you just need to port puppy >> or make use of Nathan's MacTF utility to transfer the flat file ICE EPG >> files to the Toppy, where the ICE TAP will process the files. >> > > I must admit I hadn't considered this, and it should be fairly straightforward > as you say. I'll download the source to ice_daemon tonight and have a look to > see how much work it would be to port. > You can cetainly do this and Daniel Hall our support guy has a version of the daemon running on one of his Linux boxes at home. If you want a GUI based Mac application then you may not want to do the full ice_daemon fuctionality. Another possibility is to just write a simple(ish) script that grabs the data and sends the file to the toppy, you could then run this in cron. The actual data that the daemon uses is really quite simple, all the separate files (and the latest TAP) are send in one big file with delimiters. ex ICE_COMMENT SHOW_COUNT="1761" ICE_DATA FILE="20051122_20051122004148_EPG_CACHE" DIR="\ICE" TYPE="guide" 200511211300|4|60|Da Vinci's Inquest|12|Tommy's on the Corner|A police chase ends in tragedy and Da Vinci is left to make sense of the mess. Meanwhile, an armoured car stick-up has the rest of the crew baffled. Nicholas Campbell, Ian Tracey, Venus Terzo 200511211300|5|30|SPORT: Sailing||Volvo Round the World Ocean Race - 1st Leg|The Round the World Ocean race kicked off from Vigo, Spain on Sunday November 13th and the teams were immediately thrown in the deep end (so to speak) with 5-6 metre ocean swells. The seven teams will battle it out for race points in leg one, racing from Vigo to Cape Town. ...... ICE_DATA FILE="20051123_20051122004148_EPG_CACHE" DIR="\ICE" TYPE="guide" 200511221300|3|30|Scrubs|9|My Old Friend's New Friend|JD is ecstatic about his impending promotion - only one week remains until he is officially a fully-fledged, card-carrying Doctor. Not even the loony new Doctor Clock can burst his balloon. Zach Braff, Donald Faison, Sarah Chalke, John C. McGinley 200511221300|4|30|Nightline|||National and international summary of the news as it happened on this day, featuring latest footage and interviews with those who were there and those who know. 200511221300|5|30|The Osbournes|15|What Goes Up|Kelly prepares herself for the MTV Music Awards where she's set to perform her version of Madonna's "Papa Don't Preach". Meanwhile, Ozzy and Sharon head North for a Presidential reception, where the U.S. head of state inexplicably lathers the ageing rocker with praise. 200511221315|2|60|MOVIE: Storm Over Wyoming|9||Two unemployed cowhands arrive in Wyoming smack bang in the middle of a range war. After preventing a lynching, the cowhands try to get to the bottom of the trouble. Bill Kennedy, Tim Holt 2 ...... ICE_DATA FILE="ice_epg_loader_200511111435.tap" DIR="\ProgramFiles\Auto Start" TYPE="tap" ENCODING="base64" MD5SUM="8ed230d3f48bd121eb5989b0bd6c6107" VEZBUE1JUFMCAwAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAEKAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAElDRSBFUEcgTG9hZGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABJQ0UAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ...... ICE_DATA FILE="map.ini" DIR="\ICE" TYPE="map" [Channel 1] channel_id=1 region=Sydney name=SBS The separator starts with "ICE_DATA" and there are fields like FILE - name of original file DIR - Destination directory on topfield TYPE - Type of file. tap, guide, map ENCODING - base64 for tap files MD5SUM - md5sum of original file. In essence all your script needs to do is read the file and each time you see "ICE_DATA" start writing to a new file using the name in "FILE", once the file is complete you can use "DIR" to decide where to put it. If the file is base64 encoded then decode it and compare the decoded versions md5sum with the supplied md5sum. > >> The other option is to set up a cron job to run wget once a day to >> retrieve the ICE EPG files and then send these to the Toppy. All the >> required information is already present in the published source code. >> > > Where would the ICE EPG files be obtained from? Do IceTV provide those directly > as well as the XML feed? (Aplogies if these are basic questions, I've gone over > the IceTV website in some detail, but have not yet downloaded the sourceforge > source code). > If you are a current subscriber (or on a free trial), you can use the following link http://www.icetv.com.au/cgi-bin/epg/iceguide.cgi?op=topguide to retrieve the guide exactly as the daemon does it. Authentication is done through http authentication. > >> Both of these approaches are almost trivial in comparison with coding an >> XML parser, but will require the use of a command line, rather than just >> a point-n-click approach. I guess dressing the above with a GUI could be >> an interesting project for a Mac hacker and would result in something >> acceptable to typical Mac users. >> > > True. > > Fred > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > icebox-devel mailing list > ice...@li... > https://lists.sourceforge.net/lists/listinfo/icebox-devel > -- *Daniel Drysdale* Software Engineer *Work:* +61 2 8424 7508 *Mobile:* +61 410 60 70 92 *Fax:* +61 2 9901 3679 *Email:* dan...@ic... <mailto:dan...@ic...> *Professional Profile <https://www.linkedin.com/e/fps/4064139/>* *My Blog <http://blog.drysdale.org>* *Ice TV Pty Ltd* <http://www.icetv.com.au> 34-36 Chandos St St Leonards <http://maps.google.com/maps?q=34-36+Chandos+St%2CSt+Leonards%2CSydney%2CNSW+2065%2CAustralia&hl=en> Sydney, NSW 2065 Australia See who we know in common <https://www.linkedin.com/e/wwk/4064139/> Want a signature like this? <https://www.linkedin.com/e/sig/4064139/> |
From: <fr...@sp...> - 2005-11-22 01:10:25
|
Quoting fr...@sp...: > Quoting Peter Urbanec <ice...@ur...>: > > A better approach to get a Toppy solution for the Mac would be to port > > the existing ice_daemon to OSX. After that you just need to port puppy > > or make use of Nathan's MacTF utility to transfer the flat file ICE EPG > > files to the Toppy, where the ICE TAP will process the files. > > I must admit I hadn't considered this, and it should be fairly > straightforward as you say. I'll download the source to ice_daemon tonight > and have a look to see how much work it would be to port. Answer: not much, but most actions are done by puppy. It should be trivial to knock something up that can grab the appropriate files from IceTV for manual uploading to the toppy - thanks! > > The other option is to set up a cron job to run wget once a day to > > retrieve the ICE EPG files and then send these to the Toppy. All the > > required information is already present in the published source code. > > Where would the ICE EPG files be obtained from? Do IceTV provide those > directly as well as the XML feed? (Aplogies if these are basic questions, > I've gone over the IceTV website in some detail, but have not yet downloaded > the sourceforge source code). I've had a look at the source, and the answers are abundantly clear. I suspect that it would be easier to customise the uploading support in MacTF rather than port puppy directly, but I don't know much about the Mac USB APIs. Fred |
From: <fr...@sp...> - 2005-11-22 00:38:04
|
Quoting Peter Urbanec <ice...@ur...>: > Fredrick Meunier wrote: > > Is there any interest in producing a converter from IceTV XML to TGD > > files? It would provide an inexpensive way to take advantage of the > > IceTV service as a Mac user. > > I am sure that there would be interest in a light-weight Open Source > IceTV XML parser, but am not aware of any work being done on that. It's > a lot of work. I wanted one to use on the SLUG. I had hoped that some of the work done for the JavaXMLTV to TGD stuff would be useful, and that XML parsing wouldn't be too much work in Java (which has proven to be great for cross-platform Toppy apps). What are the complications in doing an IceTV XML parser? Is it just a comment on how hard the c XML libraries are to use? > A better approach to get a Toppy solution for the Mac would be to port > the existing ice_daemon to OSX. After that you just need to port puppy > or make use of Nathan's MacTF utility to transfer the flat file ICE EPG > files to the Toppy, where the ICE TAP will process the files. I must admit I hadn't considered this, and it should be fairly straightforward as you say. I'll download the source to ice_daemon tonight and have a look to see how much work it would be to port. > The other option is to set up a cron job to run wget once a day to > retrieve the ICE EPG files and then send these to the Toppy. All the > required information is already present in the published source code. Where would the ICE EPG files be obtained from? Do IceTV provide those directly as well as the XML feed? (Aplogies if these are basic questions, I've gone over the IceTV website in some detail, but have not yet downloaded the sourceforge source code). > Both of these approaches are almost trivial in comparison with coding an > XML parser, but will require the use of a command line, rather than just > a point-n-click approach. I guess dressing the above with a GUI could be > an interesting project for a Mac hacker and would result in something > acceptable to typical Mac users. True. Fred |
From: Peter U. <ice...@ur...> - 2005-11-21 16:26:50
|
Fredrick Meunier wrote: > Is there any interest in producing a converter from IceTV XML to TGD > files? It would provide an inexpensive way to take advantage of the > IceTV service as a Mac user. I am sure that there would be interest in a light-weight Open Source IceTV XML parser, but am not aware of any work being done on that. It's a lot of work. I wanted one to use on the SLUG. A better approach to get a Toppy solution for the Mac would be to port the existing ice_daemon to OSX. After that you just need to port puppy or make use of Nathan's MacTF utility to transfer the flat file ICE EPG files to the Toppy, where the ICE TAP will process the files. The other option is to set up a cron job to run wget once a day to retrieve the ICE EPG files and then send these to the Toppy. All the required information is already present in the published source code. Both of these approaches are almost trivial in comparison with coding an XML parser, but will require the use of a command line, rather than just a point-n-click approach. I guess dressing the above with a GUI could be an interesting project for a Mac hacker and would result in something acceptable to typical Mac users. If you have the skills to implement something like this, please feel free to get stuck into it. Don't hesitate to post technical questions if you get stuck. Good luck. |
From: Fredrick M. <fr...@sp...> - 2005-11-20 10:27:08
|
Hi, As free program guide information in Australia is in a precarious position in Australia, I am very keen to use the ICEtv guide, but as I own a Mac, the only option is the pricey one of getting a dedicated router. Is there any interest in producing a converter from IceTV XML to TGD files? It would provide an inexpensive way to take advantage of the IceTV service as a Mac user. Fred |
From: Craig J. <cr...@ro...> - 2005-10-07 00:10:58
|
Hi, I'm new to the list, but was asked to post here by Daniel from ICE regarding the issues i have been experiencing (and likely overcome) regarding wireless association of my ICE router. In short, I couldn't associate when using WEP, however had no issues when using no encryption. When I had a WEP key entered, the web GUI said that I was associated, and could tell me the MAC address of my access point. L2 was all looking good. However, I could not get any L3 connectivity happening and could not see an association entry in my access point (DLink DI764). After SSHing into the ICE router, I ran an iwconfig. Output below: ~ # iwconfig lo no wireless extensions. eth0 no wireless extensions. ath0 IEEE 802.11g ESSID:"myssid" Mode:Managed Frequency:2.412 GHz Access Point: 00:00:00:00:00:00 Bit Rate:11 Mb/s Tx-Power:50 dBm Sensitivity=0/3 Retry:off RTS thr:off Fragment thr:off Encryption key:FFFF-FFFF-FFFF-FFFF-FFFF-FFFF-00 Security mode:restricted Power Management:off Link Quality=0/94 Signal level=-83 dBm Noise level=-95 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 From here I noted that the security mode is set to "restricted". In restricted mode the client will only associate with APs that it can first do shared key authentication with. If the AP is not configured to require shared key authentication, association won't happen. My access point is configured for open authentication, based upon the information available here: http://www.cisco.com/en/US/netsol/ns340/ns394/ns348/ns386/networking_solutio ns_white_paper09186a008009c8b3.shtml Note: With open authentication, the use of WEP prevents the client from sending data to and receiving data from the access point, unless the client has the correct WEP key. With shared-key authentication, the access point sends the client device a challenge text packet that the client must then encrypt with the correct WEP key and return to the access point. If the client has the wrong key or no key, authentication will fail and the client will not be allowed to associate with the access point. Shared-key authentication is not considered secure because a hacker who detects both the clear text challenge and the same challenge encrypted with a WEP key can decipher the WEP key. I have then set my ICE router to use the Open security mode to match my AP, but this was unsuccessful too. Upon changing the security mode of the access point to support shared mode authentication, the connection was successfully achieved with encryption on the link. I'm unlikley to be the first or last person to experience this, and I suggest that some further testing be done to ascertain whether Open authentication can be reliably supported, or if this information should be built into the support documentation for the ICE router firmware. Sorry for the long post first up. Cheers, Craig Joyce |
From: Peter U. <ice...@ur...> - 2005-10-02 19:37:32
|
A new page, containing high level developer documentation has been added to the project web site. See http://icebox.sourceforge.net/docs/ More documentation will be added as it is requested/contributed. |
From: Peter U. <ice...@ur...> - 2005-09-30 17:54:51
|
I would like to add some project documentation so that new developers can get started quickly. Some of the ideas for docs: * what to install on your machine (probably OS specific) * how to set up a development environment for developing component X * how to get a copy of current source via CVS * how to generate patches against current CVS code and anything else that will help with getting people involved and making them productive. Chances are that most potential developers do not have experience with version control or other formal code development methodologies. Rather than prevent them from participating until they somehow acquire such skills (which is unlikely to eventuate), I'd rather coach them through the learning curve and even spoon feed them the required information. Some of us may take a lot of the basic skills, such as version control, for granted. On the other hand, these concepts are very foreign to people who have only ever dealt with downloading zip files. I'd like to make the project documentation practical. Ideally a new developer will be able to follow simple step by step guides to get productive. Any and all help would be greatly appreciated. Please feel free to use this list to circulate any ideas or drafts you wish to contribute. I'll figure out a way of publishing the docs, while we are putting it together. |
From: Peter U. <ice...@ur...> - 2005-09-30 16:34:21
|
Some simple rules regarding CVS write access for this project. First, at least one of the existing project members will need to get to know you and your abilities. This is best done by submitting a contribution to the project. For example, emailing a patch to the icebox-devel mailing list. The existing developers will review your work and possibly accept it for inclusion in the project. If there are issues with your contribution, we will provide some constructive feedback so that your submission can be improved, fine tuned, adapted or otherwise made suitable. Once you have demonstrated your ability to contribute, you can request CVS write access. When you do this, you will need to supply your SourceForge user id. If you don't have a SourceForge user id, you can go over to http://sourceforge.net/account/newuser_emailverify.php and register. It's free and quick. We also expect that any user requesting CVS write access has read and understood the SourceForge documentation and is reasonably competent with CVS. If it all seems too complicated, we are happy to receive patches from you via email and update CVS on your behalf. Of course, your submissions don't have to be restricted to patches only. If you have a substantial body of work to contribute (for example, a port to another platform) we will be happy to hear about this too. Any major changes or additions will always be discussed on the icebox-devel mailing list. And remember, if you are unsure, look in the archives at http://sourceforge.net/mailarchive/forum.php?forum=icebox-devel or just ask in the icebox-devel mailing list. |
From: Peter U. <ice...@ur...> - 2005-09-30 15:01:03
|
I have imported the latest changes from IceTV source base to the icebox project CVS. The changes were relatively minor and occurred during the initial GPL source code release. The only affected component was ice_epg_loader. The changes should propagate from developer CVS servers to public CVS servers within the next 6-8 hours. |
From: Peter U. <ice...@ur...> - 2005-09-30 06:30:09
|
OK, now that we have the source out in the open, what's next? I suspect that one of the first things on the roadmap may be a method for combining the best features of ice_epg_loader and Tony's epg_uploader. I think we have learned our lessons from both the ICE EPG file format and the TGD file format. In the long term, there's little to no value in having two competing standards. I propose that we now take our time to discuss and adopt one of the following strategies for handling EPG data: 1) XML parser for the Toppy. 2) New file format that is better than TGD and ICE EPG files, but less complex than XML. I'd like to solicit input on this from anyone seriously interested in contributing to the cause. Let's hear it. Peter |
From: Peter U. <ice...@ur...> - 2005-09-29 18:33:55
|
The software components related to the Netgear WGT634U router with ice firmware have been released. There are three CVS modules and the initial release has been tagged as follows: netgear_daemon NETGEAR_DAEMON_1_0 netgear_tools NETGEAR_TOOLS_1_0 netgear_web NETGEAR_WEB_1_0 Use your favourite CVS client to retrieve the modules, or do it this way from the command line: cvs -z5 -d:pserver:ano...@cv...:/cvsroot/icebox co icebox The above will create a directory named icebox and will check out the latest version of everything. |