<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 23, 2013 at 2:23 PM, Joseph Fry <span dir="ltr"><<a href="mailto:joe@thefrys.com" target="_blank">joe@thefrys.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">
<div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div>
<br></div><div>I've upgraded the firmware in all three devices to the March 28, 2013 version with no change. I'm currently running:</div><div><br></div><div><div>MythTV Version : v0.27-pre2-760-g575f7d9</div>
<div>MythTV Branch : master</div><div>Network Protocol : 77</div><div>Library API : 0.27.20130301-1</div><div>QT Version : 4.8.1</div><div>Options compiled in:</div><div> 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</div>
<div><br></div><div>Are others running from Git Master seeing these problems? Is it just with the HDHR tuners?</div><div><br></div><div>I do have an internal DVB tuner that I may re-install into MythTV this weekend to see if these issues disappear.</div>
<div><br></div><div>Regards,</div><div><br></div><div>-- Ken E</div></div></div>
<br>_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/listinfo/mythtv-users</a><br>
<br></blockquote></div><br></div><div class="gmail_extra">I had similar issues with my HDHR Prime in the past (for a few weeks) until I sorted it out. <br><br>Backend Details<br></div><div class="gmail_extra">Quad-core 8GB ram<br>
</div><div class="gmail_extra">MythTV 0.26+fixes<br></div><div class="gmail_extra">MythTV storage is NFS mounted from my NAS (5TB storage)<br></div><div class="gmail_extra">Backend set to keep 50GB free<br><br></div><div class="gmail_extra">
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. <br>
<br></div><div class="gmail_extra">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).</div>
</div></blockquote><div><br></div></div></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div></div></div></div></blockquote><div><br></div><div style>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:</div>
<div style><br></div><div style><div>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</div><div>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.</div>
<div>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</div><div>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</div>
<div>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</div><div>==============================================================================</div>
<div>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</div><div>==============================================================================</div>
<div>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</div><div><br></div><div style>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:</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>-- Ken E.</div></div></div></div></div>