[mythtv-users] Myth autoexpiring brand new shows

Enigma enigma at thedonnerparty.com
Wed Aug 27 01:28:43 UTC 2008


There are a lot of messages to which I need to to reply, for the sake of
brevity I will attempt to do it in one post.  I hope I get all the
attributions correct.

Let me start off by saying that yes, this perceived issue was caused by an
incorrect assumption on my part.  I had assumed Myth used SDs in a
round-robin fashion, rather than using a weighting system.  This caused my
shows to expire in an order that was unintuitive - the deletion was out of
order with the auto-expire list.



dean.harding wrote:

Well, if all the disks were local I think it would work like you wanted
> it to. You might be able to set the SGweightLocalStarting setting to 0
> so that local and remote storage groups have the same starting weight,
> but I say that not having looked at the code, and only from reading what
> I found on http://www.mythtv.org/wiki/index.php/Storage_Groups_Weighting
>
> Dean.



Thanks for the informative reply Dean.  As I wrote above, this was a
misunderstanding on my part about how Myth chooses the target directory.
Now that I am aware it is biased against remote filesystems I should be able
to create weights that force the behavoir I desire.  This is the primary
reason I use MythTV, it is infinitely configurable - all the way down the
the code if I want to.


mtdean wrote:

> If you read my original post, I mention that there are hundreds of
> > items on the auto-expire list that precede the recordings in
> > question. My auto expire is set to only consider age. My issue is
> > that they are not being expired in this order.
>
> They sure are. You're forgetting about the fact that the "hundreds" of
> items on the auto-expire list that precede the recordings in question
> are on other filesystems (where deleting them would be a waste, as it
> would mean hundreds of recordings must be deleted before a deletion
> actually makes space available for the new recording). If you would
> prefer that Myth deletes all of those, too, let me know and I'll make a
> patch specifically for you.
>


No, I'm not forgetting that fact.  I am just saying that I would prefer that
Myth record to the disk that has shows that have a high deletion priority,
rather than the disk that only has shows with a very low deletion priority.
Trying to suggest that I am proposing changes to Myth that would delete
recordings on a different file system than the desired target is just a
strawman.  In fact, it sounds like Chris already thought of doing it this
way since he wrote about doing it:

" If all filesystems are full and
something will end up expiring or deleting when create a new recording,
then we should choose the filesystem with the first expirable/deletable
recording rather than chosing a filesystem based on the lowest weight. "

(from the link you supplied upthread,
http://www.gossamer-threads.com/lists/mythtv/users/297293#297293)




mtdean wrote:

> Surely you can see the difference between wanting my oldest programs
> > to expire and having recent programs expire instead. I never said I
> > didn't want these programs to expire, I just don't want them to
> > expire before their time. Your remark adds nothing to the
> > conversation and is counter-productive.
>
>
> Surely you would prefer to figure it out for yourself than get help from
> knowledgeable people on the list--at least that's the only reason I can
> think of for you to insult a person who was trying to help (and, who
> happens to be a MythTV dev who knows MythTV very well).


Saying the remark was not adding to the conversation was not intended as an
insult, it was just stating a fact.  If I offended anybody in my post I
apologise.

Yes, one of the reasons I posted to the list was to obtain feedback from
people who know how this area of Myth works.  However, the post in question
did not answer or even attempt to answer the questions I put forth.  He may
be knowledgeable, but he made no attempt to share that knowledge.

I would have much preferred a simple 2 word "google SGweightLocalStarting"
reply to something that seeks to offer no help.


> But, in case I'm wrong about your wanting to figure it out for yourself,
> I'll mention that one potential approach for "fixing" this issue was
> provided in this thread and it all comes down to a misconfiguration of
> your system.
>

Why be oblique about it?  If my system is misconfigured and you know in what
way, why not say it?  Why withhold the knowledge?


mtdean wrote:

> He clearly stated that the Recording
> > Groups are not working 'as advertised.'
>
> False advertising by random wikis/posts/blogs on the 'net are not our
> fault. He needs to read the official advertising.
> http://mythtv.org/docs/mythtv-HOWTO-9.html#storagegroups
>
> Oh, and yes, people should read /and/ understand it (versus skimming it
> and picking random quotes to use to back up their false understanding
> while ignoring those points that contradict their understanding).
>

While you may view it as cherry picking quotes, when the first sentence in
the documentation introduction states that SGs give you "a flexible way to
allow you to add capacity to your MythTV system" it would imply that the
primary goal of SGs is to add capacity.  Nowhere in the introduction does it
make any mention of disk I/O.  This is the portion of the SG documentation
that describes what SGs are and what they do, the rest of the documentation
of SGs deal with setup, configuration and migration (yes, I have read it
completely).  As I said above, I made an incorrect assumption and now have
more complete information.  I don't think it was an unreasonable assumption
considering there is nothing in the UI to set weights or even a reference to
weighting and my autoexpire is set to "Oldest Show First", but it was
incorrect nontheless.



>
> > It was my impression that when
> > you added 2 or 3 filesystems to a storage group, it would ensure that
> > it recorded to the filesystem with the most free space (within that
> > group) regardless of local/remote filesystem.
>
> Like I said, read the documentation.
>
>
It is illogical to assume that every user of every piece of software will
read all the documentation on the software.  Mike, you use Linux, have you
really read all the documentation on Linux?  I use Firefox every day and I
have read very little of the documentation, I would imagine most users would
say the same.  I know RTFM is a popular response (and in fact, it is how I
came to understand why the issue is occuring), I asked the question in order
to ascertain what part of the FM I needed to read.  While the documentation
does a good job of describing how the weighting system works, it doesn't
have anything on the SG options that I need to use to achieve my desired
behavior, so I don't think a response that is soley RTFM works here.


kkuphal wrote:

A suggestion to fix this
> particular issue it was not, but simply a suggestion on how the situation
> could be avoid while a solution is determined.


It didn't seem to be presented as an interim solution, it sounded more like
"if you don't like our town then you should move" when I am just attempting
to find out how the town government works.


> Either way, his was an
> unnecessary response to his request for help.
>

Certainly true.  As I said above, I apologise if I offended you.


And I've learned from enough
> troubleshooting in my day never to assume that someone understands the
> issue
> better than what I've confirmed through some troubleshooting steps


A good policy (although I did describe myself as a "long time Myth user"
with an extensive system in the original post, wouldn't hurt to assume a
know a LITTLE bit about how it works)


The previously mentioned database setting laid out in the
> wiki from the original coder does provide the advanced user this means of
> making his/her system weigh local and remote identically so that a tie
> situation does occur in which case free space will be the determining
> factor.
>
> Seems to me that Myth, once again, has set reasonable defaults for the
> average system and provides a way for advanced users to tweak it to their
> liking.
>


Certainly true.  Great job Myth (and Chris)!



ylee wrote:

There is a
> simple solution (if I understand the weightings right): Set
> SGweightLocalStarting to 0 by default.
>


I am not sure that will alleviate the issue unless all the disks are the
same size.  If I understand the weighting right (which I obviously didn't at
the first of this thread, so take this all with a grain of salt) setting my
SGlocalStartingWeight to 0 should alleviate the symptoms, but not eliminate
the issue.  It should cause it to round-robin the recordings but since one
of my disks is much bigger than the other 2, that disk will still retain
much older recordings than the other 2 disks.  Since one of my disks is 1.1
TB and the others are 200 GB, I would have to set the weighting so it
records 5.5x more shows (in size) to the big disk in order to balance the
auto-expiring.  It should be the same if you have different drive sizes
locally, Myth will (should?) be expiring more recent recordings on your
smaller drive than it is on your bigger drive.



I want to thank everybody who posted, I'm quite happy that Myth allows me to
configure my system exactly the way I want it.  Sometimes it adds to the
complexity to the point where I need to do some deep studying to find out
how to do what I want to do, but it more than makes up for it in its
flexibility.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20080826/780fa684/attachment-0001.htm 


More information about the mythtv-users mailing list