I know this isn't going to help most people, but I finally got jack of waiting for a fix to the specific issue that seemed to be holding me up and I decided to transparently proxy just the requests to IceTV (my issue was that EyeTV seem to want to go direct for some of it's updates). I posted the network captures of this a while ago.
Anyway, I transparently proxied the IceTV requests, and then noticed this:
1195801201.466 149 192.168.17.5 TCP_MISS/200 419 GET http://www.icetv.com.au/cgi-bin/webaccount.cgi? - DIRECT/202.125.163.43 text/xml
1195801201.513 257 192.168.8.140 TCP_MISS/200 776 POST http://www.icetv.com.au/cgi-bin/pimp/pimp_server - DIRECT/202.125.163.43 application/octet-stream
1195801201.821 223 192.168.17.5 TCP_MISS/200 617 GET http://www.icetv.com.au/cgi-bin/epg/webpimpdevices.cgi? - DIRECT/202.125.163.43 text/xml
1195801218.819 17032 192.168.8.140 TCP_MISS/200 794637 POST http://www.icetv.com.au/cgi-bin/pimp/pimp_server - DIRECT/202.125.163.43 application/octet-stream
192.168.17.5 requests are those that are proxied correctly and 192.168.8.140 are those that are not. I swear those requests to /cgi-bin/pimp/pimp_server weren't in the network capture before! Anyway, that's the offending requests that seem to break everything else.
Hopefully EyeTV 2.5.2 will have updated IceTV components that will proxy everything correctly (and whatever other networking dodginess that seems to be breaking things for people who aren't even using proxies). I also hope this info is of some use to IceTV in tracking down what seems to be wrong on their end.
As for me, I'm crossing my fingers my (now working) installation of EyeTV stays that way...
