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

[Joseph Fry]

>  >> > 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:
>>> >> >       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.
>>> >>
>>> >> I believe you both mean "system drive".  A SSD as a recording drive
>>> would
>>> >> truly be a waste.  Expensive/GB, meaning those HDHR shows will cost a
>>> LOT
>>> >> more to store.
>>> >>
>>> >
>>> >No, I meant recording drive.  But I clearly meant recording and not
>>> >storage.
>>> >
>>> >I would estimate that about 80% of my recordings (to include live tv)
>>> are
>>> >watched and deleted within 1 week.  Using a 1 week delayed userjob or
>>> >cronjob that moves files older than 1 week to magnetic storage would
>>> allow
>>> >me to use a smallish SSD as temporary storage of recordings/livetv.  A
>>> >single SSD should be able to sustain enough throughput for all of my
>>> >tuners, commflagging, and watching several shows.
>>> >
>>> >
>>> >>
>>> >> If you're looking for opportunities to spin-down your magnetic drives,
>>> >> you'll use THOSE as recording drives.
>>> >
>>> >
>>> >Using a SSD as described above would allow the drives to remain spun
>>> down
>>> >except when transferring recordings from the SSD, or watching one that
>>> was
>>> >already transferred.  Because the transfers would occur faster than
>>> >recording directly and because only a fraction of all recordings would
>>> >actually make it to the magnetic drives, they would remain spun down far
>>> >more.
>>>
>>> Unfortunately, the storage drives in this scheme would be started more
>>> often than you would like.  When mythfrontend displays a list of
>>> programs, it makes a check for the presence of the recording's file
>>> and displays an X icon for those it can not find.  That checking
>>> process would start all the storage drives every time it happened as
>>> all partitions in all storage groups are scanned to find files.  There
>>> is no way the current operation of MythTV would allow just the drive
>>> needed to play a specific recording to be started, as the actual
>>> locations for the files are not stored in the database.
>>
>>
>> Interesting, I had never heard that before.  Sounds like it would be
>> worth lobbying to have changed, perhaps have it confirm they are available
>> on some sort of schedule rather then every time the user opens the watch
>> recordings screen.
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>
>>
>
> Queue bug report "Mythfrontend said a recording was there, but when I went
> to play it I received the error 'recording not available'"
>
>
I think it would be reasonable for it to do the normal scan upon opening
watch recordings, but only if the last scan was more than X hours ago OR if
the last scan revealed missing files.

I don't treat the red X icon as authoritative anyway...  anything can
happen between the time that the scan runs and I try to play a video; hell
I could leave the watch recordings screen open and go and take my storage
drives off line and it won't show the red x but I will get an error when I
try to play the file.

The red x is simply an indicator that on the last check the file was
missing... all I'm saying is that we shouldn't do so many checks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130424/0d7f62e9/attachment.html>