[mythtv-users] "yellow" recordings automatically flagged to re-record?

[John]

On 02/11/12 13:36, Brian J. Murrell wrote:
> Hi,
>
> Probably the colour yellow and the yellow dot next to a recording which
> has been deemed to be "low quality" is (MythCenter) theme specific, so
> hopefully most of you know what I am talking about.
>
> But will recordings that show up in that manner in the MythCenter theme
> automatically be scheduled to re-record?  Or do I have to manually go
> into Recording Options->Allow this episode to re-record?
>
> In my case, these are marked yellow because my backend spontaneously
> exited with status 134 (http://code.mythtv.org/trac/ticket/11217) in the
> middle of recordings and so anything in progress got split across two
> recording files of the same name.
>
> Cheers,
> b.
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
I was interested in this as well. There was a previous thread on this.

http://www.gossamer-threads.com/lists/mythtv/users/521826?search_string=damaged;#521826

When a recording is damaged, as well as marking it as damaged the 
duplicate field  in recorded table is marked as 0. The scheduler then 
ignores this recording as if it is not in current recordings. Crucially 
the oldrecording table duplicate entry is not changed, and remains as 1. 
So the scheduler sees this as a successful previous recording. So the 
state of the recording is the same as a successful recording that you 
have deleted in normal usage. It is not the same as a recording you have 
flagged to rerecord.

So if you have "look for duplicates in current and previous recordings" 
it will NOT re-record.
If you set "look for duplicates in current recordings" It WILL re-record.

FYI, playing with the manual options:

Forget old : sets previous recording to 0, but leaves current recording as 1
Allow re-record : sets both previous and current to 0

Devs stated in previous thread that they will not change this behavior 
until the damage recording detection is proved good enough.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20121103/b4dfc793/attachment.html>