Project

General

Profile

Bug #5128

When tuner is configured as a slave device, after reboot settings are lost

Added by Trex the Daemon over 1 year ago. Updated 9 months ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
Configuration
Target version:
-
Start date:
2018-06-10
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3
Affected Versions:

Description

I have 3 tv tuners:
- Dvbsky S960 DVB-S2,
- Sundtek Skytv ultimate v6 DVB-S2
- Dvbsky T330 DVB-C+DVB-T

I have usals and multiple sattelites configured.
Now the DVBSKY and Sundtek are connected through a splitter to the same LNB, therefore I wanted to set the DVBSKY as a slave.
After configuring everything, after reboot the settings are lost and the slave tuner reverts back to "Universal only" and no network configured.
I've attached the whole configuration, only the passwords are deleted for security reasons.


Files

backup_hts_10-06-2018.zip (8.21 MB) backup_hts_10-06-2018.zip Trex the Daemon, 2018-06-10 14:47
65cce2b6dc875ed17dffe0c5ee91c5c5 (722 Bytes) 65cce2b6dc875ed17dffe0c5ee91c5c5 Trex the Daemon, 2019-03-06 19:31
44128f8e1ad13b8417dac31e4e12521e (1.12 KB) 44128f8e1ad13b8417dac31e4e12521e Trex the Daemon, 2019-03-06 19:31
Capture.PNG (51.7 KB) Capture.PNG Trex the Daemon, 2019-03-06 19:35

Associated revisions

Revision 937a5fb7 (diff)
Added by Jaroslav Kysela 9 months ago

linuxdvb: create the mux instances also for the slave tuners, issue #5128

Revision 453ee8df (diff)
Added by Jaroslav Kysela 9 months ago

linuxdvb: use the right configuration root for the slave tuners (loading), issue #5128

History

#1

Updated by Jaroslav Kysela over 1 year ago

You may try to swap master/slave devices. Appearently, if the order is wrong (slave is first at the load time), the config is not restored properly, because master does not exist.

#2

Updated by Trex the Daemon over 1 year ago

Jaroslav Kysela wrote:

You may try to swap master/slave devices. Appearently, if the order is wrong (slave is first at the load time), the config is not restored properly, because master does not exist.

Thanks. I will have to create some udev rules to specify the adapter names statically, so that the master device will always get the /dev/adapter0 entry.

#3

Updated by Trex the Daemon over 1 year ago

Trex the Daemon wrote:

Jaroslav Kysela wrote:

You may try to swap master/slave devices. Appearently, if the order is wrong (slave is first at the load time), the config is not restored properly, because master does not exist.

Thanks. I will have to create some udev rules to specify the adapter names statically, so that the master device will always get the /dev/adapter0 entry.

Well, I've just checked the startup log and what we've assumed here seems to not be the reason:

Jun 12 15:22:45 raspberrypi tvheadend[21472]: linuxdvb: adapter added /dev/dvb/adapter2
Jun 12 15:22:45 raspberrypi tvheadend[21472]: linuxdvb: adapter added /dev/dvb/adapter1
Jun 12 15:22:45 raspberrypi tvheadend[21472]: linuxdvb: adapter added /dev/dvb/adapter0

So adapter 2 is the master adapter, and adapter 1 is the slave. If we take the order of the addition of the adapters, the master does exist before the slave is added.

Could you tell me where is this part of the code implemented ? Maybe I can have a look to see if I can find something there..

#4

Updated by Jaroslav Kysela over 1 year ago

It seems that the order should not matter. The master tuner should be identified just using the uuid string. Check linuxdvb_frontend_create() linuxdvb_frontend_save() in src/input/mpegts/linuxdvb/linuxdvb_frontend.c . Look for 'master for #' strings.

#5

Updated by Trex the Daemon over 1 year ago

Jaroslav Kysela wrote:

It seems that the order should not matter. The master tuner should be identified just using the uuid string. Check linuxdvb_frontend_create() linuxdvb_frontend_save() in src/input/mpegts/linuxdvb/linuxdvb_frontend.c . Look for 'master for #' strings.

I've just checked in the config file the UUID and they are correct.
I'll have a look in the code...

#6

Updated by Jaroslav Kysela over 1 year ago

There must be something wrong - linuxdvb_frontend_dvbs_slave_class is not probably used for the slave.

#7

Updated by Trex the Daemon over 1 year ago

Jaroslav Kysela wrote:

There must be something wrong - linuxdvb_frontend_dvbs_slave_class is not probably used for the slave.

I've checked the code but I'm not quite getting what here is meant:
/* Tuner slave */
snprintf(buf, sizeof(buf), "master for #%d", number);
if (conf && type == DVB_TYPE_S) {
muuid = htsmsg_get_str(conf, buf);
if (muuid && uuid && !strcmp(muuid, uuid))
muuid = NULL;
}

It gets the uuid of the master I suppose, and then checks to make sure that the master and the slave uuids are different ? What's the reason for that?

Later on, depending if we have a master uuid, it will use the correct pointer:
if (type == DVB_TYPE_S)
idc = muuid ? &linuxdvb_frontend_dvbs_slave_class : &linuxdvb_frontend_dvbs_class;

so this should be fine..

#8

Updated by Trex the Daemon about 1 year ago

Trex the Daemon wrote:

Jaroslav Kysela wrote:

There must be something wrong - linuxdvb_frontend_dvbs_slave_class is not probably used for the slave.

I've checked the code but I'm not quite getting what here is meant:
/* Tuner slave */
snprintf(buf, sizeof(buf), "master for #%d", number);
if (conf && type == DVB_TYPE_S) {
muuid = htsmsg_get_str(conf, buf);
if (muuid && uuid && !strcmp(muuid, uuid))
muuid = NULL;
}

It gets the uuid of the master I suppose, and then checks to make sure that the master and the slave uuids are different ? What's the reason for that?

Later on, depending if we have a master uuid, it will use the correct pointer:
if (type == DVB_TYPE_S)
idc = muuid ? &linuxdvb_frontend_dvbs_slave_class : &linuxdvb_frontend_dvbs_class;

so this should be fine..

Well, this issue is still present, now on a different device..

#9

Updated by Jaroslav Kysela about 1 year ago

Have you had verified (use printf or gdb) if linuxdvb_frontend_dvbs_slave_class is really used for the slave frontend?

#10

Updated by Trex the Daemon 9 months ago

Jaroslav Kysela wrote:

Have you had verified (use printf or gdb) if linuxdvb_frontend_dvbs_slave_class is really used for the slave frontend?

Sorry, did not have time to debug this.
Meanwhile I've changed the dvbsky to another sundtek tuner, and the same issue happens also here, after reboot, the tuner that was configured as slave looses it's settings and will become master again with "Universal LNB".
Interesting is, that in the config file it looks ok.
44128f8e1ad13b8417dac31e4e12521e is the master, and 65cce2b6dc875ed17dffe0c5ee91c5c5 is set as slave (see the logs).

Tvheadend version is 4.3-1774, but it's already present in previous 4.3 version.
However, in stable 4.2 it's not!

#11

Updated by Trex the Daemon 9 months ago

Trex the Daemon wrote:

Jaroslav Kysela wrote:

Have you had verified (use printf or gdb) if linuxdvb_frontend_dvbs_slave_class is really used for the slave frontend?

Sorry, did not have time to debug this.
Meanwhile I've changed the dvbsky to another sundtek tuner, and the same issue happens also here, after reboot, the tuner that was configured as slave looses it's settings and will become master again with "Universal LNB".
Interesting is, that in the config file it looks ok.
44128f8e1ad13b8417dac31e4e12521e is the master, and 65cce2b6dc875ed17dffe0c5ee91c5c5 is set as slave (see the logs).

Tvheadend version is 4.3-1774, but it's already present in previous 4.3 version.
However, in stable 4.2 it's not!

Also, Ive checked that if in the list, the slave tuner is the second, it will also show as master, so the position during initalization does not matter.

#12

Updated by Deep Thought 9 months ago

The bug is caused as follows: In linuxdvb_frontend_create,
on entry, conf points to "frontends", but is value is overwritten

by the following code:

  /* Internal config ID */
  snprintf(id, sizeof(id), "%s #%d", dvb_type2str(type), number);
  if (conf)
    conf = htsmsg_get_map(conf, id);

The key,value pair for "master for #0" is part of the "frontends" map
but it is now looked up in "DVB-S #0" instead, and is not found.

The solution is to save the initial value of conf, and then to use it
for looking up "master for #0" . E.g.:

linuxdvb_frontend_t *
linuxdvb_frontend_create
  ( htsmsg_t *conf, linuxdvb_adapter_t *la, int number,
    const char *fe_path, const char *dmx_path, const char *dvr_path,
    dvb_fe_type_t type, const char *name )
{
  const idclass_t *idc;
  const char *str, *uuid = NULL, *muuid = NULL;
  char id[16], lname[256], buf[256];
  linuxdvb_frontend_t *lfe;
  htsmsg_t *scconf;
  ssize_t r;
  int fd;
  htsmsg_t * oldconf =conf;

  /* Internal config ID */
  snprintf(id, sizeof(id), "%s #%d", dvb_type2str(type), number);
  if (conf)
    conf = htsmsg_get_map(conf, id);
  if (conf)
    uuid = htsmsg_get_str(conf, "uuid");

  /* Tuner slave */
  snprintf(buf, sizeof(buf), "master for #%d", number);
  if (conf && type == DVB_TYPE_S) {
    muuid = htsmsg_get_str(oldconf, buf);
    if (muuid && uuid && !strcmp(muuid, uuid))
      muuid = NULL;
  }
...
#13

Updated by Deep Thought 9 months ago

However, the above code change is not sufficient.

A slave tuner should be able to tune to the same network as its master tuner.
In reality it refuses to tune to anything, unless a list of networks is filled
in the adapter config file. However, there is no way of setting this list
of networks from the web ui.

I also noticed that even after setting the field "master tuner", the web ui still
shows information for switches, which it should not do.

How is this supposed to work?
I assume that the user should NOT set networks for the slave tuners,
but then the code should use the networks from the master and it does not.
Perhaps still another bug?

#14

Updated by Trex the Daemon 9 months ago

Deep Thought wrote:

However, the above code change is not sufficient.

A slave tuner should be able to tune to the same network as its master tuner.
In reality it refuses to tune to anything, unless a list of networks is filled
in the adapter config file. However, there is no way of setting this list
of networks from the web ui.

I also noticed that even after setting the field "master tuner", the web ui still
shows information for switches, which it should not do.

How is this supposed to work?
I assume that the user should NOT set networks for the slave tuners,
but then the code should use the networks from the master and it does not.
Perhaps still another bug?

Hello,
Well, all I can say is that on 4.2, once you've set the tuner to "slave" and restarted tvheadend, from the gui all other settings, as network mapping disappeared. I've tested by occupying one of the tuners and then requested a second channel, from the same polarity and orbital position. Tvheadend then used the slave tuner to tune and serve the second request.
So for some reason, this has been broken in the 4.3 versions.

#15

Updated by Deep Thought 9 months ago

Yes, my comment was about 4.3. With the above patch, the slave tuner status is permanent (which
is good). The settings which should be hidden eventually are hidden, but not immediately.

I did discover that if you add the networks of the master in the config file of the slave,
the slave tuners can be used. However, this does not sound like the correct solution,
as the slave tuner should simply use the same network as the master tuner.

#16

Updated by Jaroslav Kysela 9 months ago

Retest with v4.3-1787-g453ee8dfd .

#17

Updated by Deep Thought 9 months ago

I have tested and can confirm that this problem is now
solved.

:)

Thanks

#18

Updated by Deep Thought 9 months ago

There still is one problem: when initially configuring a slave tuner, you need to
check some boxes for each of the wanted networks. However, after a restart of tvheadend,the
screen to change these choices is missing.

#19

Updated by Jaroslav Kysela 9 months ago

  • Status changed from New to Fixed

Also available in: Atom PDF