[mythtv] EIT scanner failure caused mythbackend to miss future scheduled recordings

Daniel Kristjansson danielk at cuymedia.net
Fri Jun 23 12:42:43 UTC 2006


On Fri, 2006-06-23 at 06:01 +0100, Nick wrote:
> and this was following by 1.24 _million_ lines of:
> 2006-06-23 00:22:47.874 Error: We started a PES packet, without a payloadStart!
Hmm, I wonder if printing this simply overloaded the system.
Can you try commenting this line out, and report back on
whether the system refuses to record after that?

> Is it possible for the EIT scanner to completely nix the entire
> system, bar in-progress recordings?
It shouldn't. The scanner can be shutdown at any time to start
a recording.

> Should duplicate messages be limited? (I run a separate /var/log
> partition to avoid problems like this)
Duplicate messages are sometimes suppressed, but there are external
logging programs that can do a good job of this for you. When
debugging, which is the primary use of all the messages except
"important" and "general", duplicates are important.

> I have now turned off EIT scanning for those few channels that
> are not available from the uk_rt XMLTV grabber.
> Assuming this problem is due to the EIT scanner (I noted Trac ticket
> #1888 and -dev message
Assuming you have the same problem, which seems plausible, then this
should be restricted to a particular transport or transports.

> http://www.gossamer-threads.com/lists/mythtv/dev/205583) should it
> stop scanning gracefully? I'd hope it would be using the lowest
> priority card (I can't tell from the log) but the fact non-DVB
> recordings were also lost makes me wonder whether it might have been
> anyway and just took out the whole future scheduled recordings
> feature.
Active EIT scanning uses all available cards so that the scan
completes more quickly. But it is also always the lowest priority
"recording" and gets killed if anything else wants the recorder.
The passive EIT scanning is always running while a recording is
in progress, but of course it only collects data for the transport
you are recording.

> Does current non-mythtv-eit SVN have any fixes for this issue?
Not #1888. I'll probably address #1872, #1899, #1921, #1966,
#1972, and #1981 first. If you have any programming ability,
or know someone who does, a patch fixing the issue or an
explanation of why the code is failing would bump this up in
my to-do list. (This may be higher on Stuart A's list, but
I doubt it; this is still in my queue of 22 or so tickets.)

-- Daniel



More information about the mythtv-dev mailing list