[mythtv-users] Mysterious backend log errors

[Mike Rice]

I updated to mythbuntu a few months ago from my very stable Fedora 14
setup.  I am still trying to get back to perfect stability.  I am seeing a
few errors in the backend log that seem harmless but I'd like to correct
the problem to at least get rid of the log noise so I can find new problems
should they occur.

 mythbackend version: fixes/0.25 [v0.25.2-15-g46cab93] www.mythtv.org

When something records on one of my HDPVRs I get errors in the log, one at
the start and one at the end.  The recordings are fine afaik.

To demonstrate here is the log entries for a recording (started from the
program guide):

Apr  6 11:47:20 masterbackend mythbackend[30955]: I Scheduler
scheduler.cpp:2033 (HandleReschedule) Reschedule requested for id 4998.
Apr  6 11:47:30 masterbackend mythbackend[30955]: I Scheduler
scheduler.cpp:2093 (HandleReschedule) Scheduled 3008 items in 10.2 = 0.02
match + 10.17 place
Apr  6 11:47:31 masterbackend mythbackend[30955]: E CoreContext
programinfo.cpp:2278 (GetPlaybackURL) ProgramInfo(5708_20140406114800.mpg):
GetPlaybackURL: '5708_20140406114800.mpg' should be local, but it can not
be found.
Apr  6 11:47:31 masterbackend mythbackend[30955]: I TVRecEvent
tv_rec.cpp:1029 (HandleStateChange) TVRec(1): Changing from None to
RecordingOnly
Apr  6 11:47:31 masterbackend mythbackend[30955]: I TVRecEvent
tv_rec.cpp:3495 (TuningCheckForHWChange) TVRec(1): HW Tuner: 1->1
Apr  6 11:47:31 masterbackend mythbackend[30955]: I TVRecEvent
v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/hdpvr0):
SetInputAndFormat(1, NTSC) (v4l v2) input_switch: 0 mode_switch: 0
Apr  6 11:47:31 masterbackend mythbackend[30955]: N Scheduler
autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free
Space: 3.0 GB w/freq: 15 min
Apr  6 11:47:31 masterbackend mythbackend[30955]: I Scheduler
scheduler.cpp:2514 (HandleRecordingStatusChange) Tuning recording: "NHL
Hockey":"St. Louis Blues at Chicago Blackhawks": channel 5708 on cardid 1,
sourceid 5
Apr  6 11:47:39 masterbackend mythbackend[30955]: I CoreContext
scheduler.cpp:637 (UpdateRecStatus) Updating status for "NHL Hockey":"St.
Louis Blues at Chicago Blackhawks" on cardid 1 (Tuning => Recording)
Apr  6 11:47:39 masterbackend mythbackend[30955]: I TVRecEvent
tv_rec.cpp:3989 (TuningNewRecorder) TVRec(1): rec->GetPathname():
'/usr1/recordings/5708_20140406114800.mpg'

It appears GetPlaybackURL tries to find the file before it starts
recording.  Is that a bug or do I have something misconfigured?  I have a
single Storage Group with two directories (/usr1/recordings and
/usr3/recordings).

Also at the end of the recording I see this "Device EOF detected":

Apr  6 12:00:00 masterbackend mythbackend[30955]: I TVRecEvent
tv_rec.cpp:1029 (HandleStateChange) TVRec(1): Changing from RecordingOnly
to None
Apr  6 12:00:00 masterbackend mythbackend[30955]: E RecThread
mpegrecorder.cpp:1017 (run) MPEGRec(/dev/hdpvr0): Device EOF detected
Apr  6 12:00:00 masterbackend mythbackend[30955]: I TVRecEvent
tv_rec.cpp:816 (FinishedRecording) TVRec(1):
FinishedRecording(5708_2014-04-06T11:48:00) damaged recq:<RecordingQuality
overall_score="0" key="5708_2014-04-06T11:48:00"
countinuity_error_count="0" packet_count="3756817">#012    <Gap
start="2014-04-06T09:00:00" end="2014-04-06T11:47:40" duration="10060"
/>#012</RecordingQuality>

And then I also see these "PREVIEW_SUCCESS but no receivers":

Apr  6 12:00:00 masterbackend mythbackend[30955]: I CoreContext
scheduler.cpp:637 (UpdateRecStatus) Updating status for "NHL Hockey":"St.
Louis Blues at Chicago Blackhawks" on cardid 1 (Recording => Recorded)
Apr  6 12:00:00 masterbackend mythbackend[30955]: E CoreContext
mainserver.cpp:871 (customEvent) MainServer: PREVIEW_SUCCESS but no
receivers.

I was thinking the 'E' log entries are errors that indicate a problem.  Is
that true or are there some 'E' log entries that can be safely ignored?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140406/39052b54/attachment.html>