Q: dbox2, multi camd, /proc/bus/gtx
A: Yes, we've removed support for /proc/bus/gtx indeed, but preventing any
   multi camd solutions to work wasn't the intention for that decision. In
   fact, we've had no idea that multi camds need /proc/bus/gtx to work, we've
   never used this before. We've removed /proc/bus/gtx, because dbox2 images
   have been providing /dev/dvb/adapter/ca1 for a while now and we consider it
   the better solution, because it conforms to the Linux-TV API. However, if
   you want to continue to use /proc/bus/gtx, you can write a libcamdio.so
   library to do exactly that, output the control words to /proc/bus/gtx.
   That's in fact the reason why all box-specific code was split from the main
   newcamd binary, so people have an opportunity to use whatever special
   configurations they need.

Q: Dreambox, nds channel decoding dropouts while recording
A: Yes, unfortunately, we must confirm this problem. We've been hoping, it's
   just our box/hard drive that causes this, but apparently, it's not. We've
   spend another weekend investigating this, but unfortunately there's simply
   nothing we can do about it. The driver (both /dev/sci and also RS-232
   unfortunately) starts eating bytes in longer nds card answers as soon as a
   recording is started. An application like betad has no change to determine
   any bytes that were lost in the driver, all it can do is reinitialize the
   card, resend whatever message caused the problem and hope the result will be
   ok this time around. Unfortunately, not even recording via nfs helps with
   this problem, it seems the problem is not the hard drive itself, but the mere
   fact that enigma's recording feature is being used. So, unless you can
   convince someone at DMM who's responsible for the kernel/drivers to look into
   this problem, you just have to live with it. You can try ngrab maybe to
   record, we haven't tried that yet.

Q: Can you allow LAN sharing for nds, but not Internet?
A: No. For the simple reason that both is the same. We could of course make a
   simple check for IP addresses for something, but that would be too easily
   patchable. You can thank the idiots that patch and then distribute our stuff
   despite we've ask nicely not do that.

Q: Communication errors with Via2.4 TPS card when sending ECM on i386
A: Well, we don't have this particular card, but we've tried two other Viaccess
   cards on two different machines and had no problems. We would like to hear
   from other people that have an original TPS Via2.4 card, if they encounter
   the same problem. We do suspect however, that the original poster was trying
   to use some other card (not original) that only emulates a TPS Via2.4 card.
   Those we make no effort to support of course, because 1. you can use emu and
   2. we don't want to support commercial hackers.

Q: ...gbox sharing protocol not available...but the internal cardspider 
   (spider<->spider) protocol is not available either, so why do you critise
   gbox?
A: Well, the difference is, cardspider has a well-known camd client interface
   that is available, gbox does not. The gbox critism was aimed at the fact,
   that it isn't possible to participate in the gbox sharing network unless
   you indeed use the gbox binary on one of the limited number of platforms,
   where a gbox binary is available for. This is different with cardspider and 
   always has been, because you can use evocamd, mgcamd, Samsung 9500 machine,
   some Windows DVB-S client, in fact any platform that someone cares to write
   a client for, which is easily possible with the information available and
   without the need to reverse engineer anything.
