TV Server Crashes After Recording Ends (1 Viewer)

[georgius]

try attached filter version and let me know, if performance is better or not.

Performance not good. Had a stutter in playback about once per second, so it wasn't watchable. The CPU didn't seem to spike though. CPU utilization was actually lower than the 1.x filter, but not sure this is a good comparison until the appropriate playback is being observed.

Logs attached from 1.X filter and then new filter posted above.

If it is possible and you find some time, remove from filter MPUrlSourceSplitter_Parser_MPEG2TS.dll file and try again.

 

[Sigpi007]

Interesting results without that dll... It improved things noticeably, but didn't fix it. I tested CBS (HD) watching a program CSI. This program played for 3 seconds flawlessly and then stuttered about every other second (small improvement over last time). Audio was synchronized and clear for any frame that was played. I then tried the same program on CBS non-HD station, and that time it played perfectly fine (non-HD).

Then I tested other HD stations. Found one (Comcast SportsNet) that stuttered only every 5-7 seconds. Found another station (TLC HD) that didn't stutter at all (in HD). I went back to a major network (NBC HD) and saw that program play fine for about 8-9 seconds, and then stutter every 3-4 seconds.

Overall... I think that the filter is handling things okay until it gets to a format or size it can't process fast enough. Or something like that. I've attached the log files from the tests described above. CPU was in the normal range.

Just for my own curiosity, I went back and added the dll back and tried those same channels... even TLC HD that played fine. With the MPEG2TS file the performance was TERRIBLE. All the channels stuttered every second. (Audio worked as much as you could expect for the amount of frames being skipped.)

 

[mm1352000]

Hmmmm, interesting. What was the CPU and GPU workload like for the HD channels?

TsWriter and the IPTV filter aren't reporting any dropped/lost packets. So, seems like the path from the tuner to TV Server is okay/reliable, which is good.
However, TsReader is receiving data late and constantly trying to increase compensation, which is not good.
The EVR is also constantly dropping frames...

 

[Sigpi007]

CPU and GPU workload like for the HD channels?

I'll need to do some more testing to be absolutely accurate, but in my recollection I actually saw no difference across the different tests. Also... In this particular setup (built for low noise / low power), the processor is an APU... so the CPU and GPU are the same chip. (Specs in signature below) I may be saying that wrong, but the basic premise is that there is no discrete video card.

Another thing... before I get a comment on this... I noticed I had the TV codec for MPEG2 set to AMD Video Decoder instead of LAV filters. I changed that to LAV and did the same testing as posted above and came up with the exact same results on the same channels.

Not sure what the EVR is... but I noticed the dropped frames when watching the video during testing after hitting Shift+1. Dropped frames tended to be more noticeable on video that was 1080 and not as noticeable on 720 resolutions. I don't think this is a perfect correlation though.

 

[mm1352000]

so the CPU and GPU are the same chip. (Specs in signature below) I may be saying that wrong, but the basic premise is that there is no discrete video card.

Sure, they're packaged in the same chip, but they're still separate processors. As such they can have different utilisation levels. That's why I asked.

Another thing... before I get a comment on this... I noticed I had the TV codec for MPEG2 set to AMD Video Decoder instead of LAV filters. I changed that to LAV and did the same testing as posted above and came up with the exact same results on the same channels.

LOL, it's almost like you read my mind.
I was going to mention this and ask you to test with LAV, but I figured it probably wouldn't make a difference so decided to just let it be. Thanks for confirming!
[edit: Oh, actually... since you mentioned the 720p vs 1080i difference, can you confirm that DXVA (GPU accelerated video decoding) is enabled in the LAV settings?]

EVR is the enhanced video renderer. The stats you see when you press shift + 1 come from the EVR.

 

[georgius]

It seems that filter is not fast enough to process data As I check, data are received approx. 2393453 B/s (respectively 2394241 B/s without parser), but processed are approx. 663973 B/s (respectively 1588408 B/s without parser). So, with parser it is 3.6 times slower, without parser it is 1.5 times slower.

Try attached version, first test with parser and and second test without parser. I reverted buffer size to be same as in filter with no performance optimisations. I suppose that there will be some performance hit, but maybe filter will process data in time.

 

[mm1352000]

@georgius
When you say B/s do you mean byte or bit?
Probably the filter needs to be able to do ~15 to 20 Mega-bit per second in some cases (USA 1080i HD MPEG 2, CableCARD tuners)...

About the buffering: maybe it would be good to ramp the buffer size at startup, like TsWriter does? This increases the zap (change channel or start TV) speed, while still allowing to use a large buffer.

 

[georgius]

@georgius
When you say B/s do you mean byte or bit?
Probably the filter needs to be able to do ~15 to 20 Mega-bit per second in some cases (USA 1080i HD MPEG 2, CableCARD tuners)...

Byte per second.

About the buffering: maybe it would be good to ramp the buffer size at startup, like TsWriter does? This increases the zap (change channel or start TV) speed, while still allowing to use a large buffer.

I started to think about dynamic increase of buffer size, but I must be sure that increasing buffer size solve the problem. In other case I must descrease sleep time in threads, which surely increase CPU usage.

 

[mm1352000]

Byte per second.

Ahhh, yeah: ~19.2 Mb/s is approximately what I expected.

Hopefully the buffer size increase will help...

 

[Sigpi007]

So... I get to post what I hope is good news. So far... both scenarios of testing Filter #2 from above (with and without MPEG2 parser) worked very well. In fact, there was no noticeable difference between either. The playback worked well. Not a single stutter... and this was indeed on my low power everyday HTPC.

Here's the GPU and CPU stats for each scenario.

With MPEG2 Parser...
- GPU1 pinned at 100% utilization
- GPU2 spiky... 0 or 100% utilization in sporadic spikes
- GPU3 steady utilization roughly around 65%
- 4 CPU cores roughly average around 18% utilization
- MP client was around 10% CPU utilization
- TV Service was consistent around 2-3%


Without MPEG2 Parser...
- GPU1 pinned at 100% utilization
- GPU2 spiky... 0 or 100% utilization in sporadic spikes
- GPU3 steady utilization roughly around 65%
- 4 CPU cores roughly average around 17% utilization
- MP client was around 10% CPU utilization
- TV Service was consistent around 1-2%

I've decided to reintroduce the MPEG2 parser and run with this new filter for everyday use to see if there are any long term impacts. So far I've had pretty good luck on everything I tried to watch in the last 30 minutes or so.