Quoting Nathaniel Daw <[EMAIL PROTECTED]>: > > 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 _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
