I’ll confirm, I confess I have stopped using it as it was becoming frustrating.
Ed
I have had a play with it tonight and recorded debug logs. Ran TvHeadend for about 30-40 minutes switching between different channels. There weren’t excessive issues quality wise and I didn’t get a lot continuity errors. In fact I’d say that it worked as well as I’ve ever seen. Signal quality for most channels was over 109dBm and the lowest it got was around 70-80dBm.
Debug logs here:
Debug Logs
However, as soon as I uploaded the logs and disabled debug logging the issues that I have constantly been experiencing started. Pixelations and green artifacts 
and also continuity errors. I really don’t know what’s happening
I’m trying recording logs again after rebooting and it is much better again. No continuity errors and the quality is really good. Maybe it’s got something to do with rebooting? Or maybe recording logs changes things behind the scenes… It’s almost like taking a pet the the vet with a problem and then you get there and the pet behaves normally and the vet can’t find anything 
Do you have any thoughts? I’ll upload these logs too, but I suspect it will be similar to what I have uploaded above.
EDIT:
Still working perfectly. Been going for the last 15-20 minutes. A total of 2 continuity errors during this time. Debug logging still enabled. Ironically the signal strength is quite low at 28.9dBm
EDIT #2:
Starting to see some issues now. Getting continuity errors, again ironically the signal strength has bumped up to over 100dBm. Still got debug logging enabled.
EDIT #3
Finished logging. Lots of artifacts and green pixelations. Seemed to happen 20-25 minutes after reboot with good signal strength >100dBm. Lots of continuity errors after the initial good period (and after the signal strength improved…)
Let me know if I can provide anything else.
France
Ok thanks. I’m looking in to this
Sam
2 Likes
Thanks Sam,
I was doing a bit of investigating and found this thread on the TvHeadend forum where one of the replies (by Ly Chen) describe experiencing a similar issue (with similar symptoms). They suggested that they were able to resolve it by the ‘Force old status’ option in the TvHeadend GUI.
I looked up in the TvHeadend documentation here regarding this config option and read the following definition:
Force old status : Always use the old ioctls to read the linuxdvb status (signal strength, SNR, error counters). Some drivers are not mature enough to provide the correct values using the new v5 linuxdvb API.
Do you think that this could be contributing to the problem and this config option could help?
Thanks,
Ed
I’m not sure. We’re using a Linux 4.9 DVB stack (backported on our 3.14 kernel).
You could give it a go. I am bumping to 4.21 shortly.
Interestingly the guy who reports that (Ly Chen) has both an MN88473 (Panasonic) and CXD2837ER (Sony) stick. Both chips are used in the OSMC DVB-T2 tuner; with the Sony being the latest iteration.
Sam
Would you recommend waiting to see if the bump to 4.21 resolves the issue? If I adjust the GUI config option will that potentially interfere with things after the update/bump? I guess I’m also of the opinion of not changing too many things at once when trying to solve a problem as it may not be clear what resolved it. But that reasoning may not apply here…
I would try changing the setting; you can always flip it back
FWIW I noticed something like this for the first time last night. After about 2 hours of watching, during which using pause, restart and FF, there were several frame-drops and glitches. The only thing I can contribute is I was not using a Sony stick - could have been either OSMC Panasonic or my August/MyGica stick which has worked fine for years.
I wondered whether it was associated with TVH getting to the end of its pause/rewind buffer (is it 120 minutes?)
Hm – can that be adjusted by changing timeshift settings?
Yes. Sure enough is set to 120, so going to try 10 minutes tonight and see what happens.
Now someone has pointed it out, I am noticing more glitches in the stream - stutters or sudden changes of scene (which may be intended, of course). Even watching on the same device TVH is running on.
Watching while monitoring the TVH gui, I don’t see any correlation between glitches and reported errors.
I found timeshift pretty unreliable in TVH (4.2 branch) once pausing or restarting live TV stream. I gave up using it in the end. If you find a magic fix I’d be very interested.
+1 for having (more) continuity errors with Vero 4k (relative to other devices)
I have the first gen Vero 4k and get a lot of continuity errors using either PCTV 292e or OSMC T2 stick. This is by removing aerial cable from TV and plugging into dongle. Picture/audio glitches were frequent so become unwatchable. Panasonic TV reports 10/10 signal quality and plays fine.
Compared it with using RPI3B and 292e stick (Raspbian OS) and I get much reduced errors and playback is fine. Couldn’t test OSMC T2 stick (Sony driver not included in Raspbian OS??).
Haven’t had time to investigate further. An uneducated guess it feels like a buffer overflow issue on the Vero 4k??
It’s working fine for me on the current stable OSMC release.
Sent you a patch in MM which may improve things.
Hi Sam,
After making the config change “Force old status” I have seen an immediate, significant improvement. Virtually no visual artefacts and quality is very good. Still get the occasional continuity error, but not as many as before and these don’t seem to result in glitches or interruptions to viewing.
Is this something that I will need to leave permanently enabled? If it’s driver related then is it something that will benefit everyone using the OSMC DVB-T2 USB dongle?
Thanks 
“Force old status” fixed the problem for me also
1 Like
Thank you for the report.
I need to investigate what this setting does first, to work out why this has resulted in an improvement. In the interim, I am glad there is a workaround.
1 Like
It also worked for me.
Thank you.
1 Like