Results 1 to 5 of 5

Thread: Failed while negotiating (N17)

  1. #1

    Failed while negotiating (N17)

    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.


  2. #2
    Join Date
    Nov 2017
    Melbourne, Victoria
    Quote Originally Posted by peterb View Post
    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 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?
    Last edited by DavidKeegel; 23-01-2018 at 11:45 PM. Reason: add technical details about checking tclient log

  3. #3
    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 send=/var/tmp/HServer.send recv=/var/tmp/HServer.recv
    Jan 24 07:43:32 (none) CommGlobals[3510]: 6 HServerRqst status=none 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
    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

    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_REA SONCODE=4&IDB_SW

    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.

  4. #4
    Join Date
    Nov 2017
    Melbourne, Victoria
    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_REA SONCODE=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%2 C120868516%2C120868544%2C120868558%2C133133040%2C1 33133043%2C116352152%2C116352162%2C133133036&IDB_S HOWCASES=showcase0-0&IDB_INVFILE=&IDB_WAITCOUNT=0&IDB_TCINFO=:hd.ozti 21000001-14|&IDB_IRDBVERSION=542&IDB_GENREVERSION=139&IDB_L OG

    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.)

  5. #5
    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.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts