Michael Rickmann wrote: > I forgot to > say that we apply the patches from within the Makefile. So for the patch > I sent you would edit the Makefile, look for a line saying (cd > $(EKIGA_DIR)/; git $(GIT_EKIGA_REV) ) and add a line, starting with a > tab !!!, (cd $(EKIGA_DIR)/; patch -p1 < > $(WIN32_DIFF_DIR)/ekiga_helpers.diff ). > This works fine. > That is really bad. I have not tested such a new Win32 Ekiga under real > world conditions as I was working on other aspects introduced into the > code. The jitter buffer errors, the last signs of life in the first two > logs come from Opal which was linked in. My observations are that new > Windows are piling up under Win7 once a connection has been established > or inability to open the sound device when a call is made. Together with > your logs it seems to indicate that the code in the "libgmopal" can not > work properly after "Split ekiga into an exec and helper libs". Could > you build Ekiga before that change was done? To do that edit the Win32 > Makefile look for a line starting with GIT_EKIGA_REV and make it read > GIT_EKIGA_REV = reset --hard 4fed510c131. Then test again. > As to the crash on exit, it may have been caused by the same problem but > also others. In general Ekiga seems prone to crashes on exit. This is a > problem of design and may have evolved gradually. In essence, Ekiga > waits until the main thread has terminated and relies on Opal and Ptlib > to destroy part of its objects from the heap. This is really difficult > to debug. Due to connection problems on (remote part I suspect) I had much time to think about "make update-sources" and made up a local cache thingy. It can help with this kind of builds quite a much. I included a patch, if some one else is also interested about that kind of thing. My builds took a lot of time, because I tried to use that patch on this revision also. But I got over it and got it build eventually. At first runs I got just error dialog lock ups, when the call was connected. See error logs. The error dialogs that kept popping up said that audio device was opened OK, but reading from it fails. Many times over and over and over ... This bug is quite annoying and probably should be fixed also. Reason seemed to be that audio/video settings were wrong and probably from that crashing version of ekiga. After changing those devices no lockups or crashes have happened in one session and many calls in/out. But due to my test environment I was happy with completely silent calls with video only. After a while I noticed that this was not good. Then I deleted my ekiga.conf so that I would get complete clean start. Now I have not got decent session on at all (and some on exit crashes also). It seems that, if caller and callee have different sets of audio (video?) codecs selected it already causes Windows ekiga to lock up. I will test more. First I try to get calls throug again with some settings and then I try to come up with tests, where only one thing is changed and bad things start to happen. jarmo P.S. My first post of logs got too big and I had to cancel it. So I sent only this one that I have hevily edited. I removed millions of lines like: "2009/07/09 12:43:32.218 1:00.426 Media Patch:3400 GMAudioInputManager_ptlib Encountered error while trying to read data" But some other lines have been deleted also. Maybe it is still useful.
Attachment:
source_cache.zip
Description: Zip archive
Attachment:
ekiga-stderr-error-dialog-lock-on-out-call-connect.zip
Description: Zip archive