Mailing List Archive

On Aug 25, 2008, at 3:46 PM, Enigma wrote:

> Today, I have a very irate and panicky roommate who has just
> discovered that the NASCAR race from last weekend has already been
> deleted. Checking the system, I notice that all the NASCAR races
> have been deleted. Upon checking the logs, I discovered that MythTV
> had autoexpired them, along with many other recordings that had very
> recently been made. Checking the autoexpire list, there are
> hundreds of items that are available to be expired that are much
> older than the items that were expired. For an example of the
> logfile when expiring:

Are you sure you are expiring programs by age (oldest first) and not
priority (or a combination of the two)?

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Mon, Aug 25, 2008 at 5:46 PM, Enigma <enigma@thedonnerparty.com> wrote:

> Longtime Myth user, I have a 3 frontend/ 1 FE-BE/ 1 backend Myth 0.21
> network. I have ~1.4 TB of storage, on 4 separate mount points:
>
>
> - MythTV Drive #1:
> - Directories: burns:/home/share/MYTH/db_backups,
> burns:/home/share/video, coilette:/home/share/video
> - Total Space: 1,102,486 MB
> - Space Used: 1,077,288 MB
> - Space Free: 25,197 MB
> - MythTV Drive #2:
> - Directory: burns:/mnt/disk1
> - Total Space: 187,785 MB
> - Space Used: 162,972 MB
> - Space Free: 24,812 MB
> - MythTV Drive #3:
> - Directory: burns:/mnt/disk2
> - Total Space: 20,399 MB
> - Space Used: 379 MB
> - Space Free: 20,019 MB
> - MythTV Drive #4:
> - Directory: burns:/mnt/disk3
> - Total Space: 183,933 MB
> - Space Used: 153,203 MB
> - Space Free: 30,730 MB
> - Total Disk Space:
> - Total Space: 1,494,604 MB
> - Space Used: 1,393,844 MB
> - Space Free: 100,759 MB
>
>
> Drive #3 is configured as a LiveTV drive, the rest are all in the default
> storage group.
>
> Today, I have a very irate and panicky roommate who has just discovered
> that the NASCAR race from last weekend has already been deleted. Checking
> the system, I notice that all the NASCAR races have been deleted. Upon
> checking the logs, I discovered that MythTV had autoexpired them, along with
> many other recordings that had very recently been made. Checking the
> autoexpire list, there are hundreds of items that are available to be
> expired that are much older than the items that were expired. For an
> example of the logfile when expiring:
>
> 2008-08-25 05:06:24.954 Scheduled 789 items in 14.3 = 0.00 match + 14.31
> place
> 2008-08-25 05:15:50.998 AutoExpire: CalcParams(): Max required Free Space:
> 22.0 GB w/freq: 10 min
> 2008-08-25 05:15:51.579 Expiring 1320 MBytes for 4849 @ Sat Aug 23 14:00:00
> 2008 => Mega Disasters "Dam Break"
> 2008-08-25 05:15:51.670 Reschedule requested for id 0.
> 2008-08-25 05:16:14.024 Scheduled 789 items in 22.3 = 0.00 match + 22.29
> place
> 2008-08-25 05:16:14.032 Reschedule requested for id 0.
> 2008-08-25 05:16:31.271 Scheduled 789 items in 17.2 = 0.00 match + 17.18
> place
> 2008-08-25 05:21:26.398 UPnpMedia: BuildMediaMap - no VideoStartupDir set,
> skipping scan.
> 2008-08-25 05:25:52.104 AutoExpire: CalcParams(): Max required Free Space:
> 22.0 GB w/freq: 10 min
> 2008-08-25 05:25:52.727 Expiring 1455 MBytes for 4849 @ Sat Aug 23 15:00:00
> 2008 => Modern Marvels "Wheat"
> 2008-08-25 05:25:52.864 Reschedule requested for id 0.
> 2008-08-25 05:26:14.276 Scheduled 789 items in 21.4 = 0.00 match + 21.37
> place
> 2008-08-25 05:26:14.311 Reschedule requested for id 0.
> 2008-08-25 05:26:31.055 Scheduled 789 items in 16.7 = 0.00 match + 16.70
> place
> 2008-08-25 05:35:53.233 AutoExpire: CalcParams(): Max required Free Space:
> 22.0 GB w/freq: 10 min
> 2008-08-25 05:45:54.281 AutoExpire: CalcParams(): Max required Free Space:
> 22.0 GB w/freq: 10 min
> 2008-08-25 05:45:54.824 Expiring 1481 MBytes for 4849 @ Sat Aug 23 16:00:00
> 2008 => Modern Marvels "Coin Operated"
> 2008-08-25 05:45:55.004 Reschedule requested for id 0.
> 2008-08-25 05:46:15.576 Scheduled 789 items in 20.5 = 0.00 match + 20.50
> place
> 2008-08-25 05:46:15.584 Reschedule requested for id 0.
> 2008-08-25 05:46:31.863 Scheduled 789 items in 16.2 = 0.00 match + 16.22
> place
> 2008-08-25 05:51:31.447 UPnpMedia: BuildMediaMap - no VideoStartupDir set,
> skipping scan.
> 2008-08-25 05:55:55.336 AutoExpire: CalcParams(): Max required Free Space:
> 22.0 GB w/freq: 10 min
> 2008-08-25 05:55:55.891 Expiring 3135 MBytes for 1051 @ Sat Aug 23 17:00:00
> 2008 => NASCAR Countdown
> 2008-08-25 05:55:55.994 Reschedule requested for id 0.
> 2008-08-25 05:56:20.219 Scheduled 789 items in 24.2 = 0.00 match + 24.16
> place
> 2008-08-25 05:56:20.228 Reschedule requested for id 0.
> 2008-08-25 05:56:36.972 Scheduled 789 items in 16.7 = 0.00 match + 16.67
> place
>
>
> As you can see, Myth is autoexpiring programs that were recorded just 2
> days earlier.
>
>
> So my questions are:
>
> #1 Is there any way to determine why these programs were autoexpired
> earlier than hundreds of other eligible programs? (like 550 GB of Olympics?)
>
> #2 How the hell can I keep it from happening again?
>

I think a good question to answer is why, within the space of 30 minutes, is
enough disk space being taken up on that drive that you are bumping against
the 22GB reserve 4 times (roughly once every ten minutes). MythTV will show
you what it is considering for auto-expiration and in what order on the
System Status screen in the Frontend. This can be age, priority, or other
combinations. But obviously something is consuming the disk space so Myth
does what it is told and makes space available.

Also, if you don't want stuff to expire, don't mark it for expiration.

Kevin

> Are you sure you are expiring programs by age (oldest first) and not
> priority (or a combination of the two)?



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).

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.

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.

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.

Enigma wrote:
> 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.

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.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Kevin wrote:

I think a good question to answer is why, within the space of 30 minutes, is
>
> enough disk space being taken up on that drive that you are bumping against
>
> the 22GB reserve 4 times (roughly once every ten minutes).


Obviously, because there are recordings happening.


> MythTV will show
> you what it is considering for auto-expiration and in what order on the
> System Status screen in the Frontend.
>

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.


Also, if you don't want stuff to expire, don't mark it for expiration.


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.

On 08/26/2008 02:10 AM, Enigma wrote:

> Kevin wrote:
>
> > I think a good question to answer is why, within the space of 30
> > minutes, is enough disk space being taken up on that drive that you
> > are bumping against the 22GB reserve 4 times (roughly once every
> > ten minutes).
>
> Obviously, because there are recordings happening.
>
> > MythTV will show you what it is considering for auto-expiration and
> > in what order on the System Status screen in the Frontend.
>
> 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.

> > Also, if you don't want stuff to expire, don't mark it for
> > expiration.
>
> 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).

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.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Mon, Aug 25, 2008 at 11:31 PM, Michael T. Dean
<mtdean@thirdcontact.com> wrote:
> On 08/26/2008 02:10 AM, Enigma wrote:
>
>> Kevin wrote:
>>
>> > I think a good question to answer is why, within the space of 30
>> > minutes, is enough disk space being taken up on that drive that you
>> > are bumping against the 22GB reserve 4 times (roughly once every
>> > ten minutes).
>>
>> Obviously, because there are recordings happening.
>>
>> > MythTV will show you what it is considering for auto-expiration and
>> > in what order on the System Status screen in the Frontend.
>>
>> 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.

This is somewhat trite, isn't it? He clearly stated that the Recording
Groups are not working 'as advertised.' 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. Therefore, those
hundreds of items might *not* be on the filesystem in question, but if
they are in the same recording group, then shouldn't they have expired
to make space? More importantly though, shouldn't the recording have
defaulted to the filesystem that is clearly huge and empty (within the
same group)?

>
>> > Also, if you don't want stuff to expire, don't mark it for
>> > expiration.
>>
>> 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).

I have lots of things I don't want to expire the next day, but don't
intend to keep for months. Should I also not set these to expire? I
was again, under the impression, that mythtv was supposed to be
intelligent enough to know, "I have these three filesystems in my
recording group A, and this show is set to be recorded in group A.
Local filesystems 1 and 2 are both full, so lets try remote filesystem
1. Look, there's room. I guess I don't need to expire anything!" If
this is not how it works, then it needs to be documented better, and
developers need to stop telling people that's how it works.

I, of course, also don't see how stating that a remark is
counter-productive and adds nothing to the conversation would be
considered an insult.

>
> 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.

And I must have missed that potential approach... unless of course it
was to set things to not expire, in which case, I don't feel that is a
solution at all.

~Jon
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Jonny B wrote:
> This is somewhat trite, isn't it? He clearly stated that the Recording
> Groups are not working 'as advertised.' 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. Therefore, those
> hundreds of items might *not* be on the filesystem in question, but if
> they are in the same recording group, then shouldn't they have expired
> to make space? More importantly though, shouldn't the recording have
> defaulted to the filesystem that is clearly huge and empty (within the
> same group)?

I think this is a case where the default settings are never going to be
able to please everybody. People asked, during the development of
storage groups, to make it so that remote filesystems are chosen as a
"last resort" -- only if the local filesystems fill up.

Clearly, there are people who want it to work the other way: filesystems
to be given an equal weighting regardless of whether they're local or
remote.

So there's no one setting that will please both groups of people...

As I said before, I've only read the
http://www.mythtv.org/wiki/index.php/Storage_Groups_Weighting page in
the wiki, but from what I understand of that page, if you set the
initial weighting to be the same for local vs. remote (i.e. set
SGweightLocalStarting to 0) then it should work as you describe.

I would agree that a "Prefer local filesystems over remote filesystems"
option in the settings page might be a good idea (which just controls
the SGweightLocalStarting setting). Heck, such an option may already
exist, as I said, I've never looked into it.

Dean.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Tue, Aug 26, 2008 at 12:47 AM, Dean Harding
<dean.harding@dload.com.au> wrote:
> Jonny B wrote:
>> This is somewhat trite, isn't it? He clearly stated that the Recording
>> Groups are not working 'as advertised.' 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. Therefore, those
>> hundreds of items might *not* be on the filesystem in question, but if
>> they are in the same recording group, then shouldn't they have expired
>> to make space? More importantly though, shouldn't the recording have
>> defaulted to the filesystem that is clearly huge and empty (within the
>> same group)?
>
> I think this is a case where the default settings are never going to be
> able to please everybody. People asked, during the development of
> storage groups, to make it so that remote filesystems are chosen as a
> "last resort" -- only if the local filesystems fill up.

I understand that. That's fine. But. When the local filesystems fill
up. Shouldn't the storage groups function use the remote filesystem
BEFORE deleting *ehem* expiring shows on the local filesystems? This
is just a logical conclusion on my behalf.

> Clearly, there are people who want it to work the other way: filesystems
> to be given an equal weighting regardless of whether they're local or
> remote.

That's not specifically what I'm saying. I don't care which filesystem
it picks first so much as I care that it uses my ENTIRE recording
group before it starts erasing recordings that I may or may not be
ready to have erased. If I've ensured that my recording group has 1tb
free, it shouldn't matter if it's local, remote, or both. It shold use
that entire (up to whatever limit I've set) group before it starts
expiring stuff.

> So there's no one setting that will please both groups of people...

I think my above suggestion would go a long way towards doing such.

> As I said before, I've only read the
> http://www.mythtv.org/wiki/index.php/Storage_Groups_Weighting page in
> the wiki, but from what I understand of that page, if you set the
> initial weighting to be the same for local vs. remote (i.e. set
> SGweightLocalStarting to 0) then it should work as you describe.

Well, according the that link, once the local filesystem fills up, it
should go to the remote filesystem anyway, before expiring shows on
the local filesystem. Unless I read it wrong (happens). This, it
appears (at least in Enigmas case), is not happening.

So then the question becomes - how do you make it prefer the local
filesystem (which it does) unless it's full and then start using the
remote filesystem instead of deleting stuff? This is going to be
especially important to me, as I intend to add some 500gb drives to a
fileserver in a few weeks, and they are not going to be local to my
master myth box, which currently has only a single 200gb drive for
recordings.

~Jon
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Michael T. Dean <mtdean@thirdcontact.com> says:
> > 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).

The last sentence is a non sequitur.

I'm firmly on Jonny B and Enigma's side. Michael, you and Kevin are
both flat-out wrong on this issue. I'm very surprised that Kevin would
miss this, as he is normally very on-target.

> 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.

The above is, as far as I can tell, completely wrong. There is no
evidence whatsoever that Enigma's storage group is misconfigured.

I noticed the issue Enigma reported months ago, right after moving to
0.21 and creating a single storage group encompassing three
recording directories over two backends: Recordings were being
auto-deleted (sometimes almost immediately after beng recorded) even
when dozens or hundreds of gigabytes of recordings elsewhere within
the storage group should've been deleted first (based on their
priorities or because they were in the Deleted recording group), as
clearly indicated in the AutoExpire List. I never filed a ticket
because, I figured, such an egregious issue would surely be fixed
ASAP, right? After all, the wiki documentation
(<URL:http://www.mythtv.org/wiki/index.php/Storage_Groups>) and the
official documentation it quotes
(<URL:http://www.mythtv.org/docs/mythtv-HOWTO-9.html#storagegroups>
both say that:

MythTV will balance concurrent recordings across the available
directories in a Storage Group in order to spread out the file I/O
load. MythTV will prefer filesystems that are local to the backend
over filesystems that are remote until the local filesystem has 2
concurrent recordings active or other equivalent I/O, then the
next recording will go to the remote filesystem. The balancing
method is based purely on I/O, Myth does not try to balance out
disk space unless a filesystem is too low on free disk space in
which case it will not be used except as a last resort.

I read the above as saying that while MythTV normally chooses which
directory to store a directory in based on a) local over remote and b)
I/O balance, it would use c) free space as the governing criteria if
the directories a) and b) suggested were out of room. As this thread
demonstrates, other people interpreted this paragraph the exact same
way.

I did obliquely bring the issue up in June
(<URL:http://www.gossamer-threads.com/lists/mythtv/users/337981#337981>);
in retrospect I should have pressed the question further. And then
today I read this thread and feel very, very naive.

As Jonny B wrote:
> Shouldn't the storage groups function use the remote filesystem
> BEFORE deleting *ehem* expiring shows on the local filesystems? This
> is just a logical conclusion on my behalf.

[...]

> > Clearly, there are people who want it to work the other way:
> > filesystems to be given an equal weighting regardless of whether
> > they're local or remote.
>
> That's not specifically what I'm saying. I don't care which
> filesystem it picks first so much as I care that it uses my ENTIRE
> recording group before it starts erasing recordings that I may or
> may not be ready to have erased. If I've ensured that my recording
> group has 1tb free, it shouldn't matter if it's local, remote, or
> both. It shold use that entire (up to whatever limit I've set) group
> before it starts expiring stuff.

Amen and amen.

--
Frontend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Tue, Aug 26, 2008 at 4:50 AM, Yeechang Lee <ylee@pobox.com> wrote:

> Michael T. Dean <mtdean@thirdcontact.com> says:
> > > 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).
>
> The last sentence is a non sequitur.
>
> I'm firmly on Jonny B and Enigma's side. Michael, you and Kevin are
> both flat-out wrong on this issue. I'm very surprised that Kevin would
> miss this, as he is normally very on-target.


Thank you, but I was certainly starting this diagnosis from the most basic
position confirming that auto-expiration was set up properly, that items on
the list were expiring in order, etc. From his further information in his
rather insulting and condescending response, it is clear that those items
are configured and the issue is with remote filesystems (which I don't use
so haven't experienced much).

>
>
> > 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.
>
> The above is, as far as I can tell, completely wrong. There is no
> evidence whatsoever that Enigma's storage group is misconfigured.
>
> I noticed the issue Enigma reported months ago, right after moving to
> 0.21 and creating a single storage group encompassing three
> recording directories over two backends: Recordings were being
> auto-deleted (sometimes almost immediately after beng recorded) even
> when dozens or hundreds of gigabytes of recordings elsewhere within
> the storage group should've been deleted first (based on their
> priorities or because they were in the Deleted recording group), as
> clearly indicated in the AutoExpire List. I never filed a ticket
> because, I figured, such an egregious issue would surely be fixed
> ASAP, right? After all, the wiki documentation
> (<URL:http://www.mythtv.org/wiki/index.php/Storage_Groups>) and the
> official documentation it quotes
> (<URL:http://www.mythtv.org/docs/mythtv-HOWTO-9.html#storagegroups>
> both say that:
>
> MythTV will balance concurrent recordings across the available
> directories in a Storage Group in order to spread out the file I/O
> load. MythTV will prefer filesystems that are local to the backend
> over filesystems that are remote until the local filesystem has 2
> concurrent recordings active or other equivalent I/O, then the
> next recording will go to the remote filesystem. The balancing
> method is based purely on I/O, Myth does not try to balance out
> disk space unless a filesystem is too low on free disk space in
> which case it will not be used except as a last resort.
>
> I read the above as saying that while MythTV normally chooses which
> directory to store a directory in based on a) local over remote and b)
> I/O balance, it would use c) free space as the governing criteria if
> the directories a) and b) suggested were out of room. As this thread
> demonstrates, other people interpreted this paragraph the exact same
> way.


From the OP, it appears without further information that he had a single
recording going at the time of the expiration. In the case of a single
recording on what we can assume are all full partitions (each one has about
the same amount of free space indicating to me that they are all at
capacity), then Myth, based on the Wiki quote, will use the local disk first
for the next recording (remember, Storage Groups only dictate where a
recording will be stored, not what will be expired). As a result of local
disk being chosen, local programs are being expired.

Seems simple enough to me and exactly as described. I would guess he could
test this by running multiple recordings and seeing that they probably get
spread to non-local disk after the first or second recording and the
resulting expirations take place. I think the suggestion of changing the
local weighting is the best and documented solution.

Kevin

On 08/26/2008 03:31 AM, Jonny B wrote:
> On Mon, Aug 25, 2008 at 11:31 PM, Michael T. Dean wrote:
>
>> On 08/26/2008 02:10 AM, Enigma wrote:
>>> Kevin wrote:
>>>> I think a good question to answer is why, within the space of 30
>>>> minutes, is enough disk space being taken up on that drive that you
>>>> are bumping against the 22GB reserve 4 times (roughly once every
>>>> ten minutes).
>>> Obviously, because there are recordings happening.
>>>> MythTV will show you what it is considering for auto-expiration and
>>>> in what order on the System Status screen in the Frontend.
>>>>
>>> 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.
> This is somewhat trite, isn't it?

IMHO, no more so than the OP's dismissal of a perfectly valid response
from a very knowledgeable person.

> 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).

> 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.

> Therefore, those
> hundreds of items might *not* be on the filesystem in question, but if
> they are in the same recording group, then shouldn't they have expired
> to make space? More importantly though, shouldn't the recording have
> defaulted to the filesystem that is clearly huge and empty (within the
> same group)?

Free space is not considered when choosing a drive/directory to use for
the recording /unless/ there's a tie in the weighted determination stage.

>>>> Also, if you don't want stuff to expire, don't mark it for
>>>> expiration.
>>>>
>>> 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).
>>
> I have lots of things I don't want to expire the next day, but don't
> intend to keep for months. Should I also not set these to expire? I
> was again, under the impression, that mythtv was supposed to be
> intelligent enough to know, "I have these three filesystems in my
> recording group A, and this show is set to be recorded in group A.
> Local filesystems 1 and 2 are both full, so lets try remote filesystem
> 1. Look, there's room. I guess I don't need to expire anything!" If
> this is not how it works, then it needs to be documented better, and
> developers need to stop telling people that's how it works.
>
> I, of course, also don't see how stating that a remark is
> counter-productive and adds nothing to the conversation would be
> considered an insult.
>
>
>> 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.
> And I must have missed that potential approach... unless of course it
> was to set things to not expire, in which case, I don't feel that is a
> solution at all.

It's not the don't use autoexpire thing.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On 08/26/2008 04:05 AM, Jonny B wrote:
> So then the question becomes - how do you make it prefer the local
> filesystem (which it does) unless it's full and then start using the
> remote filesystem instead of deleting stuff? This is going to be
> especially important to me, as I intend to add some 500gb drives to a
> fileserver in a few weeks, and they are not going to be local to my
> master myth box, which currently has only a single 200gb drive for
> recordings.

cp/rm (no, not Content Protection for Recordable Media) or plain old mv

Wait, you mean it's not automatic... I guess someone should write a
script which can be executed either through a user job or through cron
and call it myth_archive_job.pl .

Note, also, that Chris Pinkham (author of Storage Groups) has said
/many/ times that he had originally planned to write code to
automatically balance filesystem usage across discs (and allow users to
decide to move recordings from one storage group to another or from one
SG directory to another through the GUI), but once he completed the
initial storage groups code, it worked so well that he found that he had
no need for the additional code (plus he's been very busy with other
non-Myth stuff in his life), so he never coded it. He also explained
how easy it would be for someone to write this code and gave pointers.

http://www.gossamer-threads.com/lists/mythtv/users/297293#297293 among them.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Kevin Kuphal <kkuphal@gmail.com> says:
> From his further information in his rather insulting and
> condescending response,

I'm sorry you took it that way, but put yourself in his shoes. He
asked why programs are being autoexpired that shouldn't be (at least
according to his, and my, and others' understanding) and you told him
"Well, don't mark those programs to be expired." It's the equivalent
of the old joke:

"Doctor, doctor, it hurts when I do this!"
"Well, then, don't do that."

especially when his messages make it clear he understands the issue
much better than that. You are normally on target (if curt, but the
latter is OK with the former), but I am afraid you were the
condescending one in this particular exchange.

> it is clear that those items are configured and the issue is with
> remote filesystems (which I don't use so haven't experienced much).

Ah, the reason why things are the way they are becomes clear.

> From the OP, it appears without further information that he had a
> single recording going at the time of the expiration. In the case
> of a single recording on what we can assume are all full partitions
> (each one has about the same amount of free space indicating to me
> that they are all at capacity), then Myth, based on the Wiki quote,
> will use the local disk first for the next recording (remember,
> Storage Groups only dictate where a recording will be stored, not
> what will be expired). As a result of local disk being chosen,
> local programs are being expired.

This is both illogical and nonsensical. It is illogical because the "a
last resort" clause indicates (to me, Enigma, and others, at least)
that free space indeed will be used as the final determinant *if
necessary*, while you are saying--if I read you right--that this
doesn't trigger unless "at least two concurrent recordings [are]
active or other equivalent I/O." If this is the case, the
documentation is very very very much not clear.

Regardless of the proper reading, it is nonsensical because *it
defeats the whole stated purpose of storage groups*. Right off the bat
in the documentation, in 9.1
(<URL:http://www.mythtv.org/docs/mythtv-HOWTO-9.html#storagegroups>),
we are told that

Storage Groups are lists of directories that are used to hold
MythTV recording files giving you a flexible way to allow you to
add capacity to your MythTV system without having to use exotic
solutions such as LVM, filesystem expansion or RAID Online
Capacity Expansion.

To any MythTV users sophisticated enough to know what LVM and RAID
are, the meaning is clear: A storage group lets a MythTV system use
multiple directories as if they were one. Period.

This unambiguous reading is supported wthin MythTV itself. Where,
within MythTV itself (minus plugins like MythVideo), is the concept of
drive directories ever used? I can't think of a single place. The
AutoExpire List does not distinguish between local and remote
recordings; on the contrary, its single, sorted-by-priorities list
reinforces the notion that all directories within a single storage
group are treated as equals for the sake of picking which recordings
to expire first. The Program Details screen explicitly omits
mentioning what directory that recording is in, only displaying the
truncated filename itself. Recording Options|Storage Options only
mentions storage groups, not directories within groups. Etc., etc.

Another sentence from the MythTV documentation, further down:

Or, say that you originally installed MythTV to a 80GB hard drive,
and that hard drive is now filling up. You could simply add a new
drive to your system, mount it and update the Storage Group to add
additional space.

The meaning is again unambiguous: Add a nice new empty drive to your
MythTV setup's storage group and MythTV will intelligently start using
it to store recordings in. We are now learning that the words
". . . if the drive is local, not remote" are missing. In any case, if
the documentation's only words

The current load-balancing preferences (in order) are:

* Local filesystems over remote
* Less-busy (less weight) over more-busy (more weight)
* More Free Space over Less Free Space

were truly followed it wouldn't be an issue because the system would
properly use free space as final determinant if the earlier criteria
aren't valid, but they're not and so it is.

> I think the suggestion of changing the local weighting is the best
> and documented solution.

I agree that this is the best solution for the time being. I disagree
that it is documented; the official documentation mentions some of the
weights but doesn't discuss how to change them and the key
SGweightLocalStarting weight is omitted anyway. More importantly, I
vigorously disagree that this state of affairs should remain the
out-of-the-box status quo.

In conclusion: Equality for all directories, regardless of location!

--
Frontend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Michael T. Dean <mtdean@thirdcontact.com> says:
> 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).

[...]

> Like I said, read the documentation.

Read Mike's words above. Then consider that

> Free space is not considered when choosing a drive/directory to use for
> the recording /unless/ there's a tie in the weighted determination stage.

the key words "a tie" *only* appear in
<URL:http://www.mythtv.org/wiki/index.php/Storage_Groups_Weighting> (a
quote from a Chris Pinkham message to mythtv-users), and not anywhere
in
<URL:http://www.mythtv.org/docs/mythtv-HOWTO-9.html#storagegroups>).

"Ignoring those points that contradict their understanding," indeed.

--
Frontend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Tue, Aug 26, 2008 at 4:06 PM, Yeechang Lee <ylee@pobox.com> wrote:

> Kevin Kuphal <kkuphal@gmail.com> says:
> > From his further information in his rather insulting and
> > condescending response,
>
> I'm sorry you took it that way, but put yourself in his shoes. He
> asked why programs are being autoexpired that shouldn't be (at least
> according to his, and my, and others' understanding) and you told him
> "Well, don't mark those programs to be expired." It's the equivalent
> of the old joke:
>
> "Doctor, doctor, it hurts when I do this!"
> "Well, then, don't do that."
>
> especially when his messages make it clear he understands the issue
> much better than that. You are normally on target (if curt, but the
> latter is OK with the former), but I am afraid you were the
> condescending one in this particular exchange.


With the lack of additional information, and knowing my own recording
habits, anything that I care enough about to complain loudly that it got
auto-expired, is not set to auto-expire. 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. Either way, his was an
unnecessary response to his request for help. 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 because
that more often than not just results in you missing the actual problem
because you overlooked something that was supposed to be "obvious".
Anyways...

>
> > From the OP, it appears without further information that he had a
> > single recording going at the time of the expiration. In the case
> > of a single recording on what we can assume are all full partitions
> > (each one has about the same amount of free space indicating to me
> > that they are all at capacity), then Myth, based on the Wiki quote,
> > will use the local disk first for the next recording (remember,
> > Storage Groups only dictate where a recording will be stored, not
> > what will be expired). As a result of local disk being chosen,
> > local programs are being expired.
>
> This is both illogical and nonsensical. It is illogical because the "a
> last resort" clause indicates (to me, Enigma, and others, at least)
> that free space indeed will be used as the final determinant *if
> necessary*, while you are saying--if I read you right--that this
> doesn't trigger unless "at least two concurrent recordings [are]
> active or other equivalent I/O." If this is the case, the
> documentation is very very very much not clear.


It says that the free space will be used to break a tie. There is no tie.
The drive with the lowest weight is always used first and in this case, that
is his local filesystem. Done. End of story. The rest of the message,
while an interesting discussion, isn't for me to comment on as it is more of
a feature request to change how some people would like the defaults of
storage group weighting to be.

I personally would not want remote storage equally weighted with local
because of the potential I/O issues with network recordings, commflagging,
and the like. 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.

Kevin

On Tue, Aug 26, 2008 at 2:06 PM, Yeechang Lee <ylee@pobox.com> wrote:
> Kevin Kuphal <kkuphal@gmail.com> says:


Excellent post,
Bravo...


Allen
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Tue, Aug 26, 2008 at 4:11 PM, Yeechang Lee <ylee@pobox.com> wrote:

> Michael T. Dean <mtdean@thirdcontact.com> says:
> > 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).
>
> [...]
>
> > Like I said, read the documentation.
>
> Read Mike's words above. Then consider that
>
> > Free space is not considered when choosing a drive/directory to use for
> > the recording /unless/ there's a tie in the weighted determination stage.
>
> the key words "a tie" *only* appear in
> <URL:http://www.mythtv.org/wiki/index.php/Storage_Groups_Weighting> (a
> quote from a Chris Pinkham message to mythtv-users), and not anywhere
> in
> URL:http://www.mythtv.org/docs/mythtv-HOWTO-9.html#storagegroups).


But it is noted in the documenation is that local filesystems are preferred
over remote and they will be used until 2 or more recordings are being made
simultaneously. That alone is enough to understand that a single recording
will *always* land on local storage. The "tie" aspect is inherent in that
definition and is only a more detailed explanation (given by the coder in
the wiki) for those that care to know why it is preferred and possibly how
to adjust it.

Kevin

On Aug 26, 2008, at 2:06 PM, Yeechang Lee wrote:
> A bunch of stuff that is true

However... I still like the fact that myth chooses to record to local
drives before resorting to network attached drives. It makes sense to
me to keep the files local if possible and then start flooding my
network bandwidth if necessary.

I recently started wondering why my new 1TB drive wasn't full but I
was still expiring programs from my 2 750GB drives (all local) until I
realized that when 2 programs were recording at the same time, it was
preferring my 1TB drive with lots of space, but then put the second
recording on another drive to help balance the load of the drives that
were recording. Then I thought, "Wow, this makes a lot of sense.
Thanks for not thrashing that one drive with a potential 6 recordings
and instead spreading it across available disks."

I also like the fact that you can simply mv /localdrive/recording.mpg /
remotedrive/recording.mpg to manually balance out the recordings and
the storage groups functionality will magically find wherever the
recording ended up.

Of course, now all my drives are full (with my assigned 25GB each set
aside for other stuff like transcoding/ripping DVDs/adding music) and
it effectively balances everything out quite nicely.

-Brad

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On 08/26/2008 05:11 PM, Yeechang Lee wrote:
> Michael T. Dean <mtdean@thirdcontact.com> says:
>
>> 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).
>>
> [...]
>> Like I said, read the documentation.
> Read Mike's words above. Then consider that
>> Free space is not considered when choosing a drive/directory to use for
>> the recording /unless/ there's a tie in the weighted determination stage.
> the key words "a tie" *only* appear in
> <URL:http://www.mythtv.org/wiki/index.php/Storage_Groups_Weighting> (a
> quote from a Chris Pinkham message to mythtv-users), and not anywhere
> in
> <URL:http://www.mythtv.org/docs/mythtv-HOWTO-9.html#storagegroups>).
>
> "Ignoring those points that contradict their understanding," indeed.

I don't see the patch for the documentation you were trying to submit.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Tue, Aug 26, 2008 at 2:20 PM, Kevin Kuphal <kkuphal@gmail.com> wrote:
> On Tue, Aug 26, 2008 at 4:06 PM, Yeechang Lee <ylee@pobox.com> wrote:
>>
>> Kevin Kuphal <kkuphal@gmail.com> says:
>> > From his further information in his rather insulting and
>> > condescending response,
>>
>> I'm sorry you took it that way, but put yourself in his shoes. He
>> asked why programs are being autoexpired that shouldn't be (at least
>> according to his, and my, and others' understanding) and you told him
>> "Well, don't mark those programs to be expired." It's the equivalent
>> of the old joke:
>>
>> "Doctor, doctor, it hurts when I do this!"
>> "Well, then, don't do that."
>>
>> especially when his messages make it clear he understands the issue
>> much better than that. You are normally on target (if curt, but the
>> latter is OK with the former), but I am afraid you were the
>> condescending one in this particular exchange.
>
>
> With the lack of additional information, and knowing my own recording
> habits, anything that I care enough about to complain loudly that it got
> auto-expired, is not set to auto-expire. 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. Either way, his was an
> unnecessary response to his request for help. 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 because
> that more often than not just results in you missing the actual problem
> because you overlooked something that was supposed to be "obvious".
> Anyways...
>>
>> > From the OP, it appears without further information that he had a
>> > single recording going at the time of the expiration. In the case
>> > of a single recording on what we can assume are all full partitions
>> > (each one has about the same amount of free space indicating to me
>> > that they are all at capacity), then Myth, based on the Wiki quote,
>> > will use the local disk first for the next recording (remember,
>> > Storage Groups only dictate where a recording will be stored, not
>> > what will be expired). As a result of local disk being chosen,
>> > local programs are being expired.
>>
>> This is both illogical and nonsensical. It is illogical because the "a
>> last resort" clause indicates (to me, Enigma, and others, at least)
>> that free space indeed will be used as the final determinant *if
>> necessary*, while you are saying--if I read you right--that this
>> doesn't trigger unless "at least two concurrent recordings [are]
>> active or other equivalent I/O." If this is the case, the
>> documentation is very very very much not clear.
>
>
> It says that the free space will be used to break a tie. There is no tie.
> The drive with the lowest weight is always used first and in this case, that
> is his local filesystem. Done. End of story. The rest of the message,
> while an interesting discussion, isn't for me to comment on as it is more of
> a feature request to change how some people would like the defaults of
> storage group weighting to be.
>
> I personally would not want remote storage equally weighted with local
> because of the potential I/O issues with network recordings, commflagging,
> and the like. 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.
>
> Kevin
> _______________________________________________


I thought I was following this but maybe I was not.

If you have two drives in the same storage group, why do you want to
leave an empty one empty and delete files on a full one?

I am having a hard time understanding why anyone would want that to
happen. I mean, if I set the drives up in the same storage group, why
is it an advantage to me as a user to effectively not use the drive,
which is what I read would happen...

That said, the obvious solution is for the original party to buy a 1T
drive and put it in the myth locally. I just bought one for $130 from
Buy.com
http://www.buy.com/retail/usersearchresults.asp?querytype=home&qu=206895079&qxt=home&display=col
This is a WD 10EACS Caviar drive and it comes with both data and power
cables and screws. It also has a nice toster called "Regen backup
software"

Now I have to figure out if I really want a 2T myth system or should I
put the drive in my desktop.

Allen


Allen
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Kevin Kuphal <kkuphal@gmail.com> says:
> I personally would not want remote storage equally weighted with
> local because of the potential I/O issues with network recordings,
> commflagging, and the like. 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.

I am pleased that the requisite setting are available for tweaking. I
very much disagree that the default weighting is "reasonable . . . for
the average system," for the reasons I laid out in my previous
message.

An advanced user who is concerned about remote I/O issues should have
the onus of tweaking things so that programs are expired in a way that
contradicts the AutoExpire List. Not the "average" MythTV user who
knows enough to set up an NFS or Samba mount or two and then is
mystified, as the original poster was, that the AutoExpire list and
the priorities he has carefully set for his recordings aren't being
followed.

--
Frontend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On 08/26/2008 05:36 PM, Allen Edwards wrote:
> If you have two drives in the same storage group, why do you want to
> leave an empty one empty and delete files on a full one?
>

Because your network/NAS may not be up to the task of handling all the
I/O required for a new recording (i.e. writing the recording, reading
the recording for mythcommflag or whatever--and note that the kernel's
buffers won't help for this because you'll be at least 8 minutes behind
the recording after initial logo detection).

> I am having a hard time understanding why anyone would want that to
> happen. I mean, if I set the drives up in the same storage group, why
> is it an advantage to me as a user to effectively not use the drive,
> which is what I read would happen...
>
> That said, the obvious solution is for the original party to buy a 1T
> drive and put it in the myth locally.

Or use cp/rm or mv to move the files to the remote storage and fill it
up. Or use myth_archive_job.pl.

(Just restating this approach, which, IMHO, is much prettier than the SG
weighting approach that was previously mentioned as one possible
solution, so it doesn't get buried in all the other garbage in the thread.)

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Tue, Aug 26, 2008 at 4:36 PM, Allen Edwards <
allen.edwards@oldpaloalto.com> wrote:

>
> I thought I was following this but maybe I was not.
>
> If you have two drives in the same storage group, why do you want to
> leave an empty one empty and delete files on a full one?


The key designator is remote vs. local. In the case where all disks are in
the same system attached to the motherboard, it will not leave one empty but
balance the recordings (this is how my system works). In the case of the
OP, some of his disks were network mounted, and Myth considers network
mounted storage lower priority than direct attached disks resulting in the
confusion he had.

>
>
> I am having a hard time understanding why anyone would want that to
> happen. I mean, if I set the drives up in the same storage group, why
> is it an advantage to me as a user to effectively not use the drive,
> which is what I read would happen...


In the case of network disks, it has to do with network I/O from, for
example, multiple HD recordings + multiple commflag operations that could
seriously degrade a network and/or result in bad recordings.

Kevin

On Tue, Aug 26, 2008 at 4:38 PM, Yeechang Lee <ylee@pobox.com> wrote:

> Kevin Kuphal <kkuphal@gmail.com> says:
> > I personally would not want remote storage equally weighted with
> > local because of the potential I/O issues with network recordings,
> > commflagging, and the like. 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.
>
> I am pleased that the requisite setting are available for tweaking. I
> very much disagree that the default weighting is "reasonable . . . for
> the average system," for the reasons I laid out in my previous
> message.
>
> An advanced user who is concerned about remote I/O issues should have
> the onus of tweaking things so that programs are expired in a way that
> contradicts the AutoExpire List. Not the "average" MythTV user who
> knows enough to set up an NFS or Samba mount or two and then is
> mystified, as the original poster was, that the AutoExpire list and
> the priorities he has carefully set for his recordings aren't being
> followed.


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.

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.

Kevin

Brad DerManouelian <myth@dermanouelian.com> says:
> However... I still like the fact that myth chooses to record to local
> drives before resorting to network attached drives. It makes sense to
> me to keep the files local if possible and then start flooding my
> network bandwidth if necessary.

I completely agree that local drives should have priority over remote
drives. But *not if that means expiring local recordings even if
there's free space on a remote drive*. Not by default, at least. It
defeats the whole stated raison d'etre behind storage groups.

> I also like the fact that you can simply mv
> /localdrive/recording.mpg / remotedrive/recording.mpg to manually
> balance out the recordings and the storage groups functionality will
> magically find wherever the recording ended up.

Agreed. I don't want directories hard set into the database records
for each recordings.

> Of course, now all my drives are full (with my assigned 25GB each
> set aside for other stuff like transcoding/ripping DVDs/adding
> music) and it effectively balances everything out quite nicely.

But it doesn't! That's the whole point of the thread.

Let's say that you have 25GB free each on a local drive and a remote
drive; i.e., both drives are full from the MythTV perspective. You
know that in the next day three recordings totaling 40GB will
occur. The AutoExpire list says that 30GB of recordings are in the
Deleted group, and another 30GB are prioritized as being deleted first
which you're fine with. Everything's OK, right?

Not if, as is entirely possible, all 60GB are on the remote drive. By
default, MythTV will delete 40GB worth of recordings on the local
drive, disregarding the "deletable" recordings on the remote drive. To
quote that well known Linux-usability expert Seth Cohen of Newport
Beach CA, that's ridonkulous.

--
Frontend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Kevin Kuphal <kkuphal@gmail.com> says:
> 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.

I agree that, if discussing revamping the AutoExpire List, this is
turning into a feature request thread. I do not think such a revamping
is necessary or even (in most cases) desirable, though. There is a
simple solution (if I understand the weightings right): Set
SGweightLocalStarting to 0 by default.

This solution has the advantage of meshing with the exsting AutoExpire
List, the existing documentation, and simple common sense. Advanced
users who prefer the current behavior can change SGweightLocalStarting
to whatever they want. Meanwhile, average users who know enough to set
up a remote NFS/Samba mount (which are pretty easy in the grand scheme
of things Linux and MythTV) should not have to also learn SQL syntax
to manually create the requisite rows in the settings table.

--
Frontend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On 08/26/2008 07:06 PM, Yeechang Lee wrote:
> Brad DerManouelian says:
>
>> However... I still like the fact that myth chooses to record to local
>> drives before resorting to network attached drives. It makes sense to
>> me to keep the files local if possible and then start flooding my
>> network bandwidth if necessary.
>>
>
> I completely agree that local drives should have priority over remote
> drives. But *not if that means expiring local recordings even if
> there's free space on a remote drive*. Not by default, at least. It
> defeats the whole stated raison d'etre behind storage groups.
>
>
>> I also like the fact that you can simply mv
>> /localdrive/recording.mpg / remotedrive/recording.mpg to manually
>> balance out the recordings and the storage groups functionality will
>> magically find wherever the recording ended up.
>>
>
> Agreed. I don't want directories hard set into the database records
> for each recordings.
>
>
>> Of course, now all my drives are full (with my assigned 25GB each
>> set aside for other stuff like transcoding/ripping DVDs/adding
>> music) and it effectively balances everything out quite nicely.
>>
>
> But it doesn't! That's the whole point of the thread.
>
> Let's say that you have 25GB free each on a local drive and a remote
> drive; i.e., both drives are full from the MythTV perspective. You
> know that in the next day three recordings totaling 40GB will
> occur. The AutoExpire list says that 30GB of recordings are in the
> Deleted group, and another 30GB are prioritized as being deleted first
> which you're fine with. Everything's OK, right?
>
> Not if, as is entirely possible, all 60GB are on the remote drive. By
> default, MythTV will delete 40GB worth of recordings on the local
> drive, disregarding the "deletable" recordings on the remote drive. To
> quote that well known Linux-usability expert Seth Cohen of Newport
> Beach CA, that's ridonkulous.

Speaking of feature requests, did you actually read
http://www.gossamer-threads.com/lists/mythtv/users/297293#297293

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Aug 26, 2008, at 4:06 PM, Yeechang Lee wrote:

> Brad DerManouelian <myth@dermanouelian.com> says:
>> However... I still like the fact that myth chooses to record to local
>> drives before resorting to network attached drives. It makes sense to
>> me to keep the files local if possible and then start flooding my
>> network bandwidth if necessary.
>
> I completely agree that local drives should have priority over remote
> drives. But *not if that means expiring local recordings even if
> there's free space on a remote drive*. Not by default, at least. It
> defeats the whole stated raison d'etre behind storage groups.

It doesn't defeat my use of storage groups. In fact, it's working
exactly how I want it to work.

>> I also like the fact that you can simply mv
>> /localdrive/recording.mpg / remotedrive/recording.mpg to manually
>> balance out the recordings and the storage groups functionality will
>> magically find wherever the recording ended up.
>
> Agreed. I don't want directories hard set into the database records
> for each recordings.
>
>> Of course, now all my drives are full (with my assigned 25GB each
>> set aside for other stuff like transcoding/ripping DVDs/adding
>> music) and it effectively balances everything out quite nicely.
>
> But it doesn't! That's the whole point of the thread.

But it does - for me. My drives are all local.

> Let's say that you have 25GB free each on a local drive and a remote
> drive; i.e., both drives are full from the MythTV perspective. You
> know that in the next day three recordings totaling 40GB will
> occur. The AutoExpire list says that 30GB of recordings are in the
> Deleted group, and another 30GB are prioritized as being deleted first
> which you're fine with. Everything's OK, right?

Let's say you have 6 recordings all happening at the same time. Since
your local drive is almost full, they all get recorded to the network
drive. Then you lose all of your recordings because your network was
so saturated that everything came screeching to a halt. Everything's
OK, right?

-Brad

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Aug 26, 2008, at 4:40 PM, Brad DerManouelian wrote:

> Let's say you have 6 recordings all happening at the same time. Since
> your local drive is almost full, they all get recorded to the network
> drive. Then you lose all of your recordings because your network was
> so saturated that everything came screeching to a halt. Everything's
> OK, right?

Almost forgot... losing 6 recordings all in the name of saving 6
recordings you told it to expire whenever room was needed. :)

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

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.

On 08/26/2008 09:28 PM, Enigma wrote:
> 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.

Right, the proper solution is for someone to write the code that Chris
started and explained at
http://www.gossamer-threads.com/lists/mythtv/users/297293#297293 .

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Tue, Aug 26, 2008 at 6:14 PM, Yeechang Lee <ylee@pobox.com> wrote:

> Kevin Kuphal <kkuphal@gmail.com> says:
> > 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.
>
> I agree that, if discussing revamping the AutoExpire List, this is
> turning into a feature request thread. I do not think such a revamping
> is necessary or even (in most cases) desirable, though. There is a
> simple solution (if I understand the weightings right): Set
> SGweightLocalStarting to 0 by default.
>
> This solution has the advantage of meshing with the exsting AutoExpire
> List, the existing documentation, and simple common sense. Advanced
> users who prefer the current behavior can change SGweightLocalStarting
> to whatever they want. Meanwhile, average users who know enough to set
> up a remote NFS/Samba mount (which are pretty easy in the grand scheme
> of things Linux and MythTV) should not have to also learn SQL syntax
> to manually create the requisite rows in the settings table.


I would tend to agree for the situation of the single tuner or solo
recording scenario. A user that has only one tuner but local and remote
storage will never use the remote storage if I understand the weighting
properly. The same is true for multi-tuner configurations where multiple
simultaneous recordings are infrequent. I'm not sure if a blanket 0 weight
is best or dynamically weighting it to zero in single tuner/recording
scenarios but leaving it as-is for others is best.

Kevin

Brad DerManouelian <myth@dermanouelian.com> says:
> Let's say you have 6 recordings all happening at the same
> time. Since your local drive is almost full, they all get recorded
> to the network drive. Then you lose all of your recordings because
> your network was so saturated that everything came screeching to a
> halt. Everything's OK, right?

I'd hope that anyone with six recording tuners and a remote drive
would be aware ahead of time of any potential network-bandwidth
issues.

As I've stated in this thread, I'm glad there are undocumented options
for adjusting the way storage groups work. My point is that the
default setting for SGweightLocalStarting makes little sense for most
people with both local and remote storage directories in a single
storage group; this thread alone has brought out four of us, and I'd
wager there's a lot more.

--
Frontend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Michael T. Dean <mtdean@thirdcontact.com> says:
> Speaking of feature requests, did you actually read
> http://www.gossamer-threads.com/lists/mythtv/users/297293#297293

I'd love to have Chris' intelligent auto-expire feature and associated
local/remote automated moves, sure. I'd gladly settle for having by
default the AutoExpire List be followed the way it appears in
mythfrontend, though.

--
Frontend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Kevin Kuphal <kkuphal@gmail.com> says:
> I'm not sure if a blanket 0 weight is best or dynamically weighting
> it to zero in single tuner/recording scenarios but leaving it as-is
> for others is best.

The intricacies of the weighting system are beyond me, too; way too
many possible permutations of tuners, backends, and local and remote
drives. I'm glad you seem to agree that the current default setting is
hard to justify, though. I continue to believe that a blanket 0 weight
to SGweightLocalStarting is an improvement over the status quo.

--
Frontend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Meant to send this to myth-users (sent to dev by accident)....

One option would be to implement a bandwidth limit of the max network
bandwidth that myth should use to spread recordings onto remote storage.
Shouldn't be too hard for myth to compute at least an approximate size (vbr
recordings may be not be exact) according to input type, the result of which
could be added to the weighting. That way, users could set an appropriate
limit based on their own network capacity and desired network usage.
And a basic level, a PVRs job is to record things so they can watched
later. Considering that the auto expire option has a setting "oldest first"
(paraphrasing), I would think it be logical that myth use all available disk
(local or remote) before expiring recordings which are not the oldest.
Just my 2 cents.. .
This has been a very interesting discussion and I'm sure the outcome will be
improvements to mythtv. Thanks to all of those who have participated

Dave