Print

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

[greynolds]

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

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.

[Yaobing]

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

I appear to be having the same problem the poster in that thread was having (audio dropouts and lines through the video during playback).

Code: [Select]

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.

[greynolds]

Code: [Select]

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.

[Yaobing]

If JTV recordings have the same issue, then there must be a different cause.  It could be a network issue.

[greynolds]

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.

[JimH]

Same machine?

[greynolds]

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.

[Yaobing]

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.

[jmone]

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.

[JimH]

It's unfair to use someone's words for your own purposes.  Shameless, in fact.  Totally out of context.

[RoderickGI]

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.

[jmone]

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    but Hendrik's quote came from the JTV to TS Remuxing Thread

[tzr916]

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

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.

[greynolds]

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.

[greynolds]

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.

[tzr916]

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).

[greynolds]

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?

[tzr916]

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...

[greynolds]

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.

[greynolds]

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:

Code: [Select]

=== 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.

[JimH]

Not bleeding edge, just fair.

[greynolds]

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?

[greynolds]

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.

[JimH]

Another possibility is a recent Windows update.  We've just seen a few too many of these lately.

[greynolds]

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.

[Yaobing]

I don't know if I already asked this, is network connection in good shape on this computer?

[greynolds]

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.

[greynolds]

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.

[RoderickGI]

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.

[greynolds]

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.

[RoderickGI]

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.

[greynolds]

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.

[RoderickGI]

Good point. 

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! 

[greynolds]

Good point. 

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! 

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.

[greynolds]

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...

[Yaobing]

Could Windows Media Center running on another machine be trying to access the tuner somehow?

[greynolds]

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.

[tzr916]

....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?

[greynolds]

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), 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.

[greynolds]

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.

[robt]

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

[robt]

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!

[robt]

I've managed to grab a screen capture which at least partly demonstrates whats going on.

[Yaobing]

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.

[robt]

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.

[Hendrik]

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?

[robt]

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....

[JimH]

Have you modified madVR settings from the default settings MC uses?

What happens if you play using Red October Standard?

[robt]

One more post. This grab is from the same recording, played back on a different machine using VLC.

[robt]

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.