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

[Ian Evans]

I like the idea of an SSD drive for the recording drive. What is the actual
lifetime of these suckers anyway, if you made sure the only thing being
sent to them was recordings?


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

>
>      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.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.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
>>>
>>
>> at this point you have:
>> a) the deletion of a recording
>> b) as automatically deleted recordings are allowed to re-record by
>>    default the scheduler runs, too
>> c) at least one ongoing recording
>> d) raid overhead
>>
>> where do your temporary database tables go?
>> If all four fight for the same physical spindle that might be a bit
>> much.
>>
>>
>>  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.
>>>
>>
>> If I remember the devices correctly you have 2+2+3 tuners. If you want
>> to record with them all at once + delete recordings + have your scratch
>> space sharing the spindle, then you really should consider to optimize
>> the raid and filesystem options.
>> The easiest way would be to switch to a simpler "one filesystem per
>> spindle" setup. Which "works for me" so I can't really help with
>> specific knobs to twist.
>>
>
> I agree completely... a JBOD setup with a spare drive to act as a backup
> for your most important stuff is far superior to a raid configuration for
> mythtv use.
>
> If that's not possible, then I would consider getting a SSD to act as your
> recording drive and create a user job (or cron) that runs after a few days
> that moves the recording to the raid array.  Getting an SSD for my
> recording drive is my next investment... it would allow my magnetic drives
> to be spun down most of the time to save on power/heat/noise.
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
>


-- 
Ian Evans
Executive Producer
Digital Hit Entertainment
http://www.digitalhit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130424/2fe04002/attachment.html>