[mythtv] Strange scheduler bug

[Bruce Markey]

First, in all of your previous postings, you've referred to
a "flag" to mark of something as been "watched". You never
once suggested an option checkbox to indicate if this "watched"
flagging should or should not be applies. In this message, there
are several references to it as being optional. I'm not impressed
by your revisionist responses.

J. Donavan Stanley wrote:
> Bruce Markey wrote:
> 
>> J. Donavan Stanley wrote:
>>
>>>
>>>
>>> It obviously caught their interest.  This isn't Tivo with "suggestions".
>>
>>
>>
>> Huh? That didn't parse. The best I can make of it is that you
>> interpreted "interest" as in interested to add a record rule.
>> What I meant was that there is a record rule but the user
>> wasn't "interested" in the episode to the point of accessing
>> it in whatever way triggers a watched flag by the time it
>> expires.
> 
> 
> 
> If you're really not interested in EVER watching a recording, do you 
> often leave it laying around?

As a matter of fact, I don't. I said so before. When I finish
watching something, I delete it. I periodically look at old
recordings and delete the things that I realize that I will
never watch. These are things that I did intend to record at
the time but now have enough other things that I know I will
never get around to watching everything. This is by design.

You, on the other hand, claim that you don't delete things
even after you've watched then but want auto-expire to eventually
remove them for you. This makes no sense to me and I can't
believe that any sizable percentage of myth (or any DVR) users
would do this. I frankly believe you said this for the sake
of argument to justify you suggestion.

>   If you do then the watched logic for 
> expiration wouldn't be for you

Say what? That's backwards. For anyone who deletes things as
they go they would not have things auto-expired. It would only
apply to those who do leave things lying around.

You've said before that you don't delete things after you've
watched them. Now you're suggesting that things that you're not
EVER ;-) going to watch should be deleted? Am I to infer that
you have a recorded list full of things that you've finished
watching (and waiting for the system to delete them) and you
carefully look through this list to find that that you haven't
watched and delete those if you decide you will never get to
them? Thus clearing more space to store more that you've finished
with? This is madness! I can't believe that you, or anyone else
behaves this way and I sure as heck don't believe a feature
needs to be added to "help" someone who does. This just seems
contrived to try to justify your suggestion.
 
>  and you could choose not to use it.

You've never said that before.

>  On 
> the same note, you probably don't want it re-recorded either so that

How do you know that? There are valid reasons either way.

> logic would need to be disabled as well.  HOWEVER if you  normally 
> delete things your not interested in ever watching

I do.

>  The watched flag 
> could serve as a layer of protection.

Only based on the insanity above. I "protect" my unwatched shows
by deleting the shows I've watch as soon as I've finished watching
them. Things that I've watched and want to keep have the auto-
expire flag unset. Everything else is something I still may
want to see whether I've never opened the file, skipped through
it, watched a little of the beginning, watched most but haven't
finished, watched all but want to listen to a song by a singer
on a talk show again, whatever. The system cannot look at some
stat and decide for the user that one undeleted show is less
valuable to the user than another undeleted show.

Your assumption, and others in this thread, is that if the flag
is titled "watched" then that must mean that the system really
does know that the user must not want the file any longer. If the
user didn't want the file, she could delete it.

>>> A simple slider "Mark a show as watched if I've seen X% of it" gives 
>>> the user full control.  A "Mark this show as unwatched" solves the 
>>> problem of being past the threshold of "watched" but not finished 
>>> with it yet.
>>
>>
>>
>> That misses the point entirely. The assumption is that the
>> system can determine for the user that they must no longer want
>> to have this show that they didn't delete. This assumption is
>> incorrect. The rule to set this unneeded and confusing flag is
>> moot.
> 
> 
> 
> I fail to see how it's confusing.

Apparently so ;-).

>   If the user sets a slider that says 
> "After I've seen at least 90% of a show mark it as watched" then THEY

"A" there is no slider nor should there be one. "B" you've
been conveniently side-stepping how you determine this percentage
even when prompted. You just toss around percentages as if it is
a given that such a statistic exists. Well, it doesn't. You could
track the highest keyframe accessed but doesn't account for the
user looking ahead to see if the recording completed or the
show ended on time or scanning for interesting segments.
You could use a timer to see how long it is from the time
playback is entered until exited but that doesn't account for
leaving it paused for a long period of time. You cold count all
the keyframes accessed but not only is that ugly and intrusive,
it doesn't account for news or talk shows where the user may
skip through most of it but is finished watching.

So, there is no way for the system to truly determine what
percentage has been watched. There is no way to infer that the
user is done watching based such a percentage. And there is
absolutely no valid conclusion that the system can draw from
a user not deleting a file that meets whatever the criteria is.
 
> ... If the system was simply making a 
> decision based on an arbitrary hidden number someplace that would be bad 
> thing but that's never been the suggestion.

That is exactly what you've suggested and why I'm objecting.

> The idea of using the watched flag in the auto delete is that *fewer* 
> shows get deleted not more.

(again with the) Say what? If there is a 120GB disk and 140GB
has been recorded, at least 20GB had to have been deleted to
make room. The only way *fewer* ;-) things get deleted is if
either the user records fewer things or deletes more things
manually. The existence of flag does not cause there to be
less data.

>  If you've watched a show or not and you 
> don't want it auto expired then you should set it to not be 
> auto-expired.

I do. Never said otherwise and I think everyone should. You've
the one flopping back and forth on how users do or should behave
to try to find an angle to justify your suggestion.

>   The system will eventually get around to deleting it 
> regardless.

No, auto-expire will not eventually get around to deleting
things that are not marked for auto-expire. If the disk is
full and there are no files for auto-expire you are SOL. It
will not decide to start deleting files that you told it to
not delete.

>   So if your real intent is to keep it then you should 
> protect it.  By choosing watched over non-watched for purposes of 
> auto-deletion the assumption made is that if the user recorded it he 
> wanted it recorded, and if they haven't watched it yet it means they 
> haven't gotten around to it.  If that's an incorrect assumption, then 
> they can choose not to use the watched flag for auto-expire...

You never said it was an before.

This is one of several bad assumptions and users shouldn't have
to waste their time figuring out what the hell such an option
is all about when it can't really do them any good.

>>>
>>> And if a user recorded a show there's probably a reason as well.
>>
>>
>>
>> Exactly, so why should the system impose any different behavior
>> hinging on an algorithm for how much the file has been accessed?
>> That would not be any sort of clear indication of the user's
>> intent and should have no bearing on the auto-expire decision.
> 
> 
> 
> Again, this is about deleting fewer recordings not more.  The system 
> wouldn't *impose* anything, the user would *choose* to use it or not.

Again, it doesn't change the size or number of files so the
claim of deleting fewer is bogus. It would impose your set of
invalid assumptions on anyone who chose it. The user would not
understand what it does, how it works or what would actually
happen as a result of choosing such an option. They would only
base the decision on what they imagine it should be. This is
always the case when a user encounters a mysterious option.

For example, recently duplicate matching policies were added
and included an option for "If empty". In almost every case this
would be the wrong choice as it could both re-record the same
episode and also skip new episodes. I've looked at a lot of
listing over the past couple years, I've never one seen any
show that needed this option as a solution. The very first
person to post any message about duplicate matching said they
set this for every record rule. Even after the option was
removed the user still claimed he knew what he was doing ;-).


>>> It may not be typical for behavior for *you* but you can't fall into 
>>> the trap of "I think like this therefore so does everyone else".
>>
>>
>>
>> Oh, the irony. That's exactly my point. All that is needed is
>> a flag for whether to include or exclude things in oldrecorded
>> when they auto-expire so the user could decide for themselves
>> what makes sense. I was posting in favor of the user having the
>> choice rather than having a behavior imposed on them.
> 
> 
> 
> And I was proposing a suggestion that could make that more usefully and 
> put more control over the behavior.

And I believe it is not useful, is likely to do something
other than what the user intended and would only serve to
confuse users.

  With your suggestion, we'd have a 
> binary setting to either rerecord things that have been auto deleted or 
> not to.  So if a user turns on this re-record flag, they're then forced 
> to delete recordings of shows they've already watched because the system 
> re-recorded them plus have to deal with scheduling issues.

The user isn't forced to do any such thing. They are not forced
to set the flag one way or the other, they are not forced to
keep shows that they've finished but didn't delete but want the
system to delete but don't want the system to re-record if it
deleted after they watched it but didn't delete it and didn't
want to uncheck the auto-expire flag but wanted to delete shows
that they would never get to so there would be more space to
keep things longer that they've finished so that they won't
auto-expire as soon then possibly re-record.

This is all non-sense. You're willing to say anything that you
believe will make a case to justify your suggestion.

>  To me it 
> makes far more sense to only re-record things that haven't been 
> watched.  If I've watched it and I want to keep it then I'll mark it not 
> to be deleted.

But the program can not determine what has and has not been
watched. The user knows what their own habits are. And the
user is not at the mercy of auto-expire. They can delete any
show at any time and the popup gives the option of re-recording
if it appears to be something that could be an episode. If the
user (stupidly ;-) leaves thing for auto-expire to delete, it
must either be marked or not marked in odlrecorded. Since neither
choice is necessarily the correct assumption for everyone, there
should be an option for what to do in this rare case.

Right now, today, it adds things to oldrecorded when they
record and does not remove the entry when it auto-expires.
This may not be what everyone wants but it will be that way
until something changes. I think there should be a checkbox
for this.

I had seen that you've been following me around replying to
some of my earlier posts believing that you were "showing me
up" in demonstrating your brilliant counterpoint. However,
I choose in the past to not dignify this childish behavior.
Yet, you've persisted.

Your response to this simple and practical solution to an
existing situation is to say that it is inadequate because
there simply must be heuristics to determine if the user
accessed the file, and how much, and if that means they are
done, and what order things should be deleted. No. That is
all BS.

>> You saw fit to reply to my posts saying "We'd need a "watched"
>> flag for that to work well..." Well, no. There is no need for a
>> "watched" flag in order to have an option for the user to decide
>> if they want auto-expire to include things in oldrecorded. Therefore, 
>> your response to my post was, in fact, incorrect.
> 
> 
> As I said above, the binary flag would result in a lot of unwanted 
> re-recordings of shows...

No, a binary flag would result in the user having the choice
as to whether they should or shouldn't be allowed to re-record.
Your assessment that allowing re-record would result in "a lot"
is bogus. All the conditions for it to happen are pretty rare.
Stating with the user would have allow a lot of things to auto-
expire. It would have to be an episode with descriptive info
and be rebroadcast after it auto-expired, etc. It's pretty much
academic. The only reason I suggested an options is that it
currently does leave things in oldrecorded but this may not
be the behavior that everyone wants. If a user really did see
"a lot" they should learn to delete things rather then leaving
them for auto-expire and/or flip the option so that it doesn't
re-record things that auto-expire.


>>> Agreed there, if you REALLY don't want it auto deleted uncheck the 
>>> box.  But then that's not what this discussion is all about.
>>
>>
>>
>> Well, it is related in that there is a mechanism where the
>> user can clearly indicate her intentions. What concerns me is
>> the belief that if the user doesn't clearly indicate their
>> intentions then the system should use a formula to decide
>> what those intentions must be.
> 
> 
> 
> And everything I've suggested also allows the user to clearly state 
> their intentions.

And everything you've suggested can't be implemented in a way
where the user would understand what it was doing and why even
if they felt good about choosing the option.

>>> Then either 1) Allow it to record any show. 2) Set your recorded 
>>> threshold high enough that that doesn't happen 3) mark the show as 
>>> unwatched or 4) uncheck the auto delete box for it.  The general idea 
>>> of the recorded flag was to make the OPs idea a little better (i.e. 
>>> don't rerecord stuff I've already seen but feel free to record things 
>>> that get auto deleted before I get around to them).  After that the 
>>> thought occurred to me that we might be able to leverage it to allow 
>>> us to keep unwatched recordings around as long as possible.
>>
>>
>>
>> But I don't think you can make the determination of watched or
>> unwatched or what watched but undeleted means to each user. If
>> you could, it is unclear which should be kept longer.
> 
> 
> 
> Again it's up to the user to tell us that...

No idea what your response means but I'm pretty sure the user
isn't talking to both of us because in my world there is no
code that believes it knows if the user has watched something
or not.

>>> Of course the question then becomes why did you record it in the 
>>> first place?
>>
>>
>>
>> Because it was an episode in a science series that usually covers
>> more interesting subjects than botany in Borneo.
> 
> 
> So then delete it,

Oh, gimme a break! I make up an example to represent a show that
might auto-expire. You questioned my wisdom for having recorded
it in the first place. I explained that in practice, I would
delete it if it wasn't just an example. Now you're going to
advise me to delete my example? Are you insane? You're just
being argumentative for argument's sake.

>>> Then again, I don't see a need for re-recording expired shows on a 
>>> regular basis either.
>>
>>
>>
>> Right, and I can see valid reasons either way which is why I
>> suggested that this should be an option.
>>
> And yet adding a flag to add *more* control is bloat?

The flag is one byte. The logic to do something illogical is
bloat. You based this statement on the unfounded premise that
the user would have more control. The user would not understand
what was happening and why and this is really less control.

>> Bloat. More complexity for no tangible benefit but more user
>> confusion. You haven't presented any compelling reason that
>> this is necessary and haven't acknowledged that your assumptions
>> may be backwards.
> 
> 
> The exact same case can be made for the original idea.  I'm not making 
> any assumptions here.  I'm adding more control for the user.

No, it already does leave things in oldrecorded and an option
for this would be unambiguous. Adding code to try to guess why
the user still has something in the recorded list is bloat.

>>> And yet one simple flag
>>
>>
>>
>> The flag is simple, the logic is broken ;-).
> 
> 
> *sigh* I'm sorry but a flag with options to turn it on and off isn't 
> complex.

In the past, you've only referred to a watched flag and never
an option to turn this on or off. If turned on, the code to
assess what percentage has been watched and make decisions
about what to do as a result is unnecessary. The way this should
behave is not as obvious as you would like to believe and users
wouldn't understand what it's for and why it does what it does.
This is unnecessarily complex.

--  bjm