I discovered a similar bug and wonder if it's tangled by your current work:
No, this is a different issue.
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.
That is correct. Currently there is nothing stopping a recording to occur if you are watching tv, only the reverse. We could create a lock file for that case as well but I don't think that is the best solution because the recording would still be missed. The reason tv didn't work after the recording crashed is probably because recordserver left a lock of its own.
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.
That is pretty much what I have planned. For that to happen we need the Freevo tv interface to accept communications and for the recordserver to send it something when a recording is aproaching, wait for a user response, and timeout with a default action (record and turn off the live tv). I have some ideas and plans on how to impliment this (fairly soon).
-Rob
------------------------------------------------------- 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
