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):
Steps to Reproduce:
1. Use DISPLAY 2:0 (modified startx script, per
encouragement in the supplied startx script)
2. Issue the 'xawtv' command.
xawtv puts up a black window immediately. However,
it is 7 seconds from command issue before the real
image appears in the window
xawtv should display the real image promptly, as
RHL 7.2 for Alpha and RHL 8.0 for X86 did.
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
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: