INTERACT FORUM
Windows => Television => Topic started by: Chris.s on February 09, 2017, 02:18:47 pm
-
I'm new to JRiver and these forums, so if there is a topic out there for this already, I apologize for duplicating it.
I am still evaluating whether to purchase a license for JRiver because I am having some issues with the TS format on television recordings. The video is VERY choppy. I've verified I have good OTA signal and I checked multiple channels using different tuner cards I have (different brands) and I have the same problem..
I ran across an article about the problem started after version 22.0.21. I downgraded to that version and all my TV recording issues went away. I have excellent high quality TV recordings now. My primary use for my media center is to record shows for me, my wife and kids, and I don't want to be stuck on an old version because anything newer has issues. So before I purchase a license I want to see if there is fix for this problem.
Has this issue be addressed or talked about? Is there a solution to this problem?
-
Can you remind me what problem was introduced in build 22.0.21? A link to the article that you read would be great. What version did you try that was problematic?
-
I use ts and everything is fine. I would check Video playback settings.
Are you using Red October Standard or HQ in your video settings? switch etween the 2 and see if it helps
-
I tried to relocated the article I came across, but couldn't find the exact one. I did, however, locate a post on the forum regarding the same issue with .ts playback in version .32 and newer. I have tried .59 and .71 and the issue is there in both.
https://yabb.jriver.com/interact/index.php?topic=107543.0
imeric: I've used both Red October and HQ and the issue is there in both. The playback issues are there with .ts files recorded in versions higher than .21 that I am on, even if I attempt to watch the recordings outside of MC or even on different computers. However, recording and playback on version .21 both in and out MC and on different computers is great! No issues!
-
There was an important change in 22.0.32:
22.0.32 (9/30/2016)
5. Changed: Internal changes in television recording in transport stream format. Users should not notice anything different. Please report any unexpected behaviors.
Can you confirm that the problem started in this version? What are the specs of your computer? I am wondering if my change in that build caused too much resource usage.
-
I can download .32 when I get back home and test to see if the problem exists in that version and let you know..
My MC Specs:
Intel 2nd Gen Quad Core i5 (3.2gig)
Windows 7 - 32 bit
4 Gigs RAM DDR3
Video: ATI Radeon 5550 HD HDMI
-
I loaded 22.0.32 and confirmed the problems exist.
-
Thanks. I will do more testing.
-
I loaded 22.0.32 and confirmed the problems exist.
I have always used TS with MC, never ever had any issues.
Are you recording to LOCAL disk SATA on the Server? or network or NAS or?
Can you record a short clip and upload to google docs or something, so others can try and play it?
-
Sure! I'm recording to a local SATA disk.
I've attached links to several clips. I've tried to play these on multiple computers and devices, and tried multiple TV tuners, brand and different channels. I have a powered ATSC antenna on my roof and have very good signal with most channels. That was the first thing I checked. Playing Live TV with any version of JRiver worked without an issue, only recording was where I ran into issues.
Bad Recordings:
(This one REALLY freaks out about half-way through) https://drive.google.com/open?id=0B6opD7WxamP7ckIzclNKMmY0MVk
https://drive.google.com/open?id=0B6opD7WxamP7ZHR1cW56TUdEd1k
Good Recording: (22.0.21)
https://drive.google.com/open?id=0B6opD7WxamP7WnpkTnpvaXV3T3c
If more example are needed, I can quickly load a new version and do some recordings. The results are easily reproducible.
-
....I have a powered ATSC antenna on my roof and have very good signal with most channels....
Maybe too much "signal"? Yes there is such a thing as too much amplification. I would go with a non-amplified high quality uni-directional antenna over an amplified multi-directional.
I also noticed the good recording is a completely different channel than the bad recording. When testing, might be best to stick to one channel, to rule out signal quality differences.
-
Maybe too much "signal"? Yes there is such a thing as too much amplification. I would go with a non-amplified high quality uni-directional antenna over an amplified multi-directional.
I also noticed the good recording is a completely different channel than the bad recording. When testing, might be best to stick to one channel, to rule out signal quality differences.
This won't affect recording quality. If it plays fine when watching live and is only choppy when recording or watching recordings I would suspect video playback settings or system performance.
Chris this is correct right? Playing live TV trough MC is OK?
-
Correct on the live TV. System performance is excellent as this is the ONLY playback issue I have, and with that, the playback issue show up ONLY after I upgrade MC above version 22.0.21 with changing nothing else. I've experienced playback issues with these recorded files on multiple computers and multiple devices so I can rule out system performance on my server. Anything I record and play from 22.0.21 plays great, I have no issues at all there....
tzr916: channel makes no difference. I'll upgrade MC and do some records from the same channel today for you to see.
-
Here are some more examples. This was recorded this morning, within 10 minutes. I did a recording on the SAME channel, using 3 different versions. This is recorded to the local disk.
Channel 24.1 - 22.0.21 - https://drive.google.com/open?id=0B6opD7WxamP7YXk0aHV2dGJPSjQ
Channel 24.1 - 22.0.32 - https://drive.google.com/open?id=0B6opD7WxamP7d1FLcjd1LUZTZFU - random distortion lines and audio distortion
Channel 24.1 - 22.0.71 - https://drive.google.com/open?id=0B6opD7WxamP7aDUybGw2ekpTWEU - random distortion lines and audio distortion
Channel 24.1 - 22.0.21 Once Again - https://drive.google.com/open?id=0B6opD7WxamP7UUJ5T25fM3NQZ1U
In my opinion, this is not a signal issue, this is an encoding issue.
-
Tell us about your equipment.
What computer (CPU/Mem, drive size (free space), OS)
What Tuner Brand (internal, USB, etc).
You are recoding over-the-air, right?
-
Intel 2nd Gen Quad Core i5 (3.2gig)
Windows 7 - 32 bit
4 Gigs RAM DDR3
Video: ATI Radeon 5550 HD HDMI
OS Disk: 500G (225G free)
TV Disk: 1TB (425G free)
Movie Disk 500G (182G free)
All disks are SATA 7200RPM
Tuners: ATI TV Wonder 650 PCIE, ATI TV Wonder 750 USB, HDHomeRun dual ATSC Network Tuner (OTA yes)
-
Sorry, I see you already posted your specs once. Not sure how I missed that.
Your system should not be a problem with regards to recording TV, but your video card may be a little weak if you're playback with RO+HQ (madVR) in anything more than its default settings. But that would affect all playback not just .ts recordings. There are also a couple of posts here about madVR problems with the ATI video cards.
I record only to .ts format. I have not noticed any problems with the current MC version. I don't think it is the software as much as the hardware causing your problem. But it might be worth a try to uninstall and reinstall MC. Be sure to back up your library first.
Do you see the problem when recording with both tuners?
Try just with the USB Tuner. IMO, the network tuners have a lot more trouble than the non-network ones.
-
I have attempted to isolate tuners but the results were the same. I can record multiple shows simultaneously without any issues on version .21.
I do not have ANY issues recording, or playing back anything recorded on version .21. Any version higher than that, I start to have issues. I do not believe it's a hardware or tuner issues with these results from my testing.. I can playback any other format perfectly on MC.
I show the same playback issues on MULTIPLE computers other than my MC, as well as on multiple devices (iphone, ipad) when I record a show with a version higher than .21.
Anything recorded on version is perfect, as shown in the examples I've posted.
-
I have done a lot of testing and can partially confirm that there may be a problem. But I am not sure we are looking at the same problem though. On my work computer there is no problem at all. On a laptop, I see problems when recording is started. I can not explain why you have no problem with build 22.0.21 since I can not identify anything changes after that build that might cause the issue. In my testing, the quality issue exists even in builds 20 and 21.
-
So after doing some more testing and playing around some more. I installed VLC and AC3 filters and loaded .71. So far I have not experience any recording issues. I know that VLC installs some additional codecs. Gonna continue testing and will update later.
-
Strange stuff.... I wonder if it's a Windows 7 32bit thing? I run Windows 10 64bit on my MC Server and don't have VLC or any extra codecs/filters installed.
-
I'm getting something similar with 22.0.59 - just about every recording has a pixelation glitch with a loss of a second or two of recording. Ceton card, Win 10 x64 recording to SSD system drive. Never seen it watching live, it's only recording to disk. Is there any kind of priority setting I can use to give the recording process higher priority? Should I try recording to a separate drive instead of the system drive?
-
Do you have antivirus software monitoring the TV recording folder?
Anyway, I made some changes in an attempt to make recording more efficient. Not sure whether it will make any difference (and I certainly hope it will not be worse). Please install the latest (build 71) first, then download, unzip, and copy JRTelevision.dll (https://www.dropbox.com/s/o5b3m8tce8f8ntv/JRTelevision.zip?dl=0) into MC installation folder.
-
..... I made some changes in an attempt to make recording more efficient. Not sure whether it will make any difference (and I certainly hope it will not be worse). Please install the latest (build 71) first, then download, unzip, and copy JRTelevision.dll (https://www.dropbox.com/s/o5b3m8tce8f8ntv/JRTelevision.zip?dl=0) into MC installation folder.
Installed yesterday afternoon and all recordings look good.
Is this special .dll included in version .74?
-
Installed yesterday afternoon and all recordings look good.
Is this special .dll included in version .74?
No. It will be in .76.
-
No. It will be in .76.
STOP. Do NOT do it....
I just reviewed ALL the recordings from last night and 5 out of 24 of the recordings came out really FUNKY:
- The DURATION of these 5 shows are reported as extremely long, like 26 hours or 19 hours.
- Playing the show back works (picture and sound is good), as long I don't try to rew or ff, then it seems to go back to beginning of the show.
- Tuners started and stopped fine.
- size on disk appears normal.
- Comskip did not detect/create any commercial skip points in the 5 shows.
Let me know if you need logs.
I will be removing this custom .dll from my system immediately and recommend everyone else do the same.
-
If you still have the log, please share with me. Can you also share a recorded TS file that has the problem?
-
Logs may have been cleared after installing latest version, but TV log does show these recordings all started and stopped normally. The shows that came out bad are:
NOVA
City in the Sky
Match Game
Doubt
CBS News at 10p
Log:
https://drive.google.com/file/d/0B82GqdDf8HSyR0l4TDBSZlBDRnM/view?usp=sharing
Copy of the bad show "NOVA":
https://drive.google.com/file/d/0B82GqdDf8HSyS3ZkbVpBcHBBNFk/view?usp=sharing
-
Here are some more examples. This was recorded this morning, within 10 minutes. I did a recording on the SAME channel, using 3 different versions. This is recorded to the local disk.
Channel 24.1 - 22.0.21 - https://drive.google.com/open?id=0B6opD7WxamP7YXk0aHV2dGJPSjQ
Channel 24.1 - 22.0.32 - https://drive.google.com/open?id=0B6opD7WxamP7d1FLcjd1LUZTZFU - random distortion lines and audio distortion
Channel 24.1 - 22.0.71 - https://drive.google.com/open?id=0B6opD7WxamP7aDUybGw2ekpTWEU - random distortion lines and audio distortion
Channel 24.1 - 22.0.21 Once Again - https://drive.google.com/open?id=0B6opD7WxamP7UUJ5T25fM3NQZ1U
In my opinion, this is not a signal issue, this is an encoding issue.
I am having this exact problem. I've tested it on two separate computers and same issue exists.
Also, if I am in Theatre View and record a show from the guide, when the recording finishes or I manually cancel it and then try to watch the resulting recording I get an error popping up saying that a tuner is not available. This is strange since I'm trying to watch the recording not live TV.
I need a fix for this asap.
-
Tvmandan,
I installed VideoLAN and AC3 filters and it has appeared to have fixed the issue I was having. I've been running on .71 all this week and all my recordings have been good! Might give that a try.
-
Tvmandan,
I installed VideoLAN and AC3 filters and it has appeared to have fixed the issue I was having. I've been running on .71 all this week and all my recordings have been good! Might give that a try.
Thanks for the info Chris. JRiver was working fine for me in previous versions. Something must have been broken in a new version. I'd rather not install third party software and codecs to fix it.
-
Today I reverted back to version 22.0.21 and recording is working again. Any recordings done on newer versions are corrupted and un-watchable.
Is there a fix for this yet? It is clearly a problem introduced after 22.0.21.
-
We're looking into the problem.
-
For those who experienced bad TS recordings, please try the following:
1. Download and install MC22.0.75 (http://yabb.jriver.com/interact/index.php/topic,109531.0.html), if you have not already done it.
2. Download, unzip, and copy JRTelevision.dll (https://www.dropbox.com/s/s7rnyjz7gxg57nk/JRTelevision.zip?dl=0) into MC installation folder.
3. Try recording in TS format, and let me know how it goes.
-
So far so good. 24 recorded shows with v75 + dll. None of them have strange long duration, played back about 5 shows and they are all good.
-
Did you play those shows in their entirety, or at least 10 minutes into them?
-
Yes, I have now watched 7 full shows and they played good all the way to the end.
-
That is good news. Thanks.
How about other users? Are you all able to record in TS without glitches?
-
That is good news. Thanks.
How about other users? Are you all able to record in TS without glitches?
Yaobing I wish I could help as I'm using TS but I don't think I never got the issue so I can't really help. I do get very minor stutter here and there but I know it's not the file since the stutter never happens at the same place (probably due to my MADvr settings...)
Can you give us a bit more details as to what changes were mad so it may help with the troubleshooting?
Any clues as to why some of us are having issues and not others?
As an FYI I often record 2-3 even 4 shows at the same time without issues....
-
Thanks Eric for offering to help. If you did not have problem recording shows in post-.32 builds, you are not likely see anything different. So this is mainly for users who reported problems and said rolling back to early builds was the only solution.
I may post another updated DLL later today.
-
Here is another attempt:
Please download, unzip and copy the DLL (https://www.dropbox.com/s/xlko25n2h9tykay/JRTelevision%202-23-2017%2014-44.zip?dl=0). Does this work better than the one I posted a few posts before this?
-
Unfortunately, it didn't make a difference for me. Running .75 with the updated DLL. My recordings are the same. Also, just an update to my last post where I installed videoLAN and AC3 filters and saw an improvement. With no changes to my MC, the issues returned a few days later. I'm baffled as to what happened..
Playing around with this DLL you sent out, I grabbed the DLL from .21 and my recordings were crystal clear again. Although attempting to play live TV crashed MC, was forced to load back the newest DLL to watch live TV.
I can upload some examples if needed. Thanks for working hard on this.
-
Can you share a log recording a show using the last DLL I posted (downloaded file is "JRTelevision 2-23-2017 14-44.zip")?
-
Sure, I'll get that posted this afternoon.
-
Sure, I'll get that posted this afternoon.
If you have not started yet, please wait. I will post another DLL, which will be the most promising so far.
-
Please try this DLL (https://www.dropbox.com/s/30gxfm9ssm426he/JRTelevision.zip?dl=0)with the latest MC build.
-
I think you nailed it with this last DLL. Initial recordings are crystal clear. Going to do some more recordings throughout the evening. Will let you know.
Just out of curiosity, what is it that you changed?
-
I think you nailed it with this last DLL. Initial recordings are crystal clear. Going to do some more recordings throughout the evening. Will let you know.
Just out of curiosity, what is it that you changed?
I introduced a stupid bug in build 32 which I had a hell of time finding for the last couple of weeks. Once I found it, I feel like slapping myself. Thanks for helping me nail this one.
-
I introduced a stupid bug in build 32 which I had a hell of time finding for the last couple of weeks. Once I found it, I feel like slapping myself. Thanks for helping me nail this one.
Just tried with version .75 and the updated dll. TS Recording now seems to be working fine. Thanks for your work on this.
-
Please try this DLL (https://www.dropbox.com/s/30gxfm9ssm426he/JRTelevision.zip?dl=0)with the latest MC build.
Working good on my system too.
-
I introduced a stupid bug in build 32 which I had a hell of time finding for the last couple of weeks. Once I found it, I feel like slapping myself. Thanks for helping me nail this one.
Is this fix coming in ver .76?
I haven't noticed the problem myself, but I still like to have the bug-free (or "improved") version just in case it's happening to me too and I just didn't notice yet.
-
It is not in .76. It will be in .77 or later.
-
No problems until..... this strange recording found.
Version 22.0.95
Recording started and finished on time. Show is Apr 6 30 min "The Big Band Theory" but length says it's 10hrs 28min. File size of TS is not correct- should be around 3GB, but it's only 577MB. Playing it is really funky. It will play but if you touch jump/ff/rew it will stop playing and have to press STOP to get back to theater view. Also comskip ran, did not find any commercial markers but created a large log file.
MC Log file corrupt because it's showing 22GB unzipped. Running Object Fix Zip now trying to recover it, then will upload to Google Docs. Might be a while......
Please MC REALLY needs an option to auto delete logs at specified interval (I'm not the only one asking).
-
No problems until..... this strange recording found.
Version 22.0.95
Recording started and finished on time. Show is Apr 6 30 min "The Big Band Theory" but length says it's 10hrs 28min. File size of TS is not correct- should be around 3GB, but it's only 577MB. Playing it is really funky. It will play but if you touch jump/ff/rew it will stop playing and have to press STOP to get back to theater view. Also comskip ran, did not find any commercial markers but created a large log file.
MC Log file corrupt because it's showing 22GB unzipped. Running Object Fix Zip now trying to recover it, then will upload to Google Docs. Might be a while......
Please MC REALLY needs an option to auto delete logs at specified interval (I'm not the only one asking).
Link to bad TS recording:
https://drive.google.com/file/d/0B82GqdDf8HSyQUJSQ3lyTElxeTg/view?usp=sharing
Link to MC Log:
https://drive.google.com/open?id=0B82GqdDf8HSyZ2dFZ09oV2hHbTQ
-
This is really a strange situation. It appears (I can not really get any solid evidence from the log to draw any conclusion) that there have been a lot of dropped packets, so much that LAV decoder could not get the duration correct. If you play the video without attempting to fast forward or jump, it plays to about 6 minutes and quits.
-
It's ok, I'm not too worried about it. One bad recording once in great while....
I'm not expecting these to be solved either... but I have noticed:
1. Still getting one or two very minor spurts of pixelation / breakup that happens every 2nd or 3rd recorded show.
2. Once in a while (maybe once a week), while playing back a show the video will jump forward (not sure maybe it's a commercial skip point or maybe not). And when I try to jump back or rewind to the previous spot, it won't go back. The timeline says it is going back but it just plays video from the same (jumped forward) spot, no matter where I jump to in the timeline. Even if I go all the way back to the start of the timeline, the video playing is the same (jumped forward) spot. I have to press STOP, then play, then manually jump forward to the spot where I left off. Thing is, I cannot reproduce the same behavior after pressing STOP and replaying. Super weird.
-
It's ok, I'm not too worried about it. One bad recording once in great while....
Getting to be more than once in a great while thing- logs say recordings start/stop correctly but file size is wonky and playback time is way too short or way too long. This NEVER used to happen until the monkeying around with the TS DLL mid Feb-Apr. Wish I could just go back to the pre Feb DLL.....
Please tell me, do I need to turn on extra logging?
Link to bad recording TS:
https://drive.google.com/file/d/0B82GqdDf8HSyWENwMGdwX3FHSHM/view?usp=sharing
Link to MC log:
https://drive.google.com/drive/folders/0B82GqdDf8HSyWTJaRUpTZnlXNVE?usp=sharing
-
Almost seems like recording on 4 HD or more channels at once = audio/video breakup. Used to be able to record 6 to 8 channels, without a single glitch. Now some recordings are virtually unwatchable.
Please tell me what I have to do to help solve this.
-
I think you'll have to find your own answer on that. It's probably something using CPU cycles, maybe several things. It could be anything.
-
CPU cycles or I/O.
Time to pull out Process Explorer (https://technet.microsoft.com/en-us/sysinternals/bb795533.aspx) from Microsoft and start tracking things down.
-
Not.
Maybe I'll just roll back to three month old MC version and stay there, since it was working before all the TS file driver monkey business....
-
Try turning off "Use extra layer of buffer when recording in TS format".
-
Try turning off "Use extra layer of buffer when recording in TS format".
Ok, will do.
-
Try turning off "Use extra layer of buffer when recording in TS format".
Here are my results of a first night's test. I recorded five 30 minutes shows at 11pm. This is what I am seeing:
-NBC garbled mess, completely unwatchable, just a pure scrambled screen.
-CBS garbled mess, completely unwatchable, just a pure scrambled screen.
-HLN completely clear, no glitches at all.
-CCN completely clear, no glitches at all.
-DXD completely clear, no glitches at all.
What is different about NBC/CBS vs the other three channels:
-BITRATE. Comcast keeps the local network channels at around 6-7GB/hr, while the other cable channels are much lower at around 2GB/hr.
-MPEG2 vs AVC (MPEG4). The two local network channels are MPEG2, the others are AVC.
BTW, I've checked my hard disks... Mobo is SATA II, drive reporting UDMA mode 5, read/write testing 100-120MB/s. That should equate to writing/reading around 50-60 full MPEG2 HD streams simultaneously.
-
Did not realize you are using CableCARD tuners.
I will have to check on that again, for such tuners the "use extra layer of buffer" option may not have an effect (it would be always on, so turning it off does nothing). I will need to make some changes on that.
-
BTW, I've checked my hard disks... Mobo is SATA II, drive reporting UDMA mode 5, read/write testing 100-120MB/s. That should equate to writing/reading around 50-60 full MPEG2 HD streams simultaneously.
Random access (ie. writing in 2 or more spots at the same time) is much much slower then just writing sequentially in one place, so writing 5 streams at the same time could in theory already go beyond the random writing speed of such a HDD.
-
Random access (ie. writing in 2 or more spots at the same time) is much much slower then just writing sequentially in one place, so writing 5 streams at the same time could in theory already go beyond the random writing speed of such a HDD.
Do not believe for one second that this is hardware. 100% no problems with this server machine prior to the TS driver monkey business. This machine is clean. Not used for anything else but recording tv, and serving MC clients. No software gets installed, no browsing, no email, etc. Nothing has changed on this machine except MC versions.
-
I'm about to roll back to v22.0.74 (the last install-able version without reworked JRTelevision.dll) but I don't necessarily need to record in TS at this point, so:
-If I switch to JTV recording, does the tv recording process behave differently (more efficiently) than when using TS?
-Did the change to JRTelevision.dll in v22.0.77 (or other internal changes forward), also change the JTV recording method/process?
-
-If I switch to JTV recording, does the tv recording process behave differently (more efficiently) than when using TS?
One difference is that when using JTV format, only one copy of the program is being written to disk.
When you use TS format, two copies of the program are being written to disk. One being the TS recording, and the other being the JTV Time Shift files. So, twice the I/O activity.
-
I need to investigate if comskip can process JTV files before I make that switch. That would be a deal breaker.
-
100% confirmed v22.0.76 fixed the bad recordings of mpeg2 higher bitrate hd channels. This points to newly introduced versions of JRTelevision.dll being a problem for mpeg2 higher bitrate hd channels.
Tested recording 5 channels using v22.0.108 = complete garbage on the mpeg2 channels. Unwatchable.
Tested recording 5 channels using v22.0.76 = all clear, no glitches whatsoever.
Let me know if you want samples/logs.
-
I need to investigate if comskip can process JTV files before I make that switch. That would be a deal breaker.
It won't be able to.
-
Did not realize you are using CableCARD tuners.
I will have to check on that again, for such tuners the "use extra layer of buffer" option may not have an effect (it would be always on, so turning it off does nothing). I will need to make some changes on that.
100% confirmed v22.0.76 fixed the bad recordings of mpeg2 higher bitrate hd channels. This points to newly introduced versions of JRTelevision.dll being a problem for mpeg2 higher bitrate hd channels.
Tested recording 5 channels using v22.0.108 = complete garbage on the mpeg2 channels. Unwatchable.
Tested recording 5 channels using v22.0.76 = all clear, no glitches whatsoever.
Let me know if you want samples/logs.
Yaobing, I realize you are busy... Any comments/ideas on what is going on?
-
I am still searching for an answer. The change made in build 77 was for fixing glitches seen by some users. I was sure it was a good fix as I did see some bad code. Did I make an over-correction? Maybe. I will first try to reproduce.
-
What is different about NBC/CBS vs the other three channels:
-BITRATE. Comcast keeps the local network channels at around 6-7GB/hr, while the other cable channels are much lower at around 2GB/hr.
-MPEG2 vs AVC (MPEG4). The two local network channels are MPEG2, the others are AVC.
Comcast would re-transmit broadcast channels as is, using whatever the broadcasters use, which I believe is MPEG-2 for most TV stations in the US.
I scheduled 5 recording last night, all were re-transmission of local TV channels, three at 1080i, two at 720p, resulting in 6-7 GB/hr, or 3-4 GB/hr. All recordings play fine. No glitches on any.
I scheduled 5 more this morning. I will see the results soon.
By the way, the hard disk I use for TV recordings is an USB3 drive.
-
The recordings done this morning are in good shape too. There are only a few very occasional brief glitches.
I am going to have to ask you to capture a log. This is going to be tough as the log will be very large. I need you to turn logging verbosity to 1 or 2 before starting to record. Record only long enough to reproduce the glitches.
-
Ok will do when possible.... appreciate your help very much.
-
Some log files:
https://drive.google.com/open?id=0B82GqdDf8HSySk5LNDRheDVVWGs
https://drive.google.com/open?id=0B82GqdDf8HSyNlpLQ2oya3ZxRmM
https://drive.google.com/open?id=0B82GqdDf8HSyR3ZYajVZTERDSTg
One of these I changed the record drive to different location, from internal SATA to PCI SATA external multidrive box (newer drives, maybe faster).
A few screenshots of Task Manager- one IDLE, one during recording....
-
And a screen shot with version 22.0.76 recording 5 HD channels tells it all :o
v22.0.110 = 85% MC cpu usage
v22.0.76 = 15% MC cpu usage
-
I will have to check on that again, for such tuners the "use extra layer of buffer" option may not have an effect (it would be always on, so turning it off does nothing). I will need to make some changes on that.
I checked. It turns out, the option does have an effect for CableCARD tuners as for other tuners. So it is still puzzling why even after turning the option off, the behavior is different from that in build 76.
I did a lot more testing, and still can not reproduce. Even on my laptop computer, with benchmark score of 2217, I am not seeing such high CPU usage as you saw on yours.
-
Please try this DLL (https://www.dropbox.com/s/e46jpvcoe7r8s1n/JRTelevision.zip?dl=0)with MC22.0.110
-
Please try this DLL (https://www.dropbox.com/s/e46jpvcoe7r8s1n/JRTelevision.zip?dl=0)with MC22.0.110
Sorry, no change. Tried with extra layer of buffer option off/on, no difference. Very high CPU usage for MC.
-
Please try again with this one (https://www.dropbox.com/s/mygtt34cy3njh5w/JRTelevision.zip?dl=0).
-
Please try again with this one (https://www.dropbox.com/s/mygtt34cy3njh5w/JRTelevision.zip?dl=0).
Bummer, no change. Still very high.
-
Perhaps it would help to run Microsoft's Process Explorer (https://technet.microsoft.com/en-us/sysinternals/bb795533.aspx) and see if anything particular shows up in the loading by thread within MC.
The image shows threads for MC running Live TV on a Client PC. Right click "Media Centre 22.exe", Properties, Threads tab. You can see MadVR sits at or near the top of the CPU load most of the time in my case.
Maybe this would highlight a specific problem.
-
Here is screenshot of Process Explorer and level 2 MC log.
https://drive.google.com/file/d/0B82GqdDf8HSya3ZiNjk0d3A5dGc/view?usp=sharing
-
You have several tuners, and I haven't read the whole thread. Have you tried removing one at a time?
-
Wow! :o :o
When I saw that I just had to see what my HTPC Server looked like when running Live TV. Image attached.
As you can see, my JRTelevison.dll loads are way down the list, at or below 0.1%. There are also a lot less of them. I only have nine in total. Easy to see Yaobing is looking at the correct bit of code; the DLL.
Note I am using internal PCIe tuners, which makes a huge difference. Even so, your loading is unusual.
-
Ya, Wow is right.
All of my tests have been using Ceton. I'll try using HDHRP tuners next. Both are Network Tuners.... but cant' do more tests until after tomorrow AM.
-
It could be us, but Ceton has more or less retired from the TV tuner business. A bad driver could explain a lot, but try removing one tuner at a time (if you do have more than one).
-
...A bad driver could explain a lot...
Do not suspect tuner driver because the problem does not happen on MC versions 22.0.76 and earlier. It shows up immediately when I install v77 and up.
-
That doesn't rule out a driver problem. Bugs take particular circumstances to occur. Antivirus programs also choke on certain builds and not others.
-
No offense but I don't believe it for a second. I've had two years of virtually flawless recordings with MC, then build 77 gets a new JRTelevision.dll and everything goes to the dumper because MC cpu usage jumped 6x of normal. Still 100% sure this has nothing to do with my hardware or drivers. Guess we will find out for sure tomorrow when I use HDHRP tuners.
-
Being 100% sure won't make the solution easier to find.
-
Ran some tests between 8p-9p while there were no vital recordings. Since HDRP only has 3 tuners, recorded on the same 3 channels on each tuner, using each version of MC.
-record 3 channels with HDHRP MC v76 => Max instance of JRTelevision.dll = 0.97% cpu
-record 3 channels with Ceton MC v76 => Max instance of JRTelevision.dll = 1.05% cpu
-record 3 channels with HDHRP MC v110 => Max instance of JRTelevision.dll = 3.63% cpu
-record 3 channels with Ceton MC v110 => Max instance of JRTelevision.dll = 4.34% cpu
If I have time tomorrow, I will record 6 channels at one time (3 Ceton + 3 HDHRP).
Screen shots.....
-
Please try this new DLL (https://www.dropbox.com/s/qyum9j9tey64eaf/JRTelevision.zip?dl=0).
I am not sure, but I think I see some reduction in CPU usage with this one.
-
Please try this new DLL (https://www.dropbox.com/s/qyum9j9tey64eaf/JRTelevision.zip?dl=0).
I am not sure, but I think I see some reduction in CPU usage with this one.
Not any different. This test is recording three mpeg2 higher bitrate channels on Ceton & three mpeg2 higher bitrate channels on HDHRP at the same time. So six tuners recording:
v76 => MC cpu usage = 12-18%
v110 => MC cpu usage = 89-95%
-
Thanks for the feedback. I will try a more thorough rollback on Monday.
-
Please try this one (https://www.dropbox.com/s/twa3koaeegp743y/JRTelevision.zip?dl=0). Thanks.
-
Please try this one (https://www.dropbox.com/s/twa3koaeegp743y/JRTelevision.zip?dl=0). Thanks.
No change :(
-
Something else is going on.
Can you confirm that build 77 is the one that breaks it?
-
I looked but didn't see... What antivirus are you using?
-
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.
-
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:
-
Please try this DLL (https://www.dropbox.com/s/a33ebik8r5p9z0c/JRTelevision.zip?dl=0) 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.
-
Please try this DLL (https://www.dropbox.com/s/a33ebik8r5p9z0c/JRTelevision.zip?dl=0) 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.
-
:'( :'( :'(
Is the high CPU usage still attributed to JRTelevision.dll?
How about re-setting logging verbosity to 0?
-
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
-
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.
-
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.
-
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:
-
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.
-
Please try this one (https://www.dropbox.com/s/lkqpay6b9l6no9t/JRTelevision.zip?dl=0)with 110.
-
Please try this one (https://www.dropbox.com/s/lkqpay6b9l6no9t/JRTelevision.zip?dl=0)with 110.
No change....
-
No change....
?
How about this one? (https://www.dropbox.com/s/zlzmu4k9iznaohm/JRTelevision.zip?dl=0)
This DLL was created at 10:34 AM today, Central DST.
-
?
How about this one? (https://www.dropbox.com/s/zlzmu4k9iznaohm/JRTelevision.zip?dl=0)
This DLL was created at 10:34 AM today, Central DST.
Looks pretty good ;D
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!
-
Looks pretty good ;D
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
-
Will do.
-
How does this one (https://www.dropbox.com/s/jc8zs216hp6s2f1/JRTelevision.zip?dl=0)work?
-
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
-
This one should be good! (https://www.dropbox.com/s/kxvq8r9a7t9md6p/JRTelevision.zip?dl=0)
-
Oops... MC cpu back up to 90-93% :(
-
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")?
-
Logging was set to verbose 0.
Extra layer buffer was On.
Will have to wait until tomorrow AM for more testing.
-
Please try this one. (https://www.dropbox.com/s/jd3mvyc38a5sk5o/JRTelevision.zip?dl=0)
-
Please try this one. (https://www.dropbox.com/s/jd3mvyc38a5sk5o/JRTelevision.zip?dl=0)
Not good. MC cpu 89-93%
Logging OFF
Extra buffer OFF
-
Please try this DLL. (https://www.dropbox.com/s/9a2yfiwkg36if7t/JRTelevision.zip?dl=0)
-
Please try this DLL. (https://www.dropbox.com/s/9a2yfiwkg36if7t/JRTelevision.zip?dl=0)
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%.
-
It looks like several things together pushed your computer to the limit. So far I identified two, and there are more.
-
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.
-
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.
-
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.
-
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.
-
Under MC's Help menu, run the benchmark utility and paste the results here.
-
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 (https://www.hdsentinel.com/) reports any issues.
-
Please try this DLL. (https://www.dropbox.com/s/4j1mzj327hy1wig/JRTelevision.zip?dl=0)
-
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.
-
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
-
It's missing some sections. You could run it again and just paste the text here.
-
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
-
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.
-
Please try this DLL. (https://www.dropbox.com/s/4j1mzj327hy1wig/JRTelevision.zip?dl=0)
Not good.
MC cpu all over the place 16-45%. Recordings are garbage.
-
This one should be it. (https://www.dropbox.com/s/xbkngdzr4slmzlr/JRTelevision.zip?dl=0)
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.
-
30-45% with spikes to 70%
-
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.
-
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
-
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.
-
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.
-
Are your tuners network tuners?
-
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.
-
If the tuners are network tuners, there is also the possibility of a network problem.
This could be anywhere and you could probably find it by simplifying your system, and gradually increasing the complexity until it breaks.
I'm going to close this now. I'll re-open it later if you find something new.