Opened 22 months ago

Closed 21 months ago

Last modified 9 months ago

#13066 closed Bug Report - General (Invalid)

Pixelation during Recordings

Reported by: W Agtail <wagtail@…> Owned by:
Priority: critical Milestone: unknown
Component: MythTV - General Version: 0.28.1
Severity: high Keywords: Pixelation
Cc: Ticket locked: no


Hi I have two computers running MythTV. Both are independent of each other. Both run Fedora 25 with a Hauppauge WinTV-quadHD TV Tuner (FreeView?). They have RAID1 SSD for the OS and DB, and RAID1 HDD for storage.

I built them during the end of last year and everything was working ok. I usually use MythTV to record programs (SD and HD) and then watch them later on. Up until recently, all recording have been good with no glitches in recording quality. I mainly use one computer for primary use and the other for testing.

A couple of months ago (not sure of exact date), I noticed recorded programs (mainly HD) contained pixelation (a couple of seconds every approx 30minutes or so). I think this was caused by a Fedora update, but not sure what package(s) caused this error. I believe this to be the case as I had not applied Fedora updates to my test computer and recordings worked fine on the test computer, until again I applied all the Fedora updates.

I am unable to undo the Fedora updates, but have tried a previous Linux kernel to no avail.

Is there a way of debugging MythTV / Linux to find out what is causing pixelation?

Would you have any ideas of what is causing this?

Many thanks, Abbie,

Attachments (2)

mythbackend.20170715204125.2200.log.bz2 (84.2 KB) - added by W Agtail <wagtail@…> 22 months ago.
mythbackend.20170719194057.2267.log (524.4 KB) - added by W Agtail <wagtail@…> 21 months ago.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 22 months ago by J.Pilk@…

Hi: This doesn't look like a problem in the myth code, and you might do better on the users mailing list or forum.

I run f25/Freeview too, fully updated, and haven't noticed anything like this.

Trees and birds don't know about fedora updates, but don't have a 30 minute schedule either. Is your signal good?

comment:2 Changed 22 months ago by J.Pilk@…

With the backend running, you might try 'mythbackend --setverbose record' - or other options from 'mythbackend -v help'

comment:3 Changed 22 months ago by Peter Bennett

What playback profile are you using? If you run a test using "Normal" or "Slim" does the problem go away?

Maybe it is a similar issue to this ->

comment:4 Changed 22 months ago by W Agtail <wagtail@…>

Hi, with reference to your comments:


I would be interested in what TV Tuner you use?

My signal is good. I'm not sure what utility to use as femon doesn't support the Hauppauge WinTV-quadHD TV Tuner (UK freeview version). Signal is 100% when connect to a TV

I will try "mythbackend --setverbose record" over the weekend.


The playback profile is irrelevant in my case as I stream via DNLA.

Thanks, abbie

comment:5 Changed 22 months ago by J.Pilk@…

The tuners that I use most (SD) are old single PCI cards using saa7134, with USB for additional muxes. With those package reordering is much more likely but usually harmless. IIRC on the f25 box the card is a Hauppauge 1100-something. HD, used less often, a PCTV-290e USB.

Is your pixellation repeatable on each playing? Can you use VGA/HDMI output for tests, and does it still happen?

comment:6 Changed 22 months ago by W Agtail <wagtail@…>

Hi I tried downgrading MythTV to 0.28-8 (removed 0.28.1-3, dropped DB, installed 0.28-8, mythsetup) and still have the same issue. I recorded a HD program on Jul/16/2017 22:00 - 00:45 (2 hrs 45mins). The first ~40mins was ok. Then had ~1-2 seconds of pixelation, every approx 4mins - 15mins. I observed pixelation at the following hrsmins:seconds of playback: 39:25 43:59 53:00 106:32 120:08 129:06 133:38 138:07 142:39 147:11 156:13 205:05 214:13 232:15 236:48

Attached is mythbackend.20170715204125.2200.log with "mythbackend --setverbose record" set at 22:00 (-45 seconds).

Changed 22 months ago by W Agtail <wagtail@…>


comment:7 Changed 22 months ago by J.Pilk@…

I've never actually tried -v record for a longish time; but perhaps

"grep "discontinuity detected" mythbackend.20170715204125.2200.log" looks worth investigating?

comment:8 Changed 22 months ago by J.Pilk@…

Just to see how it works, I'm running 'mythbackend --setverbose none,record' while making overlapping recordings of consecutive radio programmes on one dvb channel (703). That's recorders 1 and 2. I did see reports of a few 'discontinuities' shortly after the first recording stopped, but hear no defects on playback.

The other tuners, as recorders 8 and 13, show up and confuse things by their EIT activities. If you pursue this further it could be worth disabling EIT collection, as well as specifying 'none,' during the test. Of course, that might stop the observed pixelation too.

comment:9 Changed 22 months ago by W Agtail <wagtail@…>

I don't normally see any pixelation with SD programs. Would you be able to record a HD program of 1.5hrs or more? I will record HD with "--setverbose none,record" over the weekend and post the results. Thanks, abbie

comment:10 Changed 21 months ago by W Agtail <wagtail@…>

A 2hr 17min SD recording contains pixelation at 2hrs 10mins I have attached mythbackend.20170719194057.2267.log with options "--setverbose none,record" Thanks

Changed 21 months ago by W Agtail <wagtail@…>


comment:11 Changed 21 months ago by J.Pilk@…

Well, it shows 'discontinuities' at around 00:55 in DTVRec[1], and nowhere else, so there could well be a link. At the end it says it's a good recording. But my USB recorders often have packets out of order. They get reported and 'corrected' by Project-X, which I use in mythDVBcut, but don't usually show in the raw recordings. So the origin of the pixelation still isn't clear, at least to me. And I won't have access to my f25 box during the next week or so, so can't test that aspect. Sorry.

Your upnp playback might not be above suspicion. mythfrontend -v none,upnp:debug shows quite a lot of activity behind the scenes, and who knows what the display-box is doing?

comment:12 Changed 21 months ago by W Agtail <wagtail@…>

Hi. I am convinced it is the recording side of things. I have also confirmed playback with ffplay. Thanks,

comment:13 Changed 21 months ago by Peter Bennett

If so are you sure it is not some over the air interference causing this? Maybe there is something in your neighborhood causing interference. These things can come and go, which could explain why it was OK for a while.

comment:14 Changed 21 months ago by J.Pilk@…

The discontinuities are found in A/V PIDs 0x5dd, 0x5de, 0x5df

SetPAT(8385 on 0x5dc) is valid and the PMT is set to 8385

Stream info from mythffmpeg -i might help.

comment:15 Changed 21 months ago by J.Pilk@…

But they are probably just mpeg2video and two audio streams.

Peter's suggestion of local interference seems a strong possibility.

comment:16 Changed 21 months ago by W Agtail <wagtail@…>

Hi. I am not sure how to measure interference. I never see any interference on a normal TV. All recording were fine up until recently.

I have rebuilt my test computer with little updates. The test computer generates the following types of messages, the recording is good with no pixelation:

mythbackend.20170721215256.2124.log:2017-07-22 01:00:43.322865 E [2124/11861] DVBRead mpeg/pespacket.cpp:79 (AddTSPacket) - AddTSPacket: Out of sync!!! Need to wait for next payloadStart PID: 0x12, continuity counter: 5 (expected 15).

What does this message mean?

My main computer (with all updates) generates the additional following messages with pixelation: mythbackend.20170722204056.2261.log:2017-07-22 22:52:16.249911 W [2261/6116] DVBRead recorders/dtvrecorder.cpp:1477 (ProcessTSPacket) - DTVRec[1]: PID 0x15f discontinuity detected ((11+1)%16!=13) 5.62473e-5%

mythbackend.20170722204056.2261.log:2017-07-22 23:15:11.232735 W [2261/6116] DVBRead recorders/dtvrecorder.cpp:1585 (ProcessAVTSPacket) - DTVRec[1]: A/V PID 0x12d discontinuity detected ((13+1)%16!=12) 0.00%

What do each of these messages mean?

Can you expand on mythffmpeg -i? I am not sure what to do with this>

Kind regards

comment:17 Changed 21 months ago by J.Pilk@…

I'm away from home with access to a poorer signal, and see much more of stuff like this:

2017-07-25 09:44:05.029852 W  DTVRec[2]: A/V PID 0x65 discontinuity detected ((4+1)%16!=6)  0.00%
2017-07-25 09:45:06.580989 W  DTVRec[2]: A/V PID 0x65 discontinuity detected ((9+1)%16!=11)  0.00%
2017-07-25 09:47:09.465568 W  DTVRec[2]: A/V PID 0x65 discontinuity detected ((4+1)%16!=6)  0.00%
2017-07-25 09:47:10.490200 W  DTVRec[2]: A/V PID 0x66 discontinuity detected ((5+1)%16!=7)  0.00%
2017-07-25 09:48:16.433485 W  DTVRec[3]: PID 0x1c21 discontinuity detected ((10+1)%16!=12) 0.000463025%
2017-07-25 09:48:16.434360 W  DTVRec[2]: PID 0x1c21 discontinuity detected ((10+1)%16!=12) 0.000380787%
2017-07-25 09:48:16.435255 W  DTVRec[1]: PID 0x1c21 discontinuity detected ((10+1)%16!=12) 0.00058061%
2017-07-25 09:48:36.374722 W  DTVRec[2]: A/V PID 0x65 discontinuity detected ((2+1)%16!=4)  0.00%
2017-07-25 09:49:26.065406 W  DTVRec[2]: A/V PID 0x65 discontinuity detected ((5+1)%16!=7)  0.00%
2017-07-25 09:49:34.433761 W  DTVRec[2]: A/V PID 0x65 discontinuity detected ((3+1)%16!=5)  0.00%
2017-07-25 09:49:39.980888 W  DTVRec[2]: A/V PID 0x65 discontinuity detected ((9+1)%16!=11)  0.00%
2017-07-25 09:51:14.058180 W  DTVRec[3]: A/V PID 0x516 discontinuity detected ((8+1)%16!=10)  0.00%
2017-07-25 09:53:33.466888 W  DTVRec[2]: A/V PID 0x65 discontinuity detected ((2+1)%16!=4)  0.00%

which I think shows (mostly) single packets being dropped and on video does cause mild pixelation - random rectangles appearing briefly. Partly I suspect the usb device and its driver, but the best cure is a good aerial. And maybe moving away from taxis, pizza shops, police stations.

As I said earlier, this ought to be on the user list, where you might get wider range of expertise.

comment:18 Changed 21 months ago by J.Pilk@…

I have just disconnected my twin-tuner 704J usb device, which is several years old, and am using the PCTV290e again. Reception of SD is flawless - but only 1 mux at any one time. Haven't tried the HD here recently.

Your easiest course of action might be to add a simple low-noise preamplifier as the first item in the aerial downlead. It might help - but much depends on the specifics.

says the driver is in the 4.8 kernel, so the fedora updates ought to not to cause problems.

comment:19 Changed 21 months ago by lucylangthorne55@…

Since you have two machines with identical cards, could you record the same programme on both? Are they both fed by the same aerial? If you get the same pixelation from the same aerial then it's likely interference.

Most new preamplifiers say they filter 4G, not sure if that's an issue where you are but maybe a new 4G mast started a few months ago?

comment:20 Changed 21 months ago by W Agtail <wagtail@…>

Hi The two machines are fed from the same aerial. I just recorded a SD program this morning. One machine (with all the fedora updates) had pixelation. One machine (with very little fedora updates) had no pixelation. I am still unsure if interference is the issue. I am still unsure if a fedora update(s) is the issue. I will update packages a few at a time to see if I can at least rule this out. Thanks

comment:21 Changed 21 months ago by J.Pilk@…

I suppose it's possible that a cron job could be responsible and be linked to your updates, but what you have told us sounds more like interference from something that operates briefly and confuses or even swamps your tuner. The effects wouldn't necessarily be identical on every tuner - and it appears that you are asking your aerial to drive eight. Do you see the problem on all muxes?

Remote diagnosis is going to be mainly guesswork. Have you googled 'freeview interference' ?

Good luck!

comment:22 Changed 21 months ago by Peter Bennett

Resolution: Invalid
Status: newclosed

Looks like this is not a MythTV bug - closing

comment:23 Changed 9 months ago by jpilk

This report of short bursts of 'interference' on one box but not on another has some similarities with my recent experience.

Try disabling 'active' EIT scanning - if the problem still exists :-)

Note: See TracTickets for help on using tickets.