Print

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

[Yaobing]

Something else is going on.

Can you confirm that build 77 is the one that breaks it?

[JimH]

I looked but didn't see... What antivirus are you using?

[tzr916]

I looked but didn't see... What antivirus are you using?

None. Windows Defender > Real-time Protection is disabled, MC22 listed in Firewall Allowed Apps.

[tzr916]

Can you confirm that build 77 is the one that breaks it?

Confirmed v77 log:

https://drive.google.com/file/d/0B82GqdDf8HSycFZ6YjR2S1FwU3c/view?usp=sharing


Screenshot:

[Yaobing]

Please try this DLL with MC22.0.110 (install 110 first, then copy the DLL).

This one is a most thorough rollback to pre- .77 code.  Unfortunately my initial test on my machine shows it is not as good as original .110, but I would like to see how it does on your computer.

[tzr916]

Please try this DLL with MC22.0.110 (install 110 first, then copy the DLL).

This one is a most thorough rollback to pre- .77 code.  Unfortunately my initial test on my machine shows it is not as good as original .110, but I would like to see how it does on your computer.

Installed 110, copied DLL. Record 3x HDHRP & 3x Ceton.
Same high cpu usage.

[Yaobing]

 

Is the high CPU usage still attributed to JRTelevision.dll?


How about re-setting logging verbosity to 0?

[tzr916]

I already had log verbose to zero.

I will have to do another test with Process Explorer to see if it's still JRTelevision.dll

[JimH]

None. Windows Defender > Real-time Protection is disabled, MC22 listed in Firewall Allowed Apps.

There is a Windows Defender topic on our wiki.  Please take a look there.

[tzr916]

There is a Windows Defender topic on our wiki.  Please take a look there.

Sure. But how do you imagine that MC 22.0.77 behaves differently than MC 22.0.76 because of Windows Defender!? Strange place to go IMO.

EDIT: Added all the JRiver services to the Firewall exclusions. Made no difference. High CPU versions after 76.

[tzr916]

Is the high CPU usage still attributed to JRTelevision.dll?

How about re-setting logging verbosity to 0?

Yes still JRTelevision.dll

Process Explorer screen shots:

[JimH]

Sure. But how do you imagine that MC 22.0.77 behaves differently than MC 22.0.76 because of Windows Defender!? Strange place to go IMO.


EDIT: Added all the JRiver services to the Firewall exclusions. Made no difference. High CPU versions after 76.

Firewall and antivirus are different.

Yes, it's possible.

[Yaobing]

Please try this one with 110.

[tzr916]

Please try this one with 110.

No change....

[Yaobing]

No change....

?

How about this one?

This DLL was created at 10:34 AM today, Central DST.

[tzr916]

?

How about this one?

This DLL was created at 10:34 AM today, Central DST.

Looks pretty good   

Recorded 6 channels for 3 minutes. CPU stayed mostly between 13%-19%, but for a small time it jumped to 55%, then settled back down. All recordings clear, except when that cpu jump occurred- the video garbled for about 10 seconds then went back to normal.

Let me know if I should try recording for a longer period of time, or maybe you have more tweaks in mind...


Thanks so much!

[Yaobing]

Looks pretty good   

Recorded 6 channels for 3 minutes. CPU stayed mostly between 13%-19%, but for a small time it jumped to 55%, then settled back down. All recordings clear, except when that cpu jump occurred- the video garbled for about 10 seconds then went back to normal.

Let me know if I should try recording for a longer period of time, or maybe you have more tweaks in mind...


Thanks so much!

Thanks. I will now need to add back features a bit at a time until I find out exactly what was causing it.  Please bear with me as I will need you to test a few more versions

[tzr916]

Will do.

[Yaobing]

How does this one work?

[tzr916]

Not good. MC cpu is high again. Not quite as high as before (86-95%), now it's more around 73-82%. High enough to make all the recordings a garbled mess of video.

Switching back to previous version DLL

[Yaobing]

This one should be good!

[tzr916]

Oops... MC cpu back up to 90-93% 

[Yaobing]

Oops... MC cpu back up to 90-93% 

I got reduction in CPU usage on my computer (but the usage has never been too high in the first place).

Did you use "extra buffer"?  What happens if you turn logging completely off (Help > Logging > uncheck "Output to a log file")?

[tzr916]

Logging was set to verbose 0.
Extra layer buffer was On.

Will have to wait until tomorrow AM for more testing.

[Yaobing]

Please try this one.

[tzr916]

Please try this one.

Not good. MC cpu 89-93%

Logging OFF
Extra buffer OFF

[Yaobing]

Please try this DLL.

[tzr916]

Please try this DLL.

Looks ok, something not quite right.... Six channels recording at same time for 4 minutes.

MC cpu is 12-18%, with occasional spikes of 23-25%. Seeing some video breakup on each recording at the same points in the timeline - suspect when cpu is spiking to 25%.

[Yaobing]

It looks like several things together pushed your computer to the limit.  So far I identified two, and there are more.

[tzr916]

It looks like several things together pushed your computer to the limit.  So far I identified two, and there is/are more.

I appreciate all the help and I understand this is quite puzzling. Are you able to provide more details why you think this has something to do with my computer?

I hope you can understand what this looks like from my end:
1. Nothing about my computer, or tuners, or network has changed in two years of recording tv with MC. Same hardware, same OS, same tuners, same network switch and router, etc.
2. This whole setup works flawlessly with MC 22.0.76 and earlier - MC cpu less than 15%, no spikes, no bad spots in the video.
3. MC 22.0.77 release notes indicate a change in TS file recording, which is exactly when I started seeing intermittent video breakup issues.
4. Your work in the past few days on JRTelevision.dll shows that some versions of the DLL have way out of whack crazy cpu usage, while a other versions are much much lower.

I'm not a programmer, but I have been building PC's and networks for more than 20 years. I ran WMC on this same system for 3 years prior to switching to MC. To me, with all of the above evidence, it just doesn't make any sense how my computer could be at fault. Please enlighten me.

[JimH]

I'm not a programmer, but I have been building PC's and networks for more than 20 years. I ran WMC on this same system for 3 years prior to switching to MC. To me, with all of the above evidence, it just doesn't make any sense how my computer could be at fault. Please enlighten me.

Classic.

[tzr916]

Taking the high road... Working with Yaobing to actually work out (possible) bugs in MC appears to have been fruitful. It might even lead to all around improvements in MC that everyone can benefit from.

[Yaobing]

I did not even say that your computer is to blame, except that we just verified that with some code set your computer reacted worse than some other computers.  I am still trying to find the best way to avoid pushing computers like yours to the limit.  One thing that I have already determined to be a factor is excessive logging.  So it may be possible your C:\ drive, or whichever drive the log file is written to, is weak.  There are other factors as reducing logging did not help a lot on your computer.  It is possible that all that "extra buffering" stuff I added was counterproductive.  So I will try doing away with it.

[JimH]

Under MC's Help menu, run the benchmark utility and paste the results here.

[jmone]

If I read it right, your HDD(s) are 5 years old and could be at the end of life (with bad sector remapping causing performance issues).  See if HDS reports any issues.

[Yaobing]

Please try this DLL.

[tzr916]

Will be trying the new DLL soon.

Yes, I know I have an older system, but it is not compromised whatsoever... Using the maximum cpu/ram possible, and the hard drives are rated twice as "fast" as the mobo interface. To those suggesting my hardware has problems, I have attached a few reports. Hard disks are all 100%. Jmark is not as high as others I've seen here, but this has no meaning considering the facts in this thread.

[JimH]

Not a great machine for doing as much as you're asking it to.

From your Jrmark.txt file:

Abit socket 775 ATX SATA II
Q9450 Core2 Quad 2.66GHz
CPU features: MMX, SSE2, SSE3, SSSE3, SSE4.1
8GB PC2 6400
OS drive: Samsung SSD 840 EVO 120GB
DATA drive: WD AV-GP WD20EURX 2TB
GB LAN
NVIDIA GT640
Windows 10 64-bit





=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 4.359 seconds
    Single-threaded floating point math... 2.589 seconds
    Multi-threaded integer math... 2.580 seconds
    Multi-threaded mixed math... 1.347 seconds
Score: 1747

Running 'Image' benchmark...
    Image creation / destruction... 0.549 seconds
    Flood filling... 1.384 seconds
    Direct copying... 1.949 seconds
    Small renders... 2.177 seconds
    Bilinear rendering... 1.385 seconds
    Bicubic rendering... 0.931 seconds
Score: 2627

Running 'Database' benchmark...
    Create database... 0.420 seconds
    Populate database... 2.295 seconds
    Save database... 0.553 seconds
    Reload database... 0.111 seconds
    Search database... 2.195 seconds
    Sort database... 1.729 seconds
    Group database... 1.049 seconds
Score: 2574

JRMark (version 22.0.110): 2316

[JimH]

It's missing some sections.  You could run it again and just paste the text here.

[tzr916]

Not a great machine for doing as much as you're asking it to.

I hear your opinion, but it's moot given the facts in this thread. The main ones being- this system has worked flawlessly for 2 years with all versions of MC up until 22.0.77 (when release notes indicate a change in TS file recording method), and work in the past few days on JRTelevision.dll shows that some versions of the DLL have way out of whack crazy cpu usage, while other versions are much much lower (equal to version 22.0.76).



Nothing missing from Jmark. This is the whole thing:

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 4.344 seconds
    Single-threaded floating point math... 2.578 seconds
    Multi-threaded integer math... 2.342 seconds
    Multi-threaded mixed math... 1.305 seconds
Score: 1798

Running 'Image' benchmark...
    Image creation / destruction... 0.537 seconds
    Flood filling... 1.072 seconds
    Direct copying... 1.904 seconds
    Small renders... 2.132 seconds
    Bilinear rendering... 1.349 seconds
    Bicubic rendering... 0.906 seconds
Score: 2785

Running 'Database' benchmark...
    Create database... 0.400 seconds
    Populate database... 2.233 seconds
    Save database... 0.534 seconds
    Reload database... 0.114 seconds
    Search database... 2.065 seconds
    Sort database... 1.681 seconds
    Group database... 1.095 seconds
Score: 2647

JRMark (version 22.0.110): 2410

[JimH]

I'm sorry, but we're not going to spend more time on this.  The erratic results you're seeing when testing don't make sense and could be explained by a problem with your machine.

We've spent a few thousand dollars of development time on this.  It's your turn.

[tzr916]

Please try this DLL.

Not good.

MC cpu all over the place 16-45%. Recordings are garbage.

[Yaobing]

This one should be it.

This one, as well as the one I posted on Wednesday morning, is the closest to build 76 that I can do.  It should be the best we can do.

[tzr916]

30-45% with spikes to 70%

[tzr916]

v110 with tweaked DLL (least cpu per my testing) has already produced bad recordings in the first night of normal use. Last night recorded only 3 higher bitrate local channels at the same time and watching them today. Unfortunately there's one or two short bad spots in each show. This is not even close to on par with what MC has been doing, and doing so well, for the past 2 years. I'm definitely going back to v76.


I would really like to continue to stay up to date with MC because there are many outstanding feature/bug requests beyond v76 (plus I paid for v23). If the the ball is truly in my court, I'm taking suggestions. But I think it is important to note -> if you go back to the first page of this thread, you will see that I did not start this. In fact, before these MC changes were made, myself and two others clearly stated that we use TS recording and were not having any problems.

[JimH]

Sure. But how do you imagine that MC 22.0.77 behaves differently than MC 22.0.76 because of Windows Defender!?

Did you ever read the wiki topic on Windows Defender?  Last I saw, you thought it couldn't possibly be the problem.

https://wiki.jriver.com/index.php/Taming_Windows_Defender

[tzr916]

Did you ever read the wiki topic on Windows Defender?  Last I saw, you thought it couldn't possibly be the problem.

https://wiki.jriver.com/index.php/Taming_Windows_Defender

Yes, I even posted that I added all the MC services as per the wiki.

[CountryBumkin]

What's odd - is that you seem to be the only one reporting this problem.

Something in ver 77 may have changed and that change may have uncovered a flaw in your tuner card. Maybe not a flaw, but something specific to your Tuner/system.

I would suggest you get another Tuner Card (just a cheap USB. Or internal one if you have the room) so you can see if this problem goes away when using a different Tuner. I see USB Tuners on Amazon for under $30.

[JimH]

Are your tuners network tuners?

[tzr916]

What's odd - is that you seem to be the only one reporting this problem.

Something in ver 77 may have changed and that change may have uncovered a flaw in your tuner card. Maybe not a flaw, but something specific to your Tuner/system.

I would suggest you get another Tuner Card (just a cheap USB. Or internal one if you have the room) so you can see if this problem goes away when using a different Tuner. I see USB Tuners on Amazon for under $30.

I have TWO tuner devices- see my signature.

The problem occurs equally on both- see posts in this thread tested both devices separately.

There is no USA cable card USB tuner that I know of.

The only internal cable card would be Ceton - hard to find and going for over $230.