CPU usage increases as a function of time (3 Viewers)

[jonesdb]

Sorry for the delayed response. I have been having an issues with the TVServer crashing while recording. At first I thought it was only with the new filter, but I not fully convinced of that yet. It doesn't happen often. Today I did recordings off and on for several hours before it crashed. So far it has only happened with the new filter, but that may just be a coincidence or may it be the new SVN. I'll keep investigating.
I miss spoke and stand corrected on the size of the record buffer in the new msFileWriter.ax file. It is indeed 255868 bytes.
I guess I understand the focus on TSWriter when what you have to work with is DVB cards. In fact, my hat is off to everyone involved in this project as it addresses such a wide variety of hardware and multimedia standard! You guys have done an excellent job on a very tough set of problems.
I'm not sure I with the rational for the different buffer size for timeshifting. Indeed, the timeshift file is played while being written to disk but a larger buffer still only equates to a larger delay with respect to the live feed which is being written to disk. As long as this delay is within some reasonable value, say less than a second or two, the delay would not be noticeable by the viewer. At 3 GB/hr you are putting down about 833K bytes/sec, so even the buffer you are using to write the .ts file is only about delaying the real-time feed by slightly more than 300 mS. The only issue I see is handling the clearing of the buffer at the end of a program while starting the recording (or timeshift) of the next in sequence program. Am I missing something else?
On a slightly different note, when recording a show and watching it at the same time I see that a timeshift file is created in addition to the recording file. Was any thought given to just using the recording file for the timeshift operations if a recording file is being generated?

 

[tourettes]

I'm not sure I with the rational for the different buffer size for timeshifting. Indeed, the timeshift file is played while being written to disk but a larger buffer still only equates to a larger delay with respect to the live feed which is being written to disk. As long as this delay is within some reasonable value, say less than a second or two, the delay would not be noticeable by the viewer.

Unfortunately the increased buffer size will increase the channel changing time. So 1 second more buffering will increase the zapping times by one second.

 

[misterd]

On a slightly different note, when recording a show and watching it at the same time I see that a timeshift file is created in addition to the recording file. Was any thought given to just using the recording file for the timeshift operations if a recording file is being generated?

For analog cards this could work, but we are currently trying to synchronize the internal handling of analog and dvb cards in the TvServer. And for dvb cards it is very important that we have a seperate timeshift file, because there you can watch a different channel on the same transponder while recording with the same card. We could create a timeshift file when you switch to a different channel, but than we would have a slower channel switching time in this case, because we have to create the timeshift file first etc. This is much more overhead.

BTW: When you watch the recording itself, than no additional timeshift file is created.

MisterD

 

[elconejito]

I've been away for a while, but I'd like to test this out this weekend. Should I download latest SVN and still overwrite with the new file in this thread or has the change already been put into the SVN?

 

[hassegubben]

jonesdb: I have been experiencing random recording crashes. I noticed that after a recording was scheduled and it had started - when selecting currently recordings ("ongoing recordings" or what ever it is called in the english version - "pågående inspelningar" in Swedish) from the TV-section in MP, and then leaving this dialog, the ongoing recording and all scheduled recordings after that would abruptly end.

 

[jonesdb]

Unfortunately the increased buffer size will increase the channel changing time. So 1 second more buffering will increase the zapping times by one second.

Excellent point! I guess I was so focused on the buffer size and CPU performance that I forgot to consider what happend when a channel was changed.:sorry:

@misterd: Just an update concerning the mpFileWriter.ax file. The file seems to work great. CPU usage is greatly reduced when working with analog channels. Will the new file be appearing in an upcoming SVN?
The issues I have been having with the TVServer crashing and recordings not stopping do not appear to have anything to do with the new file. The same issues exist when using the mpFileWriter.ax file that was installed with the SVN.
I'm trying to isolate the TVServer crash issues and the continuing recording issues. They appear to be seperate problems, both of which seem to happen randomly. (I know, nothing happens randomly) I guess those issues should be in a seperate thread, so I will start one when I have enough information to provide some real guidance as to what is going on.

 

[Ruud]

Hello,

this thread was just brought to my attention. I have posted a related bug Here.
Count me in for testing, aegerly awaiting this weeks SVN
I installed last weeks SVN again for testing and error replication. I just keep it on there because currently I know that the limitation is with more then one card / tuner addressing. This is not going to happen again before Monday next.

Thanks for the effort.
Regards,
Ruud.

 

[jonesdb]

Here it is, an update on my experiences with the buffered mpFileWriter.ax file provided by MisterD previously in this thread and what I've learned to date. As stated earlier, I was having problems with the TVServer crashing while recording for both the SVN version of the mpFileWriter.ax and MisterD's buffered version for this thread. Because crashes were happening with both versions of the mpFile Writer.ax file I didn't believe that it had anything to do with the buffered version.
I'm sorry to report that I think I have identified a problem with the buffered version. Also with the non-buffered version though I think slightly different.
The circumstances that lead to a TVServer crash are as follows:
I have scheduled two sequential programs on the same analog channel to be recorded. (For example record program xxx on channel 62 from 5:00 pm to 6:00 pm and then record program yyy on channel 62 from 6:00 pm to 7:00 pm where channel 62 is an analog channel)
The first program records properly and ends as scheduled. The TVServer crashes between the two programs.
program.ts files are created for both programs, but only program1 has data.
After looking at numerous log files and Procmon to try to capture the events taking place at the time of the crash I have learned the following:
Scheduler wakes up to begin recording program1. Everything goes along nicely and recording of program1 begins. Next, just before program2 is supposed to start scheduler wakes up and starts setting things up to record the second program (program2). At this point, program1 is still recording. Scheduler then wakes up to end program1.
Crash!!
This sequence of events seems to be quite repeatable. At least for one pair of shows that I record daily. It doesn't happen all the time when the two channels are digital or when one is digital and the other analog. Only when both are analog. By changing the schedule database to have program1 end 1 minute early (i.e. 5:59 pm instead of 6:00 pm) and program2 start 1 minute late (i.e 6:01 pm instead of 6:00 pm) the crash does not take place and both programs are recorded properly.
The system application error log show the following when this type of crash occurs:
Source: .NET Runtime 2.0 Error ..... Faulting application tvservice.exe, version 0.9.2.20227, stamp 48cd1731, faulting module mpfilewriter.ax, version 0.0.0.0, stamp 48cbeb5b, debug? 0, fault address 0x000061a6.
I suspect that it has something to do with the buffered mpFileWriter.ax trying to write to two different files at the same time.
I'm not sure I understand why scheduler doesn't begin the teardown process for an ending program before it starts the build process for a starting program. It may have something to do with graph building and the resulting time delays. MisterD may be able to shed some light on this for us.
This particular type of crash doesn't happen with the non-buffered version of mpFileWriter.
I do however get a second (different) type of crash when using the non-buffered version (I used the non-buffered version while testing, but don't think it matters as mpFileWriter.ax should not be involved as both channels in the test are digital. I was trying to isolate any issues with the buffered version from everything else.)
The second type of TVServer crash
Source: .NET Runtime 2.0 Error ..... Faulting application tvservice.exe, version 0.9.2.20227, stamp 48cd1731, faulting module system.data.ni.dll, version 2.0.50727.3053, stamp 4889deaf, debug? 0, fault address 0x00516676.
This crash happened when changing from scheduled program3 to scheduled program4. Both programs were on digital channels (though also available on analog channels...the higher priority is set for the digital broadcast).
I have attached the pertinent sections of the following logs: tv.log, TSWriter.log, MPFileWriter.log and error.log

Basically, I think both types of crashes are happening because of some race condition happening when going from one scheduled recording to a second. It doesn't always seem to happen, as I have recorded many sequential shows with no problem, but when a crash does occur it is nearly always at the intersection of two sequential scheduled recordings.
I also notice a large number of continuity errors with this SVN.....something I have never seen before.
As always, thoughts, suggestions and comments are always welcome. I'm still looking into ways to further isolate these issues so they may be fixed in some upcoming SVN.

 

[hassegubben]

Great investigation!!! This may explain all my recording crashes with analog recordings. See also my previous post. Can you repeat that? What happens when the second recording starts before the first one has ended? Any crashes?

 

[misterd]

When I added the buffer to MPFileWriter, I also made a refactoring to this filter to make it more easier. It seems that something there is wrong. I couldn't find any error, so I decided to revert the refactoring.

You can find attached the new version of MPFileWriter with the write buffer, but without the refactoring. I wasn't able to produce any crash with this filter.

jonesdb: You have a hybrid card in you system specs, but I can't see any log lines that are indicating that this card is configured as a hybrid card. Normally you can't use both parts of a hybrid card at the same time.
Also it is correct that TvServer has chosen the analog card for the second recording as the first one was still recording because of the postrecording value and both channels are not on the same transponder. Therefor couldn't use the digital card.

MisterD