Poor quality recordings, PCTV 290e DVB-T/DVB-T2. (1 Viewer)

[Woody[UK]]

Hi,

I have a problem, MediaPortal TV Server recordings have picture glitches and sound drop outs (Similar to what you would expect from a poor signal).

I experienced this problem last year when I tested TV Server v1.7 on a AMD Athlon x2 5400+ system and now with TV Server v1.10 on an Intel i3 3225 based system. Using 'check continuity' in 'MPEG-2 TS packet analyser' recordings always have a seemingly random amount of errors. There seems to be no problem streaming live TV from MediaPortal TV Server to Kodi on the same pc or with Live TV using 'open device' in MPC-HC and VLC.

I also have poor quality recordings when using Argus TV, but I have been using TV Scheduler Pro for years and all recordings with TV Scheduler Pro are fine with no errors.

I have tried everything I can think of and I am stuck, any help appreciated.

Thank You.

 

[mm1352000]

Hello and welcome

There are a few continuity errors in the TsWriter log. These usually point to issues with reception (signal strength/quality) or HDD load. If you're sure that your reception is fine, ensure that any security software (MS Security Essentials, Windows Defender etc.) does not scan the MediaPortal program, config, timeshift and record directories.

There seems to be no problem streaming live TV from MediaPortal TV Server to Kodi on the same pc or with Live TV using 'open device' in MPC-HC and VLC.

Given that:

• you have no problem streaming on the same PC
• since there are only a few continuity errors in the TsWriter log

...have you considered that the problem might be primarily a playback problem?
In other words, if you're streaming over a network, perhaps the network doesn't have enough bandwidth to cope?
Or perhaps the codecs in whatever playback software you use are not making use of hardware acceleration for video decoding (DXVA)?

Regards,
mm

 

[Woody[UK]]

Hi thanks for the reply,

Reception and cables are fine; it’s one of the first things I checked (even though TV Scheduler Pro always works). I do not have any security software installed. I am not streaming over a network. I normally use Kodi to playback locally. I have also played back with MPC-HC and VLC, HW acceleration on or off it does not make a difference. The TS files contain packet errors.

Originally when testing, I was actually watching the programs and noticed the errors. Then I found 'MPEG-2 TS packet analyser' to scan the files. If I record TV, alternating every 10 minutes with TV Server and TV Scheduler Pro. It’s only the TV Server recordings that contain errors.

Last year I gave up and kept TV Scheduler Pro on my AMD system. I have now just put together an Intel system as an upgrade and experiencing the same problem. TV Scheduler Pro is pretty much EOL and I would like to move to better software, but not at the expense of recording errors.

Any more suggestions?

Thank you.

 

[mm1352000]

Any more suggestions?

Is the HDD that you're recording to relatively full, highly fragmented, and/or very slow?
Do you have multiple HDDs in this machine?
Is your timeshift and recording folder(s) on the same HDD?
Do you record to NAS?

Thing is, with MediaPortal there's essentially no difference playing live and recorded TV. So, in most cases I'd suspect that you should have problems with live TV if you have problems with recordings.

 

[Woody[UK]]

Hi, sorry I did not expect a reply so quick.

Sorry, some system specs might help.

Transmitter = Winter Hill, North West, England.
Distance = about 5 miles, clear line of sight.
Aerial = Vision V10-36L Log Periodic.
Cable = 15 meters Webro WF100, with 'F' connectors.

AMD system
Athlon 64 x2 5400+ 2.8ghz Black.
4gb Corsair Dominator Twin2x4096-8500C5D.
MSI KA790GX motherboard.
AMD HD 4850 graphics, upgraded to Nvidia 650 ti.
1x 640gb Black WD6401AALS HDD.
Enermax Liberty ECO 400 PSU.
Windows 7 64-bit.

Intel system
i3-3225 (Ivybridge) 3.3ghz.
8gb Crucial 1600 c9 1.35v Sport LP.
Asus P8Z77-I Deluxe ITX motherboard.
Intel HD 4000 graphics.
1x 256gb Crucial MX100 SSD.
1x 320gb Seagate Momentus Thin ST320LT0.
FSP FSP300-60GHS 300w PSU.
Windows 7 64-bit.

I record to internal sata drives, the disks have plenty of free space and CrystalDiskMark shows expected speeds. The Recordings folder and Timeshift folders are on the same disk drive. Using the Intel system, I recorded to the SSD while leaving the timeshift on the HDD. For the first time ever, TV Server created a flawless recording, 35 minutes with no errors. Unfortunately the second recording (the very next program on the same channel), had 67 errors over 25 minutes. 27 video pid packet errors and 29 sound pid packet errors.

Thank you

 

[mm1352000]

Thanks for the detailed info

I'm not familiar with the aerial and equipment you're using, but a quick google suggests they'd be adequate assuming terminations are good.

PCs with those specs should have no problem recording with TV Server. I'm running XP on an old Intel Core 2 e6600 2.4 GHz, 4 GB RAM and Asus P5W DH motherboard... and TV service hardly hits 5% with that. The only slight reservation I have is with the Seagate HDD, which is only a 5400 RPM drive. Having said that, even that HDD shouldn't have any problem recording at least a couple of HD program as long as it isn't being taxed by other software at the same time (which I'd guess it isn't, due to the SSD).

I admit that I still have concerns about the reception, but only because it is the most likely explanation and 15 m is a decent cable run. At the same time I acknowledge that you've said TV Scheduler Pro has no problem and I can't explain that. However, there seems to be no pattern to the continuity errors in the logs that you provided... and with the SSD recording test: that result doesn't make any sense to me. If you hadn't said otherwise, my first question would have been to ask whether they were for channels from different transmitters... but no.

Very odd.

I guess we should think about rarer causes of continuity errors. The ones I've encountered in my time which might be relevant to your setup are...

• overheating components (eg. the tuner, recording HDD)
• DPC latency issues; these can definitely be a problem for USB devices

You can use the DPC Latency Checker tool to check the second point.

If I were you I'd set up a recording and monitor the continuity errors and signal strength/quality in TV Server configuration manual control, and at the same time have the DPC Latency Checker tool monitor up, and the task manager resource monitor up for HDD utilisation monitoring.

If all else fails, the only way forward that I can think of is to look for patterns. Do the continuity errors only occur (of more frequently occur) [for example] when a certain other application is open, at certain times of the day, with certain channels...
Patterns are the key.

 

[Woody[UK]]

Hi,
I did check latency last week with Thesycon DPC Latency Checker. I found that Intel LAN driver v19.5 caused high latency spikes every few seconds, dropping back to driver v19.1 fixed this.

Temperatures for the CPU, Motherboard, HDD and SSD are all around 20 'C at idle. The CPU goes up to 50 'C under load with OCCT power supply test (70 watts at the wall).

Having previously discovered disabling 'Cool and Quiet' on the AMD PC improved recording with Argus TV. I disabled EIST (speedstep) and fixed the CPU multiplier to x16 on the Intel PC, this did not help.

I also…
Checked the aerial and cable connections.
Check digitaluk.co.uk for engineering work.
Checked signal strength with a digital TV signal meter.
Used the USB tuner in powered usb hub to ensure correct volts.
Updated the Intel/Asus P8Z77-I BIOS to the newest v1201.
Reset BIOS to defaults.
Toggled HPET on/off in BIOS.
Tested with Thesycon DPC Latency Checker.
Disabled Wifi in BIOS.
Disabled Bluetooth in BIOS.
Disabled Asmedia USB3 controller in BIOS.
Disabled Intel xHCi mode (usb3 mode) in BIOS.
Disabled Intel LAN controller in BIOS.
Disabled Spread Spectrum in BIOS.
Uninstalled Asus Ai Suite 2 with cleaner.
Reformatted the HDD.
Reinstalled Windows 7 sp0.
Installed Intel RST driver only (not the driver install.exe).
Installed newest Intel Management Engine driver v10.0.30.1054.
Flashed IME firmware to v8.1.52.1496.
Flashed BIOS v1203 updated with UBU v1.9.

Installing the older Intel LAN v19.1 driver helped as previous to this even TV Scheduler Pro failed to record on the Intel PC.

As I own two PCTV 290e USB tuners and now have two PCs I am able to run more tests. Using a Labgear FBS402/S 2 way splitter I connect both my AMD and Intel PCs to the same aerial. All of the tests were performed using the Intel PC, which was powered off between each test. I used PCTV 290e driver v5.2013.1206.0 from the Empia folder in the PCTVSystems TVCenter download (same driver as the PCTV 292e). All of the recordings are of the same channel on the same mux (ITV2 SD). The AMD PC was set to continuously record the same channel on the same mux (ITV2 SD). Each recording was scanned for errors using 'MPEG-2 Transport Stream packet analyser'. Power consumption was measured at the wall with a Belkin Conserve Insight Energy Use Monitor. System monitoring was performed using 'xperf' from the 'Windows Performance Toolkit' part of the 'Windows ADK for Windows 8.1 Update'.

Spoiler: xperf usage notes

======================================================

set trace_name=FileName

======================================================

start log DiagEasy (PROC_THREAD +LOADER +DISK_IO+ HARD_FAULTS+ DPC+INTERRUPT +CSWITCH +PERF_COUNTER)
------------------
Xperf –on DiagEasy

======================================================

start log latency (PROC_THREAD +LOADER +DISK_IO +HARD_FAULTS +DPC +INTERRUPT +CSWITCH +PROFILE)
---------------------
xperf -on latency -stackwalk profile

======================================================

start log custom
---------------------
xperf -on PROC_THREAD+LOADER+DPC+INTERRUPT+PROFILE+DRIVERS -stackwalk Profile -BufferSize 1024 -MinBuffers 256 -MaxBuffers 256 -MaxFile 1024 -FileMode Circular

======================================================

start log custom+hdd
---------------------------
xperf -on PROC_THREAD+LOADER+DPC+INTERRUPT+PROFILE+DRIVERS+DISK_IO+HARD_FAULTS -stackwalk Profile -BufferSize 1024 -MinBuffers 256 -MaxBuffers 256 -MaxFile 1024 -FileMode Circular

======================================================

stop and save to file
---------------------------
xperf -stop -d R:\temp\%trace_name%.etl
======================================================

filter to txt file
------------------
xperf -I R:\temp\%trace_name%.etl -a dpcisr > R:\temp\%trace_name%_dpc.txt

======================================================

list driver versions
------------------------
xperf -I R:\temp\%trace_name%.etl -a fileversion > R:\temp\%trace_name%_driver_versions.txt

======================================================

xperf: error: NT Kernel Logger: Cannot create a file when that file already exists. (0xb7)
The error message is misleading and has nothing to do with a file that already exists. It happens when a different tool already started a NT Kernel Logger to capture ETW data

======================================================

Latency Graphs
---------------------
DPC/ISR - DPC Duration by Module, Function
DPC/ISR - ISR Duration by Module, Function
DPC/ISR - DPC/ISR Duration by Module, Function

Test Results.

None of the recordings created with TV Scheduler Pro on the AMD PC had errors.

The Intel/Asus P8Z77-I BIOS has two sub-menus named 'CPU Power Management'. Accessed in different places, both contain SpeedStep but one menu has Duration Power Limits and the other has C state settings. Finding the C State settings helped a lot, as disabling 'CPU C6 Report' made a huge difference to the amount of errors produced by TV Server.

When comparing 'TV Scheduler Pro C6 on' and 'TV Server C6 on' xperf traces, I cannot see anything obvious. In 'DPC/ISR Duration by Module', USBPORT.SYS and ndis.sys Duration Max are under 0.2ms and all Module Duration Ave are under 0.025ms.

With the amount of errors TV Server (and Argus TV) vs. TV Scheduler Pro I would have thought the cause would be obvious, or maybe it is.. I'm just not seeing it… does this pattern help?

Thank you

 

[mm1352000]

Wow, that's some serious analysis... and honestly, a fair amount of it goes over my head. I haven't updated my knowledge of BIOS settings, CPU power state etc. since I assembled my current PC - which is a first gen Intel Core 2 + 975X chipset - and I've never used Xperf either.

Some questions:

1. When you test with TV Server, are you simply recording... or also timeshifting? I wasn't 100% sure given the content of the "rec to" column. Obviously it wouldn't be a fair comparison if you were only recording with TVS Pro, and timeshifting + recording with TV Server. So, I guess you're only recording... but I'd like to be certain.
2. When you tested the signal strength:
   1. What was the reading?
   2. Did you have the powered splitter connected?
3. During all this testing, were you able to observe temporal patterns? I mean, did you have TV Server manual control open to check the discontinuity counter... and check whether that correlated with any of the other metrics you were monitoring?

With the amount of errors TV Server (and Argus TV) vs. TV Scheduler Pro I would have thought the cause would be obvious, or maybe it is.. I'm just not seeing it… does this pattern help?

The cause is certainly not obvious to me.

The Xperf data is very detailed, but from my perspective it isn't that helpful. The key thing it doesn't show is correlation with continuity errors. When you're looking at an intermittent temporal (time-based) problem like continuity errors, it's critical to have correlation between the errors and the other metrics you're monitoring. That way you could say (for example): "ahhh, the errors are correlated with high power use..." (or whatever).

Intellectually I know that USB device interaction with the CPU can be troublesome. For tuners this should be user-land (software) independent. In other words, as long as the same CPU settings, USB chipset driver and tuner driver are used, the performance of the CPU+USB+tuner subsystem should be roughly the same in TVS Pro and TV Server. In saying this I'm assuming that TVS Pro isn't fiddling with eMPIA or PCTV proprietary settings... because TV Server doesn't have any code targeted at eMPIA or PCTV tuners.

The storage subsystem is a different story. File management (write chunk size, sync/async etc.) could make a difference... but I have no idea how TVS operates. Never used it.

 

[Woody[UK]]

Hi,
If you are interested, I found this article by Taylor Kidd which explains Intel power management quite well. Although I did experience the same symptoms on my AMD PC with 'Cool and Quiet' enabled, I would expect Intel power management to be similar.

When I was testing with TV Server I was only recording. I did make note of the paths under 'Rec to' as I was going to test with timeshift at different paths, but I did not.

The signal meter shows between 50dBuV and 60dBuV with the splitter fitted.

I do not own a powered splitter. The splitter I used was one I believe to be of reasonable quality. It has the ability to 'pass' power through the ports.

I have tested the hard disk with TV Server (C6 disabled). I set a schedule to record one HD channel, then to add another HD channel every five minutes until recording four channels at the same time. Except for the first recording, which dropped 2 packets right at the start. All of the recordings passed the continuity check with no errors. I think this proves the hard disk is capable of recording multiple channels simultaneously.

At first I thought a temporal pattern would be difficult to analyse because of the format that xperf logs data and because I checked the recordings for errors after they have completed. Also, watching the stream live greatly reduced the number of errors. I remembered TV Server TsWriter.log records continuity errors with a time stamp. So I used Windows Performance Monitor (perfmon.exe) to create a User Defined Data Collector Set. I specified to collect Performance Counter data from LogicalDisk, Processor and USB. I set a sample interval of 1 second and to save the data as Comma Separated (CSV). I then scheduled the Data Collector to start 1 minute before a recording. Analysing the data I observed the following.

TV Server had very slightly lower CPU use than TV Scheduler Pro.
Processor Information (0,#)\% Idle Time
C6disabled TVSchedulerPro (average) 98.66
C6disabled TVserver (average) 99.05
C6enabled TVSchedulerPro (average) 98.40
C6enabled TVserver (average) 98.79

There were less 'interrupts/sec' with TVServer and C6 enabled.
Processor Information (_Total)\Interrupts/sec
C6disabled TVSchedulerPro (average) 574
C6disabled TVserver (average) 598
C6enabled TVSchedulerPro (average) 556
C6enabled TVserver (average) 424

There were no regular 'USB(PCTV 290e)\Control Data Bytes/Sec' with TVServer (C6 enabled or disabled)
There was around 267 bytes every 10 seconds with TV Scheduler Pro (C6 enabled or disabled)

Only with TVServer and C6 enabled did 'USB(PCTV 290e)\Iso Packet Errors/Sec' occur.
These errors correspond exactly with TV Server TsWriter.log continuity error.

At least disabling C6 seems to minimise TV Server continuity errors. Though I do wonder what TV Scheduler Pro does different.

Thanks