Beyonwiz Australia

Posted: **Sun Nov 12, 2017 15:11**

Previous incidents noted here and in the post following that one.

I noticed this issue myself today where after boot from deep standby, the USB tuner attached to the T2 was identified as type DVB-S2. The tuner wasn't usable.

Two new options appeared in the "Tuner setup" screen (MENU->Tuners->Tuner allocation) -
Preferred tuner DVB-T
Preferred tuner DVB-T for recordings

I restarted the UI and Device Information now reports the USB tuner correctly as type DVB-T, and those two new options weren't shown in the "Tuner setup" screen.

Does this point to a firmware issue and not a driver issue, since the issue has been observed with different dongles/drivers, and that after a UI restart it was correctly reported?

At boot time, the tuner appers to be identified as terrestrial in /var/log/messages -

Code: Select all

Nov 12 11:35:25 beyonwizt2 user.info kernel: usb 1-1: DVB: registering adapter 1 frontend 0 (Realtek RTL2832 (DVB-T))...

The tuner type is identified as DVB-T in /var/log/messages on both occasions - (i) after boot from deep standby, when the UI identified the tuner as DVB-S2, and (ii) after UI restart, when it was identified as DVB-T

After boot from deep standby -

Code: Select all

Nov 12 11:35:29 beyonwizt2 user.info kernel: dvb dvb.0: DVB: registering adapter 0 frontend 0 ()...
Nov 12 11:35:29 beyonwizt2 user.notice kernel: vtunerc0: VTUNER_SET_NAME 'RTL2838UHIDIR'
Nov 12 11:35:29 beyonwizt2 user.notice kernel: vtunerc0: VTUNER_SET_TYPE 'DVB-T' => 'RTL2838UHIDIR'
Nov 12 11:35:29 beyonwizt2 user.err kernel: vtunerc0: unknown IOCTL 0x6
Nov 12 11:35:29 beyonwizt2 user.err kernel: vtunerc0: unknown IOCTL 0x20
Nov 12 11:35:29 beyonwizt2 user.err kernel: vtunerc0: unknown IOCTL 0x21

After UI restart -

Code: Select all

Nov 12 12:03:09 beyonwizt2 user.info kernel: dvb dvb.0: DVB: registering adapter 0 frontend 0 ()...
Nov 12 12:03:09 beyonwizt2 user.notice kernel: vtunerc0: VTUNER_SET_NAME 'RTL2838UHIDIR'
Nov 12 12:03:09 beyonwizt2 user.notice kernel: vtunerc0: VTUNER_SET_TYPE 'DVB-T' => 'RTL2838UHIDIR'
Nov 12 12:03:10 beyonwizt2 user.err kernel: vtunerc0: unknown IOCTL 0x6
Nov 12 12:03:10 beyonwizt2 user.err kernel: vtunerc0: unknown IOCTL 0x20
Nov 12 12:03:10 beyonwizt2 user.err kernel: vtunerc0: unknown IOCTL 0x21

Cheers
Geoff

Posted: **Sun Nov 12, 2017 16:31**

The tuner information in the About / Devices screen and the Tuner setup screen comes from Components.NimManager.nimmanager, which is filled by reading /proc/bus/nim_sockets. I don't know why that would have different information from what is set for the tuners in eDVBUsbAdapter::eDVBUsbAdapter(int nr), or why it would sometimes be correct and sometimes not, unless there's some sort of race condition.

This is what I see in /proc/bus/nim_sockets:

Code: Select all

NIM Socket 0:
        Type: DVB-T2
        Name: DVB-T/T2 NIM
        Mode 0: DVB-T2
        Mode 2: DVB-C
        Frontend_Device: 0
        I2C_Device: 0
NIM Socket 1:
        Type: DVB-T
        Name: DVB-T NIM
        Frontend_Device: 1
        I2C_Device: 1
NIM Socket 2:
        Type: DVB-T
        Name: DVB-T TV Stick
        Frontend_Device: 2
        I2C_Device: 759322180

It might be interesting to have a look at the contents of that file when the system has settled but the tuner type is incorrect for the USB tuner. The debug log also prints what NimManager interpreted from /proc/bus/nim_sockets, and a short summary of the slot information, so that should help confirm what /proc/bus/nim_sockets looked like when it was read.

grep '\[NimManager\]' debugfile

Posted: **Sun Nov 12, 2017 17:15**

Thanks,

I don't normally have debug logging enabled on the T2 as it prevents the 'deep standby' Power Timer from firing (as you've previously pointed out).
I'll enable the logging again, but I'll not get as many boot from deep standby events as some starts will now be from standby (where the issue may not occur).

His lordship is watching a marathon of Fairly Odd Parents at the moment, so I'll have to wait to set this (and the other thread's monitoring up).

Cheers
Geoff

Posted: **Sun Nov 12, 2017 17:24**

Grumpy_Geoff wrote: ↑
Sun Nov 12, 2017 17:15
... I don't normally have debug logging enabled on the T2 as it prevents the 'deep standby' Power Timer from firing (as you've previously pointed out). ...

I don't remember saying that (but I may have!). But I just tried a "deep standby" power timer on my test T2, and it shut down just fine.

I do know that enabling logging can stop HDD spindown in ordinary standby.

Posted: **Sun Nov 12, 2017 17:40**

prl wrote: ↑
Sun Nov 12, 2017 17:24

Grumpy_Geoff wrote: ↑
Sun Nov 12, 2017 17:15
... I don't normally have debug logging enabled on the T2 as it prevents the 'deep standby' Power Timer from firing (as you've previously pointed out). ...

I don't remember saying that (but I may have!). But I just tried a "deep standby" power timer on my test T2, and it shut down just fine.

I do know that enabling logging can stop HDD spindown in ordinary standby.

This "Auto Deep Standby power timer issue"

Posted: **Sun Nov 12, 2017 17:57**

Oh, I remember that one. But you said "it prevents the 'deep standby' Power Timer from firing", and I took it to mean a normal time-of-day power timer.

Posted: **Sun Nov 12, 2017 22:21**

From previous boot, USB tuner is DVB-T only, and "[enumerateNIMs]" block appears once only -

Code: Select all

{553}<    38.532> [NimManager][enumerateNIMs] slot: 0 - entry: {'multi_type': {'0': 'DVB-T2', '2': 'DVB-C'}, 'name': 'DVB-T/T2 NIM', 'frontend_device': 0, 'isempty': False, 'i2c': 0, 'type': 'DVB-T2'}
{553}<    38.534> [NimManager][enumerateNIMs] slot: 1 - entry: {'isempty': False, 'frontend_device': 1, 'i2c': 1, 'type': 'DVB-T', 'name': 'DVB-T NIM'}
{553}<    38.537> [NimManager][enumerateNIMs] slot: 2 - entry: {'isempty': False, 'frontend_device': 2, 'i2c': 843863122, 'type': 'DVB-T', 'name': 'RTL2838UHIDIR'}
{553}<    38.541> [NimManager] Reading cables.xml
{553}<    38.688> [NimManager] Reading terrestrial.xml
{553}<    38.769> [eDVBFrontend] opening frontend 0
{553}<    38.777> [InitNimManager] tunerTypeChanged tuner type is already 0
{553}<    38.784> [NimManager] slotname = Tuner A, slotdescription = DVB-T/T2 NIM, multitype = True
{553}<    38.786> [NimManager] slotname = Tuner B, slotdescription = DVB-T NIM, multitype = 0
{553}<    38.787> [NimManager] slotname = Tuner C, slotdescription = RTL2838UHIDIR, multitype = 0
{553}<    38.797> [SecConfigure] sec config cleared
{553}<    38.799> [eDVBFrontend] setSlotInfo for dvb frontend 0 to slotid 0, descr DVB-T/T2 NIM, need rotorworkaround No, enabled Yes, DVB-S2 No
{553}<    38.799> [eDVBFrontend] setSlotInfo for dvb frontend 1 to slotid 1, descr DVB-T NIM, need rotorworkaround No, enabled Yes, DVB-S2 No
{553}<    38.799> [eDVBFrontend] setSlotInfo for dvb frontend 2 to slotid 2, descr RTL2838UHIDIR, need rotorworkaround No, enabled Yes, DVB-S2 No

Code: Select all

NIM Socket 2:
	Type: DVB-T
	Name: RTL2838UHIDIR
	Frontend_Device: 2
	I2C_Device: 843863122

At next boot USB tuner is now multi-type DVB-C / DVB-T2 "[enumerateNIMs]" block appears twice -

Code: Select all

{553}<    38.476> [NimManager][enumerateNIMs] slot: 0 - entry: {'multi_type': {'0': 'DVB-T2', '2': 'DVB-C'}, 'name': 'DVB-T/T2 NIM', 'frontend_device': 0, 'isempty': False, 'i2c': 0, 'type': 'DVB-T2'}
{553}<    38.478> [NimManager][enumerateNIMs] slot: 1 - entry: {'isempty': False, 'frontend_device': 1, 'i2c': 1, 'type': 'DVB-T', 'name': 'DVB-T NIM'}
{553}<    38.480> [NimManager][enumerateNIMs] slot: 2 - entry: {'multi_type': {'2': 'DVB-C', '6': 'DVB-T2'}, 'name': 'RTL2838UHIDIR', 'frontend_device': 2, 'isempty': False, 'i2c': 843863122, 'type': 'DVB-T'}
{553}<    38.483> [NimManager] Reading cables.xml
{553}<    38.644> [NimManager] Reading terrestrial.xml
{553}<    38.721> [eDVBFrontend] opening frontend 0
{553}<    38.730> [InitNimManager] tunerTypeChanged tuner type is already 0
{553}<    38.736> [NimManager] slotname = Tuner A, slotdescription = DVB-T/T2 NIM, multitype = True
{553}<    38.737> [NimManager] slotname = Tuner B, slotdescription = DVB-T NIM, multitype = 0
{553}<    38.739> [eDVBFrontend] opening frontend 2
{553}<    39.285> [InitNimManager] tunerTypeChanged feid 2 from -1 to mode 6
{553}<    39.288> [eDVBFrontend] close frontend 2
{553}<    40.290> [eDVBFrontend] opening frontend 2
{553}<    40.829> [NimManager][enumerateNIMs] slot: 0 - entry: {'multi_type': {'0': 'DVB-T2', '2': 'DVB-C'}, 'name': 'DVB-T/T2 NIM', 'frontend_device': 0, 'isempty': False, 'i2c': 0, 'type': 'DVB-T2'}
{553}<    40.831> [NimManager][enumerateNIMs] slot: 1 - entry: {'isempty': False, 'frontend_device': 1, 'i2c': 1, 'type': 'DVB-T', 'name': 'DVB-T NIM'}
{553}<    40.832> [NimManager][enumerateNIMs] slot: 2 - entry: {'multi_type': {'2': 'DVB-C', '6': 'DVB-T2'}, 'name': 'RTL2838UHIDIR', 'frontend_device': 2, 'isempty': False, 'i2c': 843863122, 'type': 'DVB-T'}
{553}<    40.833> [InitNimManager] tunerTypeChanged force update setting
{553}<    40.834> [InitNimManager] tunerTypeChanged error:  NimManager instance has no attribute 'sec'
{553}<    40.835> [NimManager] slotname = Tuner C, slotdescription = RTL2838UHIDIR, multitype = True
{553}<    40.845> [SecConfigure] sec config cleared
{553}<    40.847> [eDVBFrontend] setSlotInfo for dvb frontend 0 to slotid 0, descr DVB-T/T2 NIM, need rotorworkaround No, enabled Yes, DVB-S2 No
{553}<    40.847> [eDVBFrontend] setSlotInfo for dvb frontend 1 to slotid 1, descr DVB-T NIM, need rotorworkaround No, enabled Yes, DVB-S2 No
{553}<    40.847> [eDVBFrontend] setSlotInfo for dvb frontend 2 to slotid 2, descr RTL2838UHIDIR, need rotorworkaround No, enabled Yes, DVB-S2 No

Code: Select all

NIM Socket 2:
        Type: DVB-T
        Name: RTL2838UHIDIR
        Mode 6: DVB-T2
        Mode 2: DVB-C
        Frontend_Device: 2
        I2C_Device: 843863122

I can't reboot to try again for a while,

Cheers
Geoff

Posted: **Mon Nov 13, 2017 16:51**

After a number of reboots where the UDB tuner dongle was correctly determined to be a terrestrial one, I jagged another boot where it was decided it was a satellite tuner - Mode 4: DVB-S2.

Code: Select all

{552}<    40.805> [NimManager][enumerateNIMs] slot: 2 - entry: {'multi_type': {'4': 'DVB-S2'}, 'name': 'RTL2838UHIDIR', 'frontend_device': 2, 'isempty': False, 'i2c': 843863122, 'type': 'DVB-T'}
{552}<    40.808> [NimManager] slotname = Tuner C, slotdescription = RTL2838UHIDIR, multitype = True

See attached for contents of enigma2_pre_start.sh script used to produce the logging, the tuner log, plus the full contents of /proc/bus/nim_sockets for the last two boots.

Please let me know if you need more debugging.

enigma2_pre_start.txt: (1.12 KiB) Downloaded 61 times

vtuner2.log: (3.27 KiB) Downloaded 80 times

nim_sockets.txt: (644 Bytes) Downloaded 66 times

Cheers
Geoff

Posted: **Mon Nov 13, 2017 17:52**

I was hoping to get the /proc/bus/nim_sockets info from before the enigma2 binary started as well as after.

There definitely seems to be a timing issue involved somehow.

When the USB tuner is correctly identified, you get:

Code: Select all

{552}<    39.294> [NimManager] slotname = Tuner A, slotdescription = DVB-T/T2 NIM, multitype = True
{552}<    39.295> [NimManager] slotname = Tuner B, slotdescription = DVB-T NIM, multitype = 0
{552}<    39.296> [NimManager] slotname = Tuner C, slotdescription = RTL2838UHIDIR, multitype = 0

all within 2ms.

But when it's misidentified as a DVB-S2 tuner, you get:

Code: Select all

{552}<    38.703> [NimManager] slotname = Tuner A, slotdescription = DVB-T/T2 NIM, multitype = True
{552}<    38.704> [NimManager] slotname = Tuner B, slotdescription = DVB-T NIM, multitype = 0
[... time passes ...]
{552}<    40.808> [NimManager] slotname = Tuner C, slotdescription = RTL2838UHIDIR, multitype = True

Where the NIMs are enumerated once more between when the slot info for Tuner B is printed and when it's printed for Tuner C. I think that's due to a signal from the lower levels to say that there's been a tuner change.

This is an area of the code I haven't really looked at much before.

Posted: **Mon Nov 13, 2017 18:04**

Also see my earlier post when "[enumerateNIMs]" block appeared twice when the tuner was chosen to be DVB-C/DVB-T2.

I can try to also get the /proc/bus/nim_sockets file captured at the beginning of the script (before the 'sleep', but still in the sub-shell) - would that work?

Cheers
Geoff

Posted: **Mon Nov 13, 2017 19:04**

Yes, that should work.

Posted: **Mon Nov 13, 2017 22:11**

NIM sockets at boot don't contain the USB tuner

Code: Select all

NIM Socket 0:
	Type: DVB-T2
	Name: DVB-T/T2 NIM
	Mode 0: DVB-T2
	Mode 2: DVB-C
	Frontend_Device: 0
	I2C_Device: 0
NIM Socket 1:
	Type: DVB-T
	Name: DVB-T NIM
	Frontend_Device: 1
	I2C_Device: 1

I'll try a delay...

Posted: **Mon Nov 13, 2017 23:20**

On this bootup it had an each way bet on (all?) five types -

Code: Select all

{555}<    41.020> [NimManager][enumerateNIMs] slot: 2 - entry: {'multi_type': {'3': 'DVB-T', '2': 'DVB-C', '5': 'DVB-C2', '4': 'DVB-S2', '6': 'DVB-T2'}, 'name': 'RTL2838UHIDIR', 'frontend_device': 2, 'isempty': False, 'i2c': 843863122, 'type': 'DVB-T'}
{555}<    41.022> [NimManager] slotname = Tuner C, slotdescription = RTL2838UHIDIR, multitype = True

Code: Select all

NIM Socket 2:
	Type: DVB-T
	Name: RTL2838UHIDIR
	Mode 6: DVB-T2
	Mode 3: DVB-T
	Mode 5: DVB-C2
	Mode 2: DVB-C
	Mode 4: DVB-S2
	Frontend_Device: 2
	I2C_Device: 843863122

Mode 6 won though

Posted: **Tue Nov 14, 2017 16:16**

In all instances I've looked at, it appears to me that whenever the file /proc/bus/nim_sockets lists one or more 'Mode: {n}' entries for the USB tuner (multitype = True), the first or only list entry is used to assign the tuner type.
My guess then is that if DVB-C/C2/S2 is the first or only listed type, then that's what gets assigned and the tuner is unusable for terrestrial TV.
If there are no 'Mode' entries listed (multitype = 0) then the 'Type' is used, which is always "DVB-T".

Is there any particular sequencing to the list of entries?

Examples:

Code: Select all

single type -
NIM Socket 2:
	Type: DVB-T
	Name: RTL2838UHIDIR
	Frontend_Device: 2
	I2C_Device: 843863122


multi type (of one)
NIM Socket 2:
	Type: DVB-T
	Name: RTL2838UHIDIR
	Mode 4: DVB-S2
	Frontend_Device: 2
	I2C_Device: 843863122


multi type (of two)
NIM Socket 2:
	Type: DVB-T
	Name: RTL2838UHIDIR
	Mode 6: DVB-T2
	Mode 2: DVB-C
	Frontend_Device: 2
	I2C_Device: 843863122	


multi type (of many)
NIM Socket 2:
	Type: DVB-T
	Name: RTL2838UHIDIR
	Mode 6: DVB-T2
	Mode 3: DVB-T
	Mode 5: DVB-C2
	Mode 2: DVB-C
	Mode 4: DVB-S2
	Frontend_Device: 2
	I2C_Device: 843863122

Posted: **Tue Nov 14, 2017 17:51**

Grumpy_Geoff wrote: ↑
Tue Nov 14, 2017 16:16
...
Is there any particular sequencing to the list of entries?
...

By the time it gets to the Python code, none at all: the multiple types are held in a dict, so there's no particular order.

I don't have access to the driver code, so I have no idea how the driver orders the entries in /proc/bus/nim_sockets. It doesn't appear to be in numerical order.

It also doesn't appear to just be an issue with the RTL2838UHIDIR, either, because I've had an instance of mt yest T2 booting with multiple modes for its ITE USB tuner, too, and saying that it's DVB-T2, when I don't think that it is. I lost the output for that, I'll try to replicate it tomorrow.

I need to check the code for just what is chosen out of the multi_type map. I do know that if the multi_type pam is empty that you're right that the type field is used.

Posted: **Tue Nov 14, 2017 18:34**

prl wrote: ↑
Tue Nov 14, 2017 17:51
...
It also doesn't appear to just be an issue with the RTL2838UHIDIR, either, because I've had an instance of mt yest T2 booting with multiple modes for its ITE USB tuner, too, and saying that it's DVB-T2, when I don't think that it is. I lost the output for that, I'll try to replicate it tomorrow.

gawaterman had DVB-C2 assigned in this thread - viewtopic.php?f=49&t=11443&p=156240#p156215
He was using the Beyonwiz supplied MINI DVB-T stick (same as you).

Posted: **Wed Nov 15, 2017 12:22**

If multi_type is present in the nim, then DVB-T2 is selected as the default if there's a DVB-T2 entry, and DVB-T is selected as the default if there is a DVB-T entry, but no DVB-T2 entry. Otherwise the default is None, and the ConfigSelection that's used in getType if there is a multi_type will return the first element in the ConfigSelection's list, but the order that items are added to the ConfigSelection is determined by the order of iteration over the multi_type map (and that order is unspecified).

Posted: **Wed Nov 15, 2017 13:13**

I think I got the first part of that, but most of the second part of that (from "Otherwise the default is None" onwards) went straight to the keeper

I think you're saying -

Single-type will take tuner type (DVB-T)
If multi-type,
- DVB-T2 or DVB-T mode is preferred (in that order, but I don't think that matters in Australia right now)
- If no DVB-T/T2, then first multi-type mode entry is chosen and entry ordering is random

So the issue comes about when a multi-type nim list is constructed without DVB-T/T2 modes (i.e. one or more of DVB-C, DVB-C2, DVB-S2 only)
i.e. we're up $h?t* creek if we get this multi type (of one) -

Code: Select all

NIM Socket 2:
	Type: DVB-T
	Name: RTL2838UHIDIR
	Mode 4: DVB-S2
	Frontend_Device: 2
	I2C_Device: 843863122

Do you think this is a firmware issue, or driver issue?
Is it likely to hit the U4 (turning it into a U3) or possibly saved by different driver and perhaps different /proc/bus/nim_sockets entry ordering?

Posted: **Wed Nov 15, 2017 15:13**

Grumpy_Geoff wrote: ↑
Wed Nov 15, 2017 13:13
...
I think you're saying -

Single-type will take tuner type (DVB-T)

If multi-type,

DVB-T2 or DVB-T mode is preferred (in that order, but I don't think that matters in Australia right now)

If no DVB-T/T2, then first multi-type mode entry is chosen and entry ordering is random

Yes, that's exactly what I meant. Sorry it wasn't clear.

Grumpy_Geoff wrote: ↑
Wed Nov 15, 2017 13:13
...
So the issue comes about when a multi-type nim list is constructed without DVB-T/T2 modes (i.e. one or more of DVB-C, DVB-C2, DVB-S2 only)
i.e. we're up $h?t* creek if we get this multi type (of one) -
Code: Select all
NIM Socket 2:
	Type: DVB-T
	Name: RTL2838UHIDIR
	Mode 4: DVB-S2
	Frontend_Device: 2
	I2C_Device: 843863122

Yes, and if there's only one entry in the "multi" list, then clearly that will be the one chosen.

Grumpy_Geoff wrote: ↑
Wed Nov 15, 2017 13:13
Do you think this is a firmware issue, or driver issue?
Is it likely to hit the U4 (turning it into a U3) or possibly saved by different driver and perhaps different /proc/bus/nim_sockets entry ordering?

The data comes from /proc, so it's out of the kernel, and probably from a driver. Of course, system calls (like ioctls) from applications change the driver state, but I don't think that that's being done in this case.

Posted: **Wed Nov 15, 2017 16:25**

prl wrote: ↑
Wed Nov 15, 2017 15:13
...
The data comes from /proc, so it's out of the kernel, and probably from a driver. Of course, system calls (like ioctls) from applications change the driver state, but I don't think that that's being done in this case.

Thanks,

I've reported here where a UI restart can change the reported tuner type. Do you think that may be from one of the 'system calls' you mention, or is the low-level kernel/driver stuff being invoked again.

Cheers
Geoff

Posted: **Wed Nov 15, 2017 17:09**

Grumpy_Geoff wrote: ↑
Wed Nov 15, 2017 16:25

prl wrote: ↑
Wed Nov 15, 2017 15:13
...
The data comes from /proc, so it's out of the kernel, and probably from a driver. Of course, system calls (like ioctls) from applications change the driver state, but I don't think that that's being done in this case.
...
I've reported here where a UI restart can change the reported tuner type. Do you think that may be from one of the 'system calls' you mention, or is the low-level kernel/driver stuff being invoked again.
...

I'm afraid I really don't know. There may be more interaction with the kernel drivers in some of the libraries. I'll have a dig, but I'm not all that hopeful.

Posted: **Tue Dec 05, 2017 11:37**

There's a bug fix included in the recent 20171204 that may address (part of) this issue, but I don't think it will help if there's incorrect information in /proc/bus/nim_sockets.

Posted: **Tue Dec 05, 2017 12:25**

prl wrote: ↑
Tue Dec 05, 2017 11:37
There's a bug fix included in the recent 20171204 that may address (part of) this issue, but I don't think it will help if there's incorrect information in /proc/bus/nim_sockets.

Yes, thanks. I spotted that this morning

I haven't updated the T2 yet, but I'll do so soon and see how it goes.
I was thinking of using a crude hack in my pre-start script monitoring - if the USB tuner is identified as multi-type, and the first mode/type is not terrestrial, then restart the UI:

Code: Select all

awk '/NIM Socket 2:/ {USBtuner = 1}; \
     USBtuner && /Mode [0-9]: DVB-/ { if($0 !~ /DVB-T/) {print "*** non-Terrestrial USB tuner type, restarting UI"; print "init 3" | "sh"}; exit }' /proc/bus/nim_sockets

Posted: **Tue Dec 05, 2017 21:58**

That'll just create a restart loop.

The /proc entries are created by the drivers* and restarting the GUI will not make it change.

_______________________________________________
* I have not been able to divine the complex interactions that go on there. The entry must be generated based on the presence of the USB tuner driver, but /proc/bus/nim_sockets is not a standard Linux kernel feature. Somehow the STB platform specific drivers must interact with the USB tuner drivers and manage the entries in /proc/bus/nim_sockets. I don't know how that works (or in this case how it may break).

Posted: **Tue Dec 05, 2017 22:22**

peteru wrote: ↑
Tue Dec 05, 2017 21:58
That'll just create a restart loop.

The /proc entries are created by the drivers* and restarting the GUI will not make it change.
...

But it does change, look at what happened earlier today -

Code: Select all

root@beyonwizt2:/usr/bin# cat /proc/bus/nim_sockets
NIM Socket 0:
        Type: DVB-T2
        Name: DVB-T/T2 NIM
        Mode 0: DVB-T2
        Mode 2: DVB-C
        Frontend_Device: 0
        I2C_Device: 0
NIM Socket 1:
        Type: DVB-T
        Name: DVB-T NIM
        Frontend_Device: 1
        I2C_Device: 1
NIM Socket 2:
        Type: DVB-T
        Name: RTL2838UHIDIR
        Mode 3: DVB-T
        Mode 5: DVB-C2
        Mode 2: DVB-C
        Mode 4: DVB-S2
        Frontend_Device: 2
        I2C_Device: 843863122
root@beyonwizt2:/usr/bin#

... and then after a UI restart -

Code: Select all

root@beyonwizt2:/usr/bin# cat /proc/bus/nim_sockets
NIM Socket 0:
        Type: DVB-T2
        Name: DVB-T/T2 NIM
        Mode 0: DVB-T2
        Mode 2: DVB-C
        Frontend_Device: 0
        I2C_Device: 0
NIM Socket 1:
        Type: DVB-T
        Name: DVB-T NIM
        Frontend_Device: 1
        I2C_Device: 1
NIM Socket 2:
        Type: DVB-T
        Name: RTL2838UHIDIR
        Mode 3: DVB-T
        Mode 4: DVB-S2
        Frontend_Device: 2
        I2C_Device: 843863122
root@beyonwizt2:/usr/bin#

The USB tuner is first reported as being multi-mode (incorrect I believe), having modes DVB-T, as well as modes C, C2, and S2 (incorrect, AFAIK).
After a UI restart, it now reports as DVB-T & S2.
I've observed this type of difference many times.

I believe the correct reporting of the USB tuner is -

Code: Select all

NIM Socket 2:
	Type: DVB-T
	Name: RTL2838UHIDIR
	Frontend_Device: 2
	I2C_Device: 843863122

Fixed mode, non-switchable.

Cheers,
Geoff

Posted: **Tue Dec 05, 2017 23:32**

WTF?

Time to dig through some more code...

Thanks for persisting with collecting evidence.

Posted: **Wed Dec 06, 2017 00:42**

Oh dear!

Code: Select all

# echo "I corrupted this" >/proc/bus/nim_sockets
# cat /proc/bus/nim_sockets
I corrupted this

It looks like the issue could come from just about anywhere...

Posted: **Wed Dec 06, 2017 03:35**

Well, a few hours later and I think I have a handle on what is happening...

Maybe.

The USB tuners are linked to the STB drivers through the use of a vtuner proxy. Initially the STB drivers know nothing about the USB drivers. The application code in lib/dvb/dvb.cpp is responsible for making the connection. The constructor of the eDVBUsbAdapter class uses a number of ioctls to configure this and the entries that eventually appear in /proc/bus/nim_sockets depend on what this code does.

I haven't studied this any further. At the moment I don't have a T2 set up for debug, so can't actually observe what is going on, but if anyone else wants to dig deeper, I'd suggest putting some debug statements in eDVBUsbAdapter.

Posted: **Wed Dec 06, 2017 08:25**

Given where the problem seems to happen, you may be able to see/debug it on your test U4.

Posted: **Wed Dec 06, 2017 10:44**

I've had an idea about what may be going on with this, but I need to set up to build for the T2 to test it.

Posted: **Wed Dec 06, 2017 12:23**

prl wrote: ↑
Wed Dec 06, 2017 10:44
I've had an idea about what may be going on with this, but I need to set up to build for the T2 to test it.

It doesn't seem to be that problem that I thought it was (prop[0].u.buffer.data not being terminated by a SYS_UNDEFINED). The VTUNER_SET_DELSYS ioctl fails, anyway (not supported by driver).

Doing some more digging.

Posted: **Wed Dec 06, 2017 16:49**

The problem happens when the virtual tuner is opened, in

Code: Select all

eDVBUsbAdapter::eDVBUsbAdapter(int nr)
: eDVBAdapterLinux(nr)
{
	...
		snprintf(filename, sizeof(filename), "/dev/misc/vtuner%d", vtunerid);
		if (::access(filename, F_OK) < 0) break;
		vtunerFd = open(filename, O_RDWR | O_CLOEXEC);
	...
}

Before the open, /proc/bus/nim_sockets doesn't contain an entry for the USB tuner. After the open it does. If, after the open, nim_sockets contains the correct tuner multi-types (no multi-type entries), it continues to be correct. If, after the open, it contains incorrect multi-types, it stays with incorrect multi-types and Components.NimManager gets set up incorrectly for the USB tuner.

eDVBUsbAdapter::eDVBUsbAdapter() tries to set the correct tuner multi-types in the vtuner by copying them from the frontend (/dev/dvb/adapter%d/frontend0):

Code: Select all

	snprintf(filename, sizeof(filename), "/dev/dvb/adapter%d/frontend0", nr);
	frontend = open(filename, O_RDWR);
	...
	struct dtv_properties props;
	struct dtv_property prop[1];

	prop[0].cmd = DTV_ENUM_DELSYS;
	memset(prop[0].u.buffer.data, 0, sizeof(prop[0].u.buffer.data));
	prop[0].u.buffer.len = 0;
	props.num = 1;
	props.props = prop;

	if (ioctl(frontend, FE_GET_PROPERTY, &props) < 0)
		eDebug("[eDVBUsbAdapter] FE_GET_PROPERTY DTV_ENUM_DELSYS failed %m");

	::close(frontend);
	frontend = -1;
	...
	while (vtunerFd < 0)
	{
		snprintf(filename, sizeof(filename), "/dev/misc/vtuner%d", vtunerid);
		if (::access(filename, F_OK) < 0) break;
		vtunerFd = open(filename, O_RDWR | O_CLOEXEC);
		if (vtunerFd < 0)
		{
			vtunerid++;
		}
	}
	...
#define VTUNER_SET_DELSYS 32
	if (prop[0].u.buffer.len > 0)
		ioctl(vtunerFd, VTUNER_SET_DELSYS, prop[0].u.buffer.data);

Which should work, you'd think, but in /var/log/messages:

Code: Select all

Dec  6 17:27:11 beyonwizt2 user.notice kernel: vtunerc0: VTUNER_SET_NAME 'DVB-T TV Stick'
Dec  6 17:27:11 beyonwizt2 user.notice kernel: vtunerc0: VTUNER_SET_TYPE 'DVB-T' => 'DVB-T TV Stick' 
Dec  6 17:27:11 beyonwizt2 user.err kernel: vtunerc0: unknown IOCTL 0x6
Dec  6 17:27:11 beyonwizt2 user.err kernel: vtunerc0: unknown IOCTL 0x20 <<<< ioctl(vtunerFd, VTUNER_SET_DELSYS, prop[0].u.buffer.data);
Dec  6 17:27:11 beyonwizt2 user.err kernel: vtunerc0: unknown IOCTL 0x21

The delivery systems data returned by FE_GET_PROPERTY/DTV_ENUM_DELSYS for the physical tuner is correct even when the information for the corresponding attached virtual tuner in /proc/bus/nim_sockets is incorrect.

Posted: **Thu Dec 07, 2017 02:47**

Decoding this:

Code: Select all

Dec  6 17:27:11 beyonwizt2 user.err kernel: vtunerc0: unknown IOCTL 0x6
Dec  6 17:27:11 beyonwizt2 user.err kernel: vtunerc0: unknown IOCTL 0x20 <<<< ioctl(vtunerFd, VTUNER_SET_DELSYS, prop[0].u.buffer.data);
Dec  6 17:27:11 beyonwizt2 user.err kernel: vtunerc0: unknown IOCTL 0x21

Boils down to VTUNER_SET_FE_INFO, VTUNER_SET_DELSYS and VTUNER_SET_ADAPTER not being supported by the STB driver and as a result, the code effectively only does this:

Code: Select all

ioctl(vtunerFd, VTUNER_SET_NAME, name);
ioctl(vtunerFd, VTUNER_SET_TYPE, type);
ioctl(vtunerFd, VTUNER_SET_HAS_OUTPUTS, "no");

It so happens that VTUNER_SET_HAS_OUTPUTS is a no-op, so that the only thing that happens is VTUNER_SET_NAME followed by VTUNER_SET_TYPE.

So the question now is, what happens in the vtuner STB driver code that causes more or less random entries to appear in /proc/bus/nim_sockets?

Posted: **Thu Dec 07, 2017 03:33**

Another observation:

Code: Select all

NIM Socket 2:
        Type: DVB-T
        Name: RTL2838UHIDIR
        Mode 3: DVB-T
        Mode 4: DVB-S2
        Frontend_Device: 2
        I2C_Device: 843863122

Examining I2C_Device: 843863122 in closer detail gives 2LTR, when decoded as ASCII. After endian byte swap, this becomes RTL2 - an exact match for the first four bytes of the Name field.

I would have expected the I2C_Device value to be 0, since the USB tuner is not hanging off the I2C bus.

So, there's definitely something dodgy going on in the vtuner code.

Posted: **Thu Dec 07, 2017 08:22**

peteru wrote: ↑
Thu Dec 07, 2017 03:33
...
So, there's definitely something dodgy going on in the vtuner code.

I agree entirely. Nice spot on the I2C_Device code, though

Posted: **Thu Dec 07, 2017 11:23**

peteru wrote: ↑
Thu Dec 07, 2017 03:33
Another observation:
Code: Select all
NIM Socket 2:
        Type: DVB-T
        Name: RTL2838UHIDIR
        Mode 3: DVB-T
        Mode 4: DVB-S2
        Frontend_Device: 2
        I2C_Device: 843863122
Examining I2C_Device: 843863122 in closer detail gives 2LTR, when decoded as ASCII. After endian byte swap, this becomes RTL2 - an exact match for the first four bytes of the Name field.
...

The corresponding thing happens for the Beyonwiz-supplied ITE Technologies tuner stick:

Code: Select all

NIM Socket 2:
        Type: DVB-T
        Name: DVB-T TV Stick
        Mode 6: DVB-T2
        Mode 5: DVB-C2
        Mode 2: DVB-C
        Frontend_Device: 2
        I2C_Device: 759322180

That yields -BVD for the "I2C_Device" field rendered as ASCII, and byte-swapped it becomes DVB-, again the first 4 characters of the device name (though not as unambiguously as for the RTL device).

Posted: **Wed Dec 20, 2017 17:10**

Might be a fluke, or it might be like a watched kettle, or it might be peteru's "[NimManager]" changes, but with the monitoring and 20171204 f/w on the T2, it hasn't yet chosen a non-terrestrial mode for the USB tuner.
60 UI starts since[Image Flashed] 2017-12-05.

Posted: **Tue Apr 10, 2018 14:02**

T2 on firmware 20180216.

The other day, the UI started with the USB tuner assigned as a non-Terrestrial type.
Relevant socket entries from /proc/bus/nim_sockets shown below:

Code: Select all

NIM Socket 2:
	Type: DVB-T
	Name: RTL2832U
	Mode 2: DVB-C
	Frontend_Device: 2
	I2C_Device: 843863122

From experience, I know the above indicates a non-terrestrial DVB-C mode would be chosen as the tuner type.
OWIF's "deviceinfo" had also shown DVB-C was the tuner's selected type, snippet below:

Code: Select all

			<e2name>Tuner C</e2name>
			<e2model>RTL2832U (DVB-C)</e2model>

Finally, the debug log [NimManager] entries also confirm this DVB-C selection:

Code: Select all

{623}<    47.571> [NimManager][enumerateNIMs] slot: 0 - entry: {'multi_type': {'0': 'DVB-T2', '2': 'DVB-C'}, 'name': 'DVB-T/T2 NIM', 'frontend_device': 0, 'isempty': False, 'i2c': 0, 'type': 'DVB-T2'}
{623}<    47.572> [NimManager][enumerateNIMs] slot: 1 - entry: {'isempty': False, 'frontend_device': 1, 'i2c': 1, 'type': 'DVB-T', 'name': 'DVB-T NIM'}
{623}<    47.573> [NimManager][enumerateNIMs] slot: 2 - entry: {'multi_type': {'2': 'DVB-C'}, 'name': 'RTL2832U', 'frontend_device': 2, 'isempty': False, 'i2c': 843863122, 'type': 'DVB-T'}
{623}<    47.576> [NimManager] Reading cables.xml
{623}<    47.708> [NimManager] Reading terrestrial.xml
{623}<    47.771> [NimManager] slotname = Tuner A, slotdescription = DVB-T/T2 NIM, multitype = True
{623}<    47.772> [NimManager] slotname = Tuner B, slotdescription = DVB-T NIM, multitype = 0
{623}<    49.824> [NimManager][enumerateNIMs] slot: 0 - entry: {'multi_type': {'0': 'DVB-T2', '2': 'DVB-C'}, 'name': 'DVB-T/T2 NIM', 'frontend_device': 0, 'isempty': False, 'i2c': 0, 'type': 'DVB-T2'}
{623}<    49.826> [NimManager][enumerateNIMs] slot: 1 - entry: {'isempty': False, 'frontend_device': 1, 'i2c': 1, 'type': 'DVB-T', 'name': 'DVB-T NIM'}
{623}<    49.827> [NimManager][enumerateNIMs] slot: 2 - entry: {'multi_type': {'2': 'DVB-C'}, 'name': 'RTL2832U', 'frontend_device': 2, 'isempty': False, 'i2c': 843863122, 'type': 'DVB-T'}
{623}<    49.829> [NimManager] slotname = Tuner C, slotdescription = RTL2832U, multitype = True

On numerous occasions, I've seen the tuner reported as either DVB-T fixed type (mostly), or multi-types that includes at least DVB-T or T2 (or both) - all of which have meant the tuner was assigned a terrestrial mode, so it would operate fine.
In this particular case, multi-type capability was designated for the tuner, but unfortunately no terrestrial mode was listed amongst its modes and thus couldn't be chosen (preferred).

This multi-mode capability doesn't appear to be reported on the U4, it is always a fixed type (DVB-T). Is there a discernible code difference?
I know the two Peters have spent some time in this area, probably resulting in more head scratching than progress.

Code: Select all

NIM Socket 3:
        Type: DVB-T
        Name: RTL2838UHIDIR
        Frontend_Device: 3
        Has_Ouput: no
        I2C_Device: 24

(no different for the Beyonwiz mini tuner "DVB-T TV Stick", only 'Name').

The debug reporting is certainly different compared with the T2 -

Code: Select all

[NimManager][enumerateNIMs] slot: 3 - entry: {'name': 'RTL2838UHIDIR', 'frontend_device': 3, 'has_outputs': False, 'isempty': False, 'i2c': 24, 'type': 'DVB-T'}
[NimManager][enumerateNIMs] slot: 3 - entry: {'name': 'DVB-T TV Stick', 'frontend_device': 3, 'has_outputs': False, 'isempty': False, 'i2c': 24, 'type': 'DVB-T'}

Posted: **Tue Apr 10, 2018 14:15**

Looks like some kind of memory corruption, judging by the value of the i2c field.

Problem with memory corruption is that it's entirely possible that the problem is caused by some completely unrelated bug in code that has nothing to do with the problem being experienced.

Posted: **Tue Apr 10, 2018 14:38**

Okay.
Previously, you decoded that I2C value as "RTL2" (the 1st 4 characters of the device name)

Posted: **Tue Apr 10, 2018 20:57**

Yes, I know. And you are still seeing the same bug and we still don't have a reliable way of reproducing it.

I tried to fix the code in areas that looked like they may be involved in triggering the problem, but clearly it's coming from somewhere else.

Posted: **Tue Apr 10, 2018 21:11**

Well, your changes have likely meant that this bug now only surfaces on the very odd occasion.
I haven't seen it in over 300 UI starts on the T2 since your code change in early December, except of course the other day.

Is it possible to make a change to the code, restricted to the T2/T3 models, such that only DVB-T mode is ever chosen for the USB tuner?

Posted: **Tue Apr 10, 2018 21:18**

Hi Grumpy_Geoff,

Grumpy_Geoff wrote: ↑
Tue Apr 10, 2018 21:11
Is it possible to make a change to the code, restricted to the T2/T3 models, such that only DVB-T mode is ever chosen for the USB tuner?

You may want to widen the limitation to include DVB-T/T2 given that DVB-T2 broadcasts are being trialled in Sydney at the moment.

Regards,
Ian.

Posted: **Tue Apr 10, 2018 21:41**

IanSav wrote: ↑
Tue Apr 10, 2018 21:18
Hi Grumpy_Geoff,
Grumpy_Geoff wrote: ↑
Tue Apr 10, 2018 21:11
Is it possible to make a change to the code, restricted to the T2/T3 models, such that only DVB-T mode is ever chosen for the USB tuner?
You may want to widen the limitation to include DVB-T/T2 given that DVB-T2 broadcasts are being trialled in Sydney at the moment.

Regards,
Ian.

Perhaps, but I don't believe any of the USB tuners are capable of DVB-T2. The second tuner (B) in the T2 is also not DVB-T2 capable.

Posted: **Tue Apr 10, 2018 21:48**

Hi Grumpy_Geoff,

Grumpy_Geoff wrote: ↑
Tue Apr 10, 2018 21:41
Perhaps, but I don't believe any of the USB tuners are capable of DVB-T2. The second tuner (B) in the T2 is also not DVB-T2 capable.

I only have T3s running and the only USB tuner I have is so old Captain Cook brought it with him when he first came here.

(I have some USB dual tuners but they crash the T3.

The T3 is not permitted to have 5 tuners.)

Regards,
Ian.

Posted: **Thu Apr 26, 2018 19:22**

Hi,

Grumpy_Geoff wrote: ↑
Tue Apr 10, 2018 21:11
Well, your changes have likely meant that this bug now only surfaces on the very odd occasion.
I haven't seen it in over 300 UI starts on the T2 since your code change in early December, except of course the other day.

Is it possible to make a change to the code, restricted to the T2/T3 models, such that only DVB-T mode is ever chosen for the USB tuner?

I had the 3rd/USB tuner on my T2 display as DVB-C2 this morning, after I had done a FW update to 2018417.

dRdoS7

Posted: **Thu Apr 26, 2018 21:16**

dRdoS7 wrote: ↑
Thu Apr 26, 2018 19:22
Hi,

Grumpy_Geoff wrote: ↑
Tue Apr 10, 2018 21:11
Well, your changes have likely meant that this bug now only surfaces on the very odd occasion.
I haven't seen it in over 300 UI starts on the T2 since your code change in early December, except of course the other day.

Is it possible to make a change to the code, restricted to the T2/T3 models, such that only DVB-T mode is ever chosen for the USB tuner?

I had the 3rd/USB tuner on my T2 display as DVB-C2 this morning, after I had done a FW update to 2018417.

dRdoS7

You lost 'tuner lotto'. Sigh.
I wonder what the Australian Competition and Consumer Commission would make of this? In these circumstances, it clearly can't make simultaneous recordings from 3 different broadcast networks.

Posted: **Thu Apr 26, 2018 22:24**

I wonder what the Australian Competition and Consumer Commission would make of this? In these circumstances, it clearly can't make simultaneous recordings from 3 different broadcast networks.

I can't speak for my colleagues in enforcement but it generally comes down to what the consumer wants. It's potential grounds for a repair, refund or replacement if it's a major failure. If not major, but still significant, the supplier is expected to fix the problem.

Our website at www.accc.gov.au has a consumer section that gives advice and guidance on consumer rights.
Cheers, Paul.

Posted: **Thu Apr 26, 2018 23:04**

Hi,

Before people start becoming litigious perhaps my suggestion to look at the code contribution to OpenViX, https://github.com/OpenViX/enigma2/pull/254, may address this issue for the Beyonwiz as well.

Regards,
Ian.

Beyonwiz Australia

Bug - Terrestrial USB tuner identified as non-terrestrial

Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial

Re: Bug - Terrestrial USB tuner identified as non-terrestrial