TV repeatedly freezing momentarily (1 Viewer)

[doveman]

Have you tried running the resource monitor and checking what the HDD utilisation is like when the problems occur? I know that I can get freezes and corruption when other HDDs spin up and down.

No, I'll try that and see what it shows thanks.

I've certainly found that services/drivers do seem to be connected to the problem though, as I was getting tons of these hangs before I disabled those VMWare services, to the point that it was almost becoming too annoying to watch TV. Since disabling them, I might get one an hour, which is still annoying but not so much that it makes me want to chuck the PC out the window

It seems that VMware haven't fixed the problem since I last tried Workstation a year or so back, as that caused high latency spikes which affected video as well. I can only guess that the latency spikes perhaps cause a glitch in the signal path that shows as a continuity error.

I guess it's also possible that I was having continuity errors (maybe caused by aerial/signal problems) at the same frequency before (i.e. about once an hour) and the VMWare services were causing additional hangs that didn't show in the logs, although I think I tended to check the logs after noticing hangs and saw corresponding continuity errors.

 

[doveman]

Hmm, looks like Resource Monitor only graphs 60secs, which isn't really enough for me to be able to close MP and check. Really need something that will record any spikes over 1-2 hours, as for example this morning I got three occurrences of continuity errors from 8-9am and one from 9-10am (although the last one was at 9:52 and I'm sure there was a hang nearer 9:58, just before I closed MP to save the xperf trace, so perhaps there's hangs that aren't being reflected in the logs as continuity errors, I guess I'll have to note how many hangs I see and compare this to the logs later).

I've uninstalled VMWare Player and Virtualbox completely now and it hasn't stopped the hangs happening, so I'm not sure what I'm going to try next.

 

[doveman]

OK, I did a fresh install of MP1.3A (previously did an upgrade).

I also disabled my second tuner (WinTV), the USB Redirector device (part of Virtual PC I think), installed the AMD AHCI/chipset driver 12.6 (previously had the Microsoft ones installed), disabled AMD external events service and AMD FUEL service, non of which helped. I found this morning, after resuming from standby (with MP not loaded) then starting MP, that the video was jerky and the render time was around 16, so I closed MP and restarted AMD Fuel and after that the render times returned to normal (around 3-4). I've only seen this problem before when dwm/Aero is disabled, so I guess FUEL must be connected to that.

After that I changed the power mode to High Performance and I haven't noticed a hang since, although looking in the logs there are some continuity errors around 12:30, so maybe I was out of the room then and missed it. I would normally expect to see a hang at least once an hour though, so it seems to have helped. If that is the problem, I guess we need to find why MP can't play LiveTV without these glitches with the PC in Balanced Mode (i.e. using Cool'n'Quiet).

I'll upload the logs later, just want to let TV run longer to see how many continuity errors appear and whether I notice any hangs.

Ah crap, just saw a hang at 14:24!

 

[mm1352000]

If that is the problem, I guess we need to find why MP can't play LiveTV without these glitches with the PC in Balanced Mode (i.e. using Cool'n'Quiet).

What makes you say the problem is with MP - have you tried other TV software?
As I read this thread it feels like you're diving into the most complex of investigations without necessarily having sorted out the basics. For example, I think it would help *immensely* if you could isolate the problem to client or server side (in other words: source or playback) before anything else. You could potentially have problems with both, but when dealing with a problem I always find it smarter to work from top down. So I recommend you start from source and work your way through the chain to what you see on screen, eliminating problems logically as you go. And keep it simple - if you don't need all that VMWare and AMD software, why have it installed? Installing superfluous software is just begging for problems.

So if you're starting at source to deal with the continuity errors, are you confident that your reception system is good? If memory serves me correctly, issues with your signal quality have been discussed in the past. Did you get your signal checked?

 

[doveman]

If that is the problem, I guess we need to find why MP can't play LiveTV without these glitches with the PC in Balanced Mode (i.e. using Cool'n'Quiet).

What makes you say the problem is with MP - have you tried other TV software?
As I read this thread it feels like you're diving into the most complex of investigations without necessarily having sorted out the basics. For example, I think it would help *immensely* if you could isolate the problem to client or server side (in other words: source or playback) before anything else. You could potentially have problems with both, but when dealing with a problem I always find it smarter to work from top down. So I recommend you start from source and work your way through the chain to what you see on screen, eliminating problems logically as you go. And keep it simple - if you don't need all that VMWare and AMD software, why have it installed? Installing superfluous software is just begging for problems.

So if you're starting at source to deal with the continuity errors, are you confident that your reception system is good? If memory serves me correctly, issues with your signal quality have been discussed in the past. Did you get your signal checked?

No, MP is the only TV software I've tried as it's the only one I'm interested in. In the past when I've compared other software (for video playback, not TV) I've been told it's not valid to compare like this as they work differently anyway.

I use a single-seat, but I think it's clear the issues are "server-side" as the continuity errors appear in TSwriter.log.

Regarding the AMD software, AMD external events service and AMD Fuel are installed as part of the graphics driver and as I mentioned, disabling the latter caused video render time problems the same as disabling dwm/Aero. The AMD AHCI/Chipset drivers I installed after seeing them recommended in this post and realising I was still running the default Microsoft drivers https://forum.team-mediaportal.com/...us-an-upscale-guide.108286/page-6#post-882688

I do need some VM software (either VMWare, Virtualbox or Virtual PC) so that I can keep software from being installed into the real system and possibly causing problems for MP. VMware seems to cause latency issues though, so I'll probably go with one of the others.

I haven't been able to get the signal checked yet, but I'm dubious that it's that simple as a) I'd expect to see problems more often than once or twice an hour (or less) if the signal was the problem and b) I wouldn't expect the problem to get substantially better after disabling the VMWare services and switching the power mode to High Performance if the signal was the problem. If you know of a program that will monitor the signal (not whilst MP/TVservice.exe is also running) and record any glitches, I'd be happy to run that to see what that shows though.

 

[doveman]

OK, as you can see from the attached logs (today's TSwriter and TSreader) there weren't any more continuity errors after 14:24, so using High Performance power mode certainly seems to have made a big difference (just compare to the logs for yesterday (16/07), where there were numerous such errors throughout the evening).

One wierd thing though is that after 14:24, the TsReader log stopped logging until 15:26 and the TsWriter log is full of "discontinuity header bit set" messages from 14:24 onwards

 

[mm1352000]

I'm not convinced that changing the power mode could make any major difference on the performance of the TV Server. Client side: sure, because power mode changes could have effects on the CPU and GPU performance, which can affect the smoothness of the UI and video playback. The server side is not particularly CPU or GPU intensive though (unless using software encoders for analog tuners, which you're not). To be reliable, it mostly requires decent HDD performance, clean signal, and reliable networking...

Do you believe the freezes/glitches/whatever-you-want-to-call-thems correlate with the periods where significant numbers of discontinuities are logged?
Are you doing any recording, and if so how do they come out - if you observe a glitch when watching the recording, is it consistently in the same place?
What about video playback: is it affected?

To me it seems there could be a correlation between the worst periods of discontinuities and viewing of channels on 506 MHz. However that is speculation because I can't judge the correlation with whatever visual effect you're seeing...

mm

 

[doveman]

Do you believe the freezes/glitches/whatever-you-want-to-call-thems correlate with the periods where significant numbers of discontinuities are logged?
Are you doing any recording, and if so how do they come out - if you observe a glitch when watching the recording, is it consistently in the same place?
What about video playback: is it affected?

To me it seems there could be a correlation between the worst periods of discontinuities and viewing of channels on 506 MHz. However that is speculation because I can't judge the correlation with whatever visual effect you're seeing...

mm

No correlation with the discontinuity messages, only with the continuity errors. So on 16/07 there were quite a few of these errors and quite a few freezes and today I saw a freeze at 14:24 and there's continuity errors at that time and I don't think I saw any other freezes after that and there's no continuity errors in the log after that either.

I did rewind when I saw one glitch and it was repeated but I would expect that as the errors are in TsWriter, so are going to affect any timeshift/recording files. I haven't really been doing much recording as there's only one tuner active in this HTPC at the moment. I haven't noticed this problem with video playback but a lot of what I watch is episodes which are less than an hour, so it's possible it wouldn't show up in that time., although I'm pretty sure I haven't seen it when watching films either. I suspect that it's just the LiveTV stream that is being corrupted by this problem (whatever the cause) and that video playback isn't affected.

I should be able to capture the problem by using the "include timeshift buffer in record now recordings" debug option and then I'll upload a clip so that you can see how the problem manifests.

 

[mm1352000]

No correlation with the discontinuity messages, only with the continuity errors.

When I say "discontinuities" I mean both. They indicate pretty much the same thing. Discontinuity header bit set means the tuner driver has picked up on a stream error and flagged it; continuity errors are the same thing except detected by TsWriter. That's how I understand it anyway. If my understanding is accurate then your statement above doesn't make logical sense to me.

I did rewind when I saw one glitch and it was repeated but I would expect that as the errors are in TsWriter, so are going to affect any timeshift/recording files.

That isn't an assumption that I had made since the thread started with talk about stuff that is way over on the client side (EVR presenter, SetThreadAffinityMask()).

I haven't noticed this problem with video playback but a lot of what I watch is episodes which are less than an hour, so it's possible it wouldn't show up in that time., although I'm pretty sure I haven't seen it when watching films either. I suspect that it's just the LiveTV stream that is being corrupted by this problem (whatever the cause) and that video playback isn't affected.

Well if that is the case, all the more reason to get your signal quality checked.

I haven't been able to get the signal checked yet, but I'm dubious that it's that simple as a) I'd expect to see problems more often than once or twice an hour (or less) if the signal was the problem...

My experience would suggest that your expectation is not always realistic. Different signal issues manifest in different ways. With some faults like cabling issues you might expect consistent problems. With weather or dish/aerial alignment it could be totally random but "prolonged"- like maybe issues spanning over half an hour or something. Sometimes issues can be caused by things as strange as the movement of a cable in the wind that only causes a glitch on a windy day when the gust is relatively strong. In other words, I would suggest to take an evidence based approach.

... b) I wouldn't expect the problem to get substantially better after disabling the VMWare services and switching the power mode to High Performance if the signal was the problem.

It is hard for me to judge from the other side of the world how much of a difference those actions made. My inclination is to not be convinced that the power mode is related for the reasons that I have given earlier. I did say that continuity issues seen in the TsWriter log can be caused by HDD loading or physical activity (spin up/down), so I wouldn't have half so much problem believing that VMWare could cause issues when it gets its hooks into the OS driver layers. I note that the PS entries are going wild in your tv.log. I think that is unlikely to be having a significant effect but I would appreciate it if you could disable extended logging (45 MB log files are a little extreme for my liking ).

If you know of a program that will monitor the signal (not whilst MP/TVservice.exe is also running) and record any glitches, I'd be happy to run that to see what that shows though.

I have learnt never to trust the signal quality measurements from a BDA tuner driver, so wouldn't recommend any amount of software. I recommend a technician with a professional signal quality meter. Yes it will cost, but if you really want certainty about the issue then it is the best approach. Otherwise it becomes difficult to eliminate potential causes.

I should be able to capture the problem by using the "include timeshift buffer in record now recordings" debug option and then I'll upload a clip so that you can see how the problem manifests.

Okay... although that is almost certainly not going to tell me anything about the cause.

 

[doveman]

When I say "discontinuities" I mean both. They indicate pretty much the same thing. Discontinuity header bit set means the tuner driver has picked up on a stream error and flagged it; continuity errors are the same thing except detected by TsWriter. That's how I understand it anyway. If my understanding is accurate then your statement above doesn't make logical sense to me.

Well I only had freezes roughly correlating to the number of continuity errors on 16/7. There's a much higher number and frequency of discontinuity messages and I certainly didn't have that many freezes. Again on the 17/7, I only had a couple of freezes, the last being at 14:24, whilst there's an endless number of discontinuity messages after that.

That isn't an assumption that I had made since the thread started with talk about stuff that is way over on the client side (EVR presenter, SetThreadAffinityMask()).

Yes, that was what was flagged up by the xperf trace, with high CPU spikes being caused by the CPU power management driver, which in turn was being triggered by MP changing the CPU affinity.

My experience would suggest that your expectation is not always realistic. Different signal issues manifest in different ways. With some faults like cabling issues you might expect consistent problems. With weather or dish/aerial alignment it could be totally random but "prolonged"- like maybe issues spanning over half an hour or something. Sometimes issues can be caused by things as strange as the movement of a cable in the wind that only causes a glitch on a windy day when the gust is relatively strong. In other words, I would suggest to take an evidence based approach.

Until the recent changes I've made to the system, I was getting these freezes throughout the day, roughly once or twice an hour. I don't think the weather's been much different since the 16/7 but I'll monitor it over a few days to see if there's any variation due to the weather. Hopefully this problem isn't caused by "the movement of a cable in the wind that only causes a glitch on a windy day when the gust is relatively strong" though, as if it is the chances are it won't be picked up by the (expensive) technician if I book one.

It is hard for me to judge from the other side of the world how much of a difference those actions made. My inclination is to not be convinced that the power mode is related for the reasons that I have given earlier. I did say that continuity issues seen in the TsWriter log can be caused by HDD loading or physical activity (spin up/down), so I wouldn't have half so much problem believing that VMWare could cause issues when it gets its hooks into the OS driver layers. I note that the PS entries are going wild in your tv.log. I think that is unlikely to be having a significant effect but I would appreciate it if you could disable extended logging (45 MB log files are a little extreme for my liking ).

Oops, sorry about the logs. I hadn't realised they were getting so big as they compress so well! Of course it may be a coincidence but you can compare the logs to see how much of a difference changing power mode appears to have made. It's true that it didn't seem to help when I changed it before, although perhaps it's a combination of power mode and something else I changed previously that's made the difference now. I'll try switching back to Balanced mode sometime anyway, which should show whether the power mode has anything to do with this problem.

I have learnt never to trust the signal quality measurements from a BDA tuner driver, so wouldn't recommend any amount of software. I recommend a technician with a professional signal quality meter. Yes it will cost, but if you really want certainty about the issue then it is the best approach. Otherwise it becomes difficult to eliminate potential causes.

Fair enough, I just thought it might be useful to have an alternative to compare to TsWriter or to run without playback in MP at the same time but if this continues to have none or very few continuity errors even whilst watching live at the same time then it's probably not necessary.