Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[RoderickGI]

Unfortunately, it doesn't because I've had a number of cases during this period where TV suddenly worked fine for some period of time.  Sometimes just for a few minutes while testing and sometimes I was able to get a random good recording.

WMC polls tuners for EPG data, and at other times I believe. Maybe when it isn't doing this, perhaps after a recent EPG download, you get a good recording. When WMC is running on the network, and MC is recording, it could interfere.

I've always understood the BDA Compatibility setting to be a per-PC setting.  SiliconDust sets up a virtual BDA driver on each PC that serves up access to the tuner.  That is where the compatibility mode gets switched.

Are you sure about this? Over on the Kodi forum one poster was saying that they have uninstalled the SiliconDust software from all Client PCs and only left a copy on their workstation to do firmware upgrades. That would imply no driver on the individual Client PCs. Maybe because Kodi uses the Default BDA Compatibility mode it is different. These are HDHomeRun Prime tuners, correct? Or at least network tuners?

Regarding firmware updates to the SiliconDust tuners, I hadn't touched the firmware in well over a year until the problems started.  One of the steps I took a few weeks ago was to update the SiliconDust firmware and software to the current version on all tuners and all of the PC's that access the tuners.

There is a new August 15, 2017 firmware. It has a lot of new stuff in it, including "Improvements to system logging and diagnostic logging". Perhaps get that, and start looking closely at the diagnostic logs.

I could theoretically shut the 2 WMC PC's down for a few hours in the middle of the day sometime this weekend while nothing is scheduled to record

I think that there is enough evidence to warrant this testing. Either that or break your pool into two, one for JRiver and one for WMC. You need to test MC without WMC trying to use, or having access to, any of the same tuners.

One other thing I can try is to reconfigure JRiver to make use of some OTA PCIe tuners I have installed in that PC

That would only prove MC is capable of recording with PCIe tuners. My system does that fine. I guess if it didn't work it could indicate a problem with your source signal, but you are confident about that.


Mind you, I am not totally convinced that MC doesn't have some issues with recording quality. There have been enough reports of issues to be suspicious, and I have seen some very minor pixelation in a few of my recordings, mostly at the beginning. But I have no way of knowing if that was an electrical spike, lightning, the neighbour runnings a large electric motor, something else on the PC, or MC. However, an awful lot of the reported problems just go away after some time and a lot of unanswered diagnostic questions. So testing in such a way to isolate the problem helps all future users who see something similar.

[greynolds]

WMC polls tuners for EPG data, and at other times I believe. Maybe when it isn't doing this, perhaps after a recent EPG download, you get a good recording. When WMC is running on the network, and MC is recording, it could interfere.

Huh?  Do you have a reliable source to back this up?  I've never heard anything about WMC polling tuners for EPG data and there's no need for it to as WMC gets its EPG data from a web service that it downloads from daily.  But in order for it to retrieve data from a tuner, it would have to actually tune to a channel which would show up as a connection in SiliconDust's Config app.  I can assure you that I've checked the SiliconDust software numerous times to be absolutely certain that nothing other than JRiver is accessing a tuner when running tests.

Are you sure about this? Over on the Kodi forum one poster was saying that they have uninstalled the SiliconDust software from all Client PCs and only left a copy on their workstation to do firmware upgrades. That would imply no driver on the individual Client PCs. Maybe because Kodi uses the Default BDA Compatibility mode it is different. These are HDHomeRun Prime tuners, correct? Or at least network tuners?

I'm not absolutely positive, but I'm pretty sure it's a per-PC setting.  Anything else wouldn't make any sense as the tuners are designed and intended to be shared with multiple devices within a home network and not tied to just one dedicated purpose.

My SiliconDust tuners are a mix of OTA (a mix of 2 x DUAL and 3 x Connect models, for a total of 10 tuners) and CableCard (3 x Prime models, for a total of 9 tuners) devices.  All SiliconDust tuners are network tuners.

There is a new August 15, 2017 firmware. It has a lot of new stuff in it, including "Improvements to system logging and diagnostic logging". Perhaps get that, and start looking closely at the diagnostic logs.

That's the firmware version I updated to recently.

I think that there is enough evidence to warrant this testing. Either that or break your pool into two, one for JRiver and one for WMC. You need to test MC without WMC trying to use, or having access to, any of the same tuners.

You can't really break the pool into 2 other than telling each PC to only use certain tuners and configuring the order each PC makes use of the tuners.  As I've said before, I've gone to great lengths to make sure that the 3 PC's using the tuners access them in different orders to minimize the chance of a conflict.

I will run a test with the WMC PC's physically disconnected from the network (unplugging the network cables will be more convenient than shutting them off and should be sufficient), but I need to find a convenient window to do so while I'm awake and not otherwise occupied that won't result in any lost recordings.

That would only prove MC is capable of recording with PCIe tuners. My system does that fine. I guess if it didn't work it could indicate a problem with your source signal, but you are confident about that.

If it didn't work, it would confirm that the issue is something very specific to the JRiver installation, though I'm still leaning toward that being the case.  For the heck of it, I ran the test this afternoon, switching back and forth between enabling and disabling one of the PCIe tuners (so switching back and forth between using a SiliconDust tuner and a PCIe tuner).  I consistently got bad results when using the SiliconDust tuner and consistently got good results when using the PCIe tuner.  This at least tells us that a good chunk of the JRiver functionality is working OK, but we have seen in the past that JRiver has had to make changes to resolve issues working with specific tuners.  If I had seen the same problem with both tuner options, that would have been good in some respects as it presumably would have narrowed the scope of the problem significantly.

Mind you, I am not totally convinced that MC doesn't have some issues with recording quality. There have been enough reports of issues to be suspicious, and I have seen some very minor pixelation in a few of my recordings, mostly at the beginning. But I have no way of knowing if that was an electrical spike, lightning, the neighbour runnings a large electric motor, something else on the PC, or MC. However, an awful lot of the reported problems just go away after some time and a lot of unanswered diagnostic questions. So testing in such a way to isolate the problem helps all future users who see something similar.

Quite frankly, I'm not at all convinced that MC doesn't have some issues with TV recording that are relevant here.  Given that 1) WMC recordings have been nearly perfect (minor glitches are to be expected with broadcast and cable TV signals) all along and 2) the SiliconDust Viewer app works perfectly fine on the JRiver PC I'm having a really hard time believing that the issue could be anything but JRiver.  Of course, I was asked to disable logging in JRiver as a diagnostic step, so I've got no JRiver logs to work with though I'm not sure how much info is in those logs that would be useful here anyway.

I just checked the logs for all of the SiliconDust tuners.  There really isn't a lot of detail in those logs, but of significance there are no errors other than a few rejecting a request for a tuner because all tuners were in use from when I ran the big test yesterday ("20170902-00:59:40 HTTP: rejecting request from 192.168.1.206 - all tuners in use").  Here's a sample from the first CableCard tuner I have configured for JRiver to use (192.168.1.205 is one of the WMC PC's and 192.168.1.206 is the JRiver PC; requests for tuners from .205 only got to this device because I was making use of ALL the tuners for the big test last night):

Code: [Select]

20170902-00:40:46 Tuner: tuner2 tuning 553 FX HD (EAST) (auto:861MHz-727)
20170902-00:40:46 Tuner: tuner2 streaming rtp to 192.168.1.205:5003
20170902-00:40:47 CableCARD: tuner2 553 FX HD (EAST) (auto:861MHz-727) access = subscribed
20170902-00:41:02 Tuner: tuner2 rtp stream ended (stop request)
20170902-00:41:04 Tuner: tuner1 tuning 553 FX HD (EAST) (auto:861MHz-727)
20170902-00:41:04 Tuner: tuner1 streaming rtp to 192.168.1.205:5003
20170902-00:41:04 Tuner: tuner2 tuning 568 WGNA HD (auto:117MHz-716)
20170902-00:41:04 Tuner: tuner2 streaming rtp to 192.168.1.205:5004
20170902-00:41:04 CableCARD: tuner2 568 WGNA HD (auto:117MHz-716) access = subscribed
20170902-00:41:04 CableCARD: tuner1 553 FX HD (EAST) (auto:861MHz-727) access = subscribed
20170902-00:41:20 Tuner: tuner1 rtp stream ended (stop request)
20170902-00:41:21 Tuner: tuner0 tuning 553 FX HD (EAST) (auto:861MHz-727)
20170902-00:41:21 Tuner: tuner0 streaming rtp to 192.168.1.205:5003
20170902-00:41:22 CableCARD: tuner0 553 FX HD (EAST) (auto:861MHz-727) access = subscribed
20170902-00:41:31 Tuner: tuner0 rtp stream ended (stop request)
20170902-00:41:46 Tuner: tuner1 tuning 576 NESN HD (Boston (auto:639MHz-627)
20170902-00:41:46 Tuner: tuner1 streaming rtp to 192.168.1.205:5003
20170902-00:41:47 CableCARD: tuner1 576 NESN HD (Boston (auto:639MHz-627) access = subscribed
20170902-00:42:20 Tuner: tuner0 tuning 512 CW WLVI-DTV (auto:519MHz-3110)
20170902-00:42:20 Tuner: tuner0 streaming rtp to 192.168.1.205:5005
20170902-00:42:21 CableCARD: tuner0 512 CW WLVI-DTV (auto:519MHz-3110) access = subscribed
20170902-00:59:40 HTTP: rejecting request from 192.168.1.206 - all tuners in use
20170902-01:07:54 Tuner: tuner0 rtp stream ended (stop request)
20170902-01:08:09 Tuner: tuner1 rtp stream ended (stop request)
20170902-01:08:54 Tuner: tuner2 rtp stream ended (stop request)
20170902-01:10:24 Tuner: tuner0 tuning 550 USA HD (auto:135MHz-660)
20170902-01:10:24 Tuner: tuner0 streaming rtp to 192.168.1.206:56582
20170902-01:10:25 CableCARD: tuner0 550 USA HD (auto:135MHz-660) access = subscribed
20170902-01:10:25 Tuner: tuner0 tuning 550 USA HD (auto:135MHz-660)
20170902-01:10:25 CableCARD: tuner0 550 USA HD (auto:135MHz-660) access = subscribed
20170902-01:10:25 Tuner: tuner0 rtp stream ended (new request)
20170902-01:10:25 Tuner: tuner0 streaming rtp to 192.168.1.206:55448
20170902-01:10:53 Tuner: tuner0 rtp stream ended (stop request)
20170902-01:11:10 Tuner: tuner0 tuning 550 USA HD (auto:135MHz-660)
20170902-01:11:10 Tuner: tuner0 streaming rtp to 192.168.1.206:56582
20170902-01:11:10 CableCARD: tuner0 550 USA HD (auto:135MHz-660) access = subscribed
20170902-01:11:11 Tuner: tuner0 tuning 550 USA HD (auto:135MHz-660)
20170902-01:11:11 CableCARD: tuner0 550 USA HD (auto:135MHz-660) access = subscribed
20170902-01:11:11 Tuner: tuner0 rtp stream ended (new request)
20170902-01:11:11 Tuner: tuner0 streaming rtp to 192.168.1.206:55456
20170902-01:11:46 Tuner: tuner0 rtp stream ended (stop request)
20170902-14:36:52 Tuner: tuner0 tuning 550 USA HD (auto:135MHz-660)
20170902-14:36:52 Tuner: tuner0 streaming rtp to 192.168.1.206:56582
20170902-14:36:52 CableCARD: tuner0 550 USA HD (auto:135MHz-660) access = subscribed
20170902-14:36:53 Tuner: tuner0 tuning 550 USA HD (auto:135MHz-660)
20170902-14:36:53 CableCARD: tuner0 550 USA HD (auto:135MHz-660) access = subscribed
20170902-14:36:53 Tuner: tuner0 rtp stream ended (new request)
20170902-14:36:53 Tuner: tuner0 streaming rtp to 192.168.1.206:53880
20170902-14:37:24 Tuner: tuner0 rtp stream ended (stop request)
20170902-14:45:26 Tuner: tuner0 tuning 551 TNT HD (auto:717MHz-601)
20170902-14:45:26 Tuner: tuner0 streaming rtp to 192.168.1.206:56582
20170902-14:45:27 CableCARD: tuner0 551 TNT HD (auto:717MHz-601) access = subscribed
20170902-14:45:27 Tuner: tuner0 tuning 551 TNT HD (auto:717MHz-601)
20170902-14:45:27 CableCARD: tuner0 551 TNT HD (auto:717MHz-601) access = subscribed
20170902-14:45:27 Tuner: tuner0 rtp stream ended (new request)
20170902-14:45:27 Tuner: tuner0 streaming rtp to 192.168.1.206:62014
20170902-14:45:48 Tuner: tuner0 rtp stream ended (stop request)
20170902-14:45:58 Tuner: tuner0 tuning 554 Spike HD (East) (auto:855MHz-646)
20170902-14:45:58 Tuner: tuner0 streaming rtp to 192.168.1.206:56582
20170902-14:45:59 CableCARD: tuner0 554 Spike HD (East) (auto:855MHz-646) access = subscribed
20170902-14:45:59 Tuner: tuner0 tuning 554 Spike HD (East) (auto:855MHz-646)
20170902-14:46:00 CableCARD: tuner0 554 Spike HD (East) (auto:855MHz-646) access = subscribed
20170902-14:46:00 Tuner: tuner0 rtp stream ended (new request)
20170902-14:46:00 Tuner: tuner0 streaming rtp to 192.168.1.206:62022
20170902-14:46:10 Tuner: tuner0 rtp stream ended (stop request)
20170902-20:37:03 Tuner: tuner0 tuning 44 WGBX 44-DT (auto:471MHz-3317)
20170902-20:37:04 Tuner: tuner0 streaming http to 192.168.1.206:59054
20170902-20:37:04 CableCARD: tuner0 44 WGBX 44-DT (auto:471MHz-3317) access = subscribed
20170902-20:37:13 Tuner: tuner0 http stream ended (remote closed)


[RoderickGI]

WMC was (is) capable of retrieving OTA EIT format EPG data for DVB-T transmissions, which is the way I used it initially, years ago, before I switched to downloading EPG data from a local source in Australia. A quick Google will confirm that from many sources. I forgot that being in America and using ATSC tuners you have always been spoiled with an internet download. My bad. I have read reports that WMC still "touches" tuners for other functions. I'm not going to Google a reference. I read that a long time ago while troubleshooting tuner issues with WMC. If I remember correctly the person was adamant that WMC touched tuners even when no Live TV, Recordings, or EPG collection was running, and proved it. The "touch" didn't involve tuning a channel, more just an "are you still there?" check.

Perhaps you could clarify with SiliconDust if the BDA Compatibility mode is PC specific or tuner specific? Because most devices probably use the Deafult BDA Compatibility mode, there wouldn't be an issue with a tuner specific setting. But as both WMC and MC use their own compatibility mode, this could be the issue.

Another potential issue, if the BDA Compatibility mode is PC specific and therefore should work, is that the JRiver mode was introduced in 2009. I wonder if it has been updated, or needs updating? There were some changes to the TV code a little while back... I can't find it just now. But there have been many changes with MC Television, so I'm wondering now if the BDA Compatibility mode for MC may be out of date. I don't know what the compatibility modes actually mean or do, of course, so this could be a complete non-issue.

Excellent that you will run the test with WMC isolated. Make sure to set the BDA Compatibility mode to JRiver after disconnecting, and before starting the test!

There is more Television logging in MC now, and three verbosity levels. It may pay to turn logging back on with verbosity set to "2", and see if anything appears. Turning logging off didn't fix the problem. Just check the PCIe tuners still work fine with logging on and verbosity high.

That SD log doesn't really say much, does it? Is there any way to increase the verbosity in those? Perhaps also a question for SD regarding what to look for if a signal is breaking up at the receiving end.

[RoderickGI]

This is the change I was thinking might affect the JRiver BDA Compatibility mode.

23.0.11 (6/22/2017)

1. Optimized: Television recording in transport stream format is more efficient, especially when multiple simultaneous recordings are involved.

I see Yaobing mentioned it in the second post in this thread.

The timing is about right based on your first post, but you were still on MC22 when you first saw the problem, so this change couldn't have been the cause. Although you could have had the problem from the earlier thread until you upgraded, and now you are seeing a problem with the JRiver BDA Compatibility mode. Two separate problems?

[greynolds]

FYI, here's a quote direct from JasonL (the owner of SiliconDust):

The BDA compatibility setting is per-PC. One app can't steal a tuner from another app. It's first-come, first-served, and whatever app gets it will keep it until it releases it.

FWIW, so far today, I have gone into the SiliconDust Setup application and forced it to save and re-save the relevant settings (by flipping them back and forth) and there's also a "Repair/Reinstall Windows component" button that I clicked.  The spot checks I've done of Live TV have been good so far.  I had company over during the day today, so I didn't have time to do extensive testing, but have been able to check several times.  I've got a recording schedule to start in just under and hour and a few tomorrow; I'll at least spot check them to see if they came out OK.

JasonL asked me to enable some diagnostics that send feedback to the SiliconDust mothership so they can take a look at things if the problem happens again.

I'll be in a holding pattern for now until the problem resurfaces again (obviously hoping that it doesn't), but will try to remember to post some feedback even if the problem doesn't happen again.

[RoderickGI]

JasonL asked me to enable some diagnostics that send feedback to the SiliconDust mothership so they can take a look at things if the problem happens again.

That is excellent. He may find something that hasn't been highlighted in the past.

I'll be in a holding pattern for now until the problem resurfaces again (obviously hoping that it doesn't), but will try to remember to post some feedback even if the problem doesn't happen again.

Feedback would be appreciated.

I don't have any skin in this game, but I persist because there have been several people that have used WMC alongside MC, and refused to completely turn it off for testing, resulting in long frustrating threads . . . and then those people have stopped posting or complaining, as something magically fixed their problem. There has never been a complete resolution or identification of the cause of the problem, but the implication was when WMC was disabled, the problem went away.

I know you are an intelligent analytical person, so I was hoping you could find some clear evidence that WMC and MC don't play well together, which would help convince future users to just turn off WMC and see if the problem goes away.

Anyway, I hope the problem has gone away, and if so, best guess is that the "Repair/Reinstall Windows component" function did the trick, along with saving the setting again correctly.

[JimH]

greynolds,
Let's hope ...

The owner of SD is Nick.

RoderickGI,
Whether you win or lose, I hereby award you the TV Merit Badge.  Nice work, patiently done.  Thank you.

[greynolds]

I know you are an intelligent analytical person, so I was hoping you could find some clear evidence that WMC and MC don't play well together, which would help convince future users to just turn off WMC and see if the problem goes away.

Until recently, I have had JRiver MC and 2 WMC systems coexisting just fine for the past couple of years.  Given how SiliconDust's devices work, there's really no rational reason why they shouldn't shouldn't.

Anyway, I hope the problem has gone away, and if so, best guess is that the "Repair/Reinstall Windows component" function did the trick, along with saving the setting again correctly.

That would be my guess as well.  My best guess would be that one of the recent Windows 10 updates stomped on something, simply uninstalling and re-installing the SiliconDust and JRiver software didn't reset everything (for example, I didn't have to re-enter my MC license), but the actions I took in the SiliconDust Setup application fixed whatever got stomped on.

But it's way too soon to declare a win here as I've had several false wins during this mess.  If I can get through a week without any problems, then we can throw a (virtual) party.

[greynolds]

greynolds,
Let's hope ...

Definitely hoping here.

The owner of SD is Nick.

Oh right, I should have remembered that.  Though Jason has been with them for as long as I can remember.

[RoderickGI]

Until recently, I have had JRiver MC and 2 WMC systems coexisting just fine for the past couple of years.  Given how SiliconDust's devices work, there's really no rational reason why they shouldn't shouldn't.

I have no problem with WMC coexisting, except perhaps when it is on the same PC as MC, or other media software I have used in the past. It has always just been about clearly identifying that there is an interaction between WMC and MC that is causing an issue, resolvable or not. WMC always had an advantage in its level of integration with Windows that other software didn't have, and a breadth of support from other hardware and software vendors that couldn't be matched, because, Microsoft. That has meant that it gazumped other software more often than not.

It even looks like Microsoft, and their "take it or else" update program has been the problem in this case, probably trashing some registry settings it shouldn't have touched. We wait to see.


Thanks Jim. 

[greynolds]

Unfortunately, the problem is back.  I've sent tuner id info to the SiliconDust folks, so we'll see if they're able to see anything on their end.

[greynolds]

I finally heard back from the SiliconDust folks this morning:

The logs show that moderate network packet loss is occurring. See our network packet loss information at https://forum.silicondust.com/forum/viewtopic.php?t=5877 for information on troubleshooting that.

I went through the troubleshooting process with no improvement (the "...save /tuner0 null​" command was giving me a constant stream of "nnnnnnnn" no matter what settings I tweaked). Next, I ran the "...save /tuner0 null" command​ on one of the Windows Media Center PC's and on my every day PC and had absolutely no errors. I don't know why it hadn't occurred to me sooner, but I swapped the network cable between the problem PC and my network switch and the "...save /tuner0 null" command​ ran without any errors displaying. So I put the network card settings (other than the receive buffer count, which I had adjusted up to 512 from 256) back to their defaults and still get a clean run of the command line.

So it looks like I simply had a network cable go bad...

I literally just swapped the cable (perhaps 15 minutes ago).  I do still see a few glitches when I initially tune to some TV channels in JRiver, but so far I'm not seeing any glitches after the initial second or 2 and things settle down.  This seems like a pretty clear victory given the difference in the low level network test, but I'm not going to declare victory until I've had more time to test things.

[jmone]

Fingers crossed....

[greynolds]

So after living with the change over the weekend, it looks like things are improved, but not resolved.  I watched a 1 hour TV show last night after it was done recording.  It was fine for approximately the first 55 minutes, then the breakup problem started again.  It's possible that I've got a bad network port on the PC or the switch, but I think the more likely issue is the network drivers (or simply that I'm using the motherboard's integrated networking, even though it had been working fine up until July)...

For most of the time I've been using this PC, I had been using Windows 7.  During the free upgrade period, I decided to take the plunge and upgrade to Windows 10.  So far so good.  I checked the motherboard network driver more closely over the weekend and it looks like a new driver was installed in early July, which would roughly correspond to when the problems began.  I'm not 100% positive, but I'm pretty sure that I had been using Intel drivers previously, but the new driver is a Microsoft provided driver.  The motherboard and integrated Intel LAN chipset are old enough now that Intel drivers aren't available for the Windows 10 Creator's version.

So longish story short, I'm considering 2 options:

1) Add a PCIe network card to the PC.  Given past experience, I would probably go with one from Intel, though I'm not sure what the best option would be at this point.  I've got Intel PRO/1000 PT cards in my Windows Media Center PC (running Windows 7) and my day-to-day PC (running Windows 10) and my brother has one in his Windows Media Center PC.  All 3 of those PC's have zero trouble with getting a reliable feed from the SiliconDust tuners, though I've only done somewhat random testing on the day-to-day PC.  The PRO/1000 PT is no longer a current card and ongoing Windows 10 support doesn't look like it will continue, so it probably makes sense to get something current that will be supported for a while, I'm just not sure what the best option is.

2) Upgrade to a current motherboard and obviously upgrade to a current CPU / RAM / video card combo in the process.  This would obviously be more expensive, but would presumably give me other improvements such as making the JRiver UI more responsive and have the advantage of everything on the motherboard having current driver support for a while.  I may still go with option 1 if I do this as I've never found integrated LAN to be nearly as good as a dedicated PCIe card.

The only real issue with going with a PCIe card is that it would probably force me to remove one of the PCIe tuners I currently use with BeyondTV.  But it probably makes sense to stop using BeyondTV at this point as the product has been dead for years and it only serves as a backup to catch OTA recordings that both WMC AND JRiver fail to record, which is an extremely rare occurrence (as in pretty much never over the last few years).

[Castius]

Could you try a usb network Adapter as a test?
Something like this.
https://www.amazon.com/AmazonBasics-1000-Gigabit-Ethernet-Adapter/dp/B00M77HMU0/ref=lp_13983791_1_3?s=pc&ie=UTF8&qid=1505139085&sr=1-3

[greynolds]

Could you try a usb network Adapter as a test?
Something like this.
https://www.amazon.com/AmazonBasics-1000-Gigabit-Ethernet-Adapter/dp/B00M77HMU0/ref=lp_13983791_1_3?s=pc&ie=UTF8&qid=1505139085&sr=1-3

I certainly could, but I haven't heard much recently (good or bad) about how well that type of network adapter compares to a "real" network card.  I realize you're just suggesting this as a test, but I don't think I would want to use one of these as a permanent solution.  For ~$14, perhaps it's worth trying though.  If it ends up working well, then it clearly points to either the integrated LAN port having issues OR the driver being the culprit.

One of the pain points in "simply" trying option 1 is that this is a 4U Norco rack mounted PC, so pulling it out of the rack to swap out cards is a bit of a project.  If I'm going to go to the effort of pulling it out, it probably makes sense to go all in with option 2 which would also get me ready for 4K video support as I do plan on upgrading to a 4K TV in the relatively near future.

I've done some research on retaining a Windows 10 install after a motherboard / CPU swap and it looks like it should work well as long as I take a few steps prior to the hardware swap (things like removing the current video driver and most of the drivers for integrated motherboard features so that Windows can boot up and do its thing to install all the correct drivers).  I would obviously take an image of the OS drive prior to doing any of this, but if all goes well it would be a lot less work than installing Windows from scratch and getting EVERYTHING reinstalled and tweaked as desired.  Reinstalling JRiver itself would be pretty simple thanks to the library backup, but there are lots of little things that need to be tweaked in Windows and a number of small programs that need to be installed and configured (such as MCE Controller for integration with my Crestron remote control system) that would potentially take a lot of time.

[RoderickGI]

I think the USB network Adapter is a good idea. However, I would want to confirm the issue on the existing NIC or network path between the PC and the tuners first. Or even try rolling back to an earlier driver and see if the problem goes away. I'm not sure if Windows 10 will allow that to happen and stay in place, but I would try.

It looks like the SiliconDust "Low level test for network packet loss" wouldn't work as a continuous test very well, given the nature of its output. But there must be some good tools available to monitor packet loss over the long term, to confirm the issue. I know Intel used to have some good simple tools for their cards, but haven't used such in a long time. Windows, or the driver, knows when a packet is lost, and either requests it again or ignores the loss and continues on, depending on the type of data stream I understand. So file copies require every packet to complete, but video streaming does not. That means the driver, and Windows, know a lot about what is happening with packets. I used to run an Intel tool that gave me a summary of that sort of stuff.

I guess Wireshark would be the tool to use these days, but it is more complex than the simple tools I used to use. There are some good discussions on the internet about analysing packet loss. Such as: https://serverfault.com/questions/207375/how-do-you-diagnose-packet-loss

As I said, I would want to confirm it is the NIC or something in the network path before considering upgrading the PC to fix the problem, given the work and cost involved, and that it may not fix the problem.

[tzr916]

...For ~$14, perhaps it's worth trying though.  If it ends up working well, then it clearly points to either the integrated LAN port having issues OR the driver being the culprit...

...I've done some research on retaining a Windows 10 install after a motherboard / CPU swap and it looks like it should work well as long as I take a few steps prior to the hardware swap (things like removing the current video driver and most of the drivers for integrated motherboard features so that Windows can boot up and do its thing to install all the correct drivers)....

I've got an intel pci lan card if you want it. Got from Amazon, used for less than a week in my futile quest to solve bad MC recordings. I too looked into retaining my OS drive but opted for a clean install because when changing mobo/cpu, a new Win10 product key is needed. I even had to chat with Microsoft to have them remote into my machine and reactivate Windows when changing from onboard lan to pci lan. I can suggest a great place to get a authentic Win10 Pro product key for $40. PM if interested in either.

[greynolds]

As I said, I would want to confirm it is the NIC or something in the network path before considering upgrading the PC to fix the problem, given the work and cost involved, and that it may not fix the problem.

Given that I'm having absolutely no problems with recordings made in Windows Media Center, it's got to be one of:

1) The specific port on the switch the JRiver Media Center PC is connected to.  Since I do have some open ports, one test I can obviously do is simply connect the PC to a different port.

or

2) Something to do with the JRiver Media Center PC.

The Windows Media Center PC's AND the tuners are all connected directly to other ports on the same switch (a HP ProCurve V1810-48G).

Given the info from SiliconDusts's utility, I'm pretty confident at this point that the issue is network related on the PC.  Keep in mind that I did run a test with the PCIe OTA tuners that are in the PC and the recordings were fine, which continues to point to networking as the culprit.

[greynolds]

I've got an intel pci lan card if you want it. Got from Amazon, used for less than a week in my futile quest to solve bad MC recordings. I too looked into retaining my OS drive but opted for a clean install because when changing mobo/cpu, a new Win10 product key is needed. I even had to chat with Microsoft to have them remote into my machine and reactivate Windows when changing from onboard lan to pci lan. I can suggest a great place to get a authentic Win10 Pro product key for $40. PM if interested in either.

Thanks for the offers, but I've got plenty of Windows 10 license keys available and according to this article:
https://scottiestech.info/2017/02/26/upgrade-your-motherboard-without-reinstalling-windows-10/
it should be possible to retain the same license key with a motherboard swap.

I've ordered a USB ethernet adapter, since it could be handy to have around and it's a cheap and easy test I can try.  If it works, then I'll decide whether to try a PCIe adapter or a motherboard / CPU swap at that point.  If it doesn't work, I'll go into a corner and have a good cry... 

[greynolds]

The USB 3.0 to Gigabit Ethernet adapter I ordered arrived yesterday and I got it setup before my recordings started last night.  I went with one from Startech.

So far, I'm 1 for 1 on getting a good recording, but that's clearly too small of a sample set based on previous results.  If I can get through a week without any problems, then I should be able to pin the problem squarely on the integrated LAN port or drivers and decide which option to go with:

1) Live with the USB 3.0 to Gigabit Ethernet adapter for the long term.

2) Replace the integrated LAN with a PCIe Ethernet card.

3) Upgrade the motherboard / CPU / RAM to something current.  This is clearly the most painful option, even if I can use my existing OS install, but it would also get me prepped for 4K support, though I might be OK with just upgrading to a more current video card rather than doing a full system upgrade.

[jmone]

Thanks for the update - hoping it holds well.

[greynolds]

As of last night, I have made it a full week without any problems by using the USB 3.0 to Gigabit Ethernet adapter instead of the Intel integrated network port on my motherboard.  I've recorded and watched around a dozen 1-2 hour TV shows.

I have seen glitches in the first second or 2 while the stream gets going a few times.  I also had 1 instance in the middle of a recording I watched last night that appeared to be a broadcast glitch (I'll try to remember to check my Windows Media Center recording of the same show, if I didn't nuke it already).  I would expect to see both of these happen once in a while, so I don't see these as concerns.

So at this point, I'm considering this issue resolved.

I just need to decide which long term solution to go with.  I'd like to spend a bit more time figuring out if I can find a combination of settings or drivers that will allow me to go back to using the Intel integrated network port, but spending more time on that may be a fool's errand.  Barring a hardware failure, which seems unlikely given the nature of the problem, it HAS to be some sort of driver, network adapter configuration, or Windows 10 update that is the culprit.

Looking ahead to a combination of 4K video support and long term system reliability, my best option is probably to upgrade the motherboard, CPU, RAM, and video card to current hardware.  The current hardware in this PC is from 2011 / 2012 and if I'm going to go to the effort to pull it out of the rack and upgrade the video card for 4K support, I might as well upgrade the rest while I'm at it.

So it probably makes sense to stick with the USB 3.0 to Gigabit Ethernet adapter until I upgrade the rest of the hardware.

[jmone]

Glad to see it is working and hence no need to rush.