Recording Glitches - Debug Advice?

[andrewj]

Thanks Martin. I can do the delete if you think it's OK, but I'd rather not if there's any risk of wiping out any valid recordings. Please advise.

[mvallevand]

None of those currently work, but so won't miss anything but you might end up with a sh*tload when it gets addressed.

Martin

[andrewj]

Hi Martin. I've confirmed that changing the "not in" in your code to "in" selects 316 rows with valid OIDs, so it should be safe to delete the others (with OID = 0), if it's safe to do the delete in the first place. What do you think?

[andrewj]

Sorry, just saw your reply. Do I need to restart anything after doing the delete?

[mvallevand]

Where do you create those recordings that are based on the EPGTitle, they might be obsolete. When did you convert from v4?

Does adding a condition reduce the number of hits.

and
match_rules like '%<EPGTitle>%'

Martin

[andrewj]

Hi. I just deleted the recordings with OID = 0 as per your original SQL. I think you're right and they were an artefact of the upgrade from 4.X to 5.X, which was some time ago. NPVR still has all my channel-specific recordings, and the logs are clean now.

I'll wait until I have another recording with identifiable glitches, and share the logs and .TS file.

In the meantime if there's an FAQ page or similar it might be worth posting a note about the "missing recordings" problem with a note on how to clean it up with a copy of your SQL.

Thanks, Andrew

[mvallevand]

Doing a bit of research on this the spam was actually caused by you turning on extended logging generating 587 extra lines for each recurring recording. Since you had hundreds of recurring recordings the logs filled up. You really don't need that on to help diagnose the glitch issue.

The missing recording issue will be fixed in a future update. Although it has been a issue since v5 was released and if there was a report it wasn't diagnosed I still expect a few people will be surprised.

No need to write documentation on this, I think it really only applies to people that copied their database from v4. For you it looks like the faulty rules stopped 2025-02-22 and that date matches this post https://forums.nextpvr.com/showthread.ph...#pid599303 quite well which is probably when you upgraded.

Martin

[andrewj]

Thanks, Martin. Could you please have a look at the cleaned-up logs attached? I've just watched the Top Gear which started 13/1/25 20:35. The recording started at 20:31. There were a few glitches, most minor but one quite noticeable at 53'19 in, which I think would be 21:24 in real time if I've done the sums right.

Do the logs indicate any problem?

I also have the .TS file if you need it.

Thanks, Andrew

[mvallevand]

There still is a lot of spam because you didn't turn off extended logging yet but at least I can see the so stream error messages

2026-01-14 02:48:03.708 [ERROR][91] TS continuity counter indicates missing packets

But these are only in the expected place between transitions so nothing abnormal.

It doesn't look like the attenuation is doing anything, it is still very strong.

Martin

[andrewj]

OK. I haven't got the attenuator in place yet, that's the next job. In the meantime should I should turn off extended logging?