[mythtv] re: Broken DEC2000-T filtering. (was generic digest
subject)
Taylor Jacob
rtjacob at earthlink.net
Thu Apr 21 13:53:12 UTC 2005
Quoting Nathaniel Daw <daw at gatsby.ucl.ac.uk>:
> > The implimentation of the dvb drivers in Myth is as it should be per the
> > linuxtv-dvb api.
> And I am suggesting a trivial patch in which they will still be as they
> should be (in fact exactly equivalent), per the api, and thus will work
> exactly the same with the majority of clients but in practice will work
> better with one real-world driver on most real-world networks.
They are not the same.. Its much bigger than just changing some masks.. If you
want to write a patch you can run it yourself go ahead, but I will not apply it
to myth.. I don't want to argue with this anymore, and I am sure the rest of the
developers with cvs access will agree with me..
> I don't understand what is the problem with that? It's not some ugly hack,
> and it's not stopping you from picking up 0x46 where you can. (In fact,
> 0.18 already contains special-purpose hacks to support this hardware.)
If the hardware filteirng was only useful to the dec2000-t then the driver seems
more broken that I was aware.. You are tempting me to back this out even.. The
only reason I allowed the "hardware filtering" code in was because it didn't
change how myth operated once the option was turned on, where as what you are
suggesting breaks EIT, SDT tables, and most likely would cause havock for ATSC
if I went to far as to impliment these changes for ATSC..
> Yes, to perfectly support this driver (in some future world when you are
> actually reading 0x46 tables) you would have to filter twice. That is a
> red herring. In particular, it is not a reason not to make a trivial
I already AM reading and partially processing the 0x46 tables.. Maybe you should
look at the code more closely.. I just am not using them to their full potential
at this point, but removing them will cause issues with EIT.. Opening a PID to
be filtered twice is stupid and I will not do it just because your device has
broken drivers..
> change that will allow the driver to work adequately now while leaving the
> code correct and making no difference for other drivers. As it stands,
> you're going to get either 0x42 or 0x46 on this driver and both on
> everything else -- why not make the choice that works on most networks?
Please read the myth code, and specs before you start running your mouth about
that you don't know about.. I tried to be nice twice now..
> Sure, I should also try to get the driver fixed, assuming that is
> possible. If I could do so, the small change to mythtv I am proposing
> would literally make no difference. But it would in the meantime make
> mythtv work adequately for most people who own this hardware and haven't
> updated.
Well thats what you need to do becasue I am not arguing with you anymore on
this.. I feel like I have already wasted too much of my time reading and
replying to this thread.. I am not going to repeat myself again.. If you reply
please expect silence from me there is nothing more to say..
Taylor
More information about the mythtv-dev
mailing list