Opened 4 years ago

Closed 4 years ago

Last modified 3 years 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@…> 4 years ago.
mythbackend.20170719194057.2267.log (524.4 KB) - added by W Agtail <wagtail@…> 4 years ago.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 4 years 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 4 years ago by J.Pilk@…

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

comment:3 Changed 4 years 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 4 years 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 4 years 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 4 years 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 4 years ago by W Agtail <wagtail@…>


comment:7 Changed 4 years 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 4 years 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 4 years 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 4 years 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 4 years ago by W Agtail <wagtail@…>


comment:11 Changed 4 years 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 4 years 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 4 years 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 4 years 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 4 years 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 4 years 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 4 years 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 4 years 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 4 years 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 4 years 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 4 years 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 4 years ago by Peter Bennett

Resolution: Invalid
Status: newclosed

Looks like this is not a MythTV bug - closing

comment:23 Changed 3 years 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.