Mailing List Archive

Priority et al
More and more I'm finding the scheduler is Not Recording a current program To be recorded Later.
There is no logic ie I have 4 of 4 tuners available.
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.
[.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.
Reason for the crazy logic: I get no damaged recordings with no virtual tuners, but occasional ones with virtual tuners.

Can I change priorities to force recording of first showing ? Must I resort to clever SQL and custom rules ?

James

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Priority et al [ In reply to ]
On Mon, 25 Sep 2023 22:10:23 +0800, you wrote:

>More and more I'm finding the scheduler is Not Recording a current program To be recorded Later.
>There is no logic ie I have 4 of 4 tuners available.
>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.
>[.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.
>Reason for the crazy logic: I get no damaged recordings with no virtual tuners, but occasional ones with virtual tuners.
>
>Can I change priorities to force recording of first showing ? Must I resort to clever SQL and custom rules ?
>
>James

You should be able to have the priorities set up so that the first
showing will record. To try to find out where the priorities are
going wrong, in Mythfrontend in the Upcoming Recordings list, use the
I key twice and scroll down and you will see the priority calculated
for that showing and a breakdown of how it was calculated. Look at
both the showings that are going to record Later and the previous ones
that you wanted it to record. Use the 1 key to get the full list of
upcoming recordings ("All" recordings), including all those not going
to record. Use the 2 key to get the list back to just the "Important"
showings (those that will record or where there is some warning).

Also, getting damaged recordings with virtual tuners does not make any
sense. There are many of us using virtual tuners and not having any
problems with them.

The usual causes for damaged recordings (where the recording did start
properly in the first place) are:
1) The signal coming into the tuner is damaged.
2) The hard drive is failing and there are damaged sectors, where the
data is not written correctly.
3) The hard drive is failing and the automatic rewriting of sectors
takes too long and the write buffers overflow.
4) The hard drive is shingled and the shingle rewrite delays cause the
write buffers to overflow.
4) The tuner is failing.
5) The tuner is a USB one and is having problems due to a bad USB
connection (or the cat sat on its cable).
6) There are too many recordings going to the same hard drive at the
same time and the heads can not move between all the locations fast
enough, so the write buffers overflow.
7) You are using network tuners and have a network problem that is
causing packet loss or damage, permanently or intermittently.

There are likely more, but those are the ones that I can think of at
the moment and are all things I have encountered and are moderately
likely to happen.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Priority et al [ In reply to ]
On Mon, Sep 25, 2023 at 11:03?AM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Mon, 25 Sep 2023 22:10:23 +0800, you wrote:
>
> >More and more I'm finding the scheduler is Not Recording a current
> program To be recorded Later.
> >There is no logic ie I have 4 of 4 tuners available.
> >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.
> >[.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.
> >Reason for the crazy logic: I get no damaged recordings with no virtual
> tuners, but occasional ones with virtual tuners.
> >
> >Can I change priorities to force recording of first showing ? Must I
> resort to clever SQL and custom rules ?
> >
> >James
>
> You should be able to have the priorities set up so that the first
> showing will record. To try to find out where the priorities are
> going wrong, in Mythfrontend in the Upcoming Recordings list, use the
> I key twice and scroll down and you will see the priority calculated
> for that showing and a breakdown of how it was calculated. Look at
> both the showings that are going to record Later and the previous ones
> that you wanted it to record. Use the 1 key to get the full list of
> upcoming recordings ("All" recordings), including all those not going
> to record. Use the 2 key to get the list back to just the "Important"
> showings (those that will record or where there is some warning).
>
> Also, getting damaged recordings with virtual tuners does not make any
> sense. There are many of us using virtual tuners and not having any
> problems with them.
>
> The usual causes for damaged recordings (where the recording did start
> properly in the first place) are:
> 1) The signal coming into the tuner is damaged.
> 2) The hard drive is failing and there are damaged sectors, where the
> data is not written correctly.
> 3) The hard drive is failing and the automatic rewriting of sectors
> takes too long and the write buffers overflow.
> 4) The hard drive is shingled and the shingle rewrite delays cause the
> write buffers to overflow.
> 4) The tuner is failing.
> 5) The tuner is a USB one and is having problems due to a bad USB
> connection (or the cat sat on its cable).
> 6) There are too many recordings going to the same hard drive at the
> same time and the heads can not move between all the locations fast
> enough, so the write buffers overflow.
> 7) You are using network tuners and have a network problem that is
> causing packet loss or damage, permanently or intermittently.
>
> There are likely more, but those are the ones that I can think of at
> the moment and are all things I have encountered and are moderately
> likely to happen.
>
>
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).
Re: Priority et al [ In reply to ]
> On 26 Sep 2023, at 12:23 am, Greg Oliver <oliver.greg@gmail.com> wrote:
>
> On Mon, Sep 25, 2023 at 11:03?AM Stephen Worthington <stephen_agent@jsw.gen.nz> wrote:
> On Mon, 25 Sep 2023 22:10:23 +0800, you wrote:
>
> >More and more I'm finding the scheduler is Not Recording a current program To be recorded Later.
> >There is no logic ie I have 4 of 4 tuners available.
> >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.
> >[.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.
> >Reason for the crazy logic: I get no damaged recordings with no virtual tuners, but occasional ones with virtual tuners.
> >
> >Can I change priorities to force recording of first showing ? Must I resort to clever SQL and custom rules ?
> >
> >James
>
> You should be able to have the priorities set up so that the first
> showing will record. To try to find out where the priorities are
> going wrong, in Mythfrontend in the Upcoming Recordings list, use the
> I key twice and scroll down and you will see the priority calculated
> for that showing and a breakdown of how it was calculated. Look at
> both the showings that are going to record Later and the previous ones
> that you wanted it to record. Use the 1 key to get the full list of
> upcoming recordings ("All" recordings), including all those not going
> to record. Use the 2 key to get the list back to just the "Important"
> showings (those that will record or where there is some warning).
>
> Also, getting damaged recordings with virtual tuners does not make any
> sense. There are many of us using virtual tuners and not having any
> problems with them.

The little anecdote about my wife was to highlight the impossible

First thanks lots.
My backend is using a 2T m2 flash
and a 4T SATA flash
I have 2 haupauge usb twin-tuners each on a 30 cm cable to a usb-3 port (on a nuc)
(Lots of signal woes, so I have a professionally installed external antenna with an indoor amplifier (there are 4 inputs) all using type N cable with 20Km unobstructed to the transmitter farm)
I tried ubuntu and SuSE as my backend.
I changed the nuc to i7 i3 and rysan. Since I do my development work on VMs that machine has 24G ram.
I built mythbackend from src and am using upto date 32/fixes

1 in 25 recordings has severe pixelization with virtual tuners, the rest are perfect.
I have not seen a damaged recording without virtual tuners
(as expected) the workload on the backend machine has no effect.

I have not narrowed down if all bad recordings come from a single tuner, but I would expect that random plug in - plug outs to show a pattern, which I've not seen. In fact with virtual tuners I'd expect all-good or all-bad depending on which was plugged in as number-one (since I seldom record more than 3 shows)

I'd expect network problems to manifest as intermittent frontend issues, but the recordings are damaged, and flagged a damaged, and the 'recording system' does not use the network.

I have built test systems with lucky-packet tuners and an indoor rabbit-ears that work beautifully.
Since I'm not short of tuners my setup suits me, but I'd be curious about any opinions.
James


>
> The usual causes for damaged recordings (where the recording did start
> properly in the first place) are:
> 1) The signal coming into the tuner is damaged.
> 2) The hard drive is failing and there are damaged sectors, where the
> data is not written correctly.
> 3) The hard drive is failing and the automatic rewriting of sectors
> takes too long and the write buffers overflow.
> 4) The hard drive is shingled and the shingle rewrite delays cause the
> write buffers to overflow.
> 4) The tuner is failing.
> 5) The tuner is a USB one and is having problems due to a bad USB
> connection (or the cat sat on its cable).
> 6) There are too many recordings going to the same hard drive at the
> same time and the heads can not move between all the locations fast
> enough, so the write buffers overflow.
> 7) You are using network tuners and have a network problem that is
> causing packet loss or damage, permanently or intermittently.
>
> There are likely more, but those are the ones that I can think of at
> the moment and are all things I have encountered and are moderately
> likely to happen.
>
>
> 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).
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org