New Emulator - No NZ Guide?

[hentaiboy]

Hi, just switched over to the new emulator and although my daily calls are getting through, I'm getting no NZ program guides (02113 - Sky Digital).

If I do a manual call through TivoWeb the whole thing is over in about 30 secs.

So...is there no NZ guide data on www.oztivo.net or has something gone awry?

[Skolink]

So...is there no NZ guide data on www.oztivo.net or has something gone awry?

No of course not. Stick to the NZ emulator 210.48.107.133:8000

[hentaiboy]

No of course not. Stick to the NZ emulator 210.48.107.133:8000
Cheers for that. For some reason I thought we were getting the data from Aus. Perhaps the Emulator move notice should have a "Not for NZ!" warning.

[petestrash]

It does start with "So far only 20% of OzTiVo's have moved", it mention OzTiVo three times and does not mention NZTiVo anywhere.

Sorry, you are the only one who has done this :o

Peter

[dyrplq]

Doh! I did exactly the same thing. No wonder my wife has been initiating manual phone calls for the last week or so when I have not been home!

Is the easiest way just to change the emulator back manually?

Phil from Wellington

[petestrash]

Depends on how you changed in the first place

Peter.

[dyrplq]

I ran update_oztivo -y

[petestrash]

Ok, so that means that you are running a 1.6.x image.

You need to edit /etc/oztivo.conf and change the emulator and emulator port.

Let me know if you need more detailed instructions.

Peter.

[Islander]

After reading the above posts it seems apparent to me that the update_oztivo -y process does not check the country that the TiVo resides in.
Can the update_oztivo -y be modified to enable use in both countries so that it changes emulator settings only when required?

[petestrash]

Don't forget the OzTiVo image was made by Australians for Australians. We were asked if we could include the NZ emulator and special postcodes when we released 1.6, which we have happily done. But for all intensive purposes the rest is designed for use in Australia.

Some people in NZ modified our 1.5 image to work just in NZ, and I believe New Zealanders have been asked to use this NZ image instead of the newer OzTiVo release.

Basically for the moment anyone in NZ running OzTiVo 1.6.x should consider update_oztivo as not for them, hence the 'oztivo' in the name ;)

If someone wanted to setup an NZ rsync server and maintain it, I could easily make a new file called 'update_nztivo' instead and have the update code changed to point to a NZ server.

Though this new file would have to be manually transferred to your TiVos, as running update_oztivo to pick it up will change your settings again.

To include NZ on the existing server would mean setting up a separate NZ section on maxie, I would prefer not to maintain two rsync areas with different needs. One is confusing enough :-)

Peter.

[Islander]

Apologies for misunderstanding the complexities of the update process.
My thoughts were only that if the oztivo_update process was intelligent enough to check the postcodezone in use on the target TiVo then act accordingly for the country of use this process could be of use to both countries as it has been (as far as I am aware) until now.

[petestrash]

We did not know that any New Zealanders were using update_oztivo.

It has no intelligence, all it does is run standard rsync which checks for any new or different files on our server. The ones that are different are then downloaded to the TiVo.

This does not effect most configuration files as they can be different for each TiVo regardless of country.

It should be safe to use update_oztivo, once you have the current version which points to the new server. But I can't make any promises that an update we make in the future on the OzTiVo server won't break a NZ TiVo.

To be safe, either forget about the update command or wait for someone to setup a NZ rsync server as previously advised.

Peter.

[dyrplq]

Thanks for the replies Peter. I manually changed my config back last night, rebooted, and forced a call. All ok. Will monitor for the next few days but don't expect any issues.

Phil (in Wellington)

[Skolink]

We did not know that any New Zealanders were using update_oztivo.

It has no intelligence, all it does is run standard rsync which checks for any new or different files on our server. The ones that are different are then downloaded to the TiVo.

This does not effect most configuration files as they can be different for each TiVo regardless of country.

Peter.

That might explain the port set to 909000 in oztivo.conf in the last two NZ TiVos I set up. I ran update_oztivo -y before GS. I wrongly assumed that it pulled the files off what ever emulator address had been selected eg Hydra for NZ.
I also assumed it could not partially update a file eg, change the port but not the emulator or MAC address in oztivo.conf, is that true?

[petestrash]

Yes, it now makes sense.

I couldn't find any file that was causing your issues. I didn't realise that you also ran the update_oztivo command. I thought you only ran the installer update.

The update loads a new file to fix the server and port. It looks for '80' in the Port and then replaces it with 9090. But in your case you had 8000, so it only replaced the first 2 digits leaving 909000.

Mystery solved.

As for the second part, like I said earlier, update only runs rsync to get the newest files. In this unique case we added a new file to be run on boot and then delete itself. This file looks in a few places and replaces 'minnie.tuhs.org' with 'www.oztivo.net', '131.244.9.101' with '65.49.60.197', and emulator '80' with '9090'. Unfortunately the NZ emulator is 8000, so it was changed to 909000. Again we never thought a person in New Zealand would run update-oztivo.

Peter.

[ianjf2000]

I too am having problems!

No listings due to failed daily calls. Last successful call made on 28th June 2008. Hence no daily listings.

Running a Thomson PVR10 with an NZ Tivo 1.5 image for the Thomson.

Any ideas how to fix please? Have been reading this thread and i'm a little stuck.

Regards, Ian

[ianjf2000]

ok the thomson is actually running version 1.3

[petestrash]

Did you change to the Australian Server?

Peter.

[ianjf2000]

OK! I found the information on 1.3 on this link:

http://www.oztivo.net/twiki/bin/view/Network/MoveFromMinnieToOzTivoNet

Very helpful page.

On my Mac, i booted up terminal, then went:

telnet 10.0.0.9

Up came the Tivo. Then did this:

rw
cd /etc
cp tclient.conf tclient.conf.minnie
sed 's/::131.244.9.101/::210.48.107.133/' tclient.conf.minnie > tclient.conf
diff tclient.conf tclient.conf.minnie
cd /etc/rc.d
cp rc.sysinit.author rc.sysinit.author.minnie
sed 's/131.244.9.101/210.48.107.1337/' rc.sysinit.author.minnie > rc.sysinit.author
diff rc.sysinit.author rc.sysinit.author.minnie
ro
reboot

And it is now working a treat! Succesful daily call made and downloading the listings. These things seem to be bullet proof! Thanks for putting up the info.

[petestrash]

Can you answer my original question, give us some background as to how this occurred.

It is very strange that this worked for you.

Because if you had changed to the new Australian emulator by mistake, then the sed commands should not have replaced anything, as the IP should have been for the new emulator (65.49.60.197), not the old OzTiVo 131.244.9.101 you have shown.

I would like to know how this happened to stop it occurring for others, and be sure you have fixed everything and won't have trouble down the track.

Peter

[DJC]

As an aside, I'll get a tivo message out to ensure no other coversions take place from NZ.

[ianjf2000]

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.

[petestrash]

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

[ianjf2000]

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

[catdog]

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?
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

[petestrash]

Agreed,

Peter.

[mpnash]

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.

[petestrash]

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.

[mpnash]

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.


So I'm guessing if the postcode file is unchanged, then this part should be OK...?




My current priority is to get a new image out (which also supports NZ better).


Legend!




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]:

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

[petestrash]

So I'm guessing if the postcode file is unchanged, then this part should be OK...?

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



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.

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.

[mpnash]

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.


Thanks Peter and catdog (for the offline help). I'll tell my bro to let the downloads begin....