Freeview HD Recording Issues (1 Viewer)

[mm1352000]

@BioEgo
It seems that you have a standalone TV Server. Despite what you said about the energy profile, CPU throttling, and TV service priority settings, my best guess is that the PC - or maybe even only the USB controller - is throttling to a lower power state. If it's the CPU, CPU-Z or similar may show it. I suggest to try leaving an Internet browser window open. Other people who have reported similar problems also reported that trivial things like that solved the problem for them, so...

 

[BioEgo]

Ok tried your suggestion @mm1352000 but no luck. First a few details on the setup: it's not a stand alone server but a single seat configuration connected to the main TV. I'm also using my laptop as an external client to make it easier to perform some tests while wife is using main system. (main HTPC is Media2 and laptop is TEST in my profile's system specs should you need more details).

What I've done now is to connect to the TVServer with my laptop MP and perform the usual tests (start timeshift, start recording, stop timeshift), while on the main HTPC we were streaming something in IE11. CPU-Z showed no changes in CPU throttling (always running at top speed as expected). As usual as soon as I stopped the timeshift corruption started to show in the recording (I cannot post logs at the moment since my wife is still using the HTPC and I don't have remote access to the logs folder, but I kept track of the timings and corruption was clearly visible in recording at the expected time, will post logs as soon as I can).

I also checked in Device Management every USB dongle and hub disabling the possibility to them down to save power, just in case.

Ideas?

 

[mm1352000]

Hmmmm, this could be an interesting one!

Have you tried moving the recording folder to the SSD?
I know you wouldn't want to do that in the long term, but I'm just wondering if the "green" HDD could be kicking into power-saving mode and providing insufficient performance for successful recording. An SSD shouldn't have a performance problem.

The other thing you could check is DPC Latency.
Resplendence Software - LatencyMon: suitability checker for real-time audio and other tasks

 

[BioEgo]

Changed recording drive to SSD but same results. Attached TsWriter log, the last two tests were done using the SSD.
Tried running LatencyMon: everything was fine, ran usual recording test with LatencyMon running, when stopping the recording to conclude the test an unusual high spike happened changing the result.

Here is LatencyMon report:

Spoiler: LatencyMon report

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system seems to be having difficulty handling real-time audio and other tasks. You may experience drop outs, clicks or pops due to buffer underruns. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:05:14 (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: MEDIA2
OS version: Windows 10 , 10.0, build: 15063 (x64)
Hardware: ASRock, Q1900DC-ITX
CPU: GenuineIntel Intel(R) Celeron(R) CPU J1900 @ 1.99GHz
Logical processors: 4
Processor groups: 1
RAM: 3797 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 20 MHz
Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.
Highest measured interrupt to process latency (µs): 1896,454797
Average measured interrupt to process latency (µs): 9,240628
Highest measured interrupt to DPC latency (µs): 1034,755709
Average measured interrupt to DPC latency (µs): 3,935089

_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.
Highest ISR routine execution time (µs): 73,440
Driver with highest ISR routine execution time: ndis.sys - NDIS (Network Driver Interface Specification), Microsoft Corporation
Highest reported total ISR routine time (%): 0,023363
Driver with highest ISR total time: HDAudBus.sys - High Definition Audio Bus Driver, Microsoft Corporation
Total time spent in ISRs (%) 0,044740
ISR count (execution time <250 µs): 111360
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 0
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0

_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.
Highest DPC routine execution time (µs): 618,0960
Driver with highest DPC routine execution time: Wdf01000.sys - Runtime framework driver modalità kernel, Microsoft Corporation
Highest reported total DPC routine time (%): 0,470399
Driver with highest DPC total execution time: Wdf01000.sys - Runtime framework driver modalità kernel, Microsoft Corporation
Total time spent in DPCs (%) 1,069609
DPC count (execution time <250 µs): 989799
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 588
DPC count (execution time 1000-1999 µs): 0
DPC count (execution time 2000-3999 µs): 0
DPC count (execution time >=4000 µs): 0

_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

Process with highest pagefault count: none
Total number of hard pagefaults 0
Hard pagefault count of hardest hit process: 0
Highest hard pagefault resolution time (µs): 0,0
Total time spent in hard pagefaults (%): 0,0
Number of processes hit: 0

_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 21,098570
CPU 0 ISR highest execution time (µs): 73,440
CPU 0 ISR total execution time (s): 0,522436
CPU 0 ISR count: 105780
CPU 0 DPC highest execution time (µs): 618,0960
CPU 0 DPC total execution time (s): 11,765452
CPU 0 DPC count: 874993
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 3,223871
CPU 1 ISR highest execution time (µs): 18,3720
CPU 1 ISR total execution time (s): 0,038724
CPU 1 ISR count: 5462
CPU 1 DPC highest execution time (µs): 526,1760
CPU 1 DPC total execution time (s): 0,657290
CPU 1 DPC count: 46310
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 2,945963
CPU 2 ISR highest execution time (µs): 12,8880
CPU 2 ISR total execution time (s): 0,001062
CPU 2 ISR count: 116
CPU 2 DPC highest execution time (µs): 134,5560
CPU 2 DPC total execution time (s): 0,491907
CPU 2 DPC count: 34202
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 2,855469
CPU 3 ISR highest execution time (µs): 10,8120
CPU 3 ISR total execution time (s): 0,000020
CPU 3 ISR count: 2
CPU 3 DPC highest execution time (µs): 191,5560
CPU 3 DPC total execution time (s): 0,526959
CPU 3 DPC count: 34882
_________________________________________________________________________________________________________

ETA:
there's something bugging me though: why does this happens only when using the Cinergy Stick for recording? I've attached a second TsWriter log (TsWriter2.log) in which I switched the priority of the two cards in TVServer so that the one timeshifting is the Cinergy and the one recording is the Pinnacle. As you can see no continuity errors here, even after stopping timeshifting. It seems like something related to the Cinergy in particular, like it is somehow working fine only if there's another card timeshifting....
Another additional info: I do not have logs but from past experience when I recorded two shows at the same time the one on the Cinergy was corrupted even if the Pinnacle was working on the other recording. So timeshifting on the Pinnacle positively affects recording on the Cinergy, but recording on the Pinnacle as no effects. Not sure what to make of this but it seems strange....

 

[mm1352000]

Reported CPU speed: 20 MHz

Weird!
Aside from that, nothing is standing out.

How about this for a question...
You've confirmed that the discontinuities start in the recordings after you stop timeshifting... but do the discontinuities start again if you re-start time-shifting?

 

[BioEgo]

Weird!
Aside from that, nothing is standing out.

Yeah, didn't pay attention to that, should be 2Ghz actually, not sure why the strange reading there (CPU-Z was reporting it correctly though).

How about this for a question...
You've confirmed that the discontinuities start in the recordings after you stop timeshifting... but do the discontinuities start again if you re-start time-shifting?

Ok tried the following: start timeshift, then recording, then stop timeshift, start timeshift againg, stop it again, restart it, stop it and close. Each step more or less at a minute distance from the preceding one, starting from 00.36 (see attached log).

Strangely enough it seems that the first time I stopped the timeshift everything went fine, but from the second stop the errors are back again as usual. Also restarting timeshift stops the errors until I stop timeshifting again.

By the way I edited my previous post adding a test done after switching the two TV cards priority (it took me a while to edit and meanwhile you answered), not sure if it helps or makes things more confusing...

 

[mm1352000]

Mmm, thanks for the pointer to the edit. That does change things a little.

Three questions:

1. What kind of aerial/antenna do you have? (Indoor or outdoor etc.)
2. How are the two tuners connected to the aerial/antenna?
3. In addition to the two tuners, are there other TVs or set-top-boxes connected to the aerial/antenna?

I'm just wondering if the issue could be related to a splitter and/or something the Pinnacle tuner does to affect the signal for the Cinergy tuner when the Pinnacle tuner is idle. I guess you could test this by testing the Cinergy tuner in isolation:

1. Disconnect the Pinnacle tuner from the PC and from the aerial/antenna.
2. Start timeshifting using the Cinergy tuner.
3. Start recording the same channel.
4. Stop timeshifting.

The results at steps 2, 3 and 4 are important.
If there's a general problem with the Cinergy tuner then step 2 should show problems (pixelation etc.).
If there's a strange system problem then step 3 or 4 might show problems.

 

[BioEgo]

I'm connected to the roof aerial on top of the apartment block. Single entry point in house where I connected a splitter and the two tuner. Nothing else is connected.

Tried testing after disconnecting the Pinnacle card from both the PC and aerial. Logs attached (singlecard.txt): I used the complete test starting and stopping timeshifting a few times while recording. It's the same as the previous test: when timeshifting everything is fine, when recording only I have continuity errors.

Also generated logs for dual recording situation: started timeshift on Pinnacle, then recording on different mux with Cinergy, started recording timeshifting channel with Pinnacle and after a while stopped timeshifting leaving both card recording.

As you can see as soon as I stop timeshifting errors do appear even if the Pinnacle card is still active recording (and as far as I can imagine there should be no difference for aerial connection, tv card and drivers between timeshifting and recording, isn't there?).

I'm not really sure what's happening here, but the fact that this is involving only the Cinergy makes me think it is somehow related to the fact that to make TVE3 recognize this card you had to modify TVlibrary.dll, like there's maybe some other kind of incompatibility between the server and the card.

Do you think trying the same experiment with some other TV program might give us some insight into this? Any suggestion regarding what to try next? It's not a big deal per se (it's affecting me very rarely and I do usually have some backup method to fetch what I need to see) but it bugs me that it doesn't work as expected so if I can help fixing this I'll be more than glad!

 

[mm1352000]

Hello again

Interesting information and results - I wasn't expecting that.

In short:

I'm not really sure what's happening here, but the fact that this is involving only the Cinergy makes me think it is somehow related to the fact that to make TVE3 recognize this card you had to modify TVlibrary.dll, like there's maybe some other kind of incompatibility between the server and the card.

The modification I made will have no effect in this problem - guaranteed. It only enables TVE to detect the tuner. All operations after detection are unchanged.

Do you think trying the same experiment with some other TV program might give us some insight into this?

Sure. Please feel free to try any other programs that you'd like to try.

Any suggestion regarding what to try next?

Maybe.
First a question: when you say "timeshifting", do you mean [generally] viewing live TV in MP/KODI/other-client?

If yes, the next test I would recommend would be to try using TV Server Configuration -> manual control to exclude the effect of the GUI etc. on the system power state.

 

[BioEgo]

Maybe.
First a question: when you say "timeshifting", do you mean [generally] viewing live TV in MP/KODI/other-client?

If yes, the next test I would recommend would be to try using TV Server Configuration -> manual control to exclude the effect of the GUI etc. on the system power state.

Yes, I meant watching Live TV in MP (local or from laptop). By the way I did already try using manual control and everything works fine (was trying to reproduce the issue and never had any problems). Manual control reports no discontinuities on both cards. From what I've seen though manual control always starts timeshifting during recording, never found a way to only record from there.

By the way I should have a copy of DVBViewer that was shipped with the Cinergy card, I'll try that later and see what happens. I'll keep you updated.