INTERACT FORUM
Windows => Television => Topic started by: greynolds on July 21, 2017, 08:35:10 pm
-
There's already another thread for this, but it is locked which means I can't reply to it:
https://yabb.jriver.com/interact/index.php/topic,109339.0.html (https://yabb.jriver.com/interact/index.php/topic,109339.0.html)
I appear to be having the same problem the poster in that thread was having (audio dropouts and lines through the video during playback).
I do not know exactly which version I upgraded from and to when the problem started, but it's been an issue for a few weeks now and I've been busy and keep forgetting to post about it. I initially upgraded to 22.0.110 hoping that the issue was fixed by the TV changes in that release, but the problem persisted. I then upgraded to 23.0.19, again hoping it might be fixed there, but the problem still remains.
The ONLY changes I'm aware of to the system are the new versions of Media Center and Windows updates. So it's certainly possible that a Windows update screwed something up in the process. Now that I've upgraded to MC23, trying older versions of MC22 isn't going to be practical.
If I play these JRiver recordings in VLC on another PC, I get the same audio and video glitches, so this is NOT a playback issue in JRiver - the files themselves are somehow getting corrupted during the recording process.
I've got a mix of SiliconDust Prime CableCard tuners and SiliconDust HD OTA tuners which are shared between JRiver and Windows Media Center running on another PC and the problem is happening on both OTA and CableCard recordings, but seems to be a bit worse on the OTA recordings. The exact same shows recorded by Windows Media Center at the exact same time as .wtv files play fine in both Windows Media Center AND JRiver. I'm not experiencing any other playback issues with other video files in Media Center.
I've tried unchecking the new "Use extra layer of buffer" in the TV Advanced options, but that doesn't seem to have any impact on my results.
Tonight I switched the recording format to use JTV files to see if that helps and will report back. If it cures the problem, I'm certainly willing to go with JTV files for the short term, but I'm not happy with that as a long term solution because those files aren't portable in the way that .ts files are.
-
There's already another thread for this, but it is locked which means I can't reply to it:
https://yabb.jriver.com/interact/index.php/topic,109339.0.html (https://yabb.jriver.com/interact/index.php/topic,109339.0.html)
I appear to be having the same problem the poster in that thread was having (audio dropouts and lines through the video during playback).
23.0.11 (6/22/2017)
1. Optimized: Television recording in transport stream format is more efficient, especially when multiple simultaneous recordings are involved.
If it were the same issue, it would have been fixed in 23.0.11.
Is logging on? If so, what verbosity level for TV-related logging? Try turning logging off if it was on.
-
23.0.11 (6/22/2017)
1. Optimized: Television recording in transport stream format is more efficient, especially when multiple simultaneous recordings are involved.
If it were the same issue, it would have been fixed in 23.0.11.
Is logging on? If so, what verbosity level for TV-related logging? Try turning logging off if it was on.
Logging was on and the verbosity was set to level 0 for TV-related logging. I just turned logging off.
The recordings I made earlier tonight in JTV format (but with logging still on at the time) have the same problem I've been getting with TS format.
-
If JTV recordings have the same issue, then there must be a different cause. It could be a network issue.
-
If JTV recordings have the same issue, then there must be a different cause. It could be a network issue.
If it were a network issue, it would presumably be an issue with recording on my WMC PC as well and I've had absolutely no problems there, as indicated in my first post - the same pool of tuners and the same network are used.
More importantly, it would have been an issue prior to the recent Media Center version upgrades as nothing has changed on my network. I'm using high end HP ProCurve Gigabit switches in my home and the tuners and both PC's are all connected to the same switch.
-
Same machine?
-
Same machine?
Windows Media Center is running on "server1" running Windows 7 and JRiver is running on "server2" running Windows 10 (so 2 different physical machines; these are not VM's or anything like that).
JRiver has been running on the same machine through the various version upgrades; the hardware hasn't been changed in a while.
I just did some "digging" on the JRiver machine. One thing that stood out was that oShare (a simple DLNA server) was using a non-trivial amount of CPU (around 20%). Though it has been running alongside JRiver for several years, I really only had it running for testing purposes (I'm a beta tester for Oppo), so I've shut it down for now. I also switched back to recording in .ts format. I started recording Titanic on USA and it appears to be recording without any problems at the moment.
This is obviously a separate thing, but I also noticed that my JRiver recordings folder has a bunch of what I assume are temporary .jtv folders for shows that have, for the most part, been watched and deleted. Given that I record in .ts format, is it safe to assume that I can manually clean these up by just deleting those folders without causing any issues?
If you guys offered a way to convert .jtv recordings to .ts files (.mkv or some other standard format would be fine too) without re-encoding the audio and video (so maintaining the original audio and video codecs), I would consider switching to using the .jtv format which I gather would reduce hard drive activity during recording as I understand you write out both formats and then delete the .jtv content when the recording has completed. The convert functionality doesn't seem to have an option that will do this, as 1080i isn't an available option.
-
We have considered multiplexing jtv into something more portable. For now, it does not seem to be a trivial matter. But we will keep this in mind for future.
It is safe to delete time-shifting folders left by MC if your recordings are done in TS. There is a tool in MC to help you clean up such folders. Normally, such folders would contain some files, but not all files necessary to form a jtv recording. The tool is in TV Options > Advanced. Run it once in a while to remove the unwanted folders.
-
We have considered multiplexing jtv into something more portable. For now, it does not seem to be a trivial matter. But we will keep this in mind for future.
.... a limited case from jtv to ts, where we already know the original content used to fit in ts (since thats what it broadcasts as), wouldn't be that hard.....
Anyhow I'm busy for a while to come, maybe next year.
-
It's unfair to use someone's words for your own purposes. Shameless, in fact. Totally out of context.
-
If you guys offered a way to convert .jtv recordings to .ts files (.mkv or some other standard format would be fine too) without re-encoding the audio and video (so maintaining the original audio and video codecs), I would consider switching to using the .jtv format which I gather would reduce hard drive activity during recording as I understand you write out both formats and then delete the .jtv content when the recording has completed. The convert functionality doesn't seem to have an option that will do this, as 1080i isn't an available option.
Until supported JRiver functionality is available, try this: https://yabb.jriver.com/interact/index.php/topic,107498.msg746546.html#msg746546
Of course, that doesn't mean we don't need a JRiver version, because, for example, metadata isn't carried across to the TS file. The solution requires multiple manual steps to update the library and get the TS version up to spec. But the conversion is straight forward and works.
-
It's unfair to use someone's words for your own purposes. Shameless, in fact. Totally out of context.
I can't tell if you are joking or not :-X but Hendrik's quote came from the JTV to TS Remuxing Thread (https://yabb.jriver.com/interact/index.php/topic,107498.msg)
-
There's already another thread for this, but it is locked which means I can't reply to it:
https://yabb.jriver.com/interact/index.php/topic,109339.0.html (https://yabb.jriver.com/interact/index.php/topic,109339.0.html)
I appear to be having the same problem the poster in that thread was having (audio dropouts and lines through the video during playback).
Check MC cpu usage while recording with ALL your tuners at the same time (5 or more if possible), on mpeg2 high bitrate local channels. Does MC cpu go higher than 27-35%? Any spikes over that can create bad audio/video on my machine.
-
Check MC cpu usage while recording with ALL your tuners at the same time (5 or more if possible), on mpeg2 high bitrate local channels. Does MC cpu go higher than 27-35%? Any spikes over that can create bad audio/video on my machine.
Given that it has (hopefully had after the changes I made yesterday...) been happening even when recording only 1 channel, my assumption is that another factor is/was the culprit. But during the busy TV season, I've had cases where I've had 6 or more recordings going at the same time without any problems prior to these recent issues.
-
Windows Media Center is running on "server1" running Windows 7 and JRiver is running on "server2" running Windows 10 (so 2 different physical machines; these are not VM's or anything like that).
JRiver has been running on the same machine through the various version upgrades; the hardware hasn't been changed in a while.
I just did some "digging" on the JRiver machine. One thing that stood out was that oShare (a simple DLNA server) was using a non-trivial amount of CPU (around 20%). Though it has been running alongside JRiver for several years, I really only had it running for testing purposes (I'm a beta tester for Oppo), so I've shut it down for now. I also switched back to recording in .ts format. I started recording Titanic on USA and it appears to be recording without any problems at the moment.
Now that a few more days have passed, it appears that shutting down oShare did NOT solve the problem.
As a test, I'd like to switch back to MC 22 and install a previous release to see if that resolves the problem so I can hopefully figure out if later versions of MC 22 and MC 23 are the culprit or if I need to continue looking at other potential issues on the PC. Since this seemed to have started after upgrading to one of the newer MC 22 releases and that the WMC PC isn't having any issues recording the same shows from the same pool of tuners, I'm skeptical about the PC having issues.
Can I use my "new" MC 23 library with MC 22 without causing any problems or do I have to switch to my previous MC 22 library? Hopefully the first option will work.
-
What is your PC hardware?
What is your PC jmark?
Is it CONFIRMED by Yaobing 100% that recording with TS in MC versions after 22.0.76 uses more CPU than previous versions. How much more depends on your system. Do your own comparison recording with version 22.0.76 vs recording with version 22.0.77 (there were excellent improvements put into MC v23 that reduced cpu usage since v22.0.77).
-
What is your PC hardware?
What is your PC jmark?
I'm at the office right now, so can't give specific answers to those questions, but the PC has an Intel Core i7 CPU (IIRC, it's 2.77GHz) and 12GB of fast RAM. The hardware is several years old, but I doubt that's an issue given that everything else is still working just fine, including playback of all other types of video files; even 4K video files.
Is it CONFIRMED by Yaobing 100% that recording with TS in MC versions after 22.0.76 uses more CPU than previous versions. How much more depends on your system. Do your own comparison recording with version 22.0.76 vs recording with version 22.0.77
Do you have "is" and "it" backwards? When I've checked CPU usage while recordings are happening, the percentage has remained well below 50% (as in ~30%), even with multiple recordings running at the same time.
I'll try to get more specific answers to your questions tonight, but I'd be rather surprised if this is a hardware issue of some sort.
If I'm not actually playing any media on the server while recordings are in progress how important is the jmark score? Isn't that more important for playback capabilities?
-
I'm at the office right now, so can't give specific answers to those questions, but the PC has an Intel Core i7 CPU (IIRC, it's 2.77GHz) and 12GB of fast RAM. The hardware is several years old, but I doubt that's an issue given that everything else is still working just fine, including playback of all other types of video files; even 4K video files.
Do you have "is" and "it" backwards? When I've checked CPU usage while recordings are happening, the percentage has remained well below 50% (as in ~30%), even with multiple recordings running at the same time.
I'll try to get more specific answers to your questions tonight, but I'd be rather surprised if this is a hardware issue of some sort.
If I'm not actually playing any media on the server while recordings are in progress how important is the jmark score? Isn't that more important for playback capabilities?
Sorry, yes I have "is" & "it" backwards... It is confirmed. If you are having problems even recording one channel at a time, not sure what to say...
-
If you are having problems even recording one channel at a time, not sure what to say...
Hopefully rolling back to an earlier version of MC22 will shed some light on things. If recordings are still bad, that most likely points to an issue with recent Windows updates. With Windows 10, those updates are rather frequent and difficult to avoid which means the PC configuration is always a moving target.
-
I couldn't run the benchmark last night because I had recordings running (probably should have cancelled them since they're pretty much unwatchable, but...). So I just ran it and here's the output:
=== Running Benchmarks (please do not interrupt) ===
Running 'Math' benchmark...
Single-threaded integer math... 4.155 seconds
Single-threaded floating point math... 2.343 seconds
Multi-threaded integer math... 1.390 seconds
Multi-threaded mixed math... 0.838 seconds
Score: 2177
Running 'Image' benchmark...
Image creation / destruction... 0.335 seconds
Flood filling... 0.720 seconds
Direct copying... 0.794 seconds
Small renders... 1.712 seconds
Bilinear rendering... 1.307 seconds
Bicubic rendering... 0.858 seconds
Score: 3842
Running 'Database' benchmark...
Create database... 0.279 seconds
Populate database... 1.319 seconds
Save database... 0.166 seconds
Reload database... 0.074 seconds
Search database... 1.450 seconds
Sort database... 1.697 seconds
Group database... 0.931 seconds
Score: 3634
JRMark (version 23.0.19): 3218
So obviously not bleeding edge performance, but I'm assuming this system should still be sufficient for my needs. I've verified that my CPU, network, memory, and disk performance numbers all appear to be reasonable in Windows Task Manager while recording.
My next step is going to be to roll back to a slightly older version of MC22 (probably build #76) and see what happens.
-
Not bleeding edge, just fair.
-
Not bleeding edge, just fair.
Sorry Jim, but that's not exactly helpful as it gives me pretty much nothing to work with.
Before the recent MC22 and MC23 updates, I had absolutely no issues recording multiple shows (I had at least 6 going at some points during the most recent TV season some nights) even while watching a movie, previously recorded TV show, or a TV show that was in the middle of recording. The hardware hasn't been changed, I still have no issues watching anything other than these recently recorded TV shows, and the various system performance parameters appear to be well within reasonable bounds while recording is happening which suggests to me that the PC has enough horsepower to handle recording TV.
I'd really like to get to the point where I can retire Windows Media Center and use JRiver for both my TV needs and everything else it does so well, but it's pretty much useless to me for TV recording at the moment.
I'll readily admit that the pretty much unavoidable Windows 10 updates could very well be the problem here.
But if I roll back to the previous build of MC22 and find that TV recording works well again (which should eliminate variables such as Windows updates being the culprit), will you guys take ownership and pursue this or am I wasting my time?
-
So I briefly switched back to MC22 and downgraded it from build 108 to build 76. TV recordings still have the same problem, so this presumably rules out the recent MC updates being the culprit.
Back with MC23, recordings are still not good (no surprise as I didn't expect them to magically start working).
I completely disabled Windows Defender and that didn't help.
So..... it occurred to me that SiliconDust has a Viewer app available, that can be used to view the output from their tuners on the PC and has functionality to tune to any channel the tuners have access to. So I ran the viewer app and see the exact same issue. This obviously points to something gone wrong with the tuner drivers, so it looks like I need to pursue this further with the SiliconDust folks. I don't know why this didn't occur to me sooner; probably because I'm having no problems with the same tuners on my Windows Media Center PC running on Windows 7. It's most likely going to turn out to be some sort of SiliconDust driver issue with recent Windows 10 updates.
Sorry for the false alarm, guys, but please leave this thread open so I can post my findings with the SiliconDust side as it may help someone else if they run into the same problem.
-
Another possibility is a recent Windows update. We've just seen a few too many of these lately.
-
Another possibility is a recent Windows update. We've just seen a few too many of these lately.
My home office PC also has Windows 10 installed and the SiliconDust tuners are working fine in their view app on that PC. I'm pretty sure both PC's have the same updates, but that's a tough comparison to make and the hardware on the 2 PC's isn't identical; similar but definitely not the same.
I just updated to the latest SiliconDust drivers / app which also updated the firmware on the tuners and the problem remains. But again, this is something I'll have to work through with them as until the tuners display TV without glitches in their app, you guys are off the hook.
-
I don't know if I already asked this, is network connection in good shape on this computer?
-
I don't know if I already asked this, is network connection in good shape on this computer?
I believe so. I just checked and Windows claims the latest drivers are installed for the onboard Intel Gigabit network adapter. Intel's own drivers won't install, but they don't have a Windows 10 specific driver installer and their driver installers often don't seem to recognize integrated motherboard network controllers.
I spent some more time with the SiliconDust app and after a reboot (no other changes), TV is playing fine through their app now on both CableCard and OTA tuners. However, it still had the same issue in Media Center.
For the heck of it, I just switched my Media Center recording location to a brand new 6TB HGST drive and that seems to have made a difference (live TV is now playing well in Media Center). The old drive is a 4GB HGST drive with around 1.6GB free. Hard Disk Sentinel reports the drive as 100% healthy. However, it hasn't been defragmented in quite a while and there are some folders in the recordings folder that the Media Center cleanup tool didn't nuke and I'm unable to delete them from Explorer. So it's quite possible the drive has some file structure issues and needs some "cleanup". I'll stick with the new drive for a few days and see what happens. If this resolves the problem, I'll probably relocate the existing good recordings over to the new drive, reformat the old drive, and use it for something else.
I'm glad this happened in the off season rather than in the fall as it gave me time to figure it out without interrupting too many recordings. Fingers are crossed that the recording drive swap does the trick. :)
-
So the live TV and recording problems have continued to plague me this week so I just did some more digging. Since I updated the SiliconDust drivers, the SiliconDust view app has worked flawlessly every time I've checked it, so I've been fairly confident that the SiliconDust side of things is good.
I noticed when I rebooted the PC last night (for some more Windows 10 updates - do those ever have an off season???) that I got a bit of an odd message for JRiver during startup and the JRiver tray service wasn't running (sorry, I didn't write the exact message down). So I shutdown JRiver and checked the Startup tab in Task Manager. Oddly enough, it was still configured to start JRiver MC22. So I started up MC22 and checked the settings and it claimed it wasn't supposed to start anything. After I flipped the settings back and forth and hit OK, the Startup entry for MC22 was gone in the Task Manager. That, of course, left me with no JRiver running at boot. So I started up MC23 manually, went into settings, set it up to run the service app and main app, and then confirmed the correct entry is in the Task Manager.
Next, I started up LiveTV in MC23 and it is playing fine now. It will take a few more days of testing, but it looks like this odd startup state might be what the problem was. My fingers are crossed that this solves the problem. :)
I vaguely recall running into this same problem when I upgraded from MC21 to MC22, so you guys may want to look into whether there might be some sort of upgrade install issue that needs to be dealt with or at least add a note somewhere visible letting people know they need to double check their startup settings after a major version upgrade.
-
I vaguely recall running into this same problem when I upgraded from MC21 to MC22, so you guys may want to look into whether there might be some sort of upgrade install issue that needs to be dealt with or at least add a note somewhere visible letting people know they need to double check their startup settings after a major version upgrade.
There is definitely an issue when an upgrade is done while there are still two existing versions of MC installed on the PC. So if going from MC22 to MC23, and you still have MC21 and MC22 installed, MC doesn't seem to be able to find the correct previous installation to upgrade from, doesn't upgrade the library (so a restore is required) and doesn't change File Associations over to the new version correctly, even if the changes are specified during the upgrade.
So you could have been running MC22 components while actually running MC23. That could well be the cause of other people's issues. There have been a few similar reports.
-
There is definitely an issue when an upgrade is done while there are still two existing versions of MC installed on the PC. So if going from MC22 to MC23, and you still have MC21 and MC22 installed, MC doesn't seem to be able to find the correct previous installation to upgrade from, doesn't upgrade the library (so a restore is required) and doesn't change File Associations over to the new version correctly, even if the changes are specified during the upgrade.
So you could have been running MC22 components while actually running MC23. That could well be the cause of other people's issues. There have been a few similar reports.
That would explain it as MC21 (and I think MC20 too) is also still installed on the PC. There's probably no reason for me to leave the older versions, but they really don't take up much space and I never remember to go back and remove them after I decide I'm happy with the new version.
Thanks for the comments about the library update - I wasn't aware that would also be a problem. I'm less concerned about file associations.
This strikes me as the sort of thing that should be fixed before focusing on completely new features. At a minimum, if the installer for the new version can detect there's more than 1 old version installed, put up an error message telling the user to uninstall the old version(s) before it can proceed.
-
I tend to leave the old versions there for a while as well, and forget about them. Then get caught out by file associations trying to launch an earlier version, which then "fixes" its component registrations, which makes things worse.
At a minimum, if the installer for the new version can detect there's more than 1 old version installed, put up an error message telling the user to uninstall the old version(s) before it can proceed.
I would be happier with a question asking which version/installation to upgrade from.
-
I tend to leave the old versions there for a while as well, and forget about them. Then get caught out by file associations trying to launch an earlier version, which then "fixes" its component registrations, which makes things worse.
I would be happier with a question asking which version/installation to upgrade from.
I'd be happy with anything that would prevent the adventure I've gone through for the last few weeks trying to figure out why TV recordings have been pretty much unwatchable. Fortunately I record just about everything on Windows Media Center too. The goal is to be confident enough with MC that I can get rid of Windows Media Center at some point, though the user interface for TV in WMC is SOOOOO nice and now that I switched it over to use Schedules Direct data, it should keep going for quite a while.
-
Good point. 8)
I would have thought other things will start to fail in WMC over time, like IMDB, TheTVDB and other metadata lookups. Anything hard coded could break without much warning. I only used WMC for a short time before converting to MC though, so I don't know enough about it to know what might break. Or how good its visuals and usability are. Plus sorting, management, view customisation... basically, I've forgotten nearly everything about it! ;D
-
Good point. 8)
I would have thought other things will start to fail in WMC over time, like IMDB, TheTVDB and other metadata lookups. Anything hard coded could break without much warning. I only used WMC for a short time before converting to MC though, so I don't know enough about it to know what might break. Or how good its visuals and usability are. Plus sorting, management, view customisation... basically, I've forgotten nearly everything about it! ;D
Strictly for TV purposes, WMC really is excellent IMHO. There are a few relatively minor bugs that Microsoft never got around to fixing, but they truly are minor and don't really impact usability.
One specific example is the UI will display the current time in the upper right hand corner when the OSD pops up to show where your time progress when you fast forward, press pause, etc. The problem is that every once in a while, the clock gets "stuck" and stops displaying the current time. It's a bit annoying, but doesn't cause recordings to not happen, it's purely a display issue.
The only major issue has been that the guide data updates stop updating from time to time for all users and it usually gets too close to the point where there's no data left before Microsoft gets it fixed. The last time it happened, which was several weeks ago, the guide data did run out and Microsoft didn't get it fixed until at least a week after the data ran out. But someone put a considerable amount of effort into developing a mechanism (he named his app EPG123) to replace the data source (Rovi) with SchedulesDirect, which is extremely reliable. I decided to make the switch once the guide data actually ran out and am glad I did as I shouldn't have to worry about it for a while. One nice change EPG123 can do is add the season and episode numbers to the show name and/or description, which allowed me to configure JRiver MC to parse them out when it imports my WMC recordings.
For anything other than TV, WMC isn't worth using and never really was IMO.
-
So the live TV and recording problems have continued to plague me this week so I just did some more digging. Since I updated the SiliconDust drivers, the SiliconDust view app has worked flawlessly every time I've checked it, so I've been fairly confident that the SiliconDust side of things is good.
I noticed when I rebooted the PC last night (for some more Windows 10 updates - do those ever have an off season???) that I got a bit of an odd message for JRiver during startup and the JRiver tray service wasn't running (sorry, I didn't write the exact message down). So I shutdown JRiver and checked the Startup tab in Task Manager. Oddly enough, it was still configured to start JRiver MC22. So I started up MC22 and checked the settings and it claimed it wasn't supposed to start anything. After I flipped the settings back and forth and hit OK, the Startup entry for MC22 was gone in the Task Manager. That, of course, left me with no JRiver running at boot. So I started up MC23 manually, went into settings, set it up to run the service app and main app, and then confirmed the correct entry is in the Task Manager.
Next, I started up LiveTV in MC23 and it is playing fine now. It will take a few more days of testing, but it looks like this odd startup state might be what the problem was. My fingers are crossed that this solves the problem. :)
So Live TV and Records working properly didn't last long as the problem returned the next time I took a look at Live TV (on Friday). As before, TV still plays fine through SiliconDust viewer app on the same PC.
It was a busy weekend, so I didn't have much time to look into things, but after I found that TV was messed up again, I did / found the following:
1) I checked add/remove programs and had MC21, MC22, and MC23 installed.
2) I uninstalled version MC21, leaving me with just MC22 and MC23.
3) I installed MC23v30 from the downloaded installer, and selected the advanced option to select file associations and so on.
After doing the above, Live TV still has the same problem and, of course, recorded TV does too. To be clear, as stated earlier in this thread this is NOT limited to a playback issue as the problem recordings have the same issue if I open them in VLC, so something is getting messed up while writing the recordings to disc.
I really want to avoid the painful exercise of rebuilding the PC from a fresh Windows 10 install, but I'm starting to wonder if that's the only solution. If I have to do that, it would probably make sense to take it as an opportunity to update to newer hardware and replace the MB, CPU, RAM, and video card. I'm definitely open to less painful options though as I don't know when I'll be able to find the time to do that in the near future... :)
-
Could Windows Media Center running on another machine be trying to access the tuner somehow?
-
Could Windows Media Center running on another machine be trying to access the tuner somehow?
When recordings are scheduled start, MC and WMC will grab a tuner from the "pool" and I've confirmed via SiliconDust's tools that they're definitely using different tuners (the tool shows the IP that each tuner is connected to or a blank entry if the tuner is not in use), which makes sense as. I have configured MC and WMC to grab tuners from the pool in different orders, so there should never be a conflict unless I run out of tuners (too many recordings in progress). When I've run some of the quick tests with Live TV, WMC has been completely idle and not using any tuners (again, confirmed in SiliconDust's tools) and like I said, SiliconDust's viewer app works just fine on the JRiver PC.
-
....I really want to avoid the painful exercise of rebuilding the PC from a fresh Windows 10 install, but I'm starting to wonder if that's the only solution. If I have to do that, it would probably make sense to take it as an opportunity to update to newer hardware and replace the MB, CPU, RAM, and video card....
Wouldn't put too much into better hardware helping (as far as MC cpu usage during recording multiple channels). Changing my Server from [Q9450 Core2 Quad 2.66GHz/8GB PC2-6400/OS SSD/Data SATA II] to [i5-7500 3.4GHz/16BG PC4-19200/OS PCIe 128GB NVMe Gen3x4 M.2/Data SATAIII] made virtually no difference in regards to MC cpu usage when recording. Only real MC benefits - slightly quicker channel changing, theaterview navigation, library scanning, thumbnail creation, client access. Outside of that - it can do more/faster comskip scanning and runs cooler/quieter.
Is your recording drive LOCAL (in server SATA)? Have you tried changing the recording location to a different (LOCAL) hard disk?
-
Wouldn't put too much into better hardware helping (as far as MC cpu usage during recording multiple channels). Changing my Server from [Q9450 Core2 Quad 2.66GHz/8GB PC2-6400/OS SSD/Data SATA II] to [i5-7500 3.4GHz/16BG PC4-19200/OS PCIe 128GB NVMe Gen3x4 M.2/Data SATAIII] made virtually no difference in regards to MC cpu usage when recording. Only real MC benefits - slightly quicker channel changing, theaterview navigation, library scanning, thumbnail creation, client access. Outside of that - it can do more/faster comskip scanning and runs cooler/quieter.
Yeah, I wouldn't expect it to make much, if any, difference as recording obviously isn't a high CPU load. But if I do HAVE to reinstall Windows to resolve this problem, it would make sense to update the hardware at the same time as the hardware is ~5 years old at this point.
Is your recording drive LOCAL (in server SATA)? Have you tried changing the recording location to a different (LOCAL) hard disk?
The recording drive is a local SATA drive on a high end LSI controller (https://www.amazon.com/gp/product/B003UNP05O/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 (https://www.amazon.com/gp/product/B003UNP05O/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1)), but setup with a UNC share path (ie: \\servername\JRiverRecordings), which is how it has been configured for the entire time this system has been in use. This allows JRiver running on a different PC to access the recordings without any issues and makes it easier if I want to move the recordings to a new drive (shut down JRiver first and then just make sure the new drive uses the same share name once I've moved the files). I did switch it point to the local drive letter briefly for testing purposes and I also switched to record to a brand new drive; neither change improved things.
-
As of this evening, the problem with watching live TV and recording TV remains.
I did a bit more investigation of recordings I haven't had time to watch yet, spread over the last few months. It looks like everything up to July 13 recorded just fine. There's 1 recording on July 14 that appears to be fine for the first ~30 minutes and then starts having the problem with audio dropouts and the picture breaking up. I've got a few recordings since then that look like they may be OK (I spot checked them, so haven't watched them all the way through), but everything else on and after July 14th appears to have the problem.
As I believe I said above, the MC recordings don't play properly in VLC either, so this problem isn't a MC specific playback issue of some sort - the files that MC is writing out have problems.
-
I think we may be having the same issues and interestingly I too am using an HDHomerun tuner (Connect DVB-T2). My live tv works fine through the HDHomerun app on Win10 64 and if I play the stream through VLC.
I am having issues with movement lines on screen using MC (I've tried v22 and v23). Any fast movements on screen cause horizontal black "smearing" on the moving objects like hands, or any panning horizontally. The lines go as soon as the movement stops. Static or slow movement is absolutely fine. I've tried turning off everything in the video "custom" option in MC but the lines remain, but perhaps less obvious. I also have an HD recording from a few days ago that is unwatchable, it looks like the sharpness has been maxed out and all the edges are "twinkling". That shows when played back on a different machine and different software so its in the recording.
I've eliminated everything else so I am satisfied that MC is causing the issue, but its only been recent. I cant tie down when it started but its around the time I installed v23.
Perhaps this is an incompatibility between MC and Silicon Dust gear.
The problem seems worse on live broadcast tv, but if I record a film then I dont see the same issue, or playback a ripped blu ray that too is fine.
See my short thread https://yabb.jriver.com/interact/index.php/topic,111755.0.html (https://yabb.jriver.com/interact/index.php/topic,111755.0.html)
-
If it helps as to when this may have started, thinking back, the first time I noticed this issue was watching the Azerbaijan F1 GP which obviously is full of fast movement.
That was June 25th, and it was shown live on terrestrial tv in the UK so I probably watched live rather than a recording, but I cant be sure.
I always update any stable releases of MC as soon as available so perhaps some of the gurus can work out what version I would have been on at that time? That was definitely the first time I became aware of a problem, and its been there since.
Having tried every adjustment and permutation, I am 100% convinced the common factor in the issue is MC. I can have perfect quality tv playback on my current hardware, but not through MC. I have been watching the athletics WC for the last hour on the Silicon Dust app and it has been perfect playback and no sign of a glitch or issue.
Yaobing, I hope you are reading this and can help!
-
I've managed to grab a screen capture which at least partly demonstrates whats going on.
-
Ive managed to grab a screen capture which at least partly demonstrates whats going on.
Yours may be a different issue from greynold's. Can you record a show in TS format and play it in another player (e.g. VLC)? Yours looks like a deinterlacing issue.
-
Yours may be a different issue from greynold's. Can you record a show in TS format and play it in another player (e.g. VLC)? Yours looks like a deinterlacing issue.
Yes, I can record in .ts format and play to other players. The screen grab doesnt really show whats actually showing on a moving screen. Movement creates a strange blurring that appears like black horizontal lines on all edges, appearing like stripes which go as soon as the movement slows or stops. But it only happens on tv, and as far as I can ascertain on HDTV and normal broadcasts, not films. Standard res tv doesnt do it and playback of other rips and the like is fine too.
Ive got another capture which illustrates the effect a bit better. The car in the foreground is moving and the others parked. All the vertical lines on the car are lined and as a moving picture it looks like a weird lined dithering effect. It looks far more pronounced on a a full screen moving picture than the grab shows.
-
Looks like bad handling of chroma on interlaced videos to me.
If you record such content in .TS format and play it back later, in MC or anywhere else, does the problem not persist?
-
Here's another. The train was moving right to left. The pipe in the middle illustrates the effect quite well I think. This is from a recorded (ts format) HD program.
Hopefully you will have some suggestions? I'll shut up now and wait....
-
Have you modified madVR settings from the default settings MC uses?
What happens if you play using Red October Standard?
-
One more post. This grab is from the same recording, played back on a different machine using VLC.
-
Have you modified madVR settings from the default settings MC uses?
What happens if you play using Red October Standard?
I have in the last few days played with madVR to try and have some effect but to no result. I guess when I reselect ROS it resets the settings? Up until a couple of days ago, I only used ROS, I tried ROHQ and it was too much for my computer. The recording was made with ROS and thats the setting I use now. Nothing I've tried seems to change it, other than playing through a different player. Ive tried HDHomeruns own app, VLC and ProgTV all of which work faultlessly.
-
As of this evening, the problem with watching live TV and recording TV remains.
I did a bit more investigation of recordings I haven't had time to watch yet, spread over the last few months. It looks like everything up to July 13 recorded just fine. There's 1 recording on July 14 that appears to be fine for the first ~30 minutes and then starts having the problem with audio dropouts and the picture breaking up. I've got a few recordings since then that look like they may be OK (I spot checked them, so haven't watched them all the way through), but everything else on and after July 14th appears to have the problem.
As I believe I said above, the MC recordings don't play properly in VLC either, so this problem isn't a MC specific playback issue of some sort - the files that MC is writing out have problems.
Greynolds
I hope I haven't hijacked your thread. I think we are seeing the same thing..
-
Yaobing doesn't think so.
-
Yaobing doesn't think so.
I saw that, and he asked if I could play back a recording on another machine and see the same issues. He was apparently thinking my issue was local playback on my main machine.
But the screen grab when playing the recording on a different machine, using different software and even a different monitor shows that the issues were part of the recording and not part of the playback. It also shows that MC is doing something to the tv signal before its played back, or it wouldn't also be present on recorded material.
So, hopefully there is only one issue to be addressed here rather than two, which would be good news?
The one aspect I cannot investigate is if the problem is an interaction between HDHomeruns hardware / firmware and MC. But I can say that my HDHomerun works fine with every other piece of tv software I can find (I can now include Kodi as fine as well) so we just have one common factor left.
I'm not criticising here, MC is my chosen software and I love it. Just at the moment there is for me and another user a strange and frustrating issue.
-
Greynolds and Robt, have you guys had a change in broadcast TV format recently? Perhaps one you didn't even know about? Does rescanning channels make a difference? Maybe note down the Video, Audio, and other format parameters such as interlacing, and then rescan and see if they change. The issue certainly looks like a deinterlacing issue.
I had some very minor video problems a while back when TV broadcasters changed the format of quite a few channels. I don't know if MC dynamically checks the format and changes, or uses the information it collects when channels are scanned, but my problem went away when I rescanned. I'm using an internal PCIe DVB-T tuner card though, so nothing to do with HDHomeRun.
-
I don't believe the TV broadcast format has changed recently and it happens on both OTA and Cable channels on a mix of SiliconDust HDHomeRun (OTA) and HDHomeRun Prime (CableCard) tuners. I know that Comcast has been making some broadcast format changes, but my cable TV provider is Verizon FIOS and I don't believe they've made any changes.
Though they might be related, the problems robt and I are seeing definitely manifest themselves a bit differently.
I've included a screenshot taken with my iPhone 6S that illustrates what the problem I'm seeing looks like. The problem is sometimes much worse than that thick green horizontal line shown in the screenshot - sometimes the entire bottom or top half of the screen is blotchy like that. As said above, when the video breaks up like this, the audio will also skip briefly or cut out for several seconds; these recordings are pretty much completely unwatchable. The recorded TV files have the exact same playback issues whether I play them back in MC or other software, such as VLC, so it's definitely not something like bad MadVR settings in MC.
(http://geoff-reynolds.net/IMG-0398.JPG)
-
It looks to me like the robt issue is different than greynolds, or at least the on-screen manifestations appear visually different. The robt issue looks like vsync / deinterlacing, while the greynolds issue looks like horizontal blocks or large areas of the video breaking up into a garbled mess.
Unfortunately, despite building a whole new server PC about 10 days ago, I am (still) having symptoms exactly like greynolds, although maybe less severe. All of my recordings are watchable, it's just sad having to see the video breakup 4 or 8 or 12 times per hour, knowing that MC used to be capable of flawless recording :'(
-
robt,
Thanks for posting the solution.
-
Excellent Robt.
Greynolds, maybe it is time for a complete uninstall of all MC versions on that PC, after suitable backups, and a clean reinstall of MC23?
It could be some corruption in madVR, LAV, or DirectShow filters, which don't get updated with every version. You could just try deleting madVR and LAV, and having MC reinstall them when you play videos. But if something has broken the JRiver DirectShow filters, which would be more consistent with this problem, a reinstall is probably best. I'm suspecting corruption or a bad install, rather than a bug. The Version 21, 22, 23 on one PC issue could have contributed. Or Windows protecting a DirectShow filter and putting an old version back into the system folder? Something like that. (Which reminds me; I must uninstall all the old versions I have on my PCs. I still get caught out with some file association trying to start MC22!)
Maybe check back through the Release Notes and see when the last madVR update happened. I think that wasn't that long ago. Maybe that is when the problem started.
-
Excellent Robt.
Greynolds, maybe it is time for a complete uninstall of all MC versions on that PC, after suitable backups, and a clean reinstall of MC23?
It could be some corruption in madVR, LAV, or DirectShow filters, which don't get updated with every version. You could just try deleting madVR and LAV, and having MC reinstall them when you play videos. But if something has broken the JRiver DirectShow filters, which would be more consistent with this problem, a reinstall is probably best. I'm suspecting corruption or a bad install, rather than a bug. The Version 21, 22, 23 on one PC issue could have contributed. Or Windows protecting a DirectShow filter and putting an old version back into the system folder? Something like that. (Which reminds me; I must uninstall all the old versions I have on my PCs. I still get caught out with some file association trying to start MC22!)
Maybe check back through the Release Notes and see when the last madVR update happened. I think that wasn't that long ago. Maybe that is when the problem started.
A fresh reinstall of MC23 strikes me as a pretty painful exercise and is something I'd prefer to avoid if I can. What settings will be restored from my library backup and what settings would I have to redo from scratch? Specifically, things like my Theater View settings, TV tuner configuration, hidden channels, and so on.
I have uninstalled all previous versions of MC at this point. After uninstalling the previous MC versions, I did run through the MC 23.30 install again this afternoon and did a "rescan" of the CableCard channels (which really just reloads the guide data - for CableCard MC doesn't do an actual scan using the tuners). Doing those things made no difference.
I can certainly try a fresh install of the SiliconDust stuff. If I exit MC and shut the service down first, MC presumably shouldn't even be aware that I did anything. I don't expect it to accomplish anything, but it should be easy enough to try and will help rule out one more potential culprit.
But some guidance from the JRiver folks would be appreciated...
-
I backed up from my old server machine, and restored into the new machine. Everything came over except channel icons and theaterview custom theme background so save those to a safe location, as well as any series cover art you want to re-instate.
-
Settings are saved with a backup and can be restored to a new installation. I believe what Tzr916 says is correct, although there were a few little things missed in the past. You may want to wait for Yaobing or someone else to confirm everything is now backed up and restored. Or search the forum for recent discussion on the topic.
I also think that in the case of uninstalling and reinstalling on one PC, the Channel icons, Theatreview Backgrounds, Series, and Season Cover Art will be left in place, and should be found again by MC. I believe backups from all versions are also left in place. But it wouldn't hurt to save a copy of such things somewhere before uninstalling.
-
TV channels are saved in MC as main database entries, and thus will be restored upon a library restore, including Hidden or Favorite status (which are in Keywords tag). As far as CableCARD channels are concerned, the only data saved in a channel are channel number and an optional audio PID. So re-scanning, as greynolds noted, just grabs the channel name and channel number from the EPG xml file and probably will not have an impact on video glitches.
robt uses DVB-T, that is quite different.
-
TV channels are saved in MC as main database entries, and thus will be restored upon a library restore, including Hidden or Favorite status (which are in Keywords tag). As far as CableCARD channels are concerned, the only data saved in a channel are channel number and an optional audio PID. So re-scanning, as greynolds noted, just grabs the channel name and channel number from the EPG xml file and probably will not have an impact on video glitches.
robt uses DVB-T, that is quite different.
So any guidance on how I should proceed and how much setup I would need to deal with if I completely uninstall MC and start over (with a library backup, of course)?
Will things like configured zones be saved in the library backup? Are all the folder settings (things like the recorded TV location) and the auto import configuration saved as part of the library backup?
I'm trying to get a feel for if this is something I can tackle quickly some evening after work or if it's something I better hold off till I have a bigger block of time free AND what I should do as far as taking notes and saving backups of files (series art, for example) that might get nuked when I uninstall MC.
-
So any guidance on how I should proceed and how much setup I would need to deal with if I completely uninstall MC and start over (with a library backup, of course)?
Will things like configured zones be saved in the library backup? Are all the folder settings (things like the recorded TV location) and the auto import configuration saved as part of the library backup?
I'm trying to get a feel for if this is something I can tackle quickly some evening after work or if it's something I better hold off till I have a bigger block of time free AND what I should do as far as taking notes and saving backups of files (series art, for example) that might get nuked when I uninstall MC.
@yaobing and @jimh any response to this? Please?
-
In general, settings are saved with library backup, and restored upon library restore. There may be rare exceptions. For instance, for a while I forgot to add TV channel ordering data to the backup (now it is part of the backup).
Recorded TV Location, yes it is restored. I don't use zones much, so I have no direct experience as to whether they are restored properly. They should.
Basically, you just need to:
1. Backup library
2. Uninstall
3. re-install
4. Restore library.
Have I missed anything?
-
In general, settings are saved with library backup, and restored upon library restore. There may be rare exceptions. For instance, for a while I forgot to add TV channel ordering data to the backup (now it is part of the backup).
Recorded TV Location, yes it is restored. I don't use zones much, so I have no direct experience as to whether they are restored properly. They should.
Basically, you just need to:
1. Backup library
2. Uninstall
3. re-install
4. Restore library.
Have I missed anything?
Thanks! If I get some time free in the next few nights, I'll take some notes on the items that are a bit unknown, such as zones, and give it a go. If I don't get time during the week, I should certainly be able to do it this coming weekend.
-
robt,
I split your last few posts to a new thread. https://yabb.jriver.com/interact/index.php/topic,111819.msg772447.html#msg772447
It does look like a completely different issue from greynolds'.
-
Greynolds, this thread should give you some confidence. Can't get a better test than carrying settings from Vista to a new Windows 7 installation.
https://yabb.jriver.com/interact/index.php/topic,111836.msg772753.html#msg772753
-
Greynolds, this thread should give you some confidence. Can't get a better test than carrying settings from Vista to a new Windows 7 installation.
https://yabb.jriver.com/interact/index.php/topic,111836.msg772753.html#msg772753
Yeah, I spent a bit of time actually looking through the contents of the library backup zip file and confirmed that things like all of my zones and Theater View settings are in there. I'm confident enough at this point to proceed and hope to have the time available tonight; if I don't get to it tonight it will probably have to wait until Saturday as I'm going to be busy Friday night.
-
I had some time available tonight, so I did the reinstall.
I did the following:
1) Make a library backup.
2) Uninstall JRiver. During the uninstall, I checked the option to remove all settings.
3) Uninstall the SiliconDust package / drivers.
4) Install the SiliconDust package / drivers and go through their setup.
5) Install JRiver 23.30.
6) Restore the library backup.
The good news is that all of my settings appear to have been restored, even my existing guide data remained.
The bad news is that this did not resolve the problem with live & recorded TV. :(
-
I had similar issues with the original DVB-T HomeRun after a few years of flawless use. Turned out it was the Power Pack slowing failing to deliver enough current to the HomeRun. May be worth trying a different Power Pack if you have one with enough current. Just grasping at straws however.
-
I haven't compared them in a long time. But when I was, I found that HD home run was using a lot more
Blurring on there viewer. I also had to force interlace to the right setting.
https://yabb.jriver.com/interact/index.php/topic,92170.msg634371.html#msg634371
-
I had similar issues with the original DVB-T HomeRun after a few years of flawless use. Turned out it was the Power Pack slowing failing to deliver enough current to the HomeRun. May be worth trying a different Power Pack if you have one with enough current. Just grasping at straws however.
Given that the issue doesn't exist when I record TV from the same pool of tuners in Windows Media Center (which is running on a separate PC but connected to the same HP ProCurve Gigabit switch as the MC PC and the tuners) or when I watch live TV using SiliconDust's viewer app, this seems unlikely. But it's certainly possible since I've got MC and WMC setup to grab the tuners in different orders.
-
I haven't compared them in a long time. But when I was, I found that HD home run was using a lot more
Blurring on there viewer. I also had to force interlace to the right setting.
https://yabb.jriver.com/interact/index.php/topic,92170.msg634371.html#msg634371
That definitely isn't the problem here as we aren't talking about something like a subtle overall softness to the picture where it just generally looks better played back via other means. If you look at the screenshot I posted above, the issue is that the picture is breaking up into rectangular green blobs and the audio keeps cutting out. It's also not a MC playback chain problem (such as having Red October set to HQ when the PC doesn't have the horsepower for it or choosing the wrong scaling options in the MadVR config) because the recordings made in MC fail to play in other players, such as VLC, too.
-
<meant to edit my post, not quote it>
-
Given that the issue doesn't exist when I record TV from the same pool of tuners in Windows Media Center (which is running on a separate PC but connected to the same HP ProCurve Gigabit switch as the MC PC and the tuners) or when I watch live TV using SiliconDust's viewer app, this seems unlikely. But it's certainly possible since I've got MC and WMC setup to grab the tuners in different orders.
Yeah I know your WMC install does not show the issue, but I brought it up after reading that you did have the same issue with the Silicon Dust viewer at one point as well. It is worth a shot. Mine was a dual DVB-T and I got these lost packets (video blocks, dropped audio) sporadically as well and could not work out what was going on (I thought it was poor signal quality). Anyway gave the logs to the SD guys and they suggested swaping the PSU out. Had one on hand that fit and had more than the necessary amperage and it solved the issue at the time (I have the V2 DVB-T tuner).
-
Yeah I know your WMC install does not show the issue, but I brought it up after reading that you did have the same issue with the Silicon Dust viewer at one point as well. It is worth a shot. Mine was a dual DVB-T and I got these lost packets (video blocks, dropped audio) sporadically as well and could not work out what was going on (I thought it was poor signal quality). Anyway gave the logs to the SD guys and they suggested swaping the PSU out. Had one on hand that fit and had more than the necessary amperage and it solved the issue at the time (I have the V2 DVB-T tuner).
I could easily swap the power supplies I have around. I've got 3 of the SD HDHomerun Primes. Recordings in WMC seem to be good 100% of the time (very occasional blips which IMO are to be expected once in a while, but never the blocky stuff or audio dropouts like I'm seeing in the JRiver recordings) while the recordings done in MC seem to be bad nearly 100% of the time and generally throughout the recordings. Another thing I could try is temporarily switching the tuner priority around in MC and see if that helps (simply disabling some of the tuners would do the trick). Swapping the tuner priorities around in WMC is a more difficult thing to try.
-
Good Idea. If you have a window without any recordings being done at all try MC on each tuner on each of the Homerun to see if it isolated to one tuner or if it is across all (it would help rule out the HW).
-
Testing one at a time would be good. Testing without WMC in the picture would also be good. It has caused problems in the past.
-
...the greynolds issue looks like horizontal blocks or large areas of the video breaking up into a garbled mess.
Unfortunately, despite building a whole new server PC about 10 days ago, I am (still) having symptoms exactly like greynolds, although maybe less severe. All of my recordings are watchable, it's just sad having to see the video breakup 4 or 8 or 12 times per hour, knowing that MC used to be capable of flawless recording :'(
I wonder what happened to greynolds?
My tv recordings have actually gotten much better after replacing my standard RF cable splitter with one of these: CSAPDU5VP five port passive forward/reverse amplifier (https://www.partfiniti.com/files/index/download/file/968596) I've tried amplifiers before, but this one is the only one that plays nice with modems and tuners. My ceton SNR numbers are way better, especially on the "local" mpeg2 channels. I'm close to retracting my statement about MC recording abilities being flawed. So far so good... let's see how it goes late Sept prime time premiere week.
-
I'd be interested in how Greynolds went as well. FYI - when I had this issue I:
- Replaced the antenna and had the signal strength measured at the mast head and the main point in the house
- Terminated all unused coax points
- Played with splitters, amps etc
- Sent logs to SD etc.... who then said, swap out the PS which fixed it.
-
Hey guys, I haven't responded for a bit because I just haven't had enough time to run a ton of tests. I started a new job recently...
My limited testing seems to suggest:
1) When only JRiver is accessing a tuner (whether it be OTA or CableCard), everything seems to be fine. Note that I haven't had a chance to test this as extensively as I'd like yet, so this is just a preliminary finding at this point.
2) When either or both WMC systems in the house (my brother and I each have separate PC's running Windows 7 & WMC all sharing the same pool of tuners) are using 1 or more tuners from the tuner pool the WMC recordings come out just fine without any issues and Live TV is fine.
3) When either or both WMC systems are using 1 or more tuners AND JRiver MC is using 1 or more tuners, the WMC recordings and Live TV are still fine, but the JRiver MC recordings and Live TV have the problems described earlier.
4) In any of the prior 3 scenarios, the SiliconDust viewer app running on the JRiver MC PC has absolutely no issues playing Live TV on either OTA or CableCard tuners, again from the same pool of tuners.
I have had JRiver configured to record to a UNC path (ie: \\{servername}\JRiverRecordings) for several years without any issues up until this point and I wasn't having any issues with TV recordings or Live TV up until recently. Reconfiguring JRiver to write to a local path (either to the same drive or a different drive) doesn't resolve the issue. In anticipation of the obvious question, I've gone with the UNC path as it makes it easier to move things around any time I want to as I just need to make sure the network share name is the same.
Given that there aren't any issues with recordings in WMC, I'm pretty confident that both my OTA and CableCard signal quality is fine and the readings I see in the SiliconDust for signal strength and quality are typically at or very close to 100% any time I check them.
JimH suggested that WMC has caused issues in the past, but that certainly doesn't explain why point number 4 works.
The only performance parameter that appears to be a bit concerning on the JRiver PC is that memory utilization tends to be in the ballpark of 70%, but CPU performance is typically below 10% and network utilization is usually well under 10% when JRiver is recording (and otherwise "idle", as in I'm not playing a video or listening to music).
-
So if all the above hold true after further testing, those results would point to MC not receiving the same priority as WMC or the SiliconDust viewer either on the network or from the SiliconDust Hardware / Firmware.
Another test you might try is to have both WMC PCs recording using all tuners, half on each say, and see if any of those recordings show any problems. If all recordings are good then the SiliconDust is capable of streaming from all tuners at once and it shouldn't be assigning a lower priority to MC that results in dropped packets and hence image breakup.
Do you have QoS (Quality Of Service) set up on all your MC PCs and intervening hardware?
Unless of course MC is just doing something different when another application is using a tuner on the same hardware, like issuing "keep the connection alive" commands or something. Only detailed logs at the SiliconDust end will show if that might be the case. A network packet sniffer on the MC PC might pick up dropped packets though, and confirm a network stream continuity issue.
Some nitty gritty work required.
-
So if all the above hold true after further testing, those results would point to MC not receiving the same priority as WMC or the SiliconDust viewer either on the network or from the SiliconDust Hardware / Firmware.
Another test you might try is to have both WMC PCs recording using all tuners, half on each say, and see if any of those recordings show any problems. If all recordings are good then the SiliconDust is capable of streaming from all tuners at once and it shouldn't be assigning a lower priority to MC that results in dropped packets and hence image breakup.
Do you have QoS (Quality Of Service) set up on all your MC PCs and intervening hardware?
Unless of course MC is just doing something different when another application is using a tuner on the same hardware, like issuing "keep the connection alive" commands or something. Only detailed logs at the SiliconDust end will show if that might be the case. A network packet sniffer on the MC PC might pick up dropped packets though, and confirm a network stream continuity issue.
Some nitty gritty work required.
I can pretty easily run a test with my WMC PC using a bunch of tuners, but would have to coordinate with my brothers to run a test with the 2 WMC PC's using an even split; perhaps over the long weekend. I have done this sort of thing in the past where I've had my WMC system simultaneously recording 12 channels (since I have 9 CableCard and 10 OTA tuners, it would obviously be a mix of OTA and CableCard) without any issues, but haven't run that specific test recently. Given that the problem surfaces with as few as 2 total tuners in use (JRiver using 1 and one of the WMC PC's using 1) and that I have recently had 3 recordings going on my WMC PC while my brother was using at least 1 tuner without any issues with the WMC recordings, I'm guessing that this test will go off without a hitch, but I'm certainly willing to give it a go.
QoS is turned on on my WMC and JRiver MC PC network adapter settings, I would have to have him check his. My HP ProCurve switch doesn't appear to have a QoS setting.
One thing that has certainly occurred to me is that the JRiver MC PC, which is running Windows 10, has integrated motherboard Intel networking, but is using Microsoft drivers because Asus/Intel don't have Windows 10 drivers available and the latest Windows 7 drivers available from Asus seem to be fairly ancient. Driver packages that are available direct from Intel won't install on the integrated motherboard chipsets. But again, if the SiliconDust viewer app isn't have any issues, why should I be blaming something other than JRiver?
FWIW, the JRiver PC has an Asus P6X58-E-WS motherboard, an Core i7 950 CPU, and has 12GB of RAM. Video playback of all other media (including Bluray rips and even 4K video files, all output at 1080P) is fine with JRiver configured for Red October HQ. I've tried switching to Red October Standard, but that doesn't make any difference (nor would I expect it to given that the recordings themselves have issues when played on other players such as VLC). Most of my JRiver recordings happen when JRiver is otherwise idle.
-
A test without WMC would be useful. MC has an option to disable WMC when needed. Please try that.
It's possible that WMC is just helping itself to some resources when needed.
The other solutions mentioned by jmone and RoderickGI might also be useful.
I know this is an important issue for you, but it just doesn't look like an MC problem at this point. Yaobing has spent a lot of time on it and he's excellent at finding problems.
-
A test without WMC would be useful. MC has an option to disable WMC when needed. Please try that.
It's possible that WMC is just helping itself to some resources when needed.
The other solutions mentioned by jmone and RoderickGI might also be useful.
I know this is an important issue for you, but it just doesn't look like an MC problem at this point. Yaobing has spent a lot of time on it and he's excellent at finding problems.
@JimH, based on your comments, it sounds like you're assuming that WMC is running on the same PC that JRiver is running on. As mentioned earlier in this thread and should be clear from my recent posts, WMC is running on separate PC's and can't be running on my JRiver PC because it is a Windows 10 system and WMC isn't available on Windows 10 (without some ugly hacks and even then I'm pretty sure recent updates have rendered those hacks useless).
And yes, this is a pretty important issue because the problem is making MC completely useless to me for TV functionality, which is a big part of my intended MC usage.
Given that the MC TV functionality had been working well up until the problem started a few months back, something obviously changed relatively recently that's causing the problem and I'm fairly confident it is something to do with the PC JRiver is running on (such as a Windows 10 update) or JRiver itself. Given that the SD Viewer works just fine on the PC, I'm more than a bit puzzled why you're so confident that the issue isn't a MC problem...
I'm more than willing to spend money to upgrade the hardware on this PC if I were confident that it would solve the problem, but I don't want to simply throw money at the problem when the same hardware had been working just fine for the TV functionality for the last few years and isn't showing any obvious signs of failure.
-
Did you try the suggestions of jmone about power supply, etc.?
I don't read the entire thread before posting.
-
Did you try the suggestions of jmone about power supply, etc.?
I don't read the entire thread before posting.
No, I haven't had time to try all the suggestions yet (which is why I hadn't posted an update until I was pinged last night). I don't think they all apply to my situation as I clearly don't have a signal strength issue given that ALL WMC recordings, both OTA and CableCard, are fine and the MC problem is for both OTA and CableCard channels.
With the long weekend coming up, I'm hoping to find some time to do things like swap the power supplies on my SD tuners around to hopefully rule out a bad power supply.
My gut feeling is that the problem is somehow network related, but I'm truly baffled why the SiliconDust viewer app works just fine on the same PC if that's the case. Windows is also claiming a pretty low network utilization percentage, but it certainly wouldn't be the first time that motherboard integrated networking was the culprit for weird network problems, though issues are usually with non-Intel based integrated networking.
-
I clearly don't have a signal strength issue given that ALL WMC recordings, both OTA and CableCard, are fine and the MC problem is for both OTA and CableCard channels.
I don't think you should assume anything. Try to keep an open mind about where the problem is.
I'm close to retracting my statement about MC recording abilities being flawed. So far so good...
-
I don't think you should assume anything. Try to keep an open mind about where the problem is.
Keeping an open mind is obviously important. But at the same time, I'm attempting to narrow the scope of possible issues so I can hopefully track down the culprit. Given that I'm having absolutely no signal strength problems with my WMC recordings across the same pool of tuners and the same channels (I currently have WMC and JRiver setup to record the same shows with the long term goal being to eventually shut down WMC), it strikes me as reasonable to rule out issues with my antenna, distribution amp, and cables and with my cable TV signal, splitter, and cables. If I had a signal strength problem, I would expect to see the same problem in WMC and the SiliconDust Viewer app.
-
Ok, so I was able to leave work early and run a few tests during the course of the afternoon and early evening. Here's what I've found so far:
1) JRiver MC Live / Recorded TV was still having issues recording even just 1 TV show or playing Live TV even if no other tuners are in use by the 2 WMC PC's.
2) The SiliconDust viewer app continues to play Live TV on the same PC that JRiver is installed on without any issues.
3) I ran a network bandwidth test between my JRiver MC PC and one of my other PC's using the iPerf utlility and ended up with TCP performance numbers just under 1Gb in both directions over several test runs. This suggests that the switch and network cables are OK and that the network ports in the PC's are good. This didn't test huge amounts of data, but at least confirms that I don't have a bad network cable that's limiting me to 100mbps performance on the JRiver PC. My understanding is that the iPerf tests check for things like data errors and data loss and no errors were reported.
4) I started 13 (yes, THIRTEEN) recordings on my WMC PC (8 CableCard and 5 OTA) while my brother has a CableCard recording going on his WMC PC and I'm using the SiliconDust viewer app to watch another OTA channel on the JRiver PC. Despite WMC being a bit sluggish due to all the activity, each of the 13 recordings will play without any audio or video issues, my brother isn't complaining about any issues, and the SiliconDust viewer app is displaying the channel just fine. This test is making use of all 9 SiliconDust CableCard tuners and 6 of the 10 SiliconDust OTA tuners. I let this test run for 15-20 minutes before I started to cancel the recordings so I can get on with watching something shortly.
5) I'm going to go out on a limb and go with the assumption that my tuners and reception are not the issue.
6) Something else I JUST did after completing the big recording test was to run the SiliconDust HDHomeRun Setup program again on the JRiver PC and switch the BDA Compatibility Mode away from J River Media Center (to Default), clicked the Apply button, then closed the app. I then re-ran it and switched back to J River Media Center mode and clicked the Apply button again. After doing this, Live TV in JRiver seems to be OK at the moment. I've had temporary success a few times over the last few months, so it's definitely too soon to declare victory, but at this point I'm going to stop experimenting and see what happens over the next few days. I'll also keep my fingers crossed...
-
That was short lived; the problem is back again...
-
Is it on every tuner?
-
That was short lived; the problem is back again...
But it does say something about the nature of the problem, doesn't it? My understanding (because I don't have these tuners to test) is that there is no driver for these network tuners. Rather the setup program is used to configure the tuner firmware directly, in the case of MC, telling it for example that it will be talking to a MC installation.
Could it be that the WMC installations then come along and tell the tuners that they are working with a WMC installation, and changes the setting back? They may be able to do that without running the SiliconDust HDHomeRun Setup program.
Obviously there is a difference between the way the two applications work with the tuners, other wise there wouldn't be a separate BDA Compatibility Mode for J River Media Center.
Perhaps shut down the WMC PCs altogether, then run the SiliconDust HDHomeRun Setup program again, switch the BDA Compatibility Mode as you did before, then see how long MC runs without the issue, and without the WMC PCs running.
If you could do the above for a few hours while using MC, then start the WMC PCs again and see how long it takes for the problem to return, you may be able to confirm the above.
Why did it work before and stop working now? Well, there were some firmware changes on the SiliconDust HDHomeRun tuner not so long ago weren't there? Regardless, MC has required HDHomeRuns to use the JRiver setup profile for some time, and what you did fixed the problem.
Is there some way to read the configuration of the SiliconDust HDHomeRun tuners without using the setup program? Perhaps with a browser directly. Just to confirm what the setting is in the tuner.
EDIT: Perhaps by going to the http://my.hdhomerun.com/ page, which seems to try to detect a HDHomeRun.
-
Yep, it looks like you have an incompatibility in setup requirements. See http://my.hdhomerun.com/instructions/windows-media-center/
Windows Media Center
HDHomeRun Setup:
Launch HDHomeRun Setup.
Set the BDA Compatibility Mode to Windows Media Center.
Set the Signal Type
Click OK to save and exit.
You can't have the BDA Compatibility Mode set to both "Windows Media Center" and " River Media Center" at the same time. So it looks like WMC and MC have been fighting over the tuners. Or more correctly, WMC has been trashing the setup MC needs. Maybe SiliconDust can confirm, or their diagnostic logs might show something.
Also their Firmware Changelog shows a couple of things that may have an effect, plus better logging. Are you on the latest firmware? https://www.silicondust.com/support/downloads/firmware-changelog/
Actually their Software and Firmware Changelogs are pretty good, going back to the beginning. Kudos to them. https://www.silicondust.com/support/downloads/
Jim, is there any reason why JRiver isn't mentioned along with other 3RD PARTY MEDIA CENTER APPLICATIONS (https://www.silicondust.com/live-tv/#devices) on the SiliconDust site? After all, they have had JRiver Media Center support for nearly eight years. 8)
PS: My humble apologies if I am completely wrong, because, as I said, I don't have or use these tuners.
-
RoderickGI
Thanks for all the help.
I don't know why SiliconDust doesn't give JRiver more attention. They clearly know we're here. For many years, most of their business was probably centered around WMC, so maybe they let other things slide a little. If enough users asked, they might add JRiver.
-
Jim, many of the other Media Center products on the SiliconDust Third Party software section just have a logo and behind that a link to their web page or forum. I thought you might like to send a Logo file to them and the link to the forum, for them to add to that section. Shouldn't take much other than asking, I would think. Couldn't hurt.
Oh, and you a welcome.
-
But it does say something about the nature of the problem, doesn't it?
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.
My understanding (because I don't have these tuners to test) is that there is no driver for these network tuners. Rather the setup program is used to configure the tuner firmware directly, in the case of MC, telling it for example that it will be talking to a MC installation.
Could it be that the WMC installations then come along and tell the tuners that they are working with a WMC installation, and changes the setting back? They may be able to do that without running the SiliconDust HDHomeRun Setup program.
Obviously there is a difference between the way the two applications work with the tuners, other wise there wouldn't be a separate BDA Compatibility Mode for J River Media Center.
Perhaps shut down the WMC PCs altogether, then run the SiliconDust HDHomeRun Setup program again, switch the BDA Compatibility Mode as you did before, then see how long MC runs without the issue, and without the WMC PCs running.
If you could do the above for a few hours while using MC, then start the WMC PCs again and see how long it takes for the problem to return, you may be able to confirm the above.
Why did it work before and stop working now? Well, there were some firmware changes on the SiliconDust HDHomeRun tuner not so long ago weren't there? Regardless, MC has required HDHomeRuns to use the JRiver setup profile for some time, and what you did fixed the problem.
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. So you can't expect JRiver and WMC to play nicely with the tuners if both software packages are running on the same PC, but should be able to expect them to play nicely when running on separate PC's with the SiliconDust software configured appropriately on each PC.
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.
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'll have to coordinate this with my brother) but I'm not going to leave them that way when we have recordings scheduled as I just can't rely on the JRiver recordings to be playable at this point. A brief test window like that could potential provide some useful info if the TV problem remains, but won't be a long enough sample set to be useful in determining if the problem is related to JRiver and WMC fighting over tuner configuration.
One other thing I can try is to reconfigure JRiver to make use of some OTA PCIe tuners I have installed in that PC and record / watch some TV using those tuners. Those tuners are currently assigned to BeyondTV (which has coexisted just fine with JRiver for 4+ years now, but without any tuner sharing going on), but I can certainly pirate them for testing purposes and perhaps permanently as I really haven't made use of BeyondTV for quite some time now. That would at least give us some more data to work with, but obviously wouldn't resolve the problem for CableCard content.
-
One way I know WMC does not play nicely is that it grabs a tuner as if no other applications will ever use the device. It does not test whether the device is already in use before it tries to use it, on different machines or on the same.
-
One way I know WMC does not play nicely is that it grabs a tuner as if no other applications will ever use the device. It does not test whether the device is already in use before it tries to use it, on different machines or on the same.
WMC attempts to grab a tuner. But when the tuner WMC is trying to grab is in use, WMC displays a popup message that the tuner isn't available (or something similar) and then moves on to the next tuner based on the configured priority, but I've never seen it cause any actual problems elsewhere, such as messing up a recording that was already in progress in JRiver as the SiliconDust drivers won't allow the software that's requesting the tuner to force the existing connection to break. Up until the recent problems, JRiver and WMC have been sharing the same pool of tuners without any problems for quite a while. I've carefully configured tuner priorities in JRiver and the 2 WMC PC's to minimize the odds of more than 1 PC attempting to grab the same tuner as those popup messages in WMC, while harmless, get to be annoying when they happen.
The TV problem with JRiver also happens if no other SiliconDust tuners are in use (which can be verified with their HDHomeRun Config app, which shows the IP address each tuner is connected to or "none" if the tuner isn't currently in use).
-
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.
-
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):
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)
-
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.
-
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?
-
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.
-
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.
-
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.
-
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,
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.
-
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. 8)
-
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.
-
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.
-
Fingers crossed....
-
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).
-
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
-
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.
-
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.
-
...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.
-
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.
-
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/ (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... ;D
-
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.
-
Thanks for the update - hoping it holds well.
-
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.
-
Glad to see it is working and hence no need to rush. :)