Description of problem: xawtv is slow to display an image, taking 7 seconds from command issue to appearance of the first image Version-Release number of selected component (if applicable): xawtv-3.81-6 How reproducible: 100% Steps to Reproduce: 1. Use DISPLAY 2:0 (modified startx script, per encouragement in the supplied startx script) 2. Issue the 'xawtv' command. 3. Actual results: xawtv puts up a black window immediately. However, it is 7 seconds from command issue before the real image appears in the window Expected results: xawtv should display the real image promptly, as RHL 7.2 for Alpha and RHL 8.0 for X86 did. Additional info: Based on the output of strace, it appears xawtv is attempting to access /tmp/.X11-unix-X0 in a loop with 1-second nanosleep calls, even though it has earlier properly accessed /tmp/.X11-unix-X2. My /etc/hosts file uses static IP addresses for the nodes on my home network (behind NAT/firewall box). I have tried both 'one' and 'one.localnet' as 127.0.0.1 and as 192.168.254.101, with no difference in results. I'm runing the caching nameserver but no other DNS services. I'm not running NIS. I have had to make v4l-conf suid root, because I use runlevel 3 and release the text virtual console after starting the X server, so the console.apps stuff is not useful. None of that changed between RHL 8.0 and RHL 9. I'm using a Radeon 7500 AGP graphics card on an Iwill P4ES motherboard, Intel 845E chipset, 1600x1200 resolution at 24/32 bit color depth, mwm window manager. My .Xdefaults file sets Mwm*xawtv.clientDecoration: none, xawtv*geometry: 384x288-0-0. My .xawtv file selects us-bcst carriers, NTSC, Composite1 input. My BTTV card is a WinTV Series by Hauppauge, Bt878 chip. Essentially none of the setup changed between RHL 8.0 and RHL 9. I never saw the slowness/delay with RHL 8.0, and I always see it with RHL 9. All other X applications come up promptly _except_ xlock (compiled into /usr/local from an older .src.rpm), which always has the same ~7 second delay before taking over the display. It also never showed delay with RHL 8.0 and always shows it with RHL 9. Someone on a newsgroup suggested trying the bit_test=1 option for module i2c-algo-bit. That did not help, but it showed the I2C bus test as passing. One hypothesis is an X authentication issue. Another is a DNS lookup and timeout issue. However, I'm inclined to suspect one of the X libraries is mistakenly assuming display is :0.0 instead of getting it right. I'll try to attach the output of strace.
Created attachment 97823 [details] outout of 'strace -o tv6 xawtv' One other thing: Before the delay, stdout/stderr/tty gets a line identifying the xawtv and kernel version numbers. After the delay, I see "disabling TCL support". I don't recall seeing either of those with RHL 8.
Thanks for the bug report. However, Red Hat no longer included xawtv in Fedora Core. It has been replaced by tvtime. Please upgrade to the latest version of Fedora Core and open a new bug if the problem also occur in tvtime. If you still use xawtv and this bug still persists, please report the problem in upstream bug tracker or on mailing list (usualy they can be found on xawtv website http://linux.bytesex.org/xawtv/). If the project don't have bug tracker and mailing list, you should sent bug report by email to xawtv maintainer. Also Fedora Legacy Project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/