1. Some weeks ago I wrote about problem with videocapture stopping, and Damian answer me: > Perhaps it is your videodriver... Have you tried with a > different camera? You could also check the debug output of > level 3 to see if you get errors. Also check the kernel > messages. > > If both camomarama and gnomemeeting have the same problem, I > think it is 99% a video driver problem. I found problem. It was no videodriver or camera, but ACPI. Any read attempt from /proc/acpi/battery/BAT0/state (this is battery charge info) causes stopping of videograbbing in any v4l programm - gnomemeeting, camorama, and xawtv in debugging mode. The last say: v4l: timeout (got SIGALRM), hardware/driver problems? ioctl: VIDIOCSYNC(int=0): Interrupted system call v4l: timeout (got SIGALRM), hardware/driver problems? ioctl: VIDIOCSYNC(int=1): Interrupted system call This is not gnomemeeting bug, but if anyone will use gnomemeeting on notebook, he will have the same problem. I think that Damian as gnomemeeting's mainteiner must ask v4l and acpi maintainers to correct this bug. Workaround solution is to kill all battery-checkers before starting gnomemeeting, i.e. gnomemeeting must to start from shell script (in attach). 2. Because my GUI is KDE, I had to kill artsd too. Of course, artsd can to capture /dev/dsp from any application to himself (via starting application as "artsdsp [--mmap] <application-name>"), but gnomemeeting isn't a single process, so it takes no effect. This means, for example, that if I start gnomemeeting,leave it in tray for waiting incoming calls (I don't know who and when call me) - I can't listen my favorite mp3's. So, IMHO, gnomemeeting needs some start parameter (something like "gnomemeeting --audioserver=[direct,esd,arts, etc...]") for compatibility with another GUI's, not only with Gnome. 3. The next problem is a bell when somebody calls me. As I understand, it's gnome event, but my KDE doesn't proceed such events. So, call-bell doesn't work... 4. As I see, when I switch-on my videocam by gnomemeeting's button and then leave gnomemeeting in tray in "standby-for-calling", videocapturing continues. It takes about 10% of processor's time. IMHO, it will be better if videodevice opens only when gnomemeeting's window on desktop exists, and automatically closed when gnomemeeting is only in tray. Analogically, microphone must be muted when gnomemeeting is in tray. This is the first impressions of gnomemeeting's usage in a small company for videoconferencing between workers via intranet. Now we have 6 workplaces with gnomemeeting, and my boss can see my face on my workplace when I drink bear...-) Best regards. George
Attachment:
gmeeting
Description: application/shellscript