Print

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

[CountryBumkin]

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.

[Yaobing]

It is not in .76.  It will be in .77 or later.

[tzr916]

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

[tzr916]

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

[Yaobing]

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.

[tzr916]

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.

[tzr916]

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

[tzr916]

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.

[JimH]

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.

[RoderickGI]

CPU cycles or I/O.

Time to pull out Process Explorer from Microsoft and start tracking things down.

[tzr916]

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

[Yaobing]

Try turning off "Use extra layer of buffer when recording in TS format".

[tzr916]

Try turning off "Use extra layer of buffer when recording in TS format".

Ok, will do.

[tzr916]

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.

[Yaobing]

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.

[Hendrik]

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.

[tzr916]

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.

[tzr916]

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?

[RoderickGI]

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

[tzr916]

I need to investigate if comskip can process JTV files before I make that switch. That would be a deal breaker.

[tzr916]

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.

[RoderickGI]

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.

[tzr916]

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?

[Yaobing]

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.

[Yaobing]

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.

[Yaobing]

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.

[tzr916]

Ok will do when possible.... appreciate your help very much.

[tzr916]

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

[tzr916]

And a screen shot with version 22.0.76 recording 5 HD channels tells it all 

v22.0.110 = 85% MC cpu usage
v22.0.76 = 15% MC cpu usage

[Yaobing]

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.

[Yaobing]

Please try this DLL with MC22.0.110

[tzr916]

Please try this DLL with MC22.0.110

Sorry, no change. Tried with extra layer of buffer option off/on, no difference. Very high CPU usage for MC.

[Yaobing]

Please try again with this one.

[tzr916]

Please try again with this one.

Bummer, no change. Still very high.

[RoderickGI]

Perhaps it would help to run Microsoft's Process Explorer 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.

[tzr916]

Here is screenshot of Process Explorer and level 2 MC log.

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

[JimH]

You have several tuners, and I haven't read the whole thread.  Have you tried removing one at a time?

[RoderickGI]

Wow! 

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.

[tzr916]

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.

[JimH]

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

[tzr916]

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

[JimH]

That doesn't rule out a driver problem.  Bugs take particular circumstances to occur.  Antivirus programs also choke on certain builds and not others.

[tzr916]

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.

[JimH]

Being 100% sure won't make the solution easier to find.

[tzr916]

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

[Yaobing]

Please try this new DLL.

I am not sure, but I think I see some reduction in CPU usage with this one.

[tzr916]

Please try this new DLL.

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%

[Yaobing]

Thanks for the feedback.  I will try a more thorough rollback on Monday.

[Yaobing]

Please try this one.  Thanks.

[tzr916]

Please try this one.  Thanks.

No change