Hi list, I'm working on support for handling multiple frontends and their data inputs on DVB-USB devices. Therefore I had to change the dvb-usb-framework in order to register additional dvb-device-nodes and to handle an usb device with several input streams. If everything works out well, I can release this change just before those devices hit the market. I know that some of the following issues have been discussed recently, but I'm not sure on which way we agreed on :). The device has 2 (independent) DVB-T frontends connected to one USB-device-controller handling their (partial) MPEG2-TS data inputs. Demuxing has to be done in software. For me as a newbie to multiple-input-cards it seems to be the "correct way" to register 2 frontends and 2 demuxs for one dvb-adapter. This is how it currently looks like: $ ls /dev/dvb/adapter0/ demux0 demux1 dvr0 dvr1 frontend0 frontend1 net0 net1 It is working well with tzap and mplayer (playing dvr0 and dvr1) under the assumption that dvr0 is connected to frontend0 and dvr1 to frontend1. As Ralph pointed out, there are applications out there, which are not working with dvrX and demuxX (X >= 1). So in that case it's maybe better to register a dvb_adapter per stream-input to be more compatible with applications. OTOH and IMHO, it would be better to extend the applications to make use of all the features of the DVB-API. In the latter case the question remains, whether the assumption that all dvb/*0-nodes and all dvb/*1-node descibe one input stream good enough or not. Afaik it's not a good assumption. I hope I'm wrong. :) What is "the correct way" to mount all *0 and all *1 logically together? thanks for your help in advance, Patrick. -- Mail: patrick.boettcher@xxxxxxx WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
