1.15.0 TVService High cpu usage (1 Viewer)

[doskabouter]

Hi,

I know I'm on an old version, but since the current tvservice is still the same as way back (the version I use), I hope my post is acceptable here.
And as an extra: I'm using the tswriter.ax from DVB-C radio not working (because I was having some issues (not related to this one) which that version resolved)

Lately I'm getting issues with the tvservice not doing what it's supposed to do.
Not sure what triggered it, I've been using this setup since the end of 2014 without any issues, but since a month or so, mediaportal sometimes completely freezes when watching tv.
Didn't do much with windows updates, the only change I can think of, is that I'm recording a fair amount more than that I used to do, so could that be the problem?

couple of logs attached, not all because I was in kind of a hurry to fix the WAF again

Edit: forgot to mention this: When the tvservice was in it's bad mood, it was using one core to the max instead of 1-2% normally.

 

[mm1352000]

Hello

I know I'm on an old version, but since the current tvservice is still the same as way back (the version I use), I hope my post is acceptable here.

From the perspective of DVB-C support it's very similar, yes.

...so could that be the problem?

It seems unlikely to me.

couple of logs attached

Nothing stands out.

Please:

1. Provide the full set of log files. Use the Watchdog tool with option 3 ("export...").
   
2. Specify when (most recent date/time) the TV service started hogging the CPU core. (I assume that the high CPU usage only starts after a period of time, not immediately when the TV service starts.)
3. Specify whether the TV service can be stopped normally (ie. not terminated/killed with task manager) after it starts hogging the CPU core.

 

[doskabouter]

Couple of thins I can already answer:
High cpu doesn't occur right after (or in this case within a day after) restart. Currently running (after yesterday's restart) at 0-1%
In case of high cpu, Tv service can be stopped and started normally through the setuptv/manual tab.
And one I find hard to answer: Don't know when exactly the cpu is maxing out, I usually only see that after the tvservice is stopping/hanging/whatever the tvstream and mediaportal hangs..

But if the tvservice is going to act up again, I'll collect the full logs. Could take a couple of days though before that's going to happen.

 

[mm1352000]

High cpu doesn't occur right after (or in this case within a day after) restart. Currently running (after yesterday's restart) at 0-1%
In case of high cpu, Tv service can be stopped and started normally through the setuptv/manual tab.

Okay thanks.
These answers suggest that the trigger may be an external process (eg. security software) affecting the TV service (eg. by periodic security scan) or a TV Server background process (eg. thumbnail generation) that doesn't affect the overall operation of the TV service.

And one I find hard to answer: Don't know when exactly the cpu is maxing out, I usually only see that after the tvservice is stopping/hanging/whatever the tvstream and mediaportal hangs..

To be clear, I'm not looking for a general answer about when TV service starts to max out the CPU.
Rather, I'm looking for a specific answer about when (date and time) you noticed the CPU maxed out for the most recent occurrence of the problem. Surely you have some idea about that. Precise is best, but even if you can only say "yesterday morning" as an answer it would be a start.

But if the tvservice is going to act up again...

Do you mean that the problem has only happened once?
The way you wrote earlier gave me the impression that the problem was occurring semi-regularly.

...I'll collect the full logs. Could take a couple of days though before that's going to happen.

Unless the most recent occurrence was several days ago, the information that I'm looking for should be available in the existing log files, and those log files could be collected now if you wanted to.
In other words: there's no need to wait unless you have some reason for wanting to do so.

 

[doskabouter]

Okay thanks.
These answers suggest that the trigger may be an external process (eg. security software) affecting the TV service (eg. by periodic security scan) or a TV Server background process (eg. thumbnail generation) that doesn't affect the overall operation of the TV service.

As security software I have Windows defender (without excluded folders), but I thought that if that one is the problem, that process maxes out the cpu, and not the tvsercvice.
Tvserver background processes sounds plausible, especially in combination with normal service shutdown.
But it does (at least that's my assumption) affect overall operation, as I've seen this behavior only when the MP client hangs itself while watching tv.

Okay thanks.
To be clear, I'm not looking for a general answer about when TV service starts to max out the CPU.
Rather, I'm looking for a specific answer about when (date and time) you noticed the CPU maxed out for the most recent occurrence of the problem. Surely you have some idea about that. Precise is best, but even if you can only say "yesterday morning" as an answer it would be a start.

I'm going to check cpu usage regularly (f.e. now at 1%) to see if this can be correlated with MP hanging itself
Didn't check it before monday (last occurence) so no clue whatsoever on how long it was in that state.

Okay thanks.
Do you mean that the problem has only happened once?
The way you wrote earlier gave me the impression that the problem was occurring semi-regularly.

It happened three times now. Bad (optimistic?) wording on my side. Meant "when" instead of "if"

Okay thanks.

Unless the most recent occurrence was several days ago, the information that I'm looking for should be available in the existing log files, and those log files could be collected now if you wanted to.
In other words: there's no need to wait unless you have some reason for wanting to do so.

It should indeed be present, but memory is a bit hazy about the exact times and what happened exactly (restarts of mp client etc)
For what can be recalled is that around 15:04 we started watching tv, and around 15;30-ish problems arose and some restarts were done.

I've now left instructions for when that happens (write down time, and leave everything as is until I get home )
So when it happens again, I have a more coherent story, and logs from MP client too.
Wouldn't want to waste your time checking logs without clear times and description.

...Nothing stands out.

not even this?
Error "The process cannot access the file 'D:\Recorded TV\TimeShift\live5-0.ts.tsbuffer3.ts' because it is being used by another process." on delete in CleanTimeshiftFiles

 

[mm1352000]

not even this?

Nope.
That can be normal if a client is paused/time-shifting.

 

[doskabouter]

FYI:
No more tv server issues occurred until now.
Just updated tv server and client to MP 1.16
Is that old twriter.ax still necessary, or is that fix included in MP 1.16?

 

[mm1352000]

Is that old twriter.ax still necessary, or is that fix included in MP 1.16?

No that patch is not in MP 1.16.
I suggest that you check whether the patch is still needed, because the TsWriter from MP 1.16 is generally significantly better than that old version now. In other words: you should avoid using that patch unless you absolutely have to.

 

[doskabouter]

Glad to say that I still didn't see that issue popping up again.
However, a restart of the tvservice was needed because of locked files:
[2017-05-11 18:15:16,971] [Log ] [scheduler thread] [ERROR] - RecordingFileHandler: Error while deleting a recording from disk: The process cannot access the file 'D:\Recorded TV\NPO 1\NOS Journaal\NOS Journaal - 2017-05-05.ts' because it is being used by another process.

It turned out that the tvservice itself had this file open.
Unfortunately, it has been going on unnoticed long enough to only have logfiles stating this error, and not any previous things when all was normal.

Could this have been the reason for me to use the old tswriter.ax?

 

[mm1352000]

However, a restart of the tvservice was needed because of locked files:
[2017-05-11 18:15:16,971] [Log ] [scheduler thread] [ERROR] - RecordingFileHandler: Error while deleting a recording from disk: The process cannot access the file 'D:\Recorded TV\NPO 1\NOS Journaal\NOS Journaal - 2017-05-05.ts' because it is being used by another process.

It turned out that the tvservice itself had this file open.

If you have a multi-seat setup with 1.16 PR or final installed on the server, please follow this thread:
MP1.16 RecordingFileHandler: Error while deleting a recording from disk.

In short, there's a bug in the 1.16 streaming server changes which prevents recording file deletion.
You can test the patch provided by Owlsroost.

Could this have been the reason for me to use the old tswriter.ax?

No chance.
The only reason to use that TsWriter would be if you want/need to receive channels that are unreceivable with the standard TsWriter for technical reasons. The explanation of those "technical reasons" is quite complex so I won't explain in full here. However, in short, in my opinion it's quite unlikely that you should need it.