Investigating further, this bug relates to whether or not you get a
signal lock while recording.
In gnutv.c around line 339, a start timer is not initialized until a
signal lock is acquired. In receiving over-the-air broadcasts in my
area, gnutv must not be getting a strong enough signal to acquire a
lock. It does get sufficient signal to start receiving data though, and
in this case, the recording never terminate. This causes a real problem
for automated scripts which run forever and result in infinite length
recordings. At 1080i, HDTV rapidly consumes the entire hard drive.
I think the start timer should be initialized right away regardless of
the lock state so the timeout parameter can be effective. In general
you would expect a lock to be acquired within a few seconds so delaying
the start timer is not really beneficial.
An alternative might be to implement a second timeout which cancels the
recording if no lock is acquired within a specified period.
Cheers,
Chris.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
