On Thu, Jun 30, 2005 at 06:55:09PM +1000, David Whyte wrote:
> > Simple solution: If the recorder runs out of space, the recorder exits.
> > Scheduler sees the recorder exited, attempts to restart it. The
> > recorder code checks the mount points for space, sees none free on
> > option one, trie
BP <[EMAIL PROTECTED]> writes:
> Joseph A. Caputo wrote:
>
>>
>> ...which is kind of why I put forth the idea of 'slicing' the recordings
>> as they're in-progress (see my post earlier in this thread). It allows
>> you to take full advantage of *all* of the space across multiple mount
>> poin
Unit3 <[EMAIL PROTECTED]> writes:
> On Fri, 2005-07-01 at 03:23 +1000, Hamish Moffatt wrote:
>> Bigger disks are even cheaper per gigabyte! And they have better
>> power and space density too.
>
> There's really a price/performance point for this, though, like anything
> else. Right now it seems l
Sent: Thursday, June 30, 2005 8:08 AM
To: mythtv-dev@mythtv.org
Subject: Re: [mythtv] Re: New idea for storing recordings to disks
On Wednesday 29 June 2005 18:13, Hamish Moffatt wrote:
> On Wed, Jun 29, 2005 at 09:50:29AM -0400, Joseph A. Caputo wrote:
> > Here's a pie-in-the-sky thoug
On Fri, 2005-07-01 at 03:23 +1000, Hamish Moffatt wrote:
> Bigger disks are even cheaper per gigabyte! And they have better
> power and space density too.
There's really a price/performance point for this, though, like anything
else. Right now it seems like 120GB SATA drives are the point, if you
On Wed, Jun 29, 2005 at 11:09:53PM -0400, Tony Lill wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
>
> > On Wed, Jun 29, 2005 at 09:50:29AM -0400, Joseph A. Caputo wrote:
> > I don't really understand why you wouldn't just put enough disk space in
> > the backend. Disk is cheap.
>
> That's a
On Wednesday 29 June 2005 18:13, Hamish Moffatt wrote:
> On Wed, Jun 29, 2005 at 09:50:29AM -0400, Joseph A. Caputo wrote:
> > Here's a pie-in-the-sky thought (and I realize this is probably
> > *way*
> > overkill, but it's an interesting idea nonetheless). What if Myth
> > had
> > a sort of
On Thursday 30 June 2005 1:24, BP wrote:
> Joseph A. Caputo wrote:
>
> >
> > ...which is kind of why I put forth the idea of 'slicing' the
> > recordings
> > as they're in-progress (see my post earlier in this thread). It
> > allows
> > you to take full advantage of *all* of the space acro
On Wednesday 29 June 2005 22:25, Tony Lill wrote:
> "Joseph A. Caputo" <[EMAIL PROTECTED]> writes:
>
> > Here's a pie-in-the-sky thought (and I realize this is probably
> > *way*
> > overkill, but it's an interesting idea nonetheless). What if Myth
> > had
> > a sort of virtual filesystem?
On Jun 30, 2005, at 3:55 AM, David Whyte wrote:
Simple solution: If the recorder runs out of space, the recorder
exits.
Scheduler sees the recorder exited, attempts to restart it. The
recorder code checks the mount points for space, sees none free on
option one, tries option two. Just like
> Simple solution: If the recorder runs out of space, the recorder exits.
> Scheduler sees the recorder exited, attempts to restart it. The
> recorder code checks the mount points for space, sees none free on
> option one, tries option two. Just like when you restart the backend in
> the midst
Joseph A. Caputo wrote:
>
> ...which is kind of why I put forth the idea of 'slicing' the recordings
> as they're in-progress (see my post earlier in this thread). It allows
> you to take full advantage of *all* of the space across multiple mount
> points/devices, even though any one of them
Nigel Pearson <[EMAIL PROTECTED]> writes:
>> I think that's a bad idea personally. UNIX design philosopy is to
>> split up systems into small components that connect together.
>
> And is why I would prefer not to add extra "multiple disk"
> code to the backend, and to have an external script
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Wed, Jun 29, 2005 at 09:50:29AM -0400, Joseph A. Caputo wrote:
> I don't really understand why you wouldn't just put enough disk space in
> the backend. Disk is cheap.
That's a very Microsoft answer ;->
Yes, disk is cheap, but you eventually run ou
Robert Tsai <[EMAIL PROTECTED]> writes:
> Is your point that Myth should just not bother recording at all if it
> thinks it might run out of space?
>
> Otherwise, if we discuss something along the lines of "Myth should
> record as scheduled, and simply gracefully abort recording if it runs
> out o
Nigel Pearson <[EMAIL PROTECTED]> writes:
> I am just wondering if all this is really necessary.
> It is not too hard to do this sort of thing via NFS/Samba
> and symlinks and a cron job or two (e.g. every 10 minutes
> if the recordings partition is more than X% full, move the
> oldest recor
"Joseph A. Caputo" <[EMAIL PROTECTED]> writes:
> Here's a pie-in-the-sky thought (and I realize this is probably *way*
> overkill, but it's an interesting idea nonetheless). What if Myth had
> a sort of virtual filesystem? That is, not a filesystem per se, but
> more of a content management l
I think that's a bad idea personally. UNIX design philosopy is to
split up systems into small components that connect together.
And is why I would prefer not to add extra "multiple disk"
code to the backend, and to have an external script or program
(mythculldisks? mythdecimatedisks :-)
On Wed, Jun 29, 2005 at 09:50:29AM -0400, Joseph A. Caputo wrote:
> Here's a pie-in-the-sky thought (and I realize this is probably *way*
> overkill, but it's an interesting idea nonetheless). What if Myth had
> a sort of virtual filesystem? That is, not a filesystem per se, but
> more of a co
On Wed, Jun 29, 2005 at 05:25:30PM +, [EMAIL PROTECTED] wrote:
> On Wed, 29 Jun 2005 10:58 , 'Joseph A. Caputo' <[EMAIL PROTECTED]> sent:
> >(1) if your auto-expire space threshold is not at least as large as
> >the max number of bytes a recording could consume in , you could
> >still run ou
Joseph A. Caputo wrote:
On Wednesday 29 June 2005 13:52, Brandon Beattie wrote:
> On Thu, Jun 30, 2005 at 02:35:51AM +1000, Hamish Moffatt wrote:
>
>> But will the users understand that their recording died because
>> one particular storage location filled up, even though the others
>> still h
Hamish Moffatt wrote:
On Wed, Jun 29, 2005 at 12:02:04PM -0400, Joseph A. Caputo wrote:
On Wednesday 29 June 2005 11:31, Robert Tsai wrote:
Is your point that Myth should just not bother recording at all if it
thinks it might run out of space?
Actually, my *original* original po
On Wednesday 29 June 2005 13:52, Brandon Beattie wrote:
> On Thu, Jun 30, 2005 at 02:35:51AM +1000, Hamish Moffatt wrote:
> >
> > But will the users understand that their recording died because one
> > particular storage location filled up, even though the others still
had
> > space available?
>
On Wednesday 29 June 2005 13:25, [EMAIL PROTECTED] wrote:
> On Wed, 29 Jun 2005 10:58 , 'Joseph A. Caputo' <[EMAIL PROTECTED]>
> sent:
> >(1) if your auto-expire space threshold is not at least as large as
> >the max number of bytes a recording could consume in , you could
> >still run out of
On Wednesday 29 June 2005 12:35, Hamish Moffatt wrote:
> On Wed, Jun 29, 2005 at 12:02:04PM -0400, Joseph A. Caputo wrote:
> > On Wednesday 29 June 2005 11:31, Robert Tsai wrote:
> > > Is your point that Myth should just not bother recording at all if
> > > it
> > > thinks it might run out of spa
On Thu, Jun 30, 2005 at 02:35:51AM +1000, Hamish Moffatt wrote:
>
> But will the users understand that their recording died because one
> particular storage location filled up, even though the others still had
> space available?
That's what logs are for.
--Brandon
___
On Wed, 29 Jun 2005 10:58 , 'Joseph A. Caputo' <[EMAIL PROTECTED]> sent:
>(1) if your auto-expire space threshold is not at least as large as
>the max number of bytes a recording could consume in , you could
>still run out of space (not too likely, but possible)
>(2) if auto-expire runs, but the
On Wed, Jun 29, 2005 at 12:02:04PM -0400, Joseph A. Caputo wrote:
> On Wednesday 29 June 2005 11:31, Robert Tsai wrote:
> > Is your point that Myth should just not bother recording at all if it
> > thinks it might run out of space?
>
> Actually, my *original* original point was simply that having
On Wednesday 29 June 2005 11:31, Robert Tsai wrote:
> Is your point that Myth should just not bother recording at all if it
> thinks it might run out of space?
Actually, my *original* original point was simply that having multiple
storage locations would *not* really make it much more difficult (
Is your point that Myth should just not bother recording at all if it
thinks it might run out of space?
Otherwise, if we discuss something along the lines of "Myth should
record as scheduled, and simply gracefully abort recording if it runs
out of space mid-recording", then read on. (Whether this
On Wednesday 29 June 2005 10:33, Robert Tsai wrote:
> On Wed, Jun 29, 2005 at 09:50:29AM -0400, Joseph A. Caputo wrote:
> > > The point is that for MOST recording methods, Myth can't known in
> > > advance whether a recording will fit in a given location. Only
> > > PVR-x50 recordings seem to have
On Wed, Jun 29, 2005 at 09:50:29AM -0400, Joseph A. Caputo wrote:
> > The point is that for MOST recording methods, Myth can't known in
> > advance whether a recording will fit in a given location. Only
> > PVR-x50 recordings seem to have predictable file size - DVB, ATSC,
> > RTJPEG etc do not.
>
On Wednesday 29 June 2005 3:26, Hamish Moffatt wrote:
> On Tue, Jun 28, 2005 at 10:17:02PM -0500, Kevin Kuphal wrote:
> > Hamish Moffatt wrote:
> > >How would it know whether a particular location has sufficient disk
> > >space for a scheduled recording?
> > >
> > >
> > How does it know now? If
On Tue, Jun 28, 2005 at 10:17:02PM -0500, Kevin Kuphal wrote:
> Hamish Moffatt wrote:
> >How would it know whether a particular location has sufficient disk
> >space for a scheduled recording?
> >
> >
> How does it know now? If Myth already has a mechanism to deal with
> full disk situations, i
Hamish Moffatt wrote:
On Tue, Jun 28, 2005 at 07:57:43PM -0500, Kevin Kuphal wrote:
Except the script would tend to get complicated in disk full situations
where Myth already has much of the functionality built in for that, it
only needs to understand that RecordFilePrefix can be something
On Tuesday 28 June 2005 09:24 pm, Hamish Moffatt wrote:
> On Tue, Jun 28, 2005 at 07:57:43PM -0500, Kevin Kuphal wrote:
> > Except the script would tend to get complicated in disk full situations
> > where Myth already has much of the functionality built in for that, it
> > only needs to understand
On Tue, Jun 28, 2005 at 07:57:43PM -0500, Kevin Kuphal wrote:
> Except the script would tend to get complicated in disk full situations
> where Myth already has much of the functionality built in for that, it
> only needs to understand that RecordFilePrefix can be something other
> than a single
> I am just wondering if all this is really necessary.
> It is not too hard to do this sort of thing via NFS/Samba
> and symlinks and a cron job or two (e.g. every 10 minutes
> if the recordings partition is more than X% full, move the
> oldest recordings to another partition/network-mount and
Nigel Pearson wrote:
I am just wondering if all this is really necessary.
It is not too hard to do this sort of thing via NFS/Samba
and symlinks and a cron job or two (e.g. every 10 minutes
if the recordings partition is more than X% full, move the
oldest recordings to another partition/net
I am just wondering if all this is really necessary.
It is not too hard to do this sort of thing via NFS/Samba
and symlinks and a cron job or two (e.g. every 10 minutes
if the recordings partition is more than X% full, move the
oldest recordings to another partition/network-mount and
repl
Kevin Kuphal <[EMAIL PROTECTED]> writes:
> Brandon Beattie wrote:
>
>>Recordings would work like this. Just like in various mythplugins you
>>would be able to specify various locations to store recordings to. This
>>wouldn't be hard of course.. if that directory doesn't have enough
>>space, use
Kevin Kuphal wrote:
Rudy Zijlstra wrote:
Tony Lill wrote:
Brandon Beattie <[EMAIL PROTECTED]> writes:
The reason I truely like this idea is it takes a lot of complexity out
of the picture. No longer do you need LVM, Raid, or even need to have
things setup for one directory to store reco
Rudy Zijlstra wrote:
Tony Lill wrote:
Brandon Beattie <[EMAIL PROTECTED]> writes:
The reason I truely like this idea is it takes a lot of complexity out
of the picture. No longer do you need LVM, Raid, or even need to have
things setup for one directory to store recordings.. Just tell it
Tony Lill wrote:
Brandon Beattie <[EMAIL PROTECTED]> writes:
The reason I truely like this idea is it takes a lot of complexity out
of the picture. No longer do you need LVM, Raid, or even need to have
things setup for one directory to store recordings.. Just tell it where
to use space fro
Brandon Beattie <[EMAIL PROTECTED]> writes:
> Well it happened, one of 5 disks in my LVM setup went bad and the claims
> of every LVM user I know didn't come true (That if you lose one disk,
> you can still get to the data of the rest).
Depends on how bad your disk went...
1 Buy a new disk at
45 matches
Mail list logo
