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
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
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.
mythtv-users mailing list