[mythtv-users] Myth records until drive is full (auto-expire is off)

[homer]

Hello,
	The biggest problem I have is when I am just watching tv (through the
composite input as I have to do with Foxtel/Austar) it stores it in 1
huge file.  Especially if Myth is left on "Watch TV" and I go out for a
couple of hours/days.

	What I would like to see is if there is no program information about
what is being currently viewed (EIT) AND it is not scheduled for
recording, that MythTV will break up the video into (for example) 30
minute blocks and delete anything older than X minutes old.

	This should help overcome the running out of room problem and also
prevent 6-7Gb files residing on 1 partition.

	Thoughts anyone?


On Sat, 2008-11-29 at 23:35 -0500, Michael T. Dean wrote:
> On 11/29/2008 08:23 PM, Nick Morrott wrote:
> > Does anyone else feel this is the wrong way to do things? As an
> > _intelligent_ DVR, I think that if auto-expire is disabled for all
> > rules/recordings and the space available for recordings fills up or
> > hits its configured minimum space limit:
> >
> > i) the scheduler gets disabled
> >
> > ii) the upcoming recordings screen (and backend log) shows a warning
> > stating this, and that no further recordings can be made until some
> > space is freed up (and recommend using auto-expire to avoid this
> > happening in the future). Playing back an existing warning could also
> > display a message to this effect via mythtvosd.
> >
> > iii) future LiveTV sessions exits before starting playback with a
> > similar warning message
> >
> > iv) mythbackend catches the "out of disk space" error/exception,
> > aborts any in-progress recordings, and syslog escapes mostly unharmed.
> >
> > As I stated in an earlier thread, I have no experience with a
> > commercial DVR, but when faced with a similar disk full scenario, do
> > they:
> >
> > i) block any future recordings and display warning
> > ii) automatically start deleting old recordings to make room for new ones
> >
> > Many users treat their MythTV systems as appliances. Having them
> > potentially break* due to "unfriendly" behaviour is something that I'd
> > argue should be removed as far as possible. I'd rather miss some new
> > recordings and be told why, than have to manually intervene and rescue
> > a system that has run out of diskspace.
> 
> Sure, patches to http://svn.mythtv.org/ , please (which is my slightly 
> more (or less?) polite way of saying, "I /never/ have this problem so I 
> will /never/ write the code to handle that problem, but I won't complain 
> if someone who actually cares does write it").
> 
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users