Mailing List Archive

> This was part of another thread. Started clean ..
>
>> On 4 Mar 2023, at 5:03 pm, Stephen Worthington <stephen_agent@jsw.gen.nz> wrote:
>>
>> On Sat, 4 Mar 2023 15:16:22 +0800, you wrote:
>>
>>> Hmmm using fixes/32. I had a single very bad recording so I went hunting to see if THAT tuner is bad:
>>>
>>> [seagull] /var/log/mythtv [1998]% grep 'overall_score' mythbackend.*
>>> mythbackend.20230219020210.2421.log-20230302:<RecordingQuality overall_score="0.5" key="10032_2023-03-01T13:32:00Z" continuity_error_count="224286" packet_count="15540838" />
>>>
>>> The *only* entry is for that recording and it does not identify the tuner.
>>> I've not gone spelunking but are there debug flags to set?
>>>
>>> James
>>
>> You may need to add the "-v record" option on the mythbackend command
>> line.
>
> What I have got is 2 dual tuner haupague USB dongles (each on nuc usb-3 internally own hub)
>
> The numbers show that I've tried channel setup a few times, but what I setup is each of the 4 tuners has 1 virtual tuner.
> Status shure does not say that:
>
> Encoder 36 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
> Encoder 37 [ DVB : /dev/dvb/adapter1/frontend0 ] is local on seagull and is not recording.
> Encoder 38 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
> Encoder 39 [ DVB : /dev/dvb/adapter1/frontend0 ] is local on seagull and is not recording.
> Encoder 40 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
> Encoder 41 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
>
> Encoder 42 [ DVB : /dev/dvb/adapter2/frontend0 ] is local on seagull and is not recording.
> Encoder 43 [ DVB : /dev/dvb/adapter3/frontend0 ] is local on seagull and is not recording.
> Encoder 44 [ DVB : /dev/dvb/adapter2/frontend0 ] is local on seagull and is not recording.
> Encoder 45 [ DVB : /dev/dvb/adapter3/frontend0 ] is local on seagull and is not recording.
>
> Encoder 46 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
> Encoder 47 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
> Encoder 48 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
> Encoder 49 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
> Encoder 50 [ DVB : /dev/dvb/adapter1/frontend0 ] is local on seagull and is not recording.
> Encoder 51 [ DVB : /dev/dvb/adapter1/frontend0 ] is local on seagull and is not recording.
>
> Encoder 52 [ DVB : /dev/dvb/adapter2/frontend0 ] is local on seagull and is recording 'The Break Up (2006)' on 9Go! Perth. This recording is scheduled to end at 12:23 AM.
>
> My errors are limited to some cards. ie 39 seems to be a duplicate of 37 !
>
> [seagull] /home/jam [1996]% grep cardid /var/log/mythtv/mythbackend.log |grep Fail
> 2023-03-20T19:50:00.827912+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "ABC News" on cardid [41] (Recording => Recorder Failed)
> 2023-03-20T19:50:00.930959+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "ABC News" on cardid [40] (Recording => Recorder Failed)
> 2023-03-20T21:52:50.111131+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "Media Watch" on cardid [39] (Recording => Recorder Failed)
> 2023-03-22T19:49:14.142173+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "Couples Retreat (2009)":"Couples Retreat" on cardid [42] (Tuning => Failing)
> 2023-03-22T20:30:13.044778+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "Motorway Cops: Catching Britain's Speeders" on cardid [44] (Tuning => Failing)
> 2023-03-22T21:50:35.075073+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "The Break Up (2006)":"The Break Up" on cardid [52] (Tuning => Failing)
> 2023-03-22T21:50:59.539080+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "Motorway Cops: Catching Britain's Speeders" on cardid [44] (Failing => Recorder Failed)
> 2023-03-22T22:10:29.492360+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "Couples Retreat (2009)":"Couples Retreat" on cardid [42] (Failing => Recorder Failed)
>
> Is there any obvious gotcha or shall I (again) delete all cards and add again? AFAICS there should be adapters 0..3 each with a frontend 0/1.

Even though I've been using myth for years-n there is still lots I do not know.

I'm sure I allocated a channel for each card and for each virtual channel last time I setup.
I (now) allocated 4 channels each with 1 virtual channel and status shows 8 channels. All good.

LiveTV and C cycles throgh 4 channels. All 4 play without hitch.
I expect 8. Howto?

Can you name each channel (of course you can) and each virtual channel? Just say SQL if needed and I can do the rest.

Does the scheduler choose real channels first then virtual ones ? I have not changed any priorities

thanks
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

On Thu, 23 Mar 2023 15:27:53 +0800, you wrote:

>> This was part of another thread. Started clean ..
>>
>>> On 4 Mar 2023, at 5:03 pm, Stephen Worthington <stephen_agent@jsw.gen.nz> wrote:
>>>
>>> On Sat, 4 Mar 2023 15:16:22 +0800, you wrote:
>>>
>>>> Hmmm using fixes/32. I had a single very bad recording so I went hunting to see if THAT tuner is bad:
>>>>
>>>> [seagull] /var/log/mythtv [1998]% grep 'overall_score' mythbackend.*
>>>> mythbackend.20230219020210.2421.log-20230302:<RecordingQuality overall_score="0.5" key="10032_2023-03-01T13:32:00Z" continuity_error_count="224286" packet_count="15540838" />
>>>>
>>>> The *only* entry is for that recording and it does not identify the tuner.
>>>> I've not gone spelunking but are there debug flags to set?
>>>>
>>>> James
>>>
>>> You may need to add the "-v record" option on the mythbackend command
>>> line.
>>
>> What I have got is 2 dual tuner haupague USB dongles (each on nuc usb-3 internally own hub)
>>
>> The numbers show that I've tried channel setup a few times, but what I setup is each of the 4 tuners has 1 virtual tuner.
>> Status shure does not say that:
>>
>> Encoder 36 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
>> Encoder 37 [ DVB : /dev/dvb/adapter1/frontend0 ] is local on seagull and is not recording.
>> Encoder 38 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
>> Encoder 39 [ DVB : /dev/dvb/adapter1/frontend0 ] is local on seagull and is not recording.
>> Encoder 40 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
>> Encoder 41 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
>>
>> Encoder 42 [ DVB : /dev/dvb/adapter2/frontend0 ] is local on seagull and is not recording.
>> Encoder 43 [ DVB : /dev/dvb/adapter3/frontend0 ] is local on seagull and is not recording.
>> Encoder 44 [ DVB : /dev/dvb/adapter2/frontend0 ] is local on seagull and is not recording.
>> Encoder 45 [ DVB : /dev/dvb/adapter3/frontend0 ] is local on seagull and is not recording.
>>
>> Encoder 46 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
>> Encoder 47 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
>> Encoder 48 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
>> Encoder 49 [ DVB : /dev/dvb/adapter0/frontend0 ] is local on seagull and is not recording.
>> Encoder 50 [ DVB : /dev/dvb/adapter1/frontend0 ] is local on seagull and is not recording.
>> Encoder 51 [ DVB : /dev/dvb/adapter1/frontend0 ] is local on seagull and is not recording.
>>
>> Encoder 52 [ DVB : /dev/dvb/adapter2/frontend0 ] is local on seagull and is recording 'The Break Up (2006)' on 9Go! Perth. This recording is scheduled to end at 12:23 AM.
>>
>> My errors are limited to some cards. ie 39 seems to be a duplicate of 37 !
>>
>> [seagull] /home/jam [1996]% grep cardid /var/log/mythtv/mythbackend.log |grep Fail
>> 2023-03-20T19:50:00.827912+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "ABC News" on cardid [41] (Recording => Recorder Failed)
>> 2023-03-20T19:50:00.930959+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "ABC News" on cardid [40] (Recording => Recorder Failed)
>> 2023-03-20T21:52:50.111131+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "Media Watch" on cardid [39] (Recording => Recorder Failed)
>> 2023-03-22T19:49:14.142173+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "Couples Retreat (2009)":"Couples Retreat" on cardid [42] (Tuning => Failing)
>> 2023-03-22T20:30:13.044778+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "Motorway Cops: Catching Britain's Speeders" on cardid [44] (Tuning => Failing)
>> 2023-03-22T21:50:35.075073+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "The Break Up (2006)":"The Break Up" on cardid [52] (Tuning => Failing)
>> 2023-03-22T21:50:59.539080+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "Motorway Cops: Catching Britain's Speeders" on cardid [44] (Failing => Recorder Failed)
>> 2023-03-22T22:10:29.492360+08:00 seagull mythbackend: mythbackend[18886]: I CoreContext scheduler.cpp:717 (UpdateRecStatus) Updating status for "Couples Retreat (2009)":"Couples Retreat" on cardid [42] (Failing => Recorder Failed)
>>
>> Is there any obvious gotcha or shall I (again) delete all cards and add again? AFAICS there should be adapters 0..3 each with a frontend 0/1.
>
>Even though I've been using myth for years-n there is still lots I do not know.
>
>I'm sure I allocated a channel for each card and for each virtual channel last time I setup.
>I (now) allocated 4 channels each with 1 virtual channel and status shows 8 channels. All good.
>
>LiveTV and C cycles throgh 4 channels. All 4 play without hitch.
>I expect 8. Howto?
>
>Can you name each channel (of course you can) and each virtual channel? Just say SQL if needed and I can do the rest.
>
>Does the scheduler choose real channels first then virtual ones ? I have not changed any priorities
>
>thanks
>James

There are two options for handling virtual tuners now, the old way,
where you specify how many there are for each tuner, and the new way,
where you let MythTV handle the creation of virtual tuners as
required. For the new scheme, in mythtv-setup > Input connections >
select a tuner > Interactions between inputs tick the "Schedule as a
group" option. I have not tried this myself, as it was not available
back when I set up my tuners. I still use the old way and set the
"Max recordings" option to the number of virtual tuners I want. One
menu back up from there on the first tuner page, the "Display name"
option allows you to set the name for all the virtual tuners
associated with that physical tuner. One name for all of them. If
you want to give each individual virtual tuner a different name, as I
do, then you have to directly modify the capturecard.displayname field
in the database. If you subsequently edit the mythtv-setup "Display
name" field, I expect that the new name will be put on all the virtual
tuners for that physical tuner, but I have never tied that. The first
virtual tuner for each physical tuner has capturecard.parentid=0. All
the other virtual tuners for the same physical tuner have
capturecard.parentid set to the cardid of the first virtual tuner.
Here is what my DVB-T tuners look like, with 5 virtual tuners per
physical tuner:

MariaDB [mythconverg]> select
cardid,parentid,videodevice,inputname,displayname,schedorder,livetvorder
from capturecard where sourceid=1 order by videodevice,cardid;
+--------+----------+-----------------------------+-----------+----------------+------------+-------------+
| cardid | parentid | videodevice | inputname | displayname | schedorder | livetvorder |
+--------+----------+-----------------------------+-----------+----------------+------------+-------------+
| 1 | 0 | /dev/dvb/adapter0/frontend0 | DVB-T | DVB-T 1.1 (1) | 1 | 1 |
| 2 | 1 | /dev/dvb/adapter0/frontend0 | DVB-T | DVB-T 1.2 (2) | 1 | 1 |
| 3 | 1 | /dev/dvb/adapter0/frontend0 | DVB-T | DVB-T 1.3 (3) | 1 | 1 |
| 4 | 1 | /dev/dvb/adapter0/frontend0 | DVB-T | DVB-T 1.4 (4) | 1 | 1 |
| 5 | 1 | /dev/dvb/adapter0/frontend0 | DVB-T | DVB-T 1.5 (5) | 1 | 1 |
| 6 | 0 | /dev/dvb/adapter1/frontend0 | DVB-T | DVB-T 2.1 (6) | 2 | 2 |
| 7 | 6 | /dev/dvb/adapter1/frontend0 | DVB-T | DVB-T 2.2 (7) | 2 | 2 |
| 8 | 6 | /dev/dvb/adapter1/frontend0 | DVB-T | DVB-T 2.3 (8) | 2 | 2 |
| 9 | 6 | /dev/dvb/adapter1/frontend0 | DVB-T | DVB-T 2.4 (9) | 2 | 2 |
| 10 | 6 | /dev/dvb/adapter1/frontend0 | DVB-T | DVB-T 2.5 (10) | 2 | 2 |
| 11 | 0 | /dev/dvb/adapter2/frontend0 | DVB-T | DVB-T 3.1 (11) | 3 | 3 |
| 12 | 11 | /dev/dvb/adapter2/frontend0 | DVB-T | DVB-T 3.2 (12) | 3 | 3 |
| 13 | 11 | /dev/dvb/adapter2/frontend0 | DVB-T | DVB-T 3.3 (13) | 3 | 3 |
| 14 | 11 | /dev/dvb/adapter2/frontend0 | DVB-T | DVB-T 3.4 (14) | 3 | 3 |
| 15 | 11 | /dev/dvb/adapter2/frontend0 | DVB-T | DVB-T 3.5 (15) | 3 | 3 |
| 16 | 0 | /dev/dvb/adapter3/frontend0 | DVB-T | DVB-T 4.1 (16) | 4 | 4 |
| 17 | 16 | /dev/dvb/adapter3/frontend0 | DVB-T | DVB-T 4.2 (17) | 4 | 4 |
| 18 | 16 | /dev/dvb/adapter3/frontend0 | DVB-T | DVB-T 4.3 (18) | 4 | 4 |
| 19 | 16 | /dev/dvb/adapter3/frontend0 | DVB-T | DVB-T 4.4 (19) | 4 | 4 |
| 20 | 16 | /dev/dvb/adapter3/frontend0 | DVB-T | DVB-T 4.5 (20) | 4 | 4 |
| 21 | 0 | /dev/dvb/adapter4/frontend0 | DVB-T | DVB-T 5.1 (21) | 5 | 5 |
| 22 | 21 | /dev/dvb/adapter4/frontend0 | DVB-T | DVB-T 5.2 (22) | 5 | 5 |
| 23 | 21 | /dev/dvb/adapter4/frontend0 | DVB-T | DVB-T 5.3 (23) | 5 | 5 |
| 24 | 21 | /dev/dvb/adapter4/frontend0 | DVB-T | DVB-T 5.4 (24) | 5 | 5 |
| 25 | 21 | /dev/dvb/adapter4/frontend0 | DVB-T | DVB-T 5.5 (25) | 5 | 5 |
+--------+----------+-----------------------------+-----------+----------------+------------+-------------+
25 rows in set (0.000 sec)

If you want a good GUI program for editing your database tables (such
as manually changing the displayname fields), I recommend DBeaver:

https://dbeaver.io

If is free and open source and is available as a package on most
distros.

As far as I know, the scheduler uses virtual tuners in cardid order,
firstly using the next available virtual tuner from a physical tuner
that is going to be tuned on the same multiplex. If it needs a
different multiplex, it will pick the first virtual tuner on a free
physical tuner. However, there are priorities that will override the
choice of tuners, such as manual assignment of a virtual tuner in the
recording rule, or priority given to recordings when on a certain
tuner. And the capturecard.schedorder and capturecard.livetvorder
fields (if you have set them up), tell the scheduler which order you
want your physical tuners used in. All virtual tuner rows for the
same physical tuner have the same order field values - do not manually
change them or the scheduler is unlikely to work very well. It is
common to have the livetvorder set up in the reverse order to the
schedorder, but I have mine both in the same order as I have as many
physical tuners as NZ has broadcast muxes, so I will never run out of
tuners. In order to simplify debugging, I have priorities set to make
the scheduler use specific tuners for specific muxes:

MariaDB [mythconverg]> select * from powerpriority order by
priorityname;
+----------------------------+-------------+---------------------------------------------------+
| priorityname | recpriority | selectclause |
+----------------------------+-------------+---------------------------------------------------+
| Discovery multiplex | 20 | channel.mplexid=29 and cardid in (11,12,13,14,15) |
| Kordia 2 multiplex | 20 | channel.mplexid=1 and cardid in (16,17,18,19,20) |
| Kordia 3 (Maori) multiplex | 20 | channel.mplexid=21 and cardid in (21,22,23,24,25) |
| Kordia multiplex | 20 | channel.mplexid=4 and cardid in (6,7,8,9,10) |
| Mediaworks multiplex | 20 | channel.mplexid=3 and cardid in (11,12,13,14,15) |
| TVNZ multiplex | 20 | channel.mplexid=2 and cardid in (1,2,3,4,5) |
+----------------------------+-------------+---------------------------------------------------+

The "Mediaworks multiplex" row is redundant - when Discovery bought
the TV stations from Mediaworks, the retuning at the time created a
new multiplex (mplexid=29) and the old mplexid=4 is no longer used. So
it looks like I should now delete that row.

Even with the above rules, if the scheduler can not schedule something
on the high priority tuner for that mux (for example, if I am
recording more than 5 things at once from a mux, including overlaps),
it will use another tuner of lower priority and tune it to the same
mux.
_______________________________________________
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