[mythtv-users] Can anyone tell me why Ticket 6382 has been closed?

[Michael T. Dean]

On 09/27/2009 05:54 PM, nospam312 wrote:
>> snip
>>     
> Just to be clear I am an avid MythTV user, think the developers of
> MythTV are great and the community is fantastic.  I just want to try
> to help out a bit by posting "bugs" but getting a bit disillusioned.
>   

Yes, and we very much appreciate your input.  Unfortunately, the problem 
is /very/ complex (see the thread linked below).

>> The setting you're using is meant /only/ to allow you to get things going
>> before the show begins airing--i.e. spin up the hard drive, get capture card
>> going (firmware loaded/data moving), etc.  If you want to record some amount
>> of time before the scheduled start time, you need to use the start early/end
>> late settings on each recording rule (though you can set a global default
>> which will be applied to all new recording rules you create).
>>     
> If that is the "proper" use of this option surely it is even more of a
> reason to class it as a bug and get it fixed because people are
> possibly going to be missing the start of programmes if all this
> "setup" is not having the time to happen!
>   

No, it's a per-capture card setting.  Since multirec is done on a single 
capture card, the second virtual tuner used is not using a different 
capture card, so the per-capture-card startup isn't performed.

Granted, this doesn't help with hard drive spin-up when the 2nd 
recording on the multiplex uses a filesystem on a different drive.  
However, the storage groups support for multiple HDD's is newer than the 
original option, so spin-up time isn't necessarily accounted for, 
anymore.  But then again, given sufficient memory in the system, it 
won't be a problem.  At least there have been (TTBOMK) no reports of 
recording problems caused by hard drives spinning up too slowly since 
Storage Groups were added to Myth.

> Anyway for me this type of soft padding solution is a must have
> feature (even if it is not the "proper" usage)

Please read (all 5 pages of) the thread at 
http://www.gossamer-threads.com/lists/mythtv/dev/195124#195124 .  David 
Engel actually went a /long/ way down that path and in the end--after 
more than a year of work from him and a couple users--he determined that 
it wouldn't work and what we have now is better for the vast majority of 
users.

If you really want it, you can use what they created: 
http://svn.mythtv.org/trac/browser/branches/softpad .  Unfortunately, 
though, you'd be stuck at an old legacy version of Myth that's not being 
maintained unless you decided to maintain/enhance it yourself (and I'm 
sure you could find some people in Australia who would help out).

>  - I do not want 8
> tuners in my system when 2 easily do the job fine with soft padding.
> For one it is a complete waste of money buying the tuners and the
> hardware to support these 8 tuners and running costs.
>   

And, from my perspective, it is a complete waste of my time to actually 
write code to do what you want since it won't help me.  Your money costs 
me a lot less than my time costs me, so from my perspective... ;)

seriously, though, the problem--as I see it--with making the change you 
suggested is that if we make this work more and more often, then users 
will come to rely on it.  Once users rely on it, we'll get bug reports 
for the times when it's not used.  The change basically increases the 
complexity of the decision-making process for when to apply the 
"optional" padding, and makes it even harder for users to understand why 
it's not applied in some circumstances.  Therefore, rather than making 
it work for the first/last recording on any virtual tuner (a relatively 
simple, but very much /incomplete/ change), we need to make it work 
reliably on all recordings where there's any possible way to make it 
work.  That was the whole focus of the softpad branch, and it really 
wasn't workable.

> Perhaps we are lucky here in the UK where most programmes start/finish
> on time and the soft padding is a nice to have to catch the occasional
> programme starting early or perhaps running a few minutes late due to
> a breaking news or something.  Having to setup each rule to start and
> finish this way would be madness there would be conflicts galore with
> little benefit.
>   

Not with sufficient capture cards for your needs/desires...  (Yes, I 
realize that's where you and I disagree about the cost of the change 
compared to the cost of the cards.)

> I am going to continue to use it as I have understood it (and probably
> the majority of people as they do not read this mailing list) even if
> it is not the "proper" usage.

Yes, that's your prerogative...

>   I will just have to put up with the
> start padding not working on the 2nd recording on the same tuner.
>   

as long as you do that.  :)

> Hopefully one day someone who knows what they are doing could fix it -
> probably unlikely now as it is not in trac anymore.

On the bright side, there are a ton of people who would like to make the 
change you requested.  The idea won't be forgotten--even if it's not an 
open ticket in Trac.  Someone may eventually make a patch.  That change 
may actually go into the MythTV repo.  Only time will tell.

Mike