[mythtv-users] Recent "pixelation" or "glitches" in recordings (HDHR related?)

Tue Apr 23 19:44:56 UTC 2013

On Tue, Apr 23, 2013 at 2:23 PM, Joseph Fry <joe at thefrys.com> wrote:

>
> I am not sure if the problem I'm seeing is related to the thread started
>>> by Gary Buhrmaster (HDHR glitches and MythTV) so I apologize in advance of
>>> possibly splitting a previous thread.  I have two three HDHR devices (an
>>> older, white case dual OTA tuner, a newer black case OTA tuner, and the
>>> HDHR Prime with cable card).  Within the past four weeks I've been seeing
>>> glitches (some call it pixelation) in the playback of recordings.  I first
>>> attributed it to the possibility that my antenna got rotated by some of the
>>> high winds we've had (I've not checked my signal quality yet).  However,
>>> I've since noticed the same glitches occurring on my HDHR Prime on several
>>> different channels.  Since this is coming over cable, I'd not expect this
>>> type of signal (rarely had it before), so I now suspect something more
>>> sinister within either changes to MythTV or problems with the firmware in
>>> the HDHRs.
>>>
>>> I've upgraded the firmware in all three devices to the March 28, 2013
>>> version with no change.  I'm currently running:
>>>
>>> MythTV Version : v0.27-pre2-760-g575f7d9
>>> MythTV Branch : master
>>> Network Protocol : 77
>>> Library API : 0.27.20130301-1
>>> QT Version : 4.8.1
>>> Options compiled in:
>>>  linux profile use_hidesyms using_alsa using_oss using_pulse
>>> using_pulseoutput using_backend using_bindings_perl using_bindings_python
>>> using_bindings_php using_dvb using_firewire using_frontend using_hdhomerun
>>> using_ceton using_hdpvr using_ivtv using_joystick_menu using_libcec
>>> using_libcrypto using_libdns_sd using_libfftw3 using_libxml2 using_libudf
>>> using_lirc using_mheg using_opengl using_opengl_video using_qtwebkit
>>> using_qtscript using_qtdbus using_v4l2 using_x11 using_xrandr using_xv
>>> using_bindings_perl using_bindings_python using_bindings_php
>>> using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads
>>> using_mheg using_libxml2 using_libudf
>>>
>>> Are others running from Git Master seeing these problems?  Is it just
>>> with the HDHR tuners?
>>>
>>> I do have an internal DVB tuner that I may re-install into MythTV this
>>> weekend to see if these issues disappear.
>>>
>>> Regards,
>>>
>>> -- Ken E
>>>
>>> _______________________________________________
>>> mythtv-users mailing list
>>> mythtv-users at mythtv.org
>>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>>
>>>
>> I had similar issues with my HDHR Prime in the past (for a few weeks)
>> until I sorted it out.
>>
>> Backend Details
>> Quad-core 8GB ram
>> MythTV 0.26+fixes
>> MythTV storage is NFS mounted from my NAS (5TB storage)
>> Backend set to keep 50GB free
>>
>> I ran my backend disk space almost completely full (just the 50GB
>> buffer), and just allowed MythTV to delete watched content when it needed
>> space. After doing this for awhile I started to notice the pixelation issue
>> on my HDHR Prime. Nothing had changed, so I decided to manually delete all
>> my watched recordings (I don't recall why I decided to try that), and freed
>> up 1+TB on my storage. Since I did that, I've not had the pixelation issue
>> again.
>>
>> I'm not sure if Comcast was just having some issues (the recordings that
>> had pixelation spanned recording dates of a few weeks, so doubtful), or if
>> having an almost full drive was causing issues (50GB isn't that much free
>> space when recording 3 HD broadcasts).
>>
>
> There is no reason that space alone would cause pixelation... however
> running at the limits of your disk space may tigger other issues,
> especially fragmentation.  Additionally, if your disk is mostly empty, it's
> unlikely that two simultaneous recordings would be located too far from
> each other on the disk; whereas when the disk is nearly full you may be
> recording to opposite extremes on disk which could trigger a lot of long
> seek times.
>
> Truely, disk space restraints causing pixelation seems really unlikely,.
> even if heavily fragmented and with lots of seeking, unless you have other
> tasks that are generating a lot of disk IO on top of everything.
>
>
I can add a little more information since you are both talking about disk
access.  Looking at my backend log files I do see the following sprinkled
throughout:

2013-04-22 17:32:37.105528 N [29597/29712] Expire autoexpire.cpp:264
(CalcParams) - AutoExpire: CalcParams(): Max required Free Space: 7.0 GB
w/freq: 14 min
2013-04-22 17:32:37.109078 N [29597/29712] Expire autoexpire.cpp:736
(ExpireEpisodesOverMax) - Deleting 1081 at 2013-04-21T22:00:00Z => WQAD
News 8 at 5PM.  Too many episodes, we only want to keep 1.
2013-04-22 17:32:37.124127 I [29597/29710] Scheduler scheduler.cpp:2138
(HandleReschedule) - Reschedule requested for CHECK -3 1534 735344
ForgetHistory | WQAD News 8 at 5PM |  |  | SH014776300000
2013-04-22 17:32:37.124268 E [29597/29597] CoreContext mainserver.cpp:1727
(SendResponse) - SendResponse: Unable to write to client socket, as it's no
longer there
2013-04-22 17:32:37.125000 I [29597/29710] Scheduler scheduler.cpp:2138
(HandleReschedule) - Reschedule requested for CHECK 0 1534 735344
DoHandleDelete1 | WQAD News 8 at 5PM |  |  | SH014776300000
==============================================================================
2013-04-22 17:32:39.702814 W [29597/22833] TFWWrite
ThreadedFileWriter.cpp:503 (DiskLoop) -
TFW(/mythtv/data/1061_20130422223000.mpg:99): write(46436) cnt 42 total
2785032 -- took a long time, 1391 ms
==============================================================================
2013-04-22 17:32:41.981064 I [29597/29710] Scheduler scheduler.cpp:2251
(HandleReschedule) - Scheduled 1932 items in 4.7 = 0.00 match + 0.02 check
+ 4.68 place

where I have highlighted what may possibly be causing the problem.  Many
times this message comes out just after an auto-expire of a program (delete
operation?) but not always.  Am I bumping up against the limits of my disk
system?  I admit, I do not have a system designed with high speed in mind
since I didn't think it was necessary:

I have six (6) three TB drives configured in a RAID6 partition of
approximately 9TB.  On that RAID6 partition I have an LVM volume using XFS
file system that contains all of my mythTV storage groups + music + photos
+ videos.  Also on these same six drives I have RAID1 partitions that have
the OS and boot file systems (EXT4).  I have a separate SATA drive that
contains my mythTV database.  The three TB drives are slow (WD Green drives
- I think these are 5200 RPM).  Five of the drives are located on separate
SATA ports on the motherboard and the sixth drive is in a RocketRaid
external SATA enclosure.

-- Ken E.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130423/3ba9252d/attachment.html>