[mythtv] Viewing Live TV Causes Recordings to be Moved to Live TV Group - Again

Jeff Breitner jtbreitner.lists at gmail.com
Mon Mar 17 11:55:53 UTC 2014


On Tue, Mar 11, 2014 at 1:41 PM, Greg Thompson <gthompson20 at gmail.com>wrote:

>
>
> This happens all the time to me under the following conditions:
> 1. All tuners are set to livetv and recording priority defaults (meaning I
> haven't done anything special with Priorities)
> 2. A frontend will be playing a channel (in this case 1232)
> 3. A recording is scheduled for that channel at 8am till 9am.
> 4. I came home for lunch at 12pm.. MythWeb still shows that the show is
> still recording. (yup 3 hours passed the Stop time)
> 5. It will continue to show recording no matter what I do by clicking stop
> recording, cancel the schedule etc. unless I:
> a. Kill mythbackend
> or
> b. stop the live tv on the fronted.
>
> 6. The Show is in the LIveTV group twice. 1 as non expirable and the other
> as auto expire on.
>
> Hope this helps finding the issue.
>
>
>
What is happening is that an update to the recorded table as part of
closing the recording for LiveTV affects both the LiveTV and the scheduled
recording rows.  The recording ends, but oldrecord.recstatus doesn't get
properly changed, so it appears that the recording is "stuck".  When the
backend starts, it cleans up any recordings in this state, so that is why
you see what you do when you restart the backend.

There is a patch in bugs that resolves it for me (#11119) and I have been
running it since November, but warpme reported some unintended interactions
with some playback controls.  I haven't been able to replicate his
complaint.

If someone else can try the patch and confirm the interaction, that would
be great.  We can either reject the patch, fix it further or take another
approach.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20140317/e3e21d61/attachment.html>


More information about the mythtv-dev mailing list