<div dir="ltr"><div class="gmail_quote">On Tue, Aug 26, 2008 at 4:38 PM, Yeechang Lee <span dir="ltr"><<a href="mailto:ylee@pobox.com">ylee@pobox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">Kevin Kuphal <<a href="mailto:kkuphal@gmail.com">kkuphal@gmail.com</a>> says:<br></div>
<div class="Ih2E3d">> I personally would not want remote storage equally weighted with<br>> local because of the potential I/O issues with network recordings,<br>> commflagging, and the like. The previously mentioned database<br>
> setting laid out in the wiki from the original coder does provide<br>> the advanced user this means of making his/her system weigh local<br>> and remote identically so that a tie situation does occur in which<br>
> case free space will be the determining factor.<br>><br>> Seems to me that Myth, once again, has set reasonable defaults for<br>> the average system and provides a way for advanced users to tweak it<br>> to their liking.<br>
<br></div>I am pleased that the requisite setting are available for tweaking. I<br>very much disagree that the default weighting is "reasonable . . . for<br>the average system," for the reasons I laid out in my previous<br>
message.<br><br>An advanced user who is concerned about remote I/O issues should have<br>the onus of tweaking things so that programs are expired in a way that<br>contradicts the AutoExpire List. Not the "average" MythTV user who<br>
knows enough to set up an NFS or Samba mount or two and then is<br>mystified, as the original poster was, that the AutoExpire list and<br>the priorities he has carefully set for his recordings aren't being<br>followed.</blockquote>
<div> </div>
<div>Storage Groups define where recordings are recorded. I have not looked into it in detail, but I am not going to make the possibly erroneous assumption that Storage Groups have anything to do with AutoExpiration beyond choosing which drive a recording is made on. It makes sense to me from a coding standpoint that there would be no reason for a Storage Group to need to know about autoexpiration and that autoexpiration is only concerned with making free space on the drive on which space is not available. Since this is always the local drive for a single recording scenario as outlined by the OP, autoexpiration only expires local recordings until such time that additoinal recordings are made on remote drives requiring expiration on them.</div>
<div> </div>
<div>I would agree that the autoexpire list could be improved to take this into account when displaying the list of shows eligable for expiration but at first blush, it seems that it would have to take into account the current recording schedule in order to make such determinations and while possible, again falls into a feature request area. </div>
<div> </div>
<div>Kevin</div></div></div>