[mythtv] Too much EIT activity causing defective recordings
John Pilkington
johnpilk222 at gmail.com
Wed Aug 1 17:31:28 UTC 2018
On 01/08/18 17:27, Stephen Worthington wrote:
> On Wed, 1 Aug 2018 13:52:06 +0100, you wrote:
>
>> On 01/08/18 12:49, Michael T. Dean wrote:
>>> On 07/31/2018 06:51 PM, John Pilkington wrote:
>>>> Hi; I'm running Master under SL7, recording UK SD DVB-T material via
>>>> one PCI single-tuner device and one twin-tuner usb dongle.
>>>>
>>>> Bus 001 Device 002: ID 1b80:e409 Afatech IT9137FN Dual DVB-T [KWorld
>>>> UB499-2T]
>>>>
>>>> Around 9 July my Project-X-based mythDVBcut logs started reporting
>>>> multiple AV sync corrections of up to a second in recordings from the
>>>> usb tuners. The change occurred after I rescanned my transports
>>>> following the Wimbledon special tennis coverage; I'm fairly sure I
>>>> made other 'minor' changes in the multirec and EIT configs too.
>>>>
>>>> Today I realised that the defects were often around 5 minutes apart,
>>>> and EIT scanning seemed a possible culprit. I have now unchecked the
>>>> boxes for usb open-on-demand and active-EIT-scan, and it looks as if
>>>> the recording defects have largely gone.
>>>>
>>>> In the past I probably haven't taken as much notice of the EIT
>>>> settings as I should have done, but the recent defects were much worse
>>>> than I had seen before and I think some of the recent code changes
>>>> must have been implicated.
>>>>
>>>> John P
>>>>
>>>> Below is a Project-X log resync section from an affected recording.
>>>> This should be just a few lines, with no resync required.
>>>>
>>>> {{{
>>>>
>>>> Input File 0: '/mnt/dat2/RSG3/1004_20180723195800.ts.old'
>>>> (1,149,983,780 bytes)
>>>> -> Filetype is TS (generic PES Container)
>>>>
>>>> <demux log snipped>
>>>>
>>>> ++> Mpg Audio: PID 0x044E / PesID 0xC0 / SubID 0x00 :
>>>> -> check CRC of AC-3 / MPEG-Audio L1,2
>>>> -> remove CRC in MPEG-Audio L1,2
>>>> -> add frames
>>>> -> Audio PTS: first packet 08:48:35.071, last packet 09:48:52.207
>>>> -> Video PTS: start 1.GOP 08:48:41.439, end last GOP 09:48:41.999
>>>> -> adjusting audio at video-timeline
>>>> -> src_audio: MPEG-1, Layer2, 48000Hz, stereo, 192kbps, noCRC @
>>>> 00:00:00.000
>>>> !> 5 frame(s) (120ms) inserted @ 00:02:28.608
>>>> !> missing syncword @ 6527233, @ 00:04:08.064
>>>> !> found syncword @ 6528384
>>>> !> 22 frame(s) (528ms) inserted @ 00:04:08.064
>>>> !> missing syncword @ 6528961, @ 00:04:08.592
>>>> !> found syncword @ 6529352
>>>> !> missing syncword @ 14213193, @ 00:09:27.840
>>>> !> found syncword @ 14213560
>>>> !> missing syncword @ 14214137, @ 00:09:27.864
>>>> !> found syncword @ 14214344
>>>> !> 4 frame(s) (96ms) inserted @ 00:09:27.864
>>>> !> missing syncword @ 29606793, @ 00:16:02.448
>>>> !> found syncword @ 29607000
>>>> !> 1 frame(s) (24ms) inserted @ 00:16:02.448
>>>> !> 19 frame(s) (456ms) inserted @ 00:21:21.144
>>>> !> missing syncword @ 45001753, @ 00:26:40.656
>>>> !> found syncword @ 45001960
>>>> !> 23 frame(s) (552ms) inserted @ 00:26:40.680
>>>> !> missing syncword @ 52701353, @ 00:27:54.144
>>>> !> found syncword @ 52701536
>>>> !> missing syncword @ 52702689, @ 00:27:54.192
>>>> !> found syncword @ 52703080
>>>> !> 20 frame(s) (480ms) inserted @ 00:27:54.192
>>>> !> missing syncword @ 60403625, @ 00:33:14.592
>>>> !> found syncword @ 60404248
>>>> !> 17 frame(s) (408ms) inserted @ 00:33:14.616
>>>> !> missing syncword @ 68103065, @ 00:38:34.344
>>>> !> found syncword @ 68103712
>>>> !> 17 frame(s) (408ms) inserted @ 00:38:34.344
>>>> !> missing syncword @ 68120993, @ 00:38:34.752
>>>> !> found syncword @ 68121960
>>>> !> 2 frame(s) (48ms) inserted @ 00:38:34.752
>>>> !> missing syncword @ 75797161, @ 00:39:47.760
>>>> !> found syncword @ 75797944
>>>> !> missing syncword @ 83496185, @ 00:45:07.344
>>>> !> found syncword @ 83496968
>>>> !> 21 frame(s) (504ms) inserted @ 00:45:07.416
>>>> !> missing syncword @ 83504457, @ 00:45:07.920
>>>> !> found syncword @ 83505080
>>>> !> missing syncword @ 83566137, @ 00:45:09.816
>>>> !> found syncword @ 83566920
>>>> !> 2 frame(s) (48ms) inserted @ 00:45:09.816
>>>> !> 2 frame(s) (48ms) inserted @ 00:45:09.960
>>>> audio frames: wri-pre-skip-ins-add 117813-0-0-155-0 @ 00:47:07.512
>>>> done...
>>>> ---> new File: '/home/john/MythTmp/tempcut19417.mp2'
>>>>
>>>> summary of created media files:
>>>> .Video (m2v): 70688 Frames 00:47:07.520
>>>> '/home/john/MythTmp/tempcut19417.m2v'
>>>> Audio 00 (mp2): 117813 Frames 00:47:07.512 0-0-155-0
>>>> '/home/john/MythTmp/tempcut19417.mp2'
>>>> => 775,195,585 bytes written...
>>>> -> we have 139 warnings/errors.
>>>>
>>>> }}}
>>>
>>> Could this be due to I/O activity? Have you done an optimize on your
>>> database, recently? If not, it may just be that MySQL is taking too
>>> much time with I/O when MythTV tries to write your listings data and it
>>> causes problems with MythTV's writing recording data. Do you have any
>>> warnings or errors in your MythTV backend logs?
>>>
>>> Mike
>>
>> Hi Mike: I run optimize every few days, so I don't think that's it.
>> But I usually arranged the schedule to record from the usb tuners only
>> when the PCI device was already recording, often from several channels,
>> so usually the system would be fairly busy. Database sql.gz backups are
>> now 125 MiB and autodelete of old recordings is getting invoked. 40 GB
>> free, 2% of 2.3 GiB reported: 3 partitions on 2 disks.
>>
>> I haven't seen any obvious signs of distress on the terminal window in
>> which I run the backend, and at present I would prefer to let things
>> roll for a bit rather than going back to do more investigations.
>
> You might try setting the -v record option on the mythbackend command
> line. That gives more logging of the recording process, and will give
> you messages like the following if you are getting any problems
> detected with a recording:
>
> root at mypvr:/etc/mythtv# grep -a "overall_score=\"0"
> /var/log/mythtv/mythbackend.log.1
> Jul 22 20:34:01 mypvr mythbackend: mythbackend[3543]: I TVRecEvent
> tv_rec.cpp:863 (FinishedRecording) TVRec[96]:
> FinishedRecording(10072_2018-07-22T07:29:00Z) good
> recq:<RecordingQuality overall_score="0.991667"
> key="10072_2018-07-22T07:29:00Z" countinuity_error_count="11"
> packet_count="7494980">#012 <Gap start="2018-07-22T07:46:02Z"
> end="2018-07-22T07:46:22Z" duration="19" />#012</RecordingQuality>
> Jul 23 20:39:00 mypvr mythbackend: mythbackend[3543]: I TVRecEvent
> tv_rec.cpp:863 (FinishedRecording) TVRec[94]:
> FinishedRecording(10007_2018-07-23T07:59:00Z) damaged
> recq:<RecordingQuality overall_score="0"
> key="10007_2018-07-23T07:59:00Z" countinuity_error_count="0"
> packet_count="108664">#012 <Gap start="2018-07-23T07:59:30Z"
> end="2018-07-23T08:35:00Z" duration="2129" />#012</RecordingQuality>
> Jul 25 23:06:01 mypvr mythbackend: mythbackend[3644]: I TVRecEvent
> tv_rec.cpp:863 (FinishedRecording) TVRec[92]:
> FinishedRecording(10070_2018-07-25T10:14:00Z) damaged
> recq:<RecordingQuality overall_score="0"
> key="10070_2018-07-25T10:14:00Z" countinuity_error_count="0"
> packet_count="194555">#012 <Gap start="2018-07-25T10:15:27Z"
> end="2018-07-25T11:05:00Z" duration="2972" />#012</RecordingQuality>
>
> What I see if I have my hard drives too busy is that I get short gaps
> in recordings, and get messages like the first one above, where there
> is a gap with a short duration, and also continuity errors. I use a
> rule of thumb that two recordings at once is all I want to have on one
> hard drive. Three at once is OK for a short period (during overlaps
> between recordings due to pre- and post roll), but if I have three
> recordings at once to one drive for the full length of a recording,
> there is a good chance I will get gaps. Four at once and there will
> almost always be gaps. Since you have three tuners with multirec on
> each of them, and only two hard drives to record to, then it is likely
> that the drives will be overloaded at some point. And if one of the
> recording drives is also the system and database drive, then it is
> much more likely to be too busy at some point. I put my system and
> database onto an SSD a couple of years ago and that made a big
> difference. But when I increased my tuners, I also had to add more
> hard drives. I now have 5 x DVB-T2 and 4 x DVB-S2 tuners in use, and
> have 7 recording drives. And I do at times have 14 recordings at
> once. But the gaps I get now are normally caused by rain fade on the
> satellite dish, not by overworked hard drives.
Hi Stephen: yes, thanks for that. I will try more comprehensive
logging options, and I'm still wondering just how much of an archive,
and in what form, I really have a use for.
Often some of my simultaneous recordings are radio, so the load isn't
quite as heavy as the number would suggest. But I did see a big rise in
the number and length of the audio insertions in early July, when the
only system change that seemed likely to be relevant (IIRC) was in those
usb-tuner settings. Since I unticked the boxes the post-processing logs
have been much better. I'll see if they stay that way - and if I still
get the EIT data.
Cheers,
John
More information about the mythtv-dev
mailing list