Workaround for Sentinel "The underlying connection was closed."

[wallymaven]

I've read through the posts regarding this error and not found that anyone has posted a solution or workaround.

"Update full database failed.
Operation cancelled
The underlying connection was closed. An expected error on receive."

As a programmer and network engineer I can state that the problem is clearly a bug in the Sentinel software as my workaround below demonstrates, without fail. DSL has been blamed but I've proved that DSL is not the problem.

1) Using Windows File Explorer open C:\Documents and Settings\All Users\Application Data\Uniden\BCDx36HP_Sentinel\Updater
2) Start the Update by going in your Sentinel software to Update / Update Master HPDB...
3) Look at the Explorer Window and you'll find a new file named MasterHpdb_[date].gz.tmp file that starts getting updated. Hit F5 a couple of times to do a refresh and you will see it growing in size.
4) Single-click this file to select it and press CTRL-C
5) Press F5 and watch the file size. As it approaches 8,000KB just start pressing CTRL-V every few seconds. You will notice the file stops growing around 8,900KB (as of this date). If the file is somewhere this size or larger, it is almost certain that the file has downloaded just fine.
6) Let Sentinel error out and it will erase the gz.tmp file. Answer OK to the error dialog and quit Sentinel.
7) Rename your Copy of the file to MasterHpdb_[date].gz
8) Restart Sentinel and let it rebuild the database.

I've been using this workaround for almost a year now with no troubles. The problem is clearly in Sentinel at the point where it should recognize the end of the transfer.

 

[Voyager]

And this proves it's not a network issue how?

All it seems to prove is that there is a network issue with closing the transfer. The fact that you can prove you received a complete file does not prove anything other than the issue happens at the end of the transfer.

I'm not saying it isn't a Sentinel issue. But, I've read where others got 'around' errors by lowering their security settings. Maybe it's a Windows bug that doesn't accurately convey the end of file info to Sentinel.

Or maybe it's a server issue not sending that info.

When there are at least 10 hardware/software obstacles to go through, I just don't see how you can blame the last one in line simply because it's the last one in line. (10 being source SW, source OS, source HW, source modem, internet, at least one switch - likely many, destination modem, destination HW, destination OS, destination SW)

 

[wallymaven]

> And this proves it's not a network issue how?

Because 1) the network file transfer works perfectly fine 100% of the time, the only problem being Sentinel fails to properly recognize that fact a single time. 2) Because I've sniffed the Network traffic and there is nothing abnormal yet Sentinel fails to handle the end of transfer properly. 3) Because I've tested it on 3 different ISPs and all had the same problem. 4) Because I mirror massive amounts of data every day on the same Network, using the same switches, modems, computers etc. from a wide variety of servers, and do not have any other problems. I wonder why you care to argue the fact when I've worked with this for over a year. As a friendly note please allow me to recommend #9 here The RadioReference.com Forums - Announcements in Forum : Uniden Software Discussion

 

[KevinC]

Rather odd, I've updated the database on numerous computers over the years via several ISP's and nerver experienced this error. You'd think if Sentinal had an issue this problem would be more widely reported.

 

[wallymaven]

> Rather odd, I've updated the database on numerous computers over the years via several ISP's and nerver experienced this error.

I agree completely. It may be Winsock version dependent. After the transfer, it appears Sentinel is looking for something else besides the file or is making a call that perhaps throws an unhandled exception -- that is, unhandled within the download routine. The exception appears to be handled at the application level. I could put Sentinel in a Win32 API capture environment and might be able to get an idea but it isn't worth my time -- and may not be legal either! I think the easier route is to have someone review the source. I suspect the problem would be easy to fix, having done a boat-load of Winsock and WinINet programming for the last 15 years.

I should add, I've produced commercial software with tens of thousands of customers, that uses Winsock and these kinds of "works here but not there" scenarios are not uncommon with Windows. They didn't call it DLL hell without good reason. These kinds of problems can be tracked down but it takes some effort.

I have my workaround which keeps my scanner up to date and I hope it will help others facing the same problem.

 

[Voyager]

> And this proves it's not a network issue how?

Because 1) the network file transfer works perfectly fine 100% of the time, the only problem being Sentinel fails to properly recognize that fact a single time. 2) Because I've sniffed the Network traffic and there is nothing abnormal yet Sentinel fails to handle the end of transfer properly. 3) Because I've tested it on 3 different ISPs and all had the same problem. 4) Because I mirror massive amounts of data every day on the same Network, using the same switches, modems, computers etc. from a wide variety of servers, and do not have any other problems. I wonder why you care to argue the fact when I've worked with this for over a year. As a friendly note please allow me to recommend #9 here The RadioReference.com Forums - Announcements in Forum : Uniden Software Discussion

#9 doesn't apply. I'm asking how you know. You answered. If anything, #9 applies more to your post in your self-appointed moderator role.

Your admission that it could be a Winsock issue (or issue with that version communicating with Sentinel) validates my question.

 

[wallymaven]

> Your admission that it could be a Winsock issue (or issue with that version communicating with Sentinel) validates my question.

Sir, the Network (ISP through to Ethernet cable) and the network API of an O/S are not the same thing. My original post cites folks blaming DSL and the ISPs. It is not the Network as I originally stated. It is almost certainly wrong coding associated with the Winsock or WinINet API. Thank you for allowing me to clarify my point.

 

[Voyager]

Anytime, but in my original reply I did cite as possible causes in addition to the internet/network: "destination OS, destination SW"

So I am aware that the network and OS are different things, as are the 8 other things I mentioned. The OS can be broken down into many parts, too. I was just making the point that the breakdown could be anywhere in any of those (many of which you eliminated with your follow-up reply).

I didn't cite the LAN possibility since it is optional, and you could connect a PC directly to the modem. But of course LAN is different from the internet. I'm sure I'm not saying anything you don't well know here.

Not trying to be argumentative. Just trying to understand what was found. I think we agree that it's somewhere in the OS/SW section of that list.

 

[wallymaven]

10-4

 

[nr2d]

I've never had a problem updating the Sentinel database since I bought my first BCD536HP.