[mythtv-users] What might cause a recording to mysteriously stop?

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Tue Apr 11 08:03:22 UTC 2006

    > Date: Tue, 11 Apr 2006 03:40:14 -0400 (EDT)
    > From: f-myth-users at media.mit.edu

	> > Date: Mon, 10 Apr 2006 14:15:11 -0400
	> > From: "Michael T. Dean" <mtdean at thirdcontact.com>

	> >				 			 The only fix is to 
	> > close the device and reopen it.  0.19-fixes SVN (which is being used by 
	> > many packagers) and SVN head will do this for you.  ( 
	> > http://www.gossamer-threads.com/lists/mythtv/commits/182149#182149 )

    > I'm also noticing that 19 doesn't actually say -which- encoder got the
    > select timeout, which makes recovering from the gap (e.g., scheduling
    > rerecording) impossible if multiple encoders are going at once.  If I
    > submitted a patch to include the encoder number, would it be likely to
    > be accepted?

    > [It's not obvious from a quick perusal of the code in mpegrecorder
    > where that value might be stored; is there some easy way of going
    > from either the FD or the videodevice back to a human-readable
    > encoder number?]

Oh duh.  I think probably I just want to change the line
  printf("select timeout - ivtv driver has stopped responding\n");
to something like
  printf("%s select timeout - ivtv driver has stopped responding\n", videodevice.ascii);

That should at least give me the device name, which bears a fixed
relationship to the encoder number for any given installation, which
theoretically is enough information for me to figure out which
recording got glitched.  (Though apparently I'll have to have
my automation do the lookup at the moment the glitch gets logged,
since I'm not sure if there's a way of figuring out what encoder
some recording used -after- it's done recording---is there some
MySQL table I've missed that would remember this?)

Think that patch would be accepted?  Should I move this to -dev?

More information about the mythtv-users mailing list