[mythtv] [Patch] Fix for bug #10732

Daniel Thor Kristjansson danielk at cuymedia.net
Thu Oct 4 14:04:55 UTC 2012


Thanks for taking a look at this! I've unlocked the ticket, can you
put your comments in there and attach the patch so this doesn't
get lost?

Please make the patch a unified diff (diff -u), it preserves context
in case of other changes in the code that we apply this to.

-- Daniel

On 10/03/2012 08:10 PM, Tom Collins wrote:
> Patch attached.  Fixes bug: http://code.mythtv.org/trac/ticket/10732 -
> Recordings fail after upgrade to .25
>
> Changes libs/libmythtv/DeviceReadBuffer.cpp ::Poll as follows:
>
> - Reorganizes main loop to be clearer, without changing functionality.
> - Always check return from poll() before using the return structures.
> This was a bug, though perhaps innocuous.
> - Adds missing lock before setting error=true.  This was a bug.
> - Treats a poll() return of POLLHUP as EOF rather than an error.
>
> The last change is what "fixes" the problem.  What's happening is that
> the ivtv driver returns HUP when an attempt to read at EOF of the
> stream.  Myth was then interpreting this as an error, and
> re-initializing the driver, which wasn't the correct behavior.
>
> Works for me to fix the problem noted in the bug.
>
> I say "fixes" because I think this is just a workaround for a race
> condition, but I don't know enough about Myth to debug that.  What I
> see in the logs is:
>
> 2012-10-03 00:05:15.375429 I [9918/9932] TVRecEvent tv_rec.cpp:1029
> (HandleStateChange) - TVRec(4): Changing from RecordingOnly to None
> 2012-10-03 00:05:15.690488 E [9918/10107] DeviceReadBuffer
> DeviceReadBuffer.cpp:490 (Poll) - DevRdB(/dev/video0): poll eof
> (POLLHUP)
> 2012-10-03 00:05:16.039436 E [9918/10105] RecThread
> mpegrecorder.cpp:1017 (run) - MPEGRec(/dev/video0): Device EOF
> detected
> 2012-10-03 00:05:16.200041 I [9918/9918] CoreContext scheduler.cpp:638
> (UpdateRecStatus) - Updating status for Seinfeld:"The Revenge" on card
> id 4 (Recording => Recorded)
>
> At the end of a recording, I usually see one of these POLLHUP errors,
> indicating that the Poll() loop read from the device and got an EOF
> indication.  My theory is that Myth is stopping the recording (and
> somehow indicating to ivtv that it needs to stop encoding) but then
> has no way of stopping an in-progress system poll() call.  So the
> poll() returns POLLHUP, indicating that the encoder has gone away.
> Seems like the proper fix is to somehow cancel the poll().  My "fix"
> just works around the problem by not treating POLLHUP as an error.
>
> Thoughts?
>
> Tom
>
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
>



More information about the mythtv-dev mailing list