As an aside, I'll get a tivo message out to ensure no other coversions take place from NZ.
Printable View
As an aside, I'll get a tivo message out to ensure no other coversions take place from NZ.
Hiya,
Well to put it simply. Tivo started to loose tv listings over the last couple of days. Then today no listings came up at all - the wife complained!
So I jumped on the forum. I found out that my version on my Thomson which even though it says NZ Tivo 1.5 on start up, is infact version 1.3
So basing on 1.3, I scrolled down to the bottom of the page which has how to update your Tivo to the new server.
I copied and pasted the commands from the web in to terminal on my mac. I then changed the new address of the aus server to the nz one, did a reboot and forced a daily call. Hey presto, it just worked! (Just like a mac!)
I'm not fully clued up with Tivo, and did just take a chance to see if it would work. I guess I guessed right? It was as simple as that.
Ok, but prior to fixing it, did you already change to the new server by mistake?
Also did you use 131.244.9.101 as you have shown in your post or is this a typo and you actually you used 65.49.60.197, which is the new server. Because what you have posted shouldn't have made any difference. as the old address should not have been there.
Is it possible, you actually fixed it just by re-booting, and the rest was a red herring?
If someone who has changed by mistake does what you have posted it will not fix their TiVo.
Peter
Well, prior to the Tivo not working, I've never had to change anything like this before. I installed the Thomson image from a download and it's been happily working for the last year or so since I've had it. It's only when the listings stopped downloading and Tivo had made unsuccessful calls that I had to take action.
We did try several times to reboot the Tivo, but this made no difference. So really not sure whether what I did really fixed it, or whether it just decided to change after I did the reboot after the code fix?
The code I listed was the exact same code I typed in. Thanks, Ian
Your changes had nothing to do with the "fix" as the UK Thomson software doesn't even use the tclient.conf file (it gets the address from tclientUK.conf file). I guess it was just a coincidence that it all suddenly came right after a few reboots.
The important thing is that it is now all working again :D
Agreed,
Peter.
Sorry to open this can of worms again, but is there any reason why NZ'ers should not use the "update_oztivo -y" now?
After reading this thread, it seems that the only real problem might have been the port change (80 -> 909000), although maybe Peter has improved this? eg. replacing ":80:" with ":9090:" perhaps (or perhaps not?).
Were there any other inadvertent changes for NZ'ers?
If we know how to make sure that /etc/oztivo.conf and /etc/tclient.conf are correct, then I'm wondering if there is any other reason for NZ'ers *not* using "update_oztivo -y".
I had used it successfully on the 1.6.2 images (with appropriate excludes) prior to the minnie changeover without problems.
I have not made any changes to the update area, but some NZ specific changes are on the to-do list but I don't know how achievable it is in the long term. As you have said fixing the current port issue is not a problem. I am not the only one working on these files so others may not be aware what may effect NZ users as they are only concentrating on OzTiVo issues.
One difference that comes to mind is that NZTiVo have setup single headends for each type of broadcast with a made up unique postcode for each which are also the same as some real Australian postcodes (but right now this duplication does not matter). But it does mean that the postcodes file on each Tivo needs to updated to use these headends as new headends are added. Whereas we have mulitiple headends attached to a single postcode so our postcode file remains static and all the changes are only on the emulator.
My current priority is to get a new image out (which also supports NZ better).
Peter.
So I'm guessing if the postcode file is unchanged, then this part should be OK...?
Legend!Quote:
My current priority is to get a new image out (which also supports NZ better).
The reason I asked, is that I'm trying to (remotely) track down a problem with my bro's tivo failing to get EPG.
Last week we tried to move his box from old->new NZ emulator (80->8000). Since found out that we likely need to to a "Clear & Delete All" (ouch! - he wants to keep recordings), so decided to back-track and try and reinstate the port 80 setup.
In the meantime we had deleted all the program data (via TiVo menus), and did an "update_oztivo -y". We found/fixed the tclient.conf (and oztivo.conf) files but now trying to work if any other call-critical files were changed.
His /var/log/tclient (below, in part) suggests that the connection is OK - test call also works. However, nothing is actually downloaded (softwareList: NONE).
We've tried a range of things from re-doing GS (on new and old ports). No errors during call on old port 80, but nothing downloaded.
Any ideas what else we can look for/try? (Apart from extracting the 200GB of recordings and re-imaging?)
/var/log/tclient [port 80 call]:
Code:Jul 26 14:05:11 (none) comm[169]: Using Ethernet. Not starting modem/pppd.
Jul 26 14:05:11 (none) comm[169]: CallStatusReporter: Phase: Start_Auth,
Status In Progress
Jul 26 14:05:11 (none) comm[169]: CallStatusReporter: sending message "ST|33"
Jul 26 14:05:11 (none) comm[169]: CommUtil: connection to host
210.48.107.133, port 80, err 0x0
Jul 26 14:05:11 (none) comm[169]: Uploading HTTP Header for modLog of
/var/log/svclog: POST /tivo-service/mlog.cgi HTTP/1.0^M Content-Length:
1806^M ^M
Jul 26 14:05:11 (none) comm[169]: read HTTP Header: HTTP/1.1 200 OK^M
Date: Sat, 26 Jul 2008 02:05:12 GMT^M Server: Apache/2.0.54 (Mandriva
Linux/PREFORK-13.3.20060mdk) mod_ssl/2.0.54 OpenSSL/0.9.7g PHP/5.0.4
mod_perl/2.0.1 Perl/v5.8.7^M Connection: close^M Content-Type: text/plain;
charset=IS
Jul 26 14:05:11 (none) comm[169]: O-8859-1
Jul 26 14:05:11 (none) comm[169]: SvcLogRqst::verify: enter
Jul 26 14:05:11 (none) comm[169]: SvcLogRqst::verify:
unlink(/var/log/svclog.upload)ed (status = 0)
Jul 26 14:05:11 (none) comm[169]: couldn't stat input file, reason = No
such file or directory
Jul 26 14:05:11 (none) comm[169]: NetAgent::doXfer: open failed on Rqst :
No such file or directory
Jul 26 14:05:11 (none) comm[169]: drainGetPostQ: doXfer failed err=65535
(0xffff)
Jul 26 14:05:11 (none) comm[169]: Xfer Performance Log says errors are Ok!
Jul 26 14:05:11 (none) comm[169]: CommUtil: connection to host
210.48.107.133, port 80, err 0x0
Jul 26 14:05:11 (none) comm[169]: read 384 bytes of upload data for
FourOneOneRqst
Jul 26 14:05:12 (none) comm[169]: CommUtil: connection to host
210.48.107.133, port 80, err 0x0
Jul 26 14:05:12 (none) comm[169]: read 2075 bytes of upload data for
HServerRqst
Jul 26 14:05:12 (none) comm[169]: HTTP header: HTTP/1.1 200 OK^M
Jul 26 14:05:12 (none) comm[169]: HTTP header: Date: Sat, 26 Jul 2008
02:05:12 GMT^M
Jul 26 14:05:12 (none) comm[169]: HTTP header: Server: Apache/2.0.54
(Mandriva Linux/PREFORK-13.3.20060mdk) mod_ssl/2.0.54 OpenSSL/0.9.7g
PHP/5.0.4 mod_perl/2.0.1 Perl/v5.8.7^M
Jul 26 14:05:12 (none) comm[169]: HTTP header: Connection: close^M
Jul 26 14:05:12 (none) comm[169]: HTTP header: Content-Type: text/plain;
charset=ISO-8859-1^M
Jul 26 14:05:12 (none) comm[169]: HTTP header: ^M
Jul 26 14:05:12 (none) comm[169]: Start TCD411Resp =====================
Jul 26 14:05:12 (none) comm[169]: errMsg:
Jul 26 14:05:12 (none) comm[169]: areaCodeObj: OK
Jul 26 14:05:12 (none) comm[169]: tollFreeAuth: 0
Jul 26 14:05:12 (none) comm[169]: tollFreeNum:
Jul 26 14:05:12 (none) comm[169]: End TCD411Resp =====================
Jul 26 14:05:12 (none) comm[169]: current AreaCode object is OK
Jul 26 14:05:12 (none) comm[169]: HServerRqst::evaluate starting
Jul 26 14:05:12 (none) comm[169]: HTTP header: HTTP/1.1 200 OK^M
Jul 26 14:05:12 (none) comm[169]: HTTP header: Date: Sat, 26 Jul 2008
02:05:13 GMT^M
Jul 26 14:05:12 (none) comm[169]: HTTP header: Server: Apache/2.0.54
(Mandriva Linux/PREFORK-13.3.20060mdk) mod_ssl/2.0.54 OpenSSL/0.9.7g
PHP/5.0.4 mod_perl/2.0.1 Perl/v5.8.7^M
Jul 26 14:05:12 (none) comm[169]: HTTP header: Connection: close^M
Jul 26 14:05:12 (none) comm[169]: HTTP header: Content-Type: text/plain;
charset=ISO-8859-1^M
Jul 26 14:05:12 (none) comm[169]: HTTP header: ^M
Jul 26 14:05:12 (none) comm[169]: Start SvrResp =====================
Jul 26 14:05:12 (none) comm[169]: errMessage:
Jul 26 14:05:12 (none) comm[169]: version: 3
Jul 26 14:05:12 (none) comm[169]: code: 1
Jul 26 14:05:12 (none) comm[169]: softwareList: NONE
Jul 26 14:05:12 (none) comm[169]: backChannelPrv: NONE
Jul 26 14:05:12 (none) comm[169]: backChannelPub: NONE
Jul 26 14:05:12 (none) comm[169]: backChannelLog:
@http://210.48.107.133:80/tivo-service/acceptfile.cgi
Jul 26 14:05:12 (none) comm[169]: backChannelThumb: NONE
Not sure all the NZ codes are loaded, but we have the following for NZ in rync:
# New Zealand
02110 Pacific/Auckland
02111 Pacific/Auckland
02112 Pacific/Auckland
02113 Pacific/Auckland
02115 Pacific/Auckland
02116 Pacific/Auckland
02121 Pacific/Auckland
02122 Pacific/Auckland
02123 Pacific/Auckland
02124 Pacific/Auckland
For anyone else reading this thread, you should always run update_oztivo without the -y first (as shown in the instructions) this will show which files will be overwritten. If your happy to do this then run with the -y command.
As for your connection problems I think you have killed the TiVo :eek:
Once your TiVo has called the new(er) NZ server you cannot go back to the original. The only way I know to undo this ia a clear & Delete all, I don't believe anyone has succeeded any other way.
So, I suggest your friend starts watching/transferring shows. Then do the Clear & Delete All and stay on the new NZ server.
Peter.