Colossus issue with 3.3.8

[ScaryBox]

All I have right now is. Nothing in C:\Temp

[ScaryBox]

I don't know if it's relevant but I was watching livetv (not doing any channel changes) and I noticed that the buffer was creating a new file every 6mins 40 secs. Each file is about 470Mb on average. Normal??

[mvallevand]

I don't know if it's relevant but I was watching livetv (not doing any channel changes) and I noticed that the buffer was creating a new file every 6mins 40 secs. Each file is about 470Mb on average. Normal??

Absolutely normal if you aren't using the epg-based live tv. 400ms is the default for the rolling file.

Martin

[sub]

sub,

I can't find these setting in the registry. Should I be adding them or should they already be there?

You'll need to create these registry settings. They wont already be there.

The registry key on 32 bit versions of Windows is HKEY_LOCAL_MACHINE\Software\NPVR.

On 64 bit versions of Windows it's HKEY_LOCAL_MACHINE\Software\Wow6432Node\NPVR.

[IanSpringfield]

Obviously this problem is a tricky one. Since I've been dealing with the issue ever since I set up the Colossus and NPVR (over a year ago), perhaps I can add some thoughts that might help in focusing attention.

When it comes to LiveTV, npvr is a 2 part process. 1) writing the file to the drive, and 2) reading the file from the drive.

I routinely use npvr to record shows and these shows are never watched until the recording has finished (no time-shifting). I have never watched a recording via npvr. I only use mpc-hc to watch recorded programs. I have never had a recording fail due to the fault of npvr's recording process. They all play perfectly. This tells me that npvr can record programs from the Colossus without issue. I have even moved the LiveTV folder around to account for any hard drive issues causing the problem. These tests did not resolve the issue and I am 100% convinced it is not a hard drive issue.

This is a completely non-computer techie observation, but it sure seems to me that the problem is how npvr reads the file that was created using a Colossus. Although I can't prove this, my feeling is that specifically, the problems can occur when npvr starts a new file (whether this is caused by the buffer limit (400 seconds) which can cause a freeze, or a channel change (that also starts a new file) which can cause a freeze. The problem is it doesn't happen all the time, only some of the time.

In the last few days, I've tried a new test. I open LiveTV and pause the picture for >7 minutes so that I'm always a file behind. I have not experienced any freezes. Of course, channel changes still may freeze, but I have yet to experience a freeze when just watching LiveTV. That seems to indicate that npvr can stumble when switching from one file to another file provided the new file is still being written. If the new file has been completely written (and is no longer growing) npvr doesn't seem to have a problem.

Of course with channel changes, the new file is being read immediately. Unfortunely, if it freezes on the change, there is no opportunity to pause the video, but if the channel change suceeds, then I once again pause LiveTV for >7 minutes, once again npvr doesn't freeze.

If I skip forward so that I'm no longer trailing the recording by >7 minutes (and therefore can be playing as the file is growing), LiveTV may freeze.

The problem is that this is just a "test" rather than ongoing use, so what I've stated may not be true, but, I have given it a good run and it sure seems to be as I've stated.

To be completely honest and open, these tests have been conducted using the client. In my mind the client issues (channel change and freeze LiveTV) are 100% caused by the issue on the server and can be duplicated on the server.

Thought I would pass this along.

[mvallevand]

There are definite problems when you exceed the rolling file size while paused. Some users increase the size of the buffer through the registry, but I find using epg-based LiveTV works better for my use.

Martin

[IanSpringfield]

There are definite problems when you exceed the rolling file size while paused. Some users increase the size of the buffer through the registry, but I find using epg-based LiveTV works better for my use.

Martin

I think you misread what I wrote or I'm not understanding what you wrote. If I pause LiveTV for longer than the file size (ie, >7 minutes), freezing problems seem to be eliminated, not caused. All day yesterday I watched football 7 minutes behind the game. Not once over 7 hours did I experience a freeze. Once I changed the channel, and freeze. Restarted npvr changed channel again, success. Paused for 7 minutes, no more freezes. In various tests, I have paused for less than the file size, ie 2 minutes, but LiveTV freezes still could occur. It was not until I got to a 7 minute pause that freezing seems to have completely gone away. Yes, I could increase the buffer size, but taking 7 minutes to change a channel is obviously not workable.

My tests indicate that switching to a file that is currently being written is the root cause of all problems.

Martin, you're right, epg LiveTV and xbmc plugin seem to not suffer from this problem, but for a variety of reasons, I would like to get npvr working.

[IanSpringfield]

I'm thinking about another test, but I need some help and advice.

My thought is to drop the file size limitation from 400 seconds to 10 seconds. That, obviously, would result in many, many, many more files being created (rather than a new file being created every 400 seconds, a new file would be created every 10 seconds).

I would then set the buffer from 6500 (ms) to 10500 (ms)

As a result, no matter what, it occurs to me that LiveTV would always be playing from a completed file (whether channel change or simply watching LiveTv).

I figure it's worth a try however I cannot see the setting for file size limitation in the config file.

Does this test have a chance?

[ScaryBox]

Ian,

I agree with everything you are saying, however, the amount of variables involved is what makes this problem so hard to peg down and fix. I know sub is aware of the problem and has pointed out the issues with Colossus cards in the past. He'll find the fix if he can. Just gotta give him time.

Just to be clear.....I am just a newby with the inner workings of Npvr. This is all just my perspective on the problem. Sub and his team will straighten me out if I say anything not accurate. Sub, I always appreciate the insight.

Ian, Can I ask you a couple of questions? 1) Who is your cable provider and where are you located? 2) What is the make a model of your STB?

The reason I ask? I am somewhat suspicious that the Pace brand STB provided to me by Cogeco Cable here in Ontario, Canada may be a big part of the problem. I suspect that Npvr is "graphing" the video feed (Using HDMI capture) faster than the STB is starting the feed. This may be exacerbated by the fact that Cogeco can't make up their mind as far as transport method of sound and video. In fact, often different channels will "graph" differently. I've set my STB for 720p only and set Npvr to detect 720p only (Config.xml) and yet the problem persists. If I inadvertently tune to a channel I don't get the "freeze" will happen for sure. This is because the "you don't get that channel" screen the STB puts up is not 720p despite the STB being set to 720p only. I suspect that on channel change the STB occasionally starts with the "please wait" screen which also is not 720p. This has been true since Cogeco changed over to Switched Digital Video in order to preserve bandwidth. Basically, only the channel I am watching is broadcast to me. This requires the STB to request the signal and wait for the reply. While waiting for reply the STB switches to 480i resolution to disply the "please wait" message.

I still experimenting with the "WaitLonger" setting in Config.xml.

Another observation is that the channel change freeze happens less frequently when the channel is changed via typing in the channel number than when using the guide (either the default guide or add-on). I still get freezes while just watching a channel after a few hours.

It is interesting that when a freeze or stuttering happens while my second card and STB are recording a different channel the freeze/stuttering happens to the recording as well. A quick restart of the Npvr Recording Service cures all.

If I do not ever watch LiveTV a recording never fails or experiences the freeze/stuttering. So this makes me question my whole STB resolution/channel change time theory.

I'm fairly sure that the problem has more to do with how Npvr is handling LiveTV than how the recording service is "graphing", capturing, and writing. Perhaps the issue is in the Writing/Reading of the file the recording service is creating. I remember (way back) that the good people at VideoLan (Vlc player) had this issue at one point during the development of Vlc. Windows has interfered with this type of read while writing file handling before. If memory serves the problem was relieved somewhat by turning off the write caching for the concerned drives. This would hint at why the recording service gets messed up when "it" happens.

I think your test is valid and certainly supports the notion that the Recording Service is working fine and that the issue lies within Npvr's LiveTV routine. This is where my understanding ends really.

Tonight I'm gonna make the registry changes for the extra logging. It would be interesting to see how the logs compare from two different machines both running Colossus capture. (This is what brought me to wonder who your provider is and what kind of box you are using)

Sorry if that was long winded, I think I've though about this way too much! lol

Ken

[IanSpringfield]

I'm in the US and I use Directv H-21 box. It is currently fed via HDMI although I have fed it with all combinations of inputs, so the specific connection is not related to the issues.

Also, it did seem for a while that time-to-change-channels is the culprit, but I have eliminated that cause.

The problem, best I can tell, is when npvr has to move to a new file (either via channel change or because of file size limit) and the new file is still being written to.

The 2 things that are in my brain like a splinter are as follows:
1) Many channel changes work just fine. I would say I bat about 50%. I have tried to trace the issue either to the channel I'm coming from or the channel I'm going to and there is no correlation. Also, it may work 10x in a row and then fail 3x in a row. No rhyme nor reason.
2) LiveTV does not always freeze when it switches to a new file. I may watch 2 hours of perfect livetv and then, all of a sudden, a freeze. OTOH, it may freeze within the first 10 min.

What this tells me is that most of the time, NPVR does not have a problem moving from one file to the next even if the new file is being written to. I have attempted to understand what is happening that would cause many successful rollovers to all of a sudden fail. There is nothing else happening that would cause this change in behavior. It just seems to be luck of the draw.

Also, I'm at a loss why the Colossus would exhibit this behavior and other capture devices would not (I'm assuming other capture devices/tuners work perfectly for many, many users).