[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 07:36:19 UTC 2006


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

    > On 04/10/2006 02:43 AM, f-myth-users at media.mit.edu wrote:
    > > I just noticed something odd.  I'm running 0.18.1 (yes, 18)
    > ...
    > > Several recordings were in progress simultaneously, including one that
    > > was supposed to run from 8-9pm with one minute of padding on each
    > > side.  That one recording only recorded 47 minutes and quit.  All the
    > > others recording at that time are fine.

    > The new ivtv drivers sometimes stop providing data.

What does "new" mean?  Is there some ivtv or kernel version before
which this behavior does not happen?  (Is this known on the ivtv
lists?  If so, I can also ask there.)

    >				 			 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 )

Hmmm---19 logs this, but if 18 does, the printf isn't in the same file
that 19 uses and might not exist at all, which might explain why I
have no logfile entries about this when it happened.  I see a printf
of "select timeout" in the 19 code in libs/libmythtv/mpegrecorder.cpp,
but nothing to conditionalize it to a logging level; am I safe in
assuming that 19 will therefore -always- emit the "select timeout"
line when it must reinitialize the card?  [I need this to tell my
automation that the recording is defective and should be rerecorded if
reaired.]

    Perhaps it's time to upgrade.  :)

Not until I have enough uninterrupted time between trips and other
commitments to risk the days or weeks of instability upgrades bring,
which means at least July.  That will also give 19-fixes enough time
to settle down.  Many people have reported that 19 is less stable for
them than 18, and I know that any perturbation can lead to all sorts
of problems, so I'm preferring the devil I know until I have time to
thoroughly vet the new configuration---especially since it's very,
very difficult to roll back, since even if I preserve (say) complete
copies of the relevant partitions on the MBE and the FE/SBE, the
database will have been irreversably rolled forward and restoring
it from a backup while handling data added in 19 is a hassle.  So
I can't upgrade until I know I'll be able to restabilize everything
promptly.

Thanks!


More information about the mythtv-users mailing list