02-19-2011 09:51 AM
Hi Accipiter,
You are most welcome. ![]()
If doing a fresh reinstallation of NIS does not do the trick I am going to request Symantec input on this. If and when you do see the live update failure again, please be sure to click on "View Summary" button before closing the live update window.
See if there is an error code listed there. I know you mentioned checking history for an error code and none was there. I'm hoping there might be a little more information in the live update dialog itself. Perhaps an error code or even some other wording to indicate more precisely what problem NIS encountered during live update.
Best wishes.
Allen
02-19-2011 10:35 AM - edited 02-19-2011 11:00 AM
Hi Accipiter,
One more thing to check and it is a bit of a long shot.
In the directory C:\Documents and Settings\All Users\Application Data\Norton do a search for Partial via Windows Explorer.
The last part of the path should be "Lue\Downloads\Partial".
Do a right click on the Partial directory and select Properties. The click the Security tab and look for System and Administrators in the list. Click on those entries and make sure they have full permissions.
Don't forget to configure Windows Explorer to display hidden files/folders as mentioned in the Spoiler tag in my previous post.
A logical test is to monitor this directory while doing a live update. During the download you should see one or more files appear in this directory while things are being downloaded during live update. If for any reason a live update session fails, there should be at least one file left in this directory which contains the "partial" update which has been downloaded thus far. If Live Update succeeds then the file gets removed at the end.
This is what gets used when you run a subsequent live update after a previous failure so that it knows where to pick up when it resumes the live update download.
If something is preventing NIS from writing into this directory then it could cause the problem you are seeing.
Again a long shot, but worth checking to make sure.
Best wishes.
Allen
02-20-2011 08:33 AM
Hello Allen
I displayed and monitored the empty Partial directory whilst I did an update, (Still on Smart Def at the moment) and saw one item appear and then disappear. History shows 4 successful updates. I assume then, if a failure does occur, I'll be able to look in Partial and see the failed item there until a successful LU takes place.
I will carry out a removal and reload, as discussed, and look at "View Summary" if there is a failure, but I want to arrange to do this at a time day when download time is free, as I've used a large part of my allowance for this month. I will get back to you once I've completed it.
I am though, beginning to wonder if what I perceive as a fault is just a function of how LU works. Although, I had two consecutive failures on LU after reinstalling NIS, there have been several occasions earlier, where LU failed on a small update, and then downloaded 90mb or so successfully when run again. I'm not absolutely sure, but these 90mb downloads only seem to happen after an unsuccessful one, regardless of its original size.
When you went back to a Ghost of 40 days old and interrupted LU with out causing an error, was the interruption of an xon/off type, because I would imagine my much slower line would regularly be doing this without trouble.
If on the other hand, a checksum or some other form of corruption were to occur, perhaps due to the long line between my PC and the exchange, then the download would fail. If that is the case, what is LU is designed to do on its rerun? Is it just going to attempt to rerun the files that were not successful the first time, along with any new updates, or is that a trigger that causes it to do a full reload?
If I had a fast line with say a 10 or 20 gig limit, I doubt that I would have noticed a 90mb update every few days.
What do you think?
Regards,
Accipiter
02-20-2011 09:31 AM - edited 02-20-2011 09:33 AM
Hi Accipiter,
Though larger updates definitely occur from time to time, what you describe happening I don't view as normal. You are specifically stating that when a live update fails, it immediately (and every time) wants to download 90MB or so on the next live update session.
What I did with my testing is to turn off my wireless adapter during the middle of live update which causes NIS to time out after 20 seconds or so with no more received data.
The download protocol should be able to handle errors during transmission and retransmit either missing packets or packets with too many bit errors. I suppose it is possible that excessive bit errors could be triggering this but the protocol should be able to handle it.
You could do some independant download tests during your unlimited hours and see what kind of errors you get and how many retransmissions are occurring.
I don't really have a way to reproduce bit errors unfortunately.
And Yes it is true that with a higher speed connection one likely won't notice larger downloads like this. I know I wouldn't unless I happened to be watching at the time.
Best wishes.
Allen
02-20-2011 10:33 AM
AllenM wrote:Hi Accipiter,
Though larger updates definitely occur from time to time, what you describe happening I don't view as normal. You are specifically stating that when a live update fails, it immediately (and every time) wants to download 90MB or so on the next live update session.
[ ... ]
Allen -- FWIW and I can't give a link or even which Norton product it was but I have a clear recollection of some posts in the past about apparently getting stuck on a repeated cycle of 90MB downloads and I thought it had been fixed ...
02-21-2011 03:19 AM
Hello Allen and Hugh
With regards to your most recent reply, I am not specifically stating anything. It's just that I notice that a complete update seems to occur when running LU again after a failure. I did say that I'm not absolutely sure it happens every time, but it certainly has happened on several occasions.
What I wondered was this: if during an LU corrupt data was received, (rather than just flow control) would LU just update the corrupt packet, or download everything from scratch. Those who designed the programme presumably know whether that's the case or not.
I'm not a heavy user of the internet, but when I do download programmes and updates from all other sources, which is fairly often, I very rarely get any errors. My connection is not fast, but it appears to be stable.
However, I wanted to let you know that I have this morning followed your notes exactly. I uninstalled NIS once again and rebooted. I ran Norton Removal Tool twice, rebooting each time. I went into the root path and deleted the specific folders you requested. (I didn't find any others). Installed NIS 2011, downloaded from the internet earlier, and ran LU. The full update was successful, so I am back with the full set of definitions (default setting).
It's now a waiting game to see if the problem recurs, but I'll let you know how I get on.
Thanks once again for all the trouble you have taken to help me.
Kind regards
Accipiter
02-21-2011 07:37 AM
HI Accipiter,
The problem may have to do with some sort of errors occurring during the download. However the download protocols calls for resending packets if it is not received correctly due to either bit errors which causes the checksum to be wrong, or a lost packet which simply does not arrive.
On even the cleanest of lines, packets are going to occasionally get lost, this is inherent in the IP transport.
If this problem continues after you having gone through the reinstallation and using the removal tool I am going to request Symantec input on this.
Best wishes.
Allen
02-21-2011 07:41 AM
Best of luck .....
02-24-2011 04:31 AM
02-24-2011 08:36 AM
Hi surfer1000,
How are you determining the size of the download?
Best wishes.
Allen
