Mailing List Archive

Mythtv .19 live watching
Hello,

I have an issue now since that the ringbuffer has gone:

I left the system in live-tv mode last night. It recorded everything until
the disk is full (the livetv recording options is very high quality that
means it eats a lot of diskspace). It also expired any other recording that
was flagged as autoexpire.

Is this the expected behaviour?

-Yves

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
Expected behaviour is to fill your disk up and then auto expire the live tv
recordings first.

Ash.

On 7/12/06, Yves De Muyter <yves@connected.be> wrote:
>
> Hello,
>
> I have an issue now since that the ringbuffer has gone:
>
> I left the system in live-tv mode last night. It recorded everything until
> the disk is full (the livetv recording options is very high quality that
> means it eats a lot of diskspace). It also expired any other recording
> that
> was flagged as autoexpire.
>
> Is this the expected behaviour?
>
> -Yves
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
Re: Mythtv .19 live watching [ In reply to ]
On 07/12/2006 03:33 AM, Ashley Bostock wrote:
> On 7/12/06, Yves De Muyter <yves@connected.be> wrote:
>> I have an issue now since that the ringbuffer has gone:
>>
>> I left the system in live-tv mode last night. It recorded everything
>> until the disk is full (the livetv recording options is very high
>> quality that means it eats a lot of diskspace). It also expired any
>> other recording that was flagged as autoexpire.
>>
>> Is this the expected behaviour?
> Expected behaviour is to fill your disk up and then auto expire the
> live tv recordings first.

Did you have valid guide data for the channel on which you left LiveTV
playing? Was it a channel that has multi-hour blocks per program (i.e.
a radio channel/digital music channel or something)?

http://www.gossamer-threads.com/lists/mythtv/users/188292#188292
http://www.gossamer-threads.com/lists/mythtv/users/188296#188296

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
Looking at the program guide, there was 1 big block (nightly loop).

From the tip in the archives I'll add a split of 60 minutes, as
a safety measure.

-Yves

On Wed, Jul 12, 2006 at 11:10:42AM -0400, Michael T. Dean wrote:
> On 07/12/2006 03:33 AM, Ashley Bostock wrote:
> > On 7/12/06, Yves De Muyter <yves@connected.be> wrote:
> >> I have an issue now since that the ringbuffer has gone:
> >>
> >> I left the system in live-tv mode last night. It recorded everything
> >> until the disk is full (the livetv recording options is very high
> >> quality that means it eats a lot of diskspace). It also expired any
> >> other recording that was flagged as autoexpire.
> >>
> >> Is this the expected behaviour?
> > Expected behaviour is to fill your disk up and then auto expire the
> > live tv recordings first.
>
> Did you have valid guide data for the channel on which you left LiveTV
> playing? Was it a channel that has multi-hour blocks per program (i.e.
> a radio channel/digital music channel or something)?
>
> http://www.gossamer-threads.com/lists/mythtv/users/188292#188292
> http://www.gossamer-threads.com/lists/mythtv/users/188296#188296
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On 07/12/2006 11:25 AM, Yves De Muyter wrote:

>On Wed, Jul 12, 2006 at 11:10:42AM -0400, Michael T. Dean wrote:
>
>
>>On 07/12/2006 03:33 AM, Ashley Bostock wrote:
>>
>>
>>>On 7/12/06, Yves De Muyter <yves@connected.be> wrote:
>>>
>>>
>>>>I have an issue now since that the ringbuffer has gone:
>>>>
>>>>I left the system in live-tv mode last night. It recorded everything
>>>>until the disk is full (the livetv recording options is very high
>>>>quality that means it eats a lot of diskspace). It also expired any
>>>>other recording that was flagged as autoexpire.
>>>>
>>>>Is this the expected behaviour?
>>>>
>>>>
>>>Expected behaviour is to fill your disk up and then auto expire the
>>>live tv recordings first.
>>>
>>>
>>Did you have valid guide data for the channel on which you left LiveTV
>>playing? Was it a channel that has multi-hour blocks per program (i.e.
>>a radio channel/digital music channel or something)?
>>
>>http://www.gossamer-threads.com/lists/mythtv/users/188292#188292
>>http://www.gossamer-threads.com/lists/mythtv/users/188296#188296
>>
>>
>Looking at the program guide, there was 1 big block (nightly loop).
>
> From the tip in the archives I'll add a split of 60 minutes, as
>a safety measure.
>

That "tip" was a proposed solution that was never implemented, and,
IMHO, was an unnecessary workaround (which is why I linked you to the
one that explained why the splits wouldn't work instead of the one that
suggested the splits).

The right solution, though, is to stop LiveTV when you're not watching
it... Another solution is to get more hard drives. ;)

If, however, you plan to leave LiveTV playing overnight, often, you
could add splits, but you'll have to do it by editing the XMLTV data
(Myth doesn't allow you to do this).

Also, if the problem is that you're falling asleep during the
commercials in LiveTV ;), check out the "Sleep" menu--hit MENU ('M') in
LiveTV and scroll to "Sleep". There you can specify that Myth should
turn off playback in 30, 60, 90, or 120 minutes. (You can also toggle
the sleep timer with the TOGGLESLEEP key (by default 'F8'), which cycles
through 30, 60, 90, 120 minutes then off.)

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
Michael T. Dean wrote:
> The right solution, though, is to stop LiveTV when you're not watching
> it... Another solution is to get more hard drives. ;)
>
> ... Also, if the problem is that you're falling asleep during the
> commercials in LiveTV ;), check out the "Sleep" menu--hit MENU ('M') in
> LiveTV and scroll to "Sleep". There you can specify that Myth should
> turn off playback in 30, 60, 90, or 120 minutes. (You can also toggle
> the sleep timer with the TOGGLESLEEP key (by default 'F8'), which cycles
> through 30, 60, 90, 120 minutes then off.)
I'll gently suggest that such a solution is low in WAF (Wife Acceptance
Factor) and KCF (Kid Competency Factor). I remember to stop LiveTV.
Others don't, and won't.

glen
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On 07/12/06 12:40, glen martin wrote:

>Michael T. Dean wrote:
>
>
>>The right solution, though, is to stop LiveTV when you're not watching
>>it... Another solution is to get more hard drives. ;)
>>
>>... Also, if the problem is that you're falling asleep during the
>>commercials in LiveTV ;), check out the "Sleep" menu--hit MENU ('M') in
>>LiveTV and scroll to "Sleep". There you can specify that Myth should
>>turn off playback in 30, 60, 90, or 120 minutes. (You can also toggle
>>the sleep timer with the TOGGLESLEEP key (by default 'F8'), which cycles
>>through 30, 60, 90, 120 minutes then off.)
>>
>>
>I'll gently suggest that such a solution is low in WAF (Wife Acceptance
>Factor) and KCF (Kid Competency Factor). I remember to stop LiveTV.
>Others don't, and won't.
>

That may rule out the "right solution," but still leaves the "another
solution." It also leaves the "EXECTV executing xawtv" solution that I
mentioned in the linked post (
http://www.gossamer-threads.com/lists/mythtv/users/188296#188296 )--i.e.
if you don't want to record it, don't record it.

Let's say you've set LiveTV to the ridiculously-high average bitrate of
6000kbps (the default is 4500 average, 6000 max). Let's say some
channel shows 24-hour programs and some--heh hum--person leaves MythTV
playing LiveTV for the entire 24-hour program. That program will be
about 60GiB. (Even at 9000kbps, the show will be about 90GiB after 24
hours.)

Now, in the real world, how often will your MythTV box sit there playing
LiveTV for 24 hours straight? Won't someone try to use the Myth box
within that time frame? If so, once they exit LiveTV, the large LiveTV
program is eligible to be autoexpired immediately.

True, for HDTV, a 24-hour program would be much larger, but has /anyone/
ever seen a 24-hour program listed in a HDTV channel (which doesn't
include digital radio channels because they won't use much bitrate for
the video since there's not much video to them). I could see, maybe, 8
hours for a sporting event (and, assuming an average of 7GiB/hr, that's
about 56 GiB).

So, making sure the family doesn't do something stu^H^H^Hlike tell Myth
to record an entire 24-hour program when short on space (if you don't
want to lose shows marked as eligible to autoexpire) doesn't seem too
much to ask. Or, keeping a reserve of space for when someone does tell
Myth to record an entire 24-hour program doesn't seem too much to ask.

I am still very much against the artificial breaks in LiveTV for exactly
the reasons I specified (
http://www.gossamer-threads.com/lists/mythtv/users/188296#188296 ).
And, while it seems most of the list was very much for them--just in
case--it seems that once the thread died down, no one really cared
anymore (no one wrote patches, no one complained for 4 months) until it
appeared on the lists again... But, my opinion doesn't matter that much.

If there are artificial breaks, I would say the /only/ reasonable
approach is to make them /only/ when continuing to record the current
LiveTV program would cause expiration of non-LiveTV programs and when
the current LiveTV program is larger than the
highest-priority-to-autoexpire non-LiveTV program (i.e. Myth has to
decide between autoexpiring a 2GiB non-LiveTV program or a 10GiB (or a
2.3GiB) LiveTV program). At that point, Myth could break the current
program and let autoexpire delete that portion. But, that's a lot of
logic to write for a "just-in-case"... And, if the person watching the
show later decides it's worth keeping, they lose the entire beginning,
so it's not an ideal solution...

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
Michael,

Sorry, but this is a problem I encountered. It seems like others have too.

Also Mythtv is not used each day perse. There are simply too many TV-sets in
the house and mythtv is mainly used for recording. What if it was left on by
the kids on a music-channel and I noticed after 3 days ? It's not that I watch
TV each day...

The option to break live programs in segments will probably be enough for now.
You'll have to be tuned on the channel anyway to get the start of a program.

-Yves

On Wed, Jul 12, 2006 at 01:23:07PM -0400, Michael T. Dean wrote:
> On 07/12/06 12:40, glen martin wrote:
>
> >Michael T. Dean wrote:
> >
> >
> >>The right solution, though, is to stop LiveTV when you're not watching
> >>it... Another solution is to get more hard drives. ;)
> >>
> >>... Also, if the problem is that you're falling asleep during the
> >>commercials in LiveTV ;), check out the "Sleep" menu--hit MENU ('M') in
> >>LiveTV and scroll to "Sleep". There you can specify that Myth should
> >>turn off playback in 30, 60, 90, or 120 minutes. (You can also toggle
> >>the sleep timer with the TOGGLESLEEP key (by default 'F8'), which cycles
> >>through 30, 60, 90, 120 minutes then off.)
> >>
> >>
> >I'll gently suggest that such a solution is low in WAF (Wife Acceptance
> >Factor) and KCF (Kid Competency Factor). I remember to stop LiveTV.
> >Others don't, and won't.
> >
>
> That may rule out the "right solution," but still leaves the "another
> solution." It also leaves the "EXECTV executing xawtv" solution that I
> mentioned in the linked post (
> http://www.gossamer-threads.com/lists/mythtv/users/188296#188296 )--i.e.
> if you don't want to record it, don't record it.
>
> Let's say you've set LiveTV to the ridiculously-high average bitrate of
> 6000kbps (the default is 4500 average, 6000 max). Let's say some
> channel shows 24-hour programs and some--heh hum--person leaves MythTV
> playing LiveTV for the entire 24-hour program. That program will be
> about 60GiB. (Even at 9000kbps, the show will be about 90GiB after 24
> hours.)
>
> Now, in the real world, how often will your MythTV box sit there playing
> LiveTV for 24 hours straight? Won't someone try to use the Myth box
> within that time frame? If so, once they exit LiveTV, the large LiveTV
> program is eligible to be autoexpired immediately.
>
> True, for HDTV, a 24-hour program would be much larger, but has /anyone/
> ever seen a 24-hour program listed in a HDTV channel (which doesn't
> include digital radio channels because they won't use much bitrate for
> the video since there's not much video to them). I could see, maybe, 8
> hours for a sporting event (and, assuming an average of 7GiB/hr, that's
> about 56 GiB).
>
> So, making sure the family doesn't do something stu^H^H^Hlike tell Myth
> to record an entire 24-hour program when short on space (if you don't
> want to lose shows marked as eligible to autoexpire) doesn't seem too
> much to ask. Or, keeping a reserve of space for when someone does tell
> Myth to record an entire 24-hour program doesn't seem too much to ask.
>
> I am still very much against the artificial breaks in LiveTV for exactly
> the reasons I specified (
> http://www.gossamer-threads.com/lists/mythtv/users/188296#188296 ).
> And, while it seems most of the list was very much for them--just in
> case--it seems that once the thread died down, no one really cared
> anymore (no one wrote patches, no one complained for 4 months) until it
> appeared on the lists again... But, my opinion doesn't matter that much.
>
> If there are artificial breaks, I would say the /only/ reasonable
> approach is to make them /only/ when continuing to record the current
> LiveTV program would cause expiration of non-LiveTV programs and when
> the current LiveTV program is larger than the
> highest-priority-to-autoexpire non-LiveTV program (i.e. Myth has to
> decide between autoexpiring a 2GiB non-LiveTV program or a 10GiB (or a
> 2.3GiB) LiveTV program). At that point, Myth could break the current
> program and let autoexpire delete that portion. But, that's a lot of
> logic to write for a "just-in-case"... And, if the person watching the
> show later decides it's worth keeping, they lose the entire beginning,
> so it's not an ideal solution...
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On 07/12/06 13:53, Yves De Muyter wrote:

>Sorry, but this is a problem I encountered. It seems like others have too.
>
>Also Mythtv is not used each day perse. There are simply too many TV-sets in
>the house and mythtv is mainly used for recording. What if it was left on by
>the kids on a music-channel and I noticed after 3 days ? It's not that I watch
>TV each day...
>
>

Assuming the longest program in that 3-day period is 24-hours, you'd
have the exact same result as leaving it on only for the period spanning
that 24-hour program. In other words, the only way to get a long LiveTV
recording is if your guide data says it's a long program... Once the
24-hour program completed, the new program starts, and then the 24-hour
program would be the highest-priority program to expire (assuming all
other LiveTV programs had already expired).

>The option to break live programs in segments will probably be enough for now.
>You'll have to be tuned on the channel anyway to get the start of a program.
>
>

So, feel free to make that an option. :)

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On 7/12/06, Michael T. Dean <mtdean@thirdcontact.com> wrote:
> On 07/12/06 13:53, Yves De Muyter wrote:
>
> >Sorry, but this is a problem I encountered. It seems like others have too.
> >
> >Also Mythtv is not used each day perse. There are simply too many TV-sets in
> >the house and mythtv is mainly used for recording. What if it was left on by
> >the kids on a music-channel and I noticed after 3 days ? It's not that I watch
> >TV each day...
> >
> >
>
> Assuming the longest program in that 3-day period is 24-hours, you'd
> have the exact same result as leaving it on only for the period spanning
> that 24-hour program. In other words, the only way to get a long LiveTV
> recording is if your guide data says it's a long program... Once the
> 24-hour program completed, the new program starts, and then the 24-hour
> program would be the highest-priority program to expire (assuming all
> other LiveTV programs had already expired).
>
> >The option to break live programs in segments will probably be enough for now.
> >You'll have to be tuned on the channel anyway to get the start of a program.
> >
> >
>
> So, feel free to make that an option. :)
>
> Mike
> _______________________________________________

If someone were to code an option to break LiveTV into say, 8 hour
chunks at most, I think very few people would bother to use it. The
few that did might like it, so in the end, it may be a patch worth
submitting. However... I think a far better option is to simply
*teach* someone how to back out of LiveTV when not using it. It's not
only applicable in this type of situation, but when I turn on the TV,
I expect Myth to be at it's "Home" screen. It makes it more usable
for the next person who comes along to use it, they can easily select
watch recordings or whatever feature they are intending to utilize.


-Chad
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
(Responding off-list)

On 07/12/06 18:37, Chad wrote:

>If someone were to code an option to break LiveTV into say, 8 hour
>chunks at most, I think very few people would bother to use it. The
>few that did might like it, so in the end, it may be a patch worth
>submitting. However... I think a far better option is to simply
>*teach* someone how to back out of LiveTV when not using it. It's not
>only applicable in this type of situation, but when I turn on the TV,
>I expect Myth to be at it's "Home" screen. It makes it more usable
>for the next person who comes along to use it, they can easily select
>watch recordings or whatever feature they are intending to utilize.
>

Exactly!!!! :)

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On 07/12/06 20:40, Michael T. Dean wrote:

>(Responding off-list)
>
>

Or, maybe not... :-[

>On 07/12/06 18:37, Chad wrote:
>
>
>
>>If someone were to code an option to break LiveTV into say, 8 hour
>>chunks at most, I think very few people would bother to use it. The
>>few that did might like it, so in the end, it may be a patch worth
>>submitting. However... I think a far better option is to simply
>>*teach* someone how to back out of LiveTV when not using it. It's not
>>only applicable in this type of situation, but when I turn on the TV,
>>I expect Myth to be at it's "Home" screen. It makes it more usable
>>for the next person who comes along to use it, they can easily select
>>watch recordings or whatever feature they are intending to utilize.
>>
>>
>>
>
>Exactly!!!! :)
>
>Mike
>_______________________________________________
>mythtv-users mailing list
>mythtv-users@mythtv.org
>http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
>
>

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On Wed, Jul 12, 2006 at 01:23:07PM -0400, Michael T. Dean wrote:
> At that point, Myth could break the current
> program and let autoexpire delete that portion. But, that's a lot of
> logic to write for a "just-in-case"... And, if the person watching the
> show later decides it's worth keeping, they lose the entire beginning,
> so it's not an ideal solution...

The ideal solution is one that conforms with user expectations, not
one that's easier to program.

Programs that use ring-buffers traditionally have two ways of
dealing with buffer overflows: if the data is not important then
you eat your own tail; if the data is important then Something Bad
Has Happened and the program should treat the overflow as a
critical error. Dealing with that critical error is then a
completely separate issue. Using a dynamic buffer doesn't change
the choice of outcomes -- it simply delays the buffer-full
condition.

AFAIAC, the live TV buffer is not a "recording" until the user
manually chooses to make it one. That would make the ring-buffer
contents non-critical, and the only reasonable course of action
would be to eat your tail. In the case of a dynamic buffer, you
can allocate more and more storage to delay eating your tail, but
at some point you have to be prepared to do it. If you run out of
storage before the user selects "record" then that's *the user's
problem* for not selecting "record" earlier. The fact that
segmenting the recording to facilitate eating your tail is
difficult doesn't mean it shouldn't be done. If anything, it
should be done early and often, because you don't know what other
programs are going to allocate or free up space concurrently with
the live TV buffer. In other words, you should be ready to eat
your tail at any time in order to make room for other applications
(including other MythTV recordings).

When the user decided to convert the buffer into a recording then a
whole different set of rules applies. Now it's reasonable to start
expiring old programs to make room. Now a buffer-full condition
becomes critical because it means that you have no disk space left
AND no programs left to expire. At that point I would expect the
recording to stop, and the movie/episode marked for re-record.
Freeing up storage is then the user's responsibility.

I rarely use live TV in Myth, but would be very upset if MythTV
started deleting real recordings to make room for an
infinitely-expanding ring-buffer. That would be like Microsoft
Windows killing FireFox to free up memory for Excel -- it's not
what the user expects, and more importantly it usurps the user's
authority.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On 07/13/2006 02:55 AM, chris@cpr.homelinux.net wrote:
> On Wed, Jul 12, 2006 at 01:23:07PM -0400, Michael T. Dean wrote:
>
>> At that point, Myth could break the current
>> program and let autoexpire delete that portion. But, that's a lot of
>> logic to write for a "just-in-case"... And, if the person watching the
>> show later decides it's worth keeping, they lose the entire beginning,
>> so it's not an ideal solution...
>>
>
> The ideal solution is one that conforms with user expectations, not
> one that's easier to program.
>
> Programs that use ring-buffers traditionally have two ways of
> dealing with buffer overflows: if the data is not important then
> you eat your own tail; if the data is important then Something Bad
> Has Happened and the program should treat the overflow as a
> critical error. Dealing with that critical error is then a
> completely separate issue. Using a dynamic buffer doesn't change
> the choice of outcomes -- it simply delays the buffer-full
> condition.
>
> AFAIAC, the live TV buffer is not a "recording" until the user
> manually chooses to make it one. That would make the ring-buffer
> contents non-critical, and the only reasonable course of action
> would be to eat your tail. In the case of a dynamic buffer, you
> can allocate more and more storage to delay eating your tail, but
> at some point you have to be prepared to do it. If you run out of
> storage before the user selects "record" then that's *the user's
> problem* for not selecting "record" earlier.

I thought we were designing it to meet user expectations... Sounds like
the user who pushed TOGGLERECORD too late expected it would still work.

> The fact that
> segmenting the recording to facilitate eating your tail is
> difficult doesn't mean it shouldn't be done.

The fact that it's never a problem if:
a) You don't leave LiveTV running on a channel with a program that's
extremely long.
b) You have enough space available for the longest program in your
listings.
c) You explicitly tell Myth to insert a break (with a channel change
during a commercial or by exiting and re-entering LiveTV or ...)
or
d) You never use LiveTV ;)

means (to me) that writing a lot of code for this fringe case is not
worthwhile. Thus, I won't write any code for it. :) If someone else
wants to write the code, please feel free to do so.

> If anything, it
> should be done early and often, because you don't know what other
> programs are going to allocate or free up space concurrently with
> the live TV buffer. In other words, you should be ready to eat
> your tail at any time in order to make room for other applications
> (including other MythTV recordings).
>
> When the user decided to convert the buffer into a recording then a
> whole different set of rules applies. Now it's reasonable to start
> expiring old programs to make room. Now a buffer-full condition
> becomes critical because it means that you have no disk space left
> AND no programs left to expire. At that point I would expect the
> recording to stop, and the movie/episode marked for re-record.
> Freeing up storage is then the user's responsibility.
>
> I rarely use live TV in Myth, but would be very upset if MythTV
> started deleting real recordings to make room for an
> infinitely-expanding ring-buffer. That would be like Microsoft
> Windows killing FireFox to free up memory for Excel -- it's not
> what the user expects, and more importantly it usurps the user's
> authority.

Wouldn't breaking up a LiveTV recording usurp the user's authority? If
the user decides to save the show (hits TOGGLERECORD) after the break,
then he/she is only saving the part after the break. So, if there's
code to move all parts from LiveTV (assuming previous parts haven't
autoexpired, already) then the user ends up with more than one file for
the one recording. If part of the current recording has already
autoexpired, then the user ends up with only part of a recording (a la
0.18). And, the user never gave Myth permission to do any of this...

In my mind, the user's entering LiveTV is explicitly giving Myth
permission to record the current program on the current channel. If
that user is short on space, starting a new recording is explicitly
giving Myth permission to autoexpire old recordings, as necessary.
Therefore, I see this as doing exactly what the user asked.

Now, whether the user meant to ask that (as opposed to the dog stepping
on the key bound to the LiveTV jump point or the kids getting bored with
the commercials-laden LiveTV and walking away or ...) is a whole other
question... But, in those cases, simply having enough storage space
solves the problem.

Mike


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On Thu, Jul 13, 2006 at 03:49:57AM -0400, Michael T. Dean wrote:
> > AFAIAC, the live TV buffer is not a "recording" until the user
> > manually chooses to make it one.
> > If you run out of
> > storage before the user selects "record" then that's *the user's
> > problem* for not selecting "record" earlier.
>
> I thought we were designing it to meet user expectations... Sounds like
> the user who pushed TOGGLERECORD too late expected it would still work.

It's an unreasonable expectation. If it takes someone more than an
hour to decide whether or not a show is worth capturing then the
show is probably not valuable enough to cause prerecorded shows to
be deleted. Think of it this way: people compare MythTV and Tivo
to a VCR. If you start recording on a VCR at 5 minutes past the
hour then you missed the first 5 minutes and are stupid for not
planning ahead. If you reach the end of the tape before the show
is over then you lose the ending and again are stupid for not
planning ahead. If the VCR was to magically pull another tape off
the shelf and record over it, people would be stampeding to the
stores to return the VCR because the decision to destroy other
property is indefensible. MythTV has the advantage of a buffer so
the user can start recording after watching a bit of the show, but
it's not reasonable to destroy existing data in order to allow them
to waffle for the first 119 minutes of a two-hour program.

> The fact that it's never a problem if:
> a) You don't leave LiveTV running on a channel with a program that's
> extremely long.
> b) You have enough space available for the longest program in your
> listings.

Auto-expire would never happen if people always had enough disk
space left. The point is that it happens and it should be dealt
with in a rational way, not a lazy way. As I mentioned before,
there could have been enough disk space when you started the
recording but other programs have created large files since then.
The problem of low disk space needs to be handled regardless of how
it comes to pass. A properly designed out-of-storage manager
wouldn't care if the cause was a fringe case or something
entirely predictable.

Blaming the user for his mistakes is OK. Blaming the user for the
effects of your design decisions is not.

> c) You explicitly tell Myth to insert a break (with a channel change
> during a commercial or by exiting and re-entering LiveTV or ...)
> or
> d) You never use LiveTV ;)

My choice (currently) is "d", but that has less to do with the
current bad design and more to do with the fact that I prefer to
time-shift the shows I know I want and don't have a lot of interest
in pausing live TV. For me the issue may be a latent defect rather
than an active one, but it still represents a risk to my recordings.

> means (to me) that writing a lot of code for this fringe case is not
> worthwhile. Thus, I won't write any code for it. :) If someone else
> wants to write the code, please feel free to do so.

One of the things about design decisions is that when you do things
the right way then later features become easier and easier to add,
whereas when you do things the lazy way you paint yourself into a
corner and things get harder and harder until eventually you have
to refactor the code because progress becomes impossible. This
isn't about working around the "fringe case". It's about the fact
that the design decision here is just plain wrong because it
creates so many fringes in the first place. Getting the design
right means you spend less time worrying about fringe cases
(because there are fewer of them) and have a more sensible platform
for later work.

As far as writing code goes - if I had gobs of spare time I would
fork the project completely because the recording buffer is not the
only place where design has taken a back seat to expediency. The
GUI is still an abomination. The mythtv-setup program shouldn't
even exist, or should at least be text-based so that the back-end
can be installed on a machine with no X11 and no monitor.

You should read Eric Raymond's commentary on the CUPS system
entitled "The Luxury of Ignorance: An Open-Source Horror Story"
<http://www.catb.org/~esr/writings/cups-horror.html>. Most of his
observations are so spot-on he could have been writing about
MythTV. Robert Cringely has made similar comments about the
success of Apple as well.

> Wouldn't breaking up a LiveTV recording usurp the user's authority? If
> the user decides to save the show (hits TOGGLERECORD) after the break,
> then he/she is only saving the part after the break. So, if there's
> code to move all parts from LiveTV (assuming previous parts haven't
> autoexpired, already) then the user ends up with more than one file for
> the one recording.

The decisions about what to do when the user chooses to record a
show belong in the "what should I do when the user selects record?"
category, not the "how much valuable data should I delete on spec
just in case the user selects record later on?" category. As I
said in my previous email, I don't think live TV is the same as a
recording and therefore the live TV buffer is expendable. Grow the
buffer as much as you want, but be prepared to eat it if disk space
gets too low.

I would think it's obvious that when the user selects "record" then
the fragments should be gathered and logically (if not physically)
concatenated. It doesn't matter whether you are breaking on the
hour or every 5 minutes. Once you have code that can join the
fragments it doesn't matter how short those fragments become. The
code that converts a live buffer into a recording should SERVE the
disparate needs of the live TV and recording management modules,
not define how they will work. Once you adopt that mode of
managing the spool files then you can actually consider doing
things like gathering the fragments that came before and after the
user went channel-hopping during a commercial. If the schedule showed a
2-hour program and you found 23 5-minute fragments then it's better to
keep those than to use a 1-hour cut-off and lose half the show or (worse
yet) create two one-hour entries in the recordings directory.

When the user selects "record" you could use the schedule to figure
out what to keep, or you could keep everything for the current
channel and let them edit out what they don't want, or you could
ask them for start/stop times.

> In my mind, the user's entering LiveTV is explicitly giving Myth
> permission to record the current program on the current channel.

And I respectfully disagree. In fact, didn't 0.18 cancel live TV
if a scheduled recording was about to start (unless you explicitly
told it to continue)? There was an assumption that live TV was a
lower priority than the scheduled recordings, and that priority has
now apparently been inverted.

Maybe the question of whether live TV is a higher or lower priority
than the scheduled recordings should be settled by explicitly
assigning it a recording priority and then comparing it to the
scheduled events. Furthermore, if the auto-expire was done on the
basis of the recording priority instead of just age then live TV
could delete last night's "Simpsons" (which will be on five more
times in the next three days) while leaving last week's "House"
even though both are able to be expired.

When you think about it, a show's priority is a good indicator of
whether or not it should be allowed to auto-expire, and can also be used
as a hint for the "reschedule higher priorities" option. Both of those
options could be eliminated entirely if the priorities were tiered. For
example:
> 100 don't expire; don't reschedule for lower priority
50 to 99 don't expire
1 to 49 expire last; mark for re-record
0 live TV buffer
-1 to -49 expire when required; mark for re-record
-50 to -99 expire first; can't bump higher priority; don't re-record
< -100 don't record (immediately moved to "previously viewed")
This would mean retaining the priority even after the show had been
recorded. The toggle for whether or not to flag a show for
auto-expire would simply change the stored priority value. Expiry
would be done by priority value, and dates would only be used when
two or more shows with the same priority made it to the bottom of the
priority list.

What it boils down to is that if you think the user wants you to
take a destructive action, don't assume. A reasonable design would
try to minimize the damage, both by confirming the user really
intends to destroy existing data and then by doing so in a more
intelligent way.

> If
> that user is short on space, starting a new recording is explicitly
> giving Myth permission to autoexpire old recordings, as necessary.
> Therefore, I see this as doing exactly what the user asked.

This is a destructive assumption.

> Now, whether the user meant to ask that (as opposed to the dog stepping
> on the key bound to the LiveTV jump point or the kids getting bored with
> the commercials-laden LiveTV and walking away or ...) is a whole other
> question... But, in those cases, simply having enough storage space
> solves the problem.

The kids walking away or the dog stepping on the keyboard are only
problems because the design assumptions make them into problems. I
get your point -- "stuff happens" -- but a robust application
shouldn't even see most of that "stuff" as problems.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On 07/13/06 14:25, chris@cpr.homelinux.net wrote:

>On Thu, Jul 13, 2006 at 03:49:57AM -0400, Michael T. Dean wrote:
>
>
>>>AFAIAC, the live TV buffer is not a "recording" until the user
>>>manually chooses to make it one.
>>> If you run out of
>>>storage before the user selects "record" then that's *the user's
>>>problem* for not selecting "record" earlier.
>>>
>>>
>>I thought we were designing it to meet user expectations... Sounds like
>>the user who pushed TOGGLERECORD too late expected it would still work.
>>
>It's an unreasonable expectation.
>
...

To you. Recording without deleting when short on space is an
unreasonable expectation to me.

>>The fact that it's never a problem if:
>> a) You don't leave LiveTV running on a channel with a program that's
>>extremely long.
>> b) You have enough space available for the longest program in your
>>listings.
>>
>>
>Auto-expire would never happen if people always had enough disk
>space left. The point is that it happens and it should be dealt
>with in a rational way, not a lazy way. As I mentioned before,
>there could have been enough disk space when you started the
>recording but other programs have created large files since then.
>

Which is why Myth allows the user to specify the amount of space
reserved for other programs...

Extra Disk Space (in Gigabytes)
Extra disk space you want on the recording file system beyond what
MythTV requires. This is useful if you use the recording file system for
data other than MythTV recordings.

>> c) You explicitly tell Myth to insert a break (with a channel change
>>during a commercial or by exiting and re-entering LiveTV or ...)
>>or
>> d) You never use LiveTV ;)
>>
>>
>My choice (currently) is "d", but that has less to do with the
>current bad design and more to do with the fact that I prefer to
>time-shift the shows I know I want and don't have a lot of interest
>in pausing live TV. For me the issue may be a latent defect rather
>than an active one, but it still represents a risk to my recordings.
>
>

It's not a risk to my recordings. I have enough space to handle any
LiveTV recording (and my system doesn't record LiveTV when no one is
watching it, anyway).

>>means (to me) that writing a lot of code for this fringe case is not
>>worthwhile. Thus, I won't write any code for it. :) If someone else
>>wants to write the code, please feel free to do so.
>>
>>
>One of the things about design decisions is that when you do things
>the right way then later features become easier and easier to add,
>whereas when you do things the lazy way you paint yourself into a
>corner and things get harder and harder until eventually you have
>to refactor the code because progress becomes impossible. This
>isn't about working around the "fringe case". It's about the fact
>that the design decision here is just plain wrong because it
>creates so many fringes in the first place. Getting the design
>right means you spend less time worrying about fringe cases
>(because there are fewer of them) and have a more sensible platform
>for later work.
>
>As far as writing code goes - if I had gobs of spare time I would
>fork the project completely because the recording buffer is not the
>only place where design has taken a back seat to expediency. The
>GUI is still an abomination.
>

Interesting how the guy preaching about how lazy the MythTV developers
are doesn't have time to fix any problems. I guess you're just saying
your time is more valuable than Isaac's, et. al, and they should get
right on fixing this problem for you.

Perhaps you should look up the guy who re-implemented MythTV in just a
few lines of Perl code. Even if he completely missed the boat (and
created an abomination as bad as MythTV), there's a lot less code to fix.

> The mythtv-setup program shouldn't
>even exist, or should at least be text-based so that the back-end
>can be installed on a machine with no X11 and no monitor.
>
>

Not going to make a comment about the importance of 150MiB (installed
size of X and less than 10 minutes of a recording at 2000kbps or
5min@4000kbps or 2.5min@6000kbps) to a backend. Not going to comment on
the backend's not needing a monitor (or even needing to run an X
server). Not going to comment on the fact that Qt3 makes installation
of X mandatory, anyway, and that Myth requires Qt3.

>You should read Eric Raymond's commentary on the CUPS system
>entitled "The Luxury of Ignorance: An Open-Source Horror Story"
><http://www.catb.org/~esr/writings/cups-horror.html>. Most of his
>observations are so spot-on he could have been writing about
>MythTV. Robert Cringely has made similar comments about the
>success of Apple as well.
>
>

I have. And, while I generally respect ESR's opinions, I feel that
essay is just plain wrong. He talks about the usability of CUPS based
on the GUI configuration tools provided by Fedora Core (not by CUPS). I
might as well say that Linux is poorly designed because I used "Bob's
Bad Linux" and found it difficult to configure it. (Every distro is so
different that they might as well be considered different operating
systems. I cannot use any of the distros effectively, but I know a bit
about GNU/Linux--I have never been unable to configure my GNU/Linux
systems to do something I wanted them to do and they do a lot for me.)
Now, if he properly attributed the blame to Red Hat, I might take it
more seriously, but even then, IMHO, the FC configuration tools (or any
other distro-specific config/GUI tools) are not a good indicator of the
way open-source design generally works (for various reasons I won't go
into here), and, regardless, he's confusing responsibilities (but that's
a whole different story).

>>Wouldn't breaking up a LiveTV recording usurp the user's authority? If
>>the user decides to save the show (hits TOGGLERECORD) after the break,
>>then he/she is only saving the part after the break. So, if there's
>>code to move all parts from LiveTV (assuming previous parts haven't
>>autoexpired, already) then the user ends up with more than one file for
>>the one recording.
>>
>>
>The decisions about what to do when the user chooses to record a
>show belong in the "what should I do when the user selects record?"
>category, not the "how much valuable data should I delete on spec
>just in case the user selects record later on?" category.
>

And that's where the distinction comes in. MythTV currently assumes
that the currently-recording LiveTV show (which, by all reasonable
assumptions, someone is watching) is more valuable than some old
previously recorded show. If you haven't yet watched the old
recording--which you (the user) explicitly marked as eligible to
autoexpire (thereby giving Myth permission to delete it)--who's to say
you will.

If you don't want the show to autoexpire, don't mark it eligible to
autoexpire. Once you watch it, then mark it to allow autoexpire.

>>In my mind, the user's entering LiveTV is explicitly giving Myth
>>permission to record the current program on the current channel.
>>
>>
>And I respectfully disagree. In fact, didn't 0.18 cancel live TV
>if a scheduled recording was about to start (unless you explicitly
>told it to continue)? There was an assumption that live TV was a
>lower priority than the scheduled recordings, and that priority has
>now apparently been inverted.
>
>

No. There hasn't been a change in assumptions. The assumption is that
what's on LiveTV now (a show that someone is watching) is more important
than some old /previously-recorded/ program that the user may or may not
have gotten around to watching. IMHO, that's a perfectly valid assumption.

>Maybe the question of whether live TV is a higher or lower priority
>than the scheduled recordings should be settled by explicitly
>assigning it a recording priority and then comparing it to the
>scheduled events. Furthermore, if the auto-expire was done on the
>basis of the recording priority instead of just age
>

Hmmm. You mean like creating a setting:

Auto Expire Method
- Oldest Show First
- Lowest Priority First
- Weighted Time/Priority Combination
Method used to determine which recorded shows to delete first. LiveTV
recordings will always expire before normal recordings.

> then live TV
>could delete last night's "Simpsons" (which will be on five more
>times in the next three days) while leaving last week's "House"
>even though both are able to be expired.
>
>

If only that setting existed in frontend settings in the General section
on the page "General (Basic)"...

>When you think about it, a show's priority is a good indicator of
>whether or not it should be allowed to auto-expire, and can also be used
>as a hint for the "reschedule higher priorities" option. Both of those
>options could be eliminated entirely if the priorities were tiered. For
>example:
> > 100 don't expire; don't reschedule for lower priority
> 50 to 99 don't expire
> 1 to 49 expire last; mark for re-record
> 0 live TV buffer
> -1 to -49 expire when required; mark for re-record
> -50 to -99 expire first; can't bump higher priority; don't re-record
> < -100 don't record (immediately moved to "previously viewed")
>This would mean retaining the priority even after the show had been
>recorded. The toggle for whether or not to flag a show for
>auto-expire would simply change the stored priority value. Expiry
>would be done by priority value, and dates would only be used when
>two or more shows with the same priority made it to the bottom of the
>priority list.
>
>

Encoding additional meaning into priority? Yeah. That's intuitive.
From ESR's essay that you quoted, "Rule 1 of writing software for
nontechnical users is this: if they have to read documentation to use it
you designed it wrong."

Anyway, you don't have to convince me. I /will not/ write any code for
this case. Perhaps your arguments were enough to convince one of the
devs or another user to write some code.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On Thursday 13 July 2006 2:25 pm, chris@cpr.homelinux.net wrote:
> The kids walking away or the dog stepping on the keyboard are only
> problems because the design assumptions make them into problems. I
> get your point -- "stuff happens" -- but a robust application
> shouldn't even see most of that "stuff" as problems.

Please explain how to do live-tv in a full-disk situation (before starting
live tv) without:
a) deleting a recording the user has already said can be deleted.
or
b) reserving space for live-tv only (and so preventing less to be recorded in
the first place, irregardless of how often someone uses live-tv).
or
c) just disallowing live-tv to run, even though there are programs that could
be deleted, and the user obviously wants to go into live-tv.

Obviously, c will have to happen anyway, if there's nothing marked as
deletable, but it's nice to keep that from happening if at all possible. I
rather dislike b, because I want as much recorded at any given time as I have
space for.

Even with a ring-buffer (ie, <= 0.18), you need to have space on the drive
available to start it in the first place.

The problem with chunking livetv into smaller boundaries than a full program
is that in the full disk situation (which should be the norm for most people
after a short time of recording things), there won't be _any_ chunks other
than the most current one being recorded. Everything else will have been
auto-expired to make space for the next chunk. To me, that makes the ability
to keep the recording completely useless. What use would a 5 minute
ring-buffer be? The minimum I'd consider chunking a live-tv program to would
be 8 hours, I think. Harddrives are cheap enough for that, anyway.

Let's see, other options.. could prompt the user so that they're explicitly
aware that something's going to be auto-expired when they enter live-tv, but
the normal user that uses auto-expire (who always a full-drive) is going to
get that message _every_ _single_ _time_ they start live-tv. That's not
helpful or useful, that's annoying. A user that deletes programs manually
wouldn't ever see the prompt, but they'd almost never be in the situation
where live-tv would possibly need extra space in the first place.

Way I see it: if you don't want something to be autoexpired, don't turn it on
in the first place. If a program is allowed to be autoexpired, it's _going_
to be deleted at some point. If you don't want something deleted when space
is needed, simply disable autoexpire for it. I don't see that as a design
flaw.

I just got a 'global live-tv inactivity timeout' proposed to me, which could
help. Ie, automatically exit after 4 hours of inactivity or whatnot.

Any other ideas? Please, just don't ignore what happens when the disk is
_always_ full, and remember that regular scheduled recordings are also going
to be causing auto-expireable programs to be deleted.

And no, automatically buying and installing new harddrives won't work. =)

Isaac
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On Jul 13, 2006, at 2:45 PM, Isaac Richards wrote:

> On Thursday 13 July 2006 2:25 pm, chris@cpr.homelinux.net wrote:
>> The kids walking away or the dog stepping on the keyboard are only
>> problems because the design assumptions make them into problems. I
>> get your point -- "stuff happens" -- but a robust application
>> shouldn't even see most of that "stuff" as problems.
>
> Please explain how to do live-tv in a full-disk situation (before
> starting
> live tv) without:
> a) deleting a recording the user has already said can be deleted.
> or
> b) reserving space for live-tv only (and so preventing less to be
> recorded in
> the first place, irregardless of how often someone uses live-tv).
> or
> c) just disallowing live-tv to run, even though there are programs
> that could
> be deleted, and the user obviously wants to go into live-tv.
>
> Obviously, c will have to happen anyway, if there's nothing marked as
> deletable, but it's nice to keep that from happening if at all
> possible. I
> rather dislike b, because I want as much recorded at any given time
> as I have
> space for.
>
> Even with a ring-buffer (ie, <= 0.18), you need to have space on
> the drive
> available to start it in the first place.
>
> The problem with chunking livetv into smaller boundaries than a
> full program
> is that in the full disk situation (which should be the norm for
> most people
> after a short time of recording things), there won't be _any_
> chunks other
> than the most current one being recorded. Everything else will
> have been
> auto-expired to make space for the next chunk. To me, that makes
> the ability
> to keep the recording completely useless. What use would a 5 minute
> ring-buffer be? The minimum I'd consider chunking a live-tv
> program to would
> be 8 hours, I think. Harddrives are cheap enough for that, anyway.
>
> Let's see, other options.. could prompt the user so that they're
> explicitly
> aware that something's going to be auto-expired when they enter
> live-tv, but
> the normal user that uses auto-expire (who always a full-drive) is
> going to
> get that message _every_ _single_ _time_ they start live-tv.
> That's not
> helpful or useful, that's annoying. A user that deletes programs
> manually
> wouldn't ever see the prompt, but they'd almost never be in the
> situation
> where live-tv would possibly need extra space in the first place.
>
> Way I see it: if you don't want something to be autoexpired, don't
> turn it on
> in the first place. If a program is allowed to be autoexpired,
> it's _going_
> to be deleted at some point. If you don't want something deleted
> when space
> is needed, simply disable autoexpire for it. I don't see that as a
> design
> flaw.
>
> I just got a 'global live-tv inactivity timeout' proposed to me,
> which could
> help. Ie, automatically exit after 4 hours of inactivity or whatnot.
>
> Any other ideas? Please, just don't ignore what happens when the
> disk is
> _always_ full, and remember that regular scheduled recordings are
> also going
> to be causing auto-expireable programs to be deleted.
>
> And no, automatically buying and installing new harddrives won't
> work. =)
>


It's simple math: If you record video at a faster rate than you
delete it you are going to run out of space and not be able to do
something that you want to do. That might by LiveTV or recordings.

I try and make my record and delete rates equal, as that is the only
way you are going to have a happy system, your hard drive space is
really only a buffer to hold things temporarily.

I either watch the material and then delete it, or burn it to DVD and
then delete it if I want to save it but don't expect to watch it in
the near future.

I have also found the myth_archive_job.pl script to be helpful for
moving recordings to a USB drive if I need additional space temporarily.

But the problem is identical to body weight control, if you take in
more calories than you burn you will get heavier, and no tablet or
hypnosis or positive thinking can change that.

And no amount of re-coding or design philosophy changes will make the
slightest difference in the end either :-)
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On to, 2006-07-13 at 16:45 -0400, Isaac Richards wrote:
> Please explain how to do live-tv in a full-disk situation (before starting
> live tv) without:
> a) deleting a recording the user has already said can be deleted.
> or
> b) reserving space for live-tv only (and so preventing less to be recorded in
> the first place, irregardless of how often someone uses live-tv).
> or
> c) just disallowing live-tv to run, even though there are programs that could
> be deleted, and the user obviously wants to go into live-tv.

I'd think that would be fairly obvious, if you consider not the current
implementation, but what a user would expect to happen with a TV set:

d) display live tv, but show a message over the OSD that storage space
is not available, so time-shift capability and recording are disabled.

If you'd want to make it fancy, provide a shortcut for the user to
delete one of two or three shows the system expects to be least wanted
without having to exit live tv. The decision on what is least wanted
should be what the auto-prioritization would have deleted if there were
expirable programs.

> The problem with chunking livetv into smaller boundaries than a full program
> is that in the full disk situation (which should be the norm for most people
> after a short time of recording things), there won't be _any_ chunks other
> than the most current one being recorded. Everything else will have been
> auto-expired to make space for the next chunk. To me, that makes the ability
> to keep the recording completely useless. What use would a 5 minute
> ring-buffer be?

And that's entirely reasonable. If there is no space available, the user
can not expect to keep a recording. She will expect to be able to watch
tv without recording, since she could do that without MythTV in the
first place.

> Way I see it: if you don't want something to be autoexpired, don't turn it on
> in the first place. If a program is allowed to be autoexpired, it's _going_
> to be deleted at some point. If you don't want something deleted when space
> is needed, simply disable autoexpire for it. I don't see that as a design
> flaw.

To me, auto-expire is the natural default setting, as it is the only way
the system can keep space available without forcing manual management.
In fact, I think it should always be enabled by default, and the "Don't
auto expire this show" should in fact be an "Archive this show"
function, perhaps tied to DVD-R storage.

This is because the first choice should always be something that a)
provides value to the user and b) requires as little or less management
than the previous alternative (ie, minimizes cost for the provided
value).

MythTV provides both of these to the degree that: it makes time-shifting
possible, whereas without a DVR it is not, and it makes recording easy,
thanks to automatic program guide and episode searching. But if you turn
off auto-expire, you break at least one of those guidelines.

--
Osma Ahvenlampi <oa@iki.fi> http://www.fishpool.org

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On to, 2006-07-13 at 15:40 -0400, Michael T. Dean wrote:
> On 07/13/06 14:25, chris@cpr.homelinux.net wrote:
> >On Thu, Jul 13, 2006 at 03:49:57AM -0400, Michael T. Dean wrote:
> >>I thought we were designing it to meet user expectations... Sounds like
> >>the user who pushed TOGGLERECORD too late expected it would still work.
> >>
> >It's an unreasonable expectation.
>
> To you. Recording without deleting when short on space is an
> unreasonable expectation to me.

Now this is just silly. You can not record when there is no space.
That's a constraint, not an assumption. Please try to think of
objective, assumption, constraint and design choice separately from each
other, you'll find it helps model the system better.

> Which is why Myth allows the user to specify the amount of space
> reserved for other programs...

Actually, MythTV doesn't "allow" these - it requires these, as it does a
whole lot of other unreasonably complicated settings that create all
sorts of weird, unworkable combinations. I would venture to state that
for most of these cases, the existence of the setting is due to laziness
on the part of the designer.

Oops, sorry, there's no design here, just code. Anyone volunteering to
offer a design is shot down unless they volunteer the code at the same
time. (okay, rant off. sorry about that)

> It's not a risk to my recordings. I have enough space to handle any
> LiveTV recording (and my system doesn't record LiveTV when no one is
> watching it, anyway).

Where did you got that infinite capacity storage system you obviously
use?

LiveTV is not a problem for me either, because I never, ever use it. I
learnt ages ago that it's far more reliable to schedule a recording and
watch it time-delayed than to try and trust LiveTV, even if it would
have been more convenient. Doesn't this tell you something about a
design problem?

> And that's where the distinction comes in. MythTV currently assumes
> that the currently-recording LiveTV show (which, by all reasonable
> assumptions, someone is watching) is more valuable than some old
> previously recorded show. If you haven't yet watched the old

You're making a rationalization of a coding choice post-fact. Consider
that:

* If someone has exclicitly asked for a program to be recorded, it
obviously is (or at least was, but the system doesn't know the
difference) important to her, even (especially) if still unwatched. Not
all users have all the time in the world to watch everything
immediately, that's what a DVR is for.

* Most, if not all recordings must be marked autoexpire, otherwise every
system will run out of space eventually. It's unreasonable to expect an
end user to manage the storage by deleting things manually. Again, a
DVR's function is to make life easier for its user, not to introduce
something new to manage.

* A LiveTV program can be reasonably assumed to be watched by someone,
as you state yourself. That implies it has been seen (to the point where
it's been broadcast, minus time-shift delay). That makes it less
important than an auto-expire, unseen previous recording.

Now, MythTV DOES make all of these assumptions, since it prioritizes
LiveTV buffers lower than recordings. It's just that it doesn't do that
completely, and due to unimplemented cases, leads to situations where it
does the wrong thing based on the above observations, which are its own
design assumptions.

> If you don't want the show to autoexpire, don't mark it eligible to
> autoexpire. Once you watch it, then mark it to allow autoexpire.

As stated above, no reasonable end user wants to have more stuff to
manage. In fact, you don't want to either. If the system made the right
decisions by itself, you'd be happy to let it make those decisions and
would have no need to manage the expiration process yourself.

> No. There hasn't been a change in assumptions. The assumption is that
> what's on LiveTV now (a show that someone is watching) is more important
> than some old /previously-recorded/ program that the user may or may not
> have gotten around to watching. IMHO, that's a perfectly valid assumption.

That is a perfectly valid assumption. The implementation however
additionally assumes that what was on LiveTV three hours ago and was
already seen is ALSO more important than a previously recorded program
if the channel guide (which the user has no control over) didn't have a
program change in between. This is the not-perfectly-reasonable
assumption that the thread is having problems with.

> Hmmm. You mean like creating a setting:

I can't presume to know what Chris meant, but please, no more settings!

"It turns out that preferences have a cost. Of course, some preferences
also have important benefits - and can be crucial interface features.
But each one has a price, and you have to carefully consider its value.
Many users and developers don't understand this, and end up with a lot
of cost and little value for their preferences dollar."

-- Havoc Pennington, http://ometer.com/free-software-ui.html

--
Osma Ahvenlampi <oa@iki.fi> http://www.fishpool.org

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On 07/14/06 03:52, Osma Ahvenlampi wrote:

>On to, 2006-07-13 at 15:40 -0400, Michael T. Dean wrote:
>
>
>>It's not a risk to my recordings. I have enough space to handle any
>>LiveTV recording (and my system doesn't record LiveTV when no one is
>>watching it, anyway).
>>
>>
>Where did you got that infinite capacity storage system you obviously
>use?
>
>

It hardly needs to be infinite capacity--and that's the entire point.
It simply needs to be sufficient capacity to hold the longest program in
the listings:

UNIX_TIMESTAMP(starttime))) AS 'Max Duration' FROM program;
+--------------+
| Max Duration |
+--------------+
| 06:30:00 |
+--------------+
1 row in set (0.07 sec)

So, given my average recording size of 1.15GiB/hr, that means I simply
need to have 7.5GiB free to record /any/ (or all) LiveTV show(s).

Even if I used a ridiculously-high bitrate (instead of my
ridiculously-low bitrate of 2.75kbps (including audio)) like 9800kbps
(the max allowable by the DVD spec), that 6.5hr show is still less than
27GiB. And, how much is a 300GB HDD? (
http://www.newegg.com/ProductSort/SubCategory.asp?SubCategory=14 )

>>And that's where the distinction comes in. MythTV currently assumes
>>that the currently-recording LiveTV show (which, by all reasonable
>>assumptions, someone is watching) is more valuable than some old
>>previously recorded show. If you haven't yet watched the old
>>
>>
>You're making a rationalization of a coding choice post-fact. Consider
>that:
>
>* If someone has exclicitly asked for a program to be recorded, it
>obviously is (or at least was, but the system doesn't know the
>difference) important to her, even (especially) if still unwatched. Not
>all users have all the time in the world to watch everything
>immediately, that's what a DVR is for.
>
>

I would argue that if she's currently watching LiveTV (= whatever is on
right now)--as opposed to a show that she recorded because it was
important for her to be able to watch it--she's run out of interesting
recordings to watch, so the LiveTV must be more important to her than
the recordings.

>* Most, if not all recordings must be marked autoexpire, otherwise every
>system will run out of space eventually. It's unreasonable to expect an
>end user to manage the storage by deleting things manually. Again, a
>DVR's function is to make life easier for its user, not to introduce
>something new to manage.
>
>

Right, so important recordings should be marked to not autoexpire.
Then, when the user is ready to delete them, he/she can do so or can
simply mark them as eligible to autoexpire.

>* A LiveTV program can be reasonably assumed to be watched by someone,
>as you state yourself. That implies it has been seen (to the point where
>it's been broadcast, minus time-shift delay). That makes it less
>important than an auto-expire, unseen previous recording.
>
>Now, MythTV DOES make all of these assumptions, since it prioritizes
>LiveTV buffers lower than recordings. It's just that it doesn't do that
>completely, and due to unimplemented cases, leads to situations where it
>does the wrong thing based on the above observations, which are its own
>design assumptions.
>
>>If you don't want the show to autoexpire, don't mark it eligible to
>>autoexpire. Once you watch it, then mark it to allow autoexpire.
>>
>>
>As stated above, no reasonable end user wants to have more stuff to
>manage. In fact, you don't want to either. If the system made the right
>decisions by itself, you'd be happy to let it make those decisions and
>would have no need to manage the expiration process yourself.
>
>

Oh, I think I see what you want now. You want to mark all recordings as
eligible for autoexpiring (so you don't have to explicitly mark them
once you're done with them), but you want Myth to only delete those
recordings that you want to delete. Hmmm. See if you can work up some
code to do that. I'm sure it would be accepted. :)

>>No. There hasn't been a change in assumptions. The assumption is that
>>what's on LiveTV now (a show that someone is watching) is more important
>>than some old /previously-recorded/ program that the user may or may not
>>have gotten around to watching. IMHO, that's a perfectly valid assumption.
>>
>>
>That is a perfectly valid assumption. The implementation however
>additionally assumes that what was on LiveTV three hours ago and was
>already seen is ALSO more important than a previously recorded program
>if the channel guide (which the user has no control over) didn't have a
>program change in between. This is the not-perfectly-reasonable
>assumption that the thread is having problems with.
>

It all comes down to atomicity. It seems our definitions disagree, though.

>>Hmmm. You mean like creating a setting:
>>
>I can't presume to know what Chris meant, but please, no more settings!
>

No need to create a new setting for "Auto Expire Method." :) (/me
chuckles)

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
On Fri, Jul 14, 2006 at 10:41:40AM +0300, Osma Ahvenlampi wrote:
> I'd think that would be fairly obvious, if you consider not the current
> implementation, but what a user would expect to happen with a TV set:
>
> d) display live tv, but show a message over the OSD that storage space
> is not available, so time-shift capability and recording are disabled.

BINGO!

The reason this list devolves into design wars ("there's a problem
with Myth's implimentation!" vs "if you want it improved then code
it yourself!") is because some of us start from the position of
"what should myth do, given limitations caused by past
assumptions?" while others ask "what would Aunt Tillie expect?"

In the real world, when a VCR reaches the end of the tape it either
stops recording (the "storage is critical so I'll panic" model) or
else it rewinds and starts at the beginning of the current tape
(the "storage is expendable so I'll eat my tail" model). It
doesn't reach over to your rack of videos and say "you haven't
watched this movie lately so I think I'll write over it".

The intuitive solution when you don't have any room to record live
TV is simply to not record live TV.

This is not the same as deciding whether or not to auto-expire a
low-priority recording to make room for a higher priority recording.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
> -----Original Message-----
> From: mythtv-users-bounces@mythtv.org [mailto:mythtv-users-
> bounces@mythtv.org] On Behalf Of chris@cpr.homelinux.net
> Sent: 14 July 2006 12:08
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] Mythtv .19 live watching
>
> On Fri, Jul 14, 2006 at 10:41:40AM +0300, Osma Ahvenlampi wrote:
> > I'd think that would be fairly obvious, if you consider not the current
> > implementation, but what a user would expect to happen with a TV set:
> >
> > d) display live tv, but show a message over the OSD that storage space
> > is not available, so time-shift capability and recording are disabled.
>
> BINGO!
>
> The reason this list devolves into design wars ("there's a problem
> with Myth's implimentation!" vs "if you want it improved then code
> it yourself!") is because some of us start from the position of
> "what should myth do, given limitations caused by past
> assumptions?" while others ask "what would Aunt Tillie expect?"
>
> In the real world, when a VCR reaches the end of the tape it either
> stops recording (the "storage is critical so I'll panic" model) or
> else it rewinds and starts at the beginning of the current tape
> (the "storage is expendable so I'll eat my tail" model). It
> doesn't reach over to your rack of videos and say "you haven't
> watched this movie lately so I think I'll write over it".
>
> The intuitive solution when you don't have any room to record live
> TV is simply to not record live TV.
>
> This is not the same as deciding whether or not to auto-expire a
> low-priority recording to make room for a higher priority recording.
>

However if you've been using your system for any length of time you have
long filled your storage space and *rely* on myth to delete the oldest stuff
to allow you to continue recording new stuff. So there will never be free
space for live tv, so you will never be able to just go to live tv, you
would always be informed that you can't enter live tv because you have no
storage space... Which would be a pita.

If you're using MythTV you *know* that when your storage is full any new
recordings will overwrite the oldest recordings (simplified view).
If you're using MythTV you *know* that when you watch LiveTV it is in fact a
recording that can be ff/rw paused saved in it's entirety from the point you
started watching (or from the last program schedule change, which ever was
the most recent).
So now you know LiveTV is a recording, you also know new recordings
overwrite old ones, so going into LiveTV you carry the knowledge that you
are potentially overwriting old recordings.


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 13/07/2006


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
Michael T. Dean wrote:
>
> Not going to make a comment about the importance of 150MiB (installed
> size of X and less than 10 minutes of a recording at 2000kbps or
> 5min@4000kbps or 2.5min@6000kbps) to a backend. Not going to comment on
> the backend's not needing a monitor (or even needing to run an X
> server). Not going to comment on the fact that Qt3 makes installation
> of X mandatory, anyway, and that Myth requires Qt3.
>

A bit off-topic on this thread, but a text-based setup tool would be
useful. There is really no need to have a GUI for mythtv-setup, and in
fact it doesn't even use the mouse anyway. However, I'm sure most
people would feel that this is not the highest-priority issue out there
right now.

>
> And that's where the distinction comes in. MythTV currently assumes
> that the currently-recording LiveTV show (which, by all reasonable
> assumptions, someone is watching) is more valuable than some old
> previously recorded show.


Actually, assuming that somebody is watching LiveTV isn't really
reasonable considering how easy it is to turn off the TV without hitting
ESC/Back/whatever. Happens all the time in my house, despite occasional
reminders to the kids - and it isn't like I want to nag them about it
every 5 minutes when there are more important things to nag them about
like not leaving the door open with the AC on.

The way most DVRs handle LiveTV conflicts is with a pop-up prompt
stating that the system is going to do some action in x minutes and to
confirm/prevent this action with a response (which defaults to stopping
liveTV in the assumption that nobody is watching it if there is no
response).

Most of my shows are set to autoexpire - and if the system deleted a few
of them to record some show that had higher priority then it is just
doing what I wanted it to do. On the other hand, if one of the kids
leaves the TV on liveTV mode on some channel with a high bitrate and a
long program and the system wipes out 60% of the recorded shows that
would not be the correct behavior. Sure, I don't mind those shows being
deleted per-se, but that was with the expectation that when I sit down
to watch TV I'd have something else to watch, not a 2/3rds blank disk
(since as soon as that 12-hour show ended it would probably get deleted
anyway).

Sure, this is easily fixed by having $50 worth of unused hard drive
sitting around, but if I did have extra space I'd rather be using it
than buffering against a minor design flaw.

Granted, in most cases this bug isn't a huge deal unless you have some
very-long programming on a high-bitrate channel. With high-def that
could happen, and 300GB drives are expensive enough that I'd rather not
own one just to leave it unused just-in-case.

BTW - I just have to comment that I love MythTV - beats the socks off of
the DirecTV R15 DVR that was driving me insane before I took the plunge
(design isn't bad, but implementation is horrible). I look at issues
like this as things that should be acknowledged as needing a better
solution, but when it comes to priority I wouldn't consider this at the
top of the list. By simply acknowledging that a better design might
exist you at least open yourself up to improving the design when other
changes need to be made anyway, or when some of the higher-priority
issues are resolved.

Maybe a possible configuration item would be a
non-technical-users-present page which lets you easily turn on some
settings designed to compensate for users who do not fully appreciate
the design of the system. Another family-friendly option would be to
have user groups / permissions so that a kid or guest can't cancel a
recording show in order to watch liveTV if the show that is recording is
particularly important. It might also be nice if the system could keep
track of who has seen a particular show in case more than one person
wants to see it and they don't always watch TV together.

The nice thing about mythtv is the fact that there is a community, and
the community's voice actually impacts the design. I for one would like
to acknowledge that the current developers have clearly been listening!
I would also encourage the devs to recognize non-ideal cases in the
design even if they are a pain to fix - not so that they can be harped
on or fixed immediately, but rather so that they can be kept in mind so
that eventually they might be fixed in a creative way, or the next time
there is a significant rewrite/redesign anyway. On most software design
projects of some size a list of known defects/change-requests is
maintained even if 90% of them will never be fixed - because if a dev is
going to tear apart some module they might as well fix the bugs while
they are there.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Mythtv .19 live watching [ In reply to ]
Steve Daniels wrote:
> So now you know LiveTV is a recording, you also know new recordings
> overwrite old ones, so going into LiveTV you carry the knowledge that you
> are potentially overwriting old recordings.
>

Good point. I think the concern is more that if LiveTV is left on that
it shouldn't wipe out an inordinate number of recorded programs just
because it is tuned to a channel with a very long program. Maybe a
prompt every 4 hours with 30 minutes of warning that LiveTV is about to
be stopped might be a workaround? If somebody doesn't spot the prompt
in 30 minutes they aren't watching, and a show > 4 hours is an oddity -
plus it will probably just get deleted the instant it ends to make room
for the very next show that comes on LiveTV so it isn't like the user
would have much of a chance to rescue it if it were wanted. MythTV is a
big unique in that it doesn't have a ring-buffer, which is the typical
safeguard against these issues.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

1 2 3  View All