<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">On Mon, Sep 25, 2023 at 11:03 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 25 Sep 2023 22:10:23 +0800, you wrote:<br>
<br>
>More and more I'm finding the scheduler is Not Recording a current program To be recorded Later.<br>
>There is no logic ie I have 4 of 4 tuners available.<br>
>Thanks to who ever helped me I set virtual tuners to NOT be allocated automatically and have 1 tuner per tuner, this seems to have upset the scheduler.<br>
>[My wife said when I plug in the laptop charger the Fibaro blinds controller runs. Nonsense I opined. Plug - zzzzst - zzzst - click - brrrrrrrrrr !!] Likewise scheduler logic and virtual tuners.<br>
>Reason for the crazy logic: I get no damaged recordings with no virtual tuners, but occasional ones with virtual tuners.<br>
><br>
>Can I change priorities to force recording of first showing ? Must I resort to clever SQL and custom rules ?<br>
><br>
>James<br>
<br>
You should be able to have the priorities set up so that the first<br>
showing will record.  To try to find out where the priorities are<br>
going wrong, in Mythfrontend in the Upcoming Recordings list, use the<br>
I key twice and scroll down and you will see the priority calculated<br>
for that showing and a breakdown of how it was calculated.  Look at<br>
both the showings that are going to record Later and the previous ones<br>
that you wanted it to record.  Use the 1 key to get the full list of<br>
upcoming recordings ("All" recordings), including all those not going<br>
to record.  Use the 2 key to get the list back to just the "Important"<br>
showings (those that will record or where there is some warning).<br>
<br>
Also, getting damaged recordings with virtual tuners does not make any<br>
sense.  There are many of us using virtual tuners and not having any<br>
problems with them.<br>
<br>
The usual causes for damaged recordings (where the recording did start<br>
properly in the first place) are:<br>
1) The signal coming into the tuner is damaged.<br>
2) The hard drive is failing and there are damaged sectors, where the<br>
data is not written correctly.<br>
3) The hard drive is failing and the automatic rewriting of sectors<br>
takes too long and the write buffers overflow.<br>
4) The hard drive is shingled and the shingle rewrite delays cause the<br>
write buffers to overflow.<br>
4) The tuner is failing.<br>
5) The tuner is a USB one and is having problems due to a bad USB<br>
connection (or the cat sat on its cable).<br>
6) There are too many recordings going to the same hard drive at the<br>
same time and the heads can not move between all the locations fast<br>
enough, so the write buffers overflow.<br>
7) You are using network tuners and have a network problem that is<br>
causing packet loss or damage, permanently or intermittently.<br>
<br>
There are likely more, but those are the ones that I can think of at<br>
the moment and are all things I have encountered and are moderately<br>
likely to happen.<br><br></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace,monospace">Don't forget the infamous Silicon Dust bad PSUs on the HDHRs.  I have never had an HDHDR that I did not have to replace failing power supplies on - Although I have only had (4). </div></div></div>