-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 10 June 2004 03:08, Rob Shortt wrote:
> I discovered that when recording (ivtv_record.py), only the first show
> after a recordserver restart would record, it was getting stuck in the
> 'record' state because I thought the save_flag was blocking somehow.
> This wasn't quite the case. The real problem was that the videothumb
> snapshot was raising an uncaught exeption and craching the thread,
> before the mode flag could be reset.
I discovered a similar bug and wonder if it's tangled by your current work:
I was watching TV when a program scheduled for recording was about to start.
The recordserver changed the channel but died (using ivtv_record BTW),
probably because of concurrent access to /dev/video0 I guessed. But it left
the record flag behind and neither recording nor watching TV would work
anymore.
Did you discuss what should happen in this case? I mean - ideally IMHO, the
user would be warned in time that a recording is about to start, and will be
asked to quit watching TV (if he does not have more than one card/record
source) or explicitly confirm that the recording can only start when he
finishes using that record source.
Ciao, / / .o.
/--/ ..o
/ / ANS ooo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAyBN/J8iuK6bBAPMRAlh4AKC51G93PqbP00OANZt5Q1kwbvDzVwCfc1gq
SjOCrXrdfs70bQAAea2AMbs=
=9H6B
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
