While porting the dvb-apps to LinuxDVB.NET ... The dvbscan program does use a maximum of 32 file descriptors to set up dmx filters and these are being poll()ed if any data is ready. The poll() call is not available in mono.unix, so I did change it to a maximum of 32 helper threads each with one file descriptor to check for data. It does work actually, it can scan the first program list out of the initial tuning channel but it can not proceed for long - as it gets blocked IN THE KERNEL ioctl for dmx_stop. Now, that's what makes me nervous a little. So far, not even a timeout did release the main thread of my program to come back, it simply stays put or so it seems. The process itself is not dead as the mono runtime does keep checking its own stuff, it just seems to be the main thread of the program. My first question: does anyone use multithreading with dvb? All management calls are done on the main thread, the helper threads are only using read(2) on the existing file descriptors to the adapter/dmx device. The syslog messages do not show any notice about problems inside the kernel. Is there an easy way to make it say something about the dmx_(filter)_stop proceedings inside the kernel? (testing setup: ttpci budget card 0, ttpci siemens card 1, running the ZapScan program from LinuxDVB.NET on card 0 with Hotbird initial tuning file) TIA, -- guido http://google.de/search?q=guidod GCS/E/S/P C++/++++$ ULHS L++w- N++@ s+:a d->++ r+@>+++ y++ (geekcode)
