<div dir="ltr"><div><br> </div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><font size="2" color="black" face="Verdana,Arial,Helvetica"><font size="2" color="black" face="Verdana,Arial,Helvetica">Are you sure you are expiring programs by age (oldest first) and not </font></font><br>
<font size="2" color="black" face="Verdana,Arial,Helvetica"><font size="2" color="black" face="Verdana,Arial,Helvetica">priority (or a combination of the two)? </font></font></blockquote><div><br><br>Yep, the autoexpire method is set to "Oldest Show First", plus the NASCAR recordings have a higher priority than almost any other recording (which is why I am getting so much flack over it). <br>
<br>It looks like the issue lies with the Storage Groups, it appears it is expiring things as fast as it can from the 200 GB local disk and very rarely recording anything to the 1.1 TB remote disk (or the 200 GB remote disk). Digging deeper into Storage Groups, I discovered that the code does not try to balance disk space, the purpose of Storage Groups is to manage disk I/O. When the feature was first implemented there was a lot of talk about how it would make LVM and RAIDs obsolete [even the Myth documentation says this] for Myth systems but that is not at all what it is for -- it appears that if you want your recordings to be evenly spread across your disks (and not immediately deleted) you still need to concatenate your disks using traditional methods. I sure wish I knew this before storage groups effectively turned my 1.5 TB system into a 200 GB system and deleted all my new recordings.<br>
<br>In my opinion, Myth should prefer to record to the disk that has free space or can create free space by autoexpiring the first item (or at least something in the top n items) on the autoexpire list. It makes no sense to automatically delete brand new recordings when there are so many older recordings just because a certain disk is coming up with a higher SG priority number. <br>
<br>For the time being I think I should be able to work around the issue using the [undocumented...of course!] SGweightPerDir setting. This won't eliminate the problem, but at least I can force Myth to record to my big disk rather than only using 200 GB. I certainly can't be the only person that uses a combination of local and remote disks for Myth, I am a little suprised that I haven't seen this issue discussed on the list before.<br>
</div></div>