Failed while negotiating (N17)

[peterb]

Hi, I have a New Zealand TiVo that was converted over in November and received guide data correctly up to 29 December. Since that date, the connection to the TiVo service fails at "Negotiating the connection", with a "N17" error message.

If I go to the Network Diagnostics and choose Tivo Service connection, this succeeds, but of course gets no guide data.

The DialInCode is 140 and the country is NZ.

I've tried restarting several times, and also tried connecting from a friend's house (the person who converted my Tivo) with a different ISP.

Other things I've tried include "Clear program information & To Do list" and checking the file space (telnet into the tivo and used the df command) which seems ok.

A couple of weird things I've observed are:

1. The time on my Tivo is 2 hours out (in the past). I tried manually setting the time using settime, but connecting to the Tivo service still failed and afterwards the time was set back again. I did notice in the tclient log file that "timeZoneOffset" is 36000 (10 hours) - should be 13 hours for NZ.

2. Looking through the log files, most of those starting with "O" end shortly after 5:30 am (UTC) on the 29th of December which was the time of the last successful connection so something seems to have made the Tivo roll its logs at that time.

Below is an extract from tclient showing a failed connection attempt:

I'd appreciate any ideas on what could be going wrong or pointers on where to look in the log files.

Thanks,
Peter.

[DavidKeegel]

Hi, I have a New Zealand TiVo that was converted over in November and received guide data correctly up to 29 December. Since that date, the connection to the TiVo service fails at "Negotiating the connection", with a "N17" error message.
...
The DialInCode is 140 and the country is NZ.

1. The time on my Tivo is 2 hours out (in the past). ... I did notice in the tclient log file that "timeZoneOffset" is 36000 (10 hours) - should be 13 hours for NZ.



That time (or more to the point, time zone offset) being wrong seems like a significant clue. That suggests to me that the oztivo mothership emulator is not being told/understanding that your tivo is in NZ, so it is defaulting to Vic/NSW/Tas timezone (that is a thing that hd.oztivo.net does, if does not recognise the location as NZ, WA, SA, NT, Qld). The timeZoneOffset ought to be 43200 for NZ, because it does not include the hour added for summer time. The thing to look for in tclient.log is where there are log entries about HServerRqst do they include &IDB_COUNTRY=NZ? Posting the output of grep HServerRqst /var/log/tclient would probably be helpful.

If we can't come up with a better plan, maybe it is worth doing a guided setup on this tivo to make sure it clearly identifies itself as NZ. I am a little wary of guided setup in general though, because if your networking etc is not working properly, you can end up in a loop of guided setup (if the guided setup fails, you have to do another guided setup, you can't abort). If that happens and you can't fix the networking problem (or whatever is making guided setup fail) and it doesn't fix itself afer a few guided setup attempts then I don't know any better way to recover than wiping the hard disk (restoring a clean image onto the hard disk), which means losing recordings, season passes, etc unless they were on the image you restored from. So do a backup on your hard disk before trying guided setup, m'kay?

[peterb]

Thanks for your help David.

Apologies for omitting the log info in my last post. It was too long to post a whole call and I didn't know which part was significant. Here's the result of grep HServerRqst /var/log/tclient for the last call:

Jan 24 07:43:27 (none) CommGlobals[3510]: 6 HServerRqst status=none addr=hd.oztivo.net:8000 send=/var/tmp/HServer.send recv=/var/tmp/HServer.recv
Jan 24 07:43:32 (none) CommGlobals[3510]: 6 HServerRqst status=none addr=hd.oztivo.net:8000 send=/var/tmp/HServer.send recv=/var/tmp/HServer.recv

No mention of &IDB_COUNTRY=NZ at this point.

Interestingly back on Jan 22, there are a lot more HServerRqst entries including this one:

Jan 22 11:02:01 (none) HServerRqst[5978]: ,69701,69702,66563,68075,69482,68024,68025,47,46,6 8026,68412,68023,68022,68172
,68173,68190 NAG_NOTICE= NAG_WARN= NAG_CRITICAL= CLIPS_BACK=2 DOG_DELAY=28800 TIMEOUT=270 EPG_ID_TYPE=2 TZ_NAME=Australi
a/Sydney TZ=36000 DST=1 DST_PERIODS=16712:7200:16894:10800:17076:7200:1725 8:10800:17440:7200:17622:10800 AC=000 BACKUP_D
NS=8.8.8.8|8.8.4.4

which does seem to show that the timezone is wrong and a few entries up:

Jan 22 11:02:01 (none) HServerRqst[5978]: nSend=1300: IDB_VERSION=3&IDB_CENTERID=663000190211A30&IDB_REASONCODE=4&IDB_SW
DESC=NONE&IDB_LOCATIONID=NONE&IDB_SEQCOOKIE=12345678&IDB_HEADEND=NONE&IDB_ST_HIST=&IDB_ST_WORST=&IDB_SHOWCASES=NONE&IDB_
INVFILE=&IDB_WAITCOUNT=&IDB_TCINFO=&IDB_CURCODE=&IDB_MESSAGE_DESC=&IDB_IRDBVERSION=&IDB_GENREVERSION=&IDB_LOGOVERSION=&I
DB_AFFILIATIONVERSION=&IDB_SHOWCASEVERSION=&IDB_COUNTRY=&IDB_LANGU

I guess showing it doesn't know I am in NZ.

I noticed in another thread Kandels appears to have a very similar problem and trying a Guided Setup got him stuck in a loop, so doesn't seem promising. If I do it I'll do a backup first.

[DavidKeegel]

Here is what a working Australian (Victorian) HServer request looks like in tclient :-

Jan 19 22:45:50 (none) HServerRqst[1998]: nSend=2456: IDB_VERSION=3&IDB_CENTERID=66300018021F312&IDB_REASONCODE=1&IDB_SWDESC=379347214-2|379343778-2|379343803-2|379343833-2|379343843-2|379343861-2|379343851-2|145412331-2|145412331-2|113185780-3|113185790-3|113185816-3|113185824-3|113306491-3|116115226-5|116115231-5|116115243-5|122002622-3|125700273-3|&IDB_LOCATIONID=3133-236&IDB_SEQCOOKIE=12345678&IDB_HEADEND=006:00001-175
Jan 19 22:45:50 (none) HServerRqst[1998]: 50&IDB_ST_HIST=006:00001:17550-195%2C17552-51%2C17553-557&IDB_ST_WORST=006:00001:120868434%2C118603023%2C120 868516%2C120868544%2C120868558%2C133133040%2C13313 3043%2C116352152%2C116352162%2C133133036&IDB_SHOWCASES=showcase0-0&IDB_INVFILE=&IDB_WAITCOUNT=0&IDB_TCINFO=:hd.oztivo.net:8000:::::&IDB_CURCODE=140&IDB_MESSAGE_DESC=21000001-14|&IDB_IRDBVERSION=542&IDB_GENREVERSION=139&IDB_LOG
Jan 19 22:45:50 (none) HServerRqst[1998]: OVERSION=819&IDB_AFFILIATIONVERSION=106&IDB_SHOWCASEVERSION=&IDB_COUNTRY=AU&IDB_LANGUAGE=enGB&IDB_DEMOMODE=&IDB_CUR_SWNAME=11.3b10.2017.10.11-1506-01-2-Z-663&IDB_APG_ONLY=&IDB_USECHKSUMS=TRUE&IDB_PREMIUM_SHOWCASES=&IDB_CAPTURE_REQUESTS=&IDB_MENU_ITEMS=&IDB_COLLAB_DATA=&IDB_SIGNED_FILES=&IDB_SPIGOT_MAPS=&IDB_OTHER_DATASETS=MO_standard-0|HDGenre-14|DI_DriveInfo-27|DiskConfigurationVe

I'm concerned about IDB_LOCATIONID=NONE IDB_HEADEND=NONE IDB_COUNTRY=
The Sydney timezone, time offset etc are consequences of having no country.

In your case, I think a guided setup is the right thing to do (unless you know some better way to set your country and location on a tivo). I don't think you have any connection problems which aren't explained by having no country, location or headend. (No headend means no linueup to get guide data from.) So I don't think you will get into a GS loop. But doing a backup is a good precaution, if you don't want to risk losing recordings etc. (And for anyone not peterb if you have unexplained connection problems, then do a backup before guided setup unless you are happy to restore from a fresh image with no recordings if you get stuck in a GS loop.)

[peterb]

After copying all my favourite recordings off, I did a guided setup, but although this did set the location, country and time zone correctly (confirmed by looking in the log) it still failed when it got to the point of connecting to the Tivo service to get the guide data, so I don't know what the problem was. As it was then stuck in a guided setup loop, I then had to get my friend who converted my Tivo and had a partial backup to restore that and re-apply the hack, which worked and I also didn't even lose my recordings. The Tivo now connects to the service with no problems.

He said he chose the option to use the full hard drive when doing the restore and the Tivo had to reboot a couple of times, but then came up fine.