UNC Path Specification Problem/Bug??

[zoundz]

Some of you may have seen my post in the Hardware section concerning a sudden jump in CPU utilization that appeared to be coincident with installing the HDHR 20090415 drivers and firmware. Not So Sid!!!

There is a problem with UNC paths. This may already be known (I couldn't find anything about it), but if not it needs to be looked into. I am running 6.5.9 as a service on WinXP SP2. For a number of reasons I decided that I would change my recording directory specifications from explicit drives on the machine to UNC paths, even though the drives are on the same machine. The service is already set up to access UNC paths on my network and has no problem with them.

Here's the problem:
If I specify my recording directories as \\MachineName\Sharename, the CPU utilization of my system goes sky high when it is recording clear QAM from the HDHR. It has never had a CPU problem recording 2 shows in the past, but with the directories specified like that, it can't successfully record 2 HDHR streams. If I change the spec of the directories to \\<ip address>\Sharename, the problem goes away.

IOW \\Livingroom\Recordings as a recording directory has high CPU from the HDHR. \\192.168.29.103\Recordings works just fine.

I'm not sure if this is a crock in the HDHR BDA drivers or in SageTV, but it does appear to be an actual problem.

Took me a bunch testing to find this one.

[mayamaniac]

Do you have Netbios installed in the LAN properties? If not, try installing it. In my experience, normally it is not needed but it does resolve some name server problems.

[zoundz]

Originally Posted by mayamaniac

Do you have Netbios installed in the LAN properties? If not, try installing it. In my experience, normally it is not needed but it does resolve some name server problems.

Could you clarify how that would help in this situation. There was no problem resolving the names. It found the shares just fine. The problem is that for whatever reason, either something in the SageTV handling of the share or the HDHR BDA driver, there is excessive CPU time involved in writing the file when the share is specified with the computer name rather than the IP address. The machine names are available both in the hosts file and as network browser entities. The heavy CPU usage seemed to be in the "system" as opposed to the SageTV service, so I suspect it may be something in the HDHR drivers. I reverted my HDHR all the way back to 20081231 for a test and also to 20090215 and it made no difference. I am left wondering why the share spec would have any effect after the file was created and opened. Yet the fact is clear that changing it from \\computer name\sharename to \\ip address\sharename solved the problem.

[mayamaniac]

I always install the latest beta SageTV and latest official HDHR driver and have been using UNC paths for years without issues. So I'm not sure why SageTV or HDHR is giving you problems, if it is in fact related to the two sofwares.

But what I'm sure of from years of experience is that Windows workgroup networking can exhibit strange behavors. And in some cases, enabling NetBios solves some of those issues.

[zoundz]

I'll give it a try and see what happens. I really don't like having the hard IP addresses in the UNC paths, even tho all my machines are hard coded IP's.

I'm still at a loss to explain to myself how the path to the file could or should have any effect once the system has created the file and opened a file handle. At that point, I wouldn't expect that the details of the path would have any consequence. Especially when these shares are, in reality, on the same machine as the software accessing them.

FWIW, I wouldn't have noticed this if my machine was faster, so your lack of problems may just be a case of superior hardware. The only reason this is or was a problem is because it pinned the CPU at 100% and caused data errors in the mpeg files.

[nyplayer]

Originally Posted by mayamaniac

I always install the latest beta SageTV and latest official HDHR driver and have been using UNC paths for years without issues. So I'm not sure why SageTV or HDHR is giving you problems, if it is in fact related to the two sofwares.

But what I'm sure of from years of experience is that Windows workgroup networking can exhibit strange behavors. And in some cases, enabling NetBios solves some of those issues.

Mayamaniac,

I just happened to be reading this thread. Doing what you suggested helped me out with resolving some issues I was having resolving server names. It was sorta hit and miss. I enabled netbios on server and clients and its working great.

[zoundz]

Well shiver me timbers, call me an unkeys monkle, land 'o goshen, whooda thunk it. Installing the IPX/SPX Netbios protocol actually seems to have solved the problem. Thanks Mayamaniac for the suggestion. For the life of me, I am still mystified as to WHY there is a problem with the share once the file is created and opened, but that's another deal.

Verrrrrrrry interesting........but weird..