[mythtv] [bug?] slave backend expires current recording in process

[Chris Pinkham]

> Maybe the problem was that the programme that was expired was the first
> recording the slave did. Another thing I noticed: The expiring messages
> show up on the slave's console/log not the master's.

This would be why it was expired yes.  Each backend runs it's own expirer
thread and expires only recordings that it made.  So if this was the first
recording the slave had ever made it would be expired.  The autoexpire
thread doesn't know that your master and slave share the same storage so
it doesn't know that it could have deleted the oldest program on the
master.  If the master expirer had run first it would have expired on of
the recordings made on the master instead of what happened.  It's an
unintended side-effect of the two backends not being aware of the fact
that they share storage.  I have it on my TODO list to redo parts of the
auto-expire code to make it so that the master handles all expiring
and so it can know whether a slave is using shared storage and if
so find the oldest program on all backends that will free space on that
storage.  This will take a little work though and it hasn't been a big
problem in the past so I haven't had much incentive to go into that
code.  I wrote the auto-expire code but personally have never had to
use it except when testing.  I do set auto-expire on some recordings
but my drive has never filled up to the point where Myth needs to expire.

> Is this a (known) bug or am I missing something?

Thanks for the heads-up on this.  If someone else wants to take a look
at enhancing this before I get to it, you could fairly easily make it
so that if the slave is on shared storage then it doesn't run the
auto-expire thread and also so make it so that the master can auto-expire
any recordings it has access to not just the ones it recorded.  This
would allow a multi-system master/slave setup like yours to always
expire the oldest program whether it was on the master or the slave.

-- 

Chris