<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/11/12 13:36, Brian J. Murrell
wrote:<br>
</div>
<blockquote cite="mid:5093CC42.8020702@interlinx.bc.ca" type="cite">
<pre wrap="">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 (<a class="moz-txt-link-freetext" href="http://code.mythtv.org/trac/ticket/11217">http://code.mythtv.org/trac/ticket/11217</a>) in the
middle of recordings and so anything in progress got split across two
recording files of the same name.
Cheers,
b.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mythtv-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a>
<a class="moz-txt-link-freetext" href="http://www.mythtv.org/mailman/listinfo/mythtv-users">http://www.mythtv.org/mailman/listinfo/mythtv-users</a>
</pre>
</blockquote>
I was interested in this as well. There was a previous thread on
this.<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.gossamer-threads.com/lists/mythtv/users/521826?search_string=damaged;#521826">http://www.gossamer-threads.com/lists/mythtv/users/521826?search_string=damaged;#521826</a><br>
<br>
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.<br>
<br>
So if you have "look for duplicates in current and previous
recordings" it will NOT re-record.<br>
If you set "look for duplicates in current recordings" It WILL
re-record.<br>
<br>
FYI, playing with the manual options:<br>
<br>
Forget old : sets previous recording to 0, but leaves current
recording as 1<br>
Allow re-record : sets both previous and current to 0<br>
<br>
Devs stated in previous thread that they will not change this
behavior until the damage recording detection is proved good enough.<br>
</body>
</html>