Bug 116217 - xawtv is slow (7 seconds) to display an image
Summary: xawtv is slow (7 seconds) to display an image
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xawtv
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Than Ngo
QA Contact: David Lawrence
Depends On:
Blocks: FC3BugWeekTracker
TreeView+ depends on / blocked
Reported: 2004-02-19 05:17 UTC by Robert M. Riches Jr.
Modified: 2007-04-18 17:03 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-28 21:30:03 UTC

Attachments (Terms of Use)
outout of 'strace -o tv6 xawtv' (175.18 KB, text/plain)
2004-02-19 05:20 UTC, Robert M. Riches Jr.
no flags Details

Description Robert M. Riches Jr. 2004-02-19 05:17:28 UTC
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):

How reproducible:

Steps to Reproduce:
1. Use DISPLAY 2:0 (modified startx script, per
encouragement in the supplied startx script)

2. Issue the 'xawtv' command.

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
and as, 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.

Comment 1 Robert M. Riches Jr. 2004-02-19 05:20:04 UTC
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.

Comment 2 Marcin Garski 2004-09-28 21:30:03 UTC
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:

Note You need to log in before you can comment on or make changes to this bug.