[mythtv] [mythtv-commits] Ticket #1945: DVB-S/diseqc patch
danielk at cuymedia.net
Mon Jul 3 01:01:47 UTC 2006
On Sun, 2006-07-02 at 19:48 -0400, Yeasah Pell wrote:
> My problem is that you made so many different kinds of changes to that
> file in one single changeset, which has effectively blinded me. Saying
I could have made smaller change sets, and it would have been better
to do so.
> >The problem is buggy tool-chains. We want to make it as easy possible
> >to port MythTV to embedded platforms. These generally support a small
> >subset of C++ features and proper delete behaviour is one I've been
> >bit with personally on more than one embedded platform.
> Well, I'll take your word for that. I have quite a bit of experience
> working with various embedded C++ platforms, and while I've never
> encountered that particular problem, I've hit lots of other jaw-droppers
> -- generally speaking vendor-supplied compilers are quirky to the point
> of horribleness. Do you remember which toolchain this was specifically?
I was trying to remember when writing that e-mail, the last time was
approx. 5 years ago and I was working on two projects, one an image
processing project with a custom hacked up toolchain that IBM Almaden
had and another UI device interface project using a hacked up Metrowerks
toolchain. I'd say it was the IBM one, but Metrowerks made some of
the crappiest compilers on the market so I can't be sure. But I also
had this problem with C++ before the whole standardization thing kicked
in with one of the popular compilers, it might have even been a Borland
> Again, the only reason I care about the changes at all is because I
> can't see the changes I *do* care about (i.e. the ones that are breaking
> things) because they were all committed together.
The ones you pointed out in your earlier message should be fixed now.
> >>15) A comment indicating that the QTime object that is used to determine
> Fair enough, I can only go by what the Qt docs say, and I don't have a
> lot of Qt experience. I hope somebody has filed a report with trolltech
> about that. In fact, I patterned the QTime usage off of another timer in
> another place in myth, so you know ... keep your eyes open.
I've been removing them from my code little by little. But the
popular replacement, MythTimer, isn't always appropriate, so my urge
to search-n-replace has been tempered by fear of breaking things.
> >Depending on the type of state, it may or not be correct to put in
> >in the DiSEqC tree. Without knowing what the future state is I
> >would rather keep these stateless so bad future changes don't sneak
> >up on me but stick out like sore thumbs.
> Sure, I fundamentally agree with that, but what I'm saying is that the
> code isn't generally finished -- we won't know what additional state,
> etc. the methods will need until people start using the new code with
> their various hardware and give reports about how this device needs
> such-and-such alternate behavior. Since it isn't finished, making
> changes like that is premature.
> >>Things that are definitely bugs:
> >>17) Deleting the diseqc tree object in dvbchannel.
> >Why are you using global variables?
> >Why are you passing around pointers to global variables?
> Various reasons. There were cases when I was developing where the
> dvbchannel object went out of scope and thus destroyed the tree object
> with it, losing state entirely and causing the diseqc devices to be
> reinitialized from scratch -- I didn't look into why that was: remember,
> I developed this on a few hours of weekend time over a few weeks.
<snip -- other good reasons>
The solution doesn't seem ideal to me but then I can't think of
a better one. Keeping that state is important.
> >>18) Changes to the device IDs to use unsigned ints. Ah, I see why some
> >Make 0 the sentinel instead of -1.
> You misunderstood.
Yup, I've put in a temporary solution. But I may end up just reverting
to your solution.
> >>19) The switch SetChild() method no longer checks the supplied ordinal
> >Sounds like a bug.
> Yeah, that one's easy, it just needs to change back to checking against
> the container size instead of checking for null. No biggie.
I made the change just before I got your e-mail. Editing should be
working again. I can't test whether the DiSEqC stuff works here, so
you'll have to do that.
> >Document better. The code is not going in to head until I understand it.
> Fair enough, but again I don't have a lot of time to apply to a free
> contribution, and if I was to apply a normal level of documentation to
> the code I would simply never be able to contribute anything. I was
> expecting that if you had questions you would ask me, or at least
> involve me in some way.
I'll ask more questions in the future. I'm not asking for design documents
or anything like that. This is supposed to be fun. :)
> >Have you considered what happens DVB recording gets extended to
> >allow multiple recordings on the same multiplex to go on? While
> Maybe if multi-card/same LNB/same rotor type recording is ever done the
> system will have to know more about the particulars of individual diseqc
> setups, but I didn't hear much interest in support for that
There is interest in that, but this is true also:
> (and it sounds like it could be potentially quite complex)
Which has foiled several attempts in the past.
> -- for multiple
> recordings on the same multiplex there's no need I can see for any
> special diseqc state queries. Assuming there are two dvbchannel objects
> to support that, the one that doesn't have control of the frontend will
> have to be able to determine whether the one that does have control has
> successfully tuned yet (which isn't done by the diseqc stuff at all, but
> does imply a successful diseqc setup) -- so I would guess that it might
> be better to do that stuff at a higher level. Perhaps the signal monitor
> could be used for this purpose?
The channel class probably needs to handle it (or possibly TVRec).
Consider, there is an hour long program starting at 17:30 on one channel
and another hour long program starting at 18:00 on another channel on
that same multiplex, then the signal monitor will be long gone when the
second program starts up. But, if both start at 17:30 then neither channel
class will be fully tuned, so one will need to become a master channel
class which the slave channel class[es] will wait on, then when it is
tuned they can query it for any information they need to complete tuning.
To provide the slave channel classes with rotor info and other signal
monitoring info, I guess the master channel class can tell the signal
monitor and TVRec that they need to also broadcast that info to the
slave TV class[es].
More information about the mythtv-dev