[mythtv-users] Disk Space Way Wrong

Raymond Wagner raymond at wagnerrp.com
Sat Apr 21 18:48:59 UTC 2012


On 4/21/2012 13:13, Ronald Frazier wrote:
> This thread makes me so sad. The way Mark has been responded to in
> this thread is just uncalled for.

So far, I agree with you completely.  At some point the thread degraded 
into just a bunch of character attacks from both sides.  MythTV 
developers should be showing a good public face to the community, and 
partake when the discussion reaches that, as amusing as that may 
sometimes be...

Example: http://www.gossamer-threads.com/lists/mythtv/dev/187438#187438

On the other hand, if Mark Lord is going to invoke his authoritative 
knowledge as a long time kernel developer involved in storage interface 
drivers, he should be held to no less of a standard of behavior.

> He was nothing but respectful in this thread, helped identify a problem, and even provided code to deal with it.

At first, yes, however this whole thread started due to his mention of 
an "old bug" that none of us had even heard of.

On 4/20/2012 12:40, Mark Lord wrote:
> Symlinks are a "normal" (not "strange") thing on Linux,
> and are often overlooked by folks more familiar with
> only Microsoft systems (which lack them).

This is where the discussion took a turn downhill.  Mark "threw the 
first punch", as it were.   Now he may have meant this as a joke, but 
from experience having been corrected by Mark in the past, many times 
where he was correct, sometimes where he was not, Mark is never wrong.  
This felt like an insult, as if I was a Windows weenie, not experienced 
with using Linux.  Admittedly, my OS of choice is FreeBSD, rather than 
some blend of GNU/Linux, but that's besides the point as symlinks are a 
POSIX standard not specific to Linux, and even Windows has support for them.

If there were a rational argument for allowing symlinks as storage 
directories, I would gladly apply the patch.  However, I just don't see 
one, and the only argument for it was that it is how Mark configures his 
systems.  You can't argue with that, and since I am guilty of getting 
into such character arguments in the past, I bowed out at this point.

> The comment about "hundred or so workarounds already in my local tree"
> was not something I took as an attack on myth. I too have a bunch of
> patches (though not 100). Some I submit. Other I attempt to discuss
> for possible inclusion and don't get a positive response. Others I
> just dont bother with because, frankly, you sort of get a feel for
> what sorts of things the devs aren't interested in and don't want to
> waste time debating the merits of something you think will go nowhere
> (admittedly, I've been wrong in that assumption once). Other patches I
> feel are for something very particular to what I want, or at the very
> least would need to be configurable for other users taste and I just
> don't feel like taking the time to add the config options to the setup
> screens. Others patches are quite hacky and work for me, but they
> aren't very clean and I'd be embarrassed to submit them. In short,
> there are a lot of reason one would just hack together patches for
> themselves and not submit it.

Maintaining your own patch set is perfectly fine.  Maybe you are 
tweaking behavior, or adding new features, in some manner that would not 
have significant appeal.  Maybe you are adding features that you know 
would not be accepted upstream for whatever reason.  Maybe you are using 
assorted bug fixes for tickets still open on trac.  The attack on Myth 
was where he claimed it had bugs, knew what they were, but let that 
knowledge sit for years without telling anyone so it could be fixed.  No 
doubt about it, MythTV is full of bugs, but we can't do anything about 
it if we don't know where they are.  Especially if they are induced by 
some sufficiently strange configuration that no one else has experienced 
them.

So going back to the original argument, is this a bug, or is it merely 
an unsupported configuration?  Now one could argue that even if it isn't 
supported now, it should be, the the better question is, is there any 
reason to try to record to a symlinked directory?  The argument for says 
that it allows you to conveniently and quickly reorganize your 
filesystem structure.  The argument against is that MythTV's storage 
directories allow you to reorganize your filesystem just as well.  Just 
run mythtv-setup, spend a few seconds typing in a new path, and you're done.

Now one might not have a partition or disk dedicated towards MythTV 
recordings, they may have other content stored on it.  Shifting that 
around would mean one would have to update MythTV, as well as any other 
applications that had content stored on that partition.  However, 
symlinks would work perfectly fine in this scenario.  MythTV would not 
be pointed at the symlink directly, but rather at some folder 
transparently dereferenced inside that symlink.

That leaves the one scenario where you have symlinks pointed directly at 
the recording directories AND you have applications other than MythTV 
accessing those directories.  This is where the disconnect occurs.  
Those directories, and the contents contained therein, are MythTV's and 
MythTV's alone.  You don't care what's in there.  You don't rename them, 
besides to change the extension as part of transcoding.  If you want to 
access them with pretty names, use mythlink.pl to provide symlinks 
directory to each recording in whatever format you desire.  If you want 
more programmatic access to the recordings, you hit the database 
directly to discover the filename for the video you want, the defined 
storage directories, and then search through them until you find the 
absolute path to the recording.

In much shorter words, the patch is to make a particular configuration 
work, whose only advantage is to make it easier to perform tasks that we 
don't want users doing.  Since the behavior is undesirable, there is no 
point to the configuration from MythTV's standpoint, making it 
unsupported.  An unsupported configuration that causes certain things to 
break is not a bug, just an unsupported configuration.


More information about the mythtv-users mailing list