[mythtv-users] "yellow" recordings automatically flagged to re-record?
John
reidjr at lineone.net
Sat Nov 3 13:01:06 UTC 2012
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>
More information about the mythtv-users
mailing list