Recording Glitches - Debug Advice?

[andrewj]

Hi Martin,
Is there a simple way of cleaning out the recurring recordings on invalid channels? I'm happy editing XML if there's a straightforward way to identify the invalid items, but there's no practical way I can go through all my recordings to individually check the channel details interactively.

I do use Schedules Direct as my primary EPG source, so can't disable that.

I don't play the files in NextPVR. I convert them to MP4 and stream them to my TV using DLNA. However as the .TS file is the "source" and closest to NPVR, and as I have established that the faults are in the .TS files as well, that's what it makes sense to share.

Simplest way to get the .TS file is go to https://www.andrewj.com/public/, right-click on the Valley of the Kings file and download to your system.

One other thing, can you please confirm that I do have "full" logging enabled?
Thanks, Andrew

[mvallevand]

The "easiest" way to clean them would be with a sqlite3 tool backing up npvr.db3 first.

Code:

delete from recurring_recording
where
match_rules like '%<ChannelOID>%'
and
(substr(match_rules, instr(match_rules,"<ChannelOID>") + 12,
instr(match_rules,"</ChannelOID>") - instr(match_rules,"<ChannelOID>") - 12))
not in (select oid from channel)

change the delete from to select to see what will get deleted and make sure my logic is ok.

For the EPG why do you have so many channels not using SD? They might be able to add your lineup.

Thanks I didn't try that download method hower since you don't play the raw files in NextPVR and you process them too I will give up on this topic The post processing will magnify any problem in the file, there are many more missing packets then you showed 44 but that is out of 10587148

Martin

[andrewj]

Hi Martin,

It shouldn't matter what I do with the files after recording. I never change the .TS file, and I have confirmed that the errors are in the .TS files at the same places as the MP4 file. If I can fix the recordings then my downstream files will be fine.

Please can you set aside the issues with the EPG and old recurring recordings, and let me know:

• Have I got full debug logging enabled?
  
• Do the logs as they are tell us anything about the signal strength / quality?
  
• Do the logs tell us anything about the cause of the missing packets?
  

That would be very helpful.
Thanks
Andrew

[mvallevand]

I agree that there is an issue playing the file my point was really there is nothing that NextPVR can do to change how it is recorded. You can create a LogTSWriter DWORD in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\NPVR and set it to 1 but I don't see any value to that since it is the source and I won't bother looking at it.

Perhaps if you contact Hauppauge they might be able to help. They do have a signal strength utility and maybe that will help you improve the signal but the issue seems momentary.

As for a recording who is to say what FFmpeg or your UPnP server does with any file, you are assuming they are perfect Here is the same recording played using Amlogic h/w decoding not FFmpeg or Intel/ or NVIDIA in Kodi. https://streamable.com/gal6k9 The glitch is still there but likely quite different than you are used to seeing and it could easily be missed if you aren't watching for it. This capture is not as smooth as I see on the TV.

Martin

[andrewj]

Quick update...

Following Martin's advice I installed the Hauppage Signal Quality Monitor (an add-in to WinTV). This reports that my signal quality, for both SD and HD broadcasts, is 100%. Anything over about 84% would be OK, but I'm way beyond that. I think we can therefore eliminate signal quality as the issue. We can probably also eliminate physical issues such as wiring or moving foliage (there's none within 20m) as they would surely have a similar impact on live TV.

To my mind that leaves two possibilities:

1. Electrical / RF  interference. That could account for intermittent issues in an otherwise solid signal. However it's odd that we don't see any comparable issue on live TV. Obviously if this is the cause then nothing's going to be visible on the PC.
   
2. Issues on the PC, e.g. something interfering with the recording process. I'd probably expect to see that expressed in a log file somewhere. I can confirm that there's nothing in the Windows Application or System logs around the known times of the issue. I'd appreciate it if someone else could check my NPVR logs.
   

Any other ideas? I'd really appreciate any other thoughts, as this is proving really annoying.
Thanks
Andrew

[mvallevand]

Too strong a signal can actually be a problem, especially if you use a signal booster, you may need to attenuate it. I don't know if there is potential mobile phone frequency interference certainly that is possible here in North America.

I told you the 4 server logs 16MB siimply telling us spam about your bad recordings. The most useful logs info would be during the EPG update but we can't see that because of the spam. After you fix that it would be worth a revisit.


Martin

[Bobins]

Andrew,

As a long term user of PC based recording software here in the UK (and a career as a TV Engineer many years ago), I can add a few comments.

It's challenging to get a perfect digital recording without any artifacts caused by a number of external factors.

For example, where the old analogue TV system would show signal issues caused by obstructions to the transmitter such as hills, buildings trees etc. by showing ghosting effects in the picture, digital systems show issues such as dropouts or picture pixilation. Modern TVs are designed to handle these digital signal issues as they are dedicated to that function whereas PCs are a multitasking device with multiple simultaneous functions.
Blips in the signal will often be emphasised when recorded and then played back. The signal test you performed is a point in time. It does not indicate that the quality remained at 100% without interruption for an hour (such as would be needed for a perfect hour long recording).

As Martin pointed out, in the UK the move to digital TV and the frequency changes implemented to free-up space for mobile phone use have meant close proximity between TV and mobile phone frequencies which can result in sporadic interference between the two.

Other PC software running in the background can also cause issues during recording (e.g. anti-virus software).

Too much signal can be as bad as too little as it can overload the tuners internal amplifier. If you're using amplified distribution from your aerial and your test software indicates a strong signal you could try a small attenuator to see if that helps.

In my own case I live on a hill where I can see the TV mast on the opposite hill. In theory this means I have a direct line-of-sight, good/high quality signal with nothing close by to interfere and yet, I also see occasional dropouts or artifacts in recordings which I don't experience whilst watching live TV directly on the TV.

Whilst I too would like 100% perfect recordings, my experience tells me it can never be guaranteed and provided it's good 99% of the time, that's about as good as we'll get :-)

Ray

[andrewj]

Hi Martin,

Just checking your SQL to tidy up the database. It selects about 280 rows each of which has match rule like the following:

<Rules>
  <EPGTitle>Giants Live Series</EPGTitle>
  <ChannelOID>0</ChannelOID>
  <ChannelName>All Channels</ChannelName>
 ... (other fields)  
</Rules>

They all seem to have OID = 0 and ChannelName = "All channels". Is that correct for the duff entries?

Thanks, Andrew

[andrewj]

Re the comments on "too much signal" I have a signal attenuator somewhere. I'll try putting it upstream of the main splitter/amp and setting it so that WinTV reports a signal quality in the high 90s and see if that improves things.
Thanks

[mvallevand]

They all seem to have OID = 0 and ChannelName = "All channels". Is that correct for the duff entries?

It is those but thinking about it might be a bug in NextPVR

Martin