Driver autostart problem on a Vu+ Uno STB

[szirog]

Hi Sundtek Support,

I have just bought a Sundtek MediaTV Digital Home III USB stick. Everything works fine, unfortunately I can't set up the driver autostart.

My hardware configuration:
- VU+ Uno with internal DVB-S2 tuner,
- one Avermedia A867 USB DVB-T stick,
- one Sundtek MediaTV Digital Home III USB stick.

Software environment:
 - Linux version 3.1.1 (build@buildserver) (gcc version 4.8.2 (GCC) ) #1 SMP Sun Apr 13 19:54:47 CEST 2014
 - kernel-module-dvb-usb, Version: 3.1.1-r4.10.13,
 - kernel-module-dvb-usb-a867, Version: 3.1.1-r4.10.13
 - mediasrv/mediclient, Build date: 2014-06-19 14:06:38
 - enigma2, version: 2.7+git11747+a709fc6-r49,

My Sundtek configuration (in /etc/sundtek.conf):
=====>
# sundtek configuration file - /etc/sundtek.conf
# created / modified: jún 25 2014, 20:50h by sundtekcontrolcenter 1.4.0-20140223-r2

loglevel = off
autoupdate = off
dmhwpidfilter = off
vtuner_acceleration = off
enablenetwork = off
vtuner_skip0=vtuner0

###### configuration stick 1
[U140610191403]
initial_dvb_mode=DVBT
dreambox_support_fe1=on
<========

I have tried the following ways to autostart (your latest) Sundtek driver:

1. Driver default: softlink to /usr/script/sun_dvb.sh on etc/rc3.d ("ln -sfn /usr/script/DVB_T_Tuner_starten.sh /etc/rc3.d/S99tuner.sh") => did not work, the system could not tune both USB tuners ("Tune failed" error message) after your script restart the e2.

2. My first idea: call /usr/script/sun_dvb.sh with "start_t" parameter from /etc/init.d/bootmisc.sh file => did not work, the system could not tune both USB tuners ("Tune failed" error message) after your script restart the e2.

3. My second idea: created a "rcS.local" file in "/etc/init.d" directory and call the /usr/script/sun_dvb.sh file with "start_t" parameter => did not work, the system could not tune both USB tuners ("Tune failed" error message) after your script restart the e2.

4. My third idea: I tried to start only the mediaserver from the above mentioned two places (from "bootmisc.sh" and "rcS.local" file the following command line: "/opt/bin/mediasrv -d") and after that I manually restart e2 from OSD. Unfortunately also did not work, the system could not tune both USB tuners ("Tune failed" error message) after the e2 restart.

If I telnet to the Vu+ (after the boot process wholly ends!) and manually start first the mediasrv (with command: "/opt/bin/mediasrv -d") and then I restart the enigma (with command: "killall -9 anigma2" or "Menu -> Power off -> Restart Enigma" from OSD) both USB tuners work perfectly without any problem.

What is your opinion about this issue?

Do you have got any further idea how can I autostart your driver (mediasrv) on my Vu+ Uno?

Thanks in advance,
Gábor

[Sundtek]

What do following commands show up:
/opt/bin/mediaclient -e
cat /proc/bus/nim_sockets

Maybe /etc/sundtek.conf
put this in the serial number section
first_adapter=4 (or maybe 2 or 3)

[szirog]

Dear Sundtek Support,

First thank you for quick reply!

What do following commands show up:
/opt/bin/mediaclient -e
cat /proc/bus/nim_sockets

============>
root@vuuno:~# /opt/bin/mediaclient -e
**** List of Media Hardware Devices ****
device 0: [MediaTV Digital Home III (EU)]  DVB-C, DVB-T, DVB-T2, REMOTE-CONTROL
  [INFO]:
     STATUS: STANDBY
  [BUS]:
     ID: 1-2.1
  [SERIAL]:
     ID: U140610191403
  [DVB-C]:
     FRONTEND: /dev/dvb/adapter2/frontend0
     DVR: /dev/dvb/adapter2/dvr0
     DMX: /dev/dvb/adapter2/demux0
  [DVB-T]:
     FRONTEND: /dev/dvb/adapter2/frontend0
     DVR: /dev/dvb/adapter2/dvr0
     DMX: /dev/dvb/adapter2/demux0
  [DVB-T2]:
     FRONTEND: /dev/dvb/adapter2/frontend0
     DVR: /dev/dvb/adapter2/dvr0
     DMX: /dev/dvb/adapter2/demux0
  [REMOTECONTROL]:
     INPUT0: /dev/mediainput0

root@vuuno:~#
root@vuuno:~#
root@vuuno:~# cat /proc/bus/nim_sockets
NIM Socket 0:
        Type: DVB-S2
        Name: Vuplus DVB-S NIM(AVL2108)
        Frontend_Device: 0
        I2C_Device: 2


NIM Socket 1:
        Type: DVB-T
        Name: A867
        Frontend_Device: 1
NIM Socket 2:
        Type: DVB-T
        Name: Sundtek DVB-T (III) (0/0) (USB)
        Frontend_Device: 2
root@vuuno:~#
root@vuuno:~# lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 003 Device 001: ID 1d6b:0001
Bus 004 Device 001: ID 1d6b:0001
Bus 001 Device 002: ID 07ca:1867
Bus 001 Device 003: ID 1a40:0101
Bus 001 Device 004: ID 2659:1401
Bus 001 Device 005: ID 0951:1665
Bus 001 Device 006: ID 0403:6001
root@vuuno:~#
<============

Maybe /etc/sundtek.conf
put this in the serial number section
first_adapter=4 (or maybe 2 or 3)

I think in my case the correct driver option is (must be) "first_adapter=2". Is it right?

I will try it this evening when I'll be at home!

Thanks in advance,
Gábor

[Sundtek]

You need to test, that kind of tuner setup heavily depends if the STB supports it or not.

[szirog]

Hi,

I have tried three versions ("first_adapter=4","first_adapter=3" and "first_adapter=2") and none of them works - just the error message changed to "There is no data on the transponder (PAT reading timeout)".

I think my STB supports this type of tuner because of if I manually start the driver it works correctly - so this cannot be a substantive question.

My opinion is the next: before the first e2 start (which normally the last step on a boot process) the Sundtek driver doesn’t recognize correctly which USB tuner is its and which isn't its (and tries to tune the other USB tuner - in my case the Avermedia A867 USB stick - which couldn't be successful). Is it possible?

Best regards,
Gábor 

[Sundtek]

Basically there should not be any difference between starting the driver manually and autostarting everything. The only thing I could think about would be that the legacy drivers are loaded on the fly and mess up the tuner allocation, so maybe you just need to see that your legacy drivers are loaded earlier?
I know that 2 of our devices work at the same time and there's no problem with it.

[szirog]

My "legacy" driver are two kernel objects the dvb-usb and the dvb-usb-a867. As I know this objects is loaded automatically by the kernel during boot process.

Here is my last bootlog (logged by syslogd, I shorted and signed the relevant lines with colours):

Jun 30 22:55:13 vuuno syslog.info syslogd started: BusyBox v1.22.1
Jun 30 22:55:13 vuuno user.notice kernel: klogd started: BusyBox v1.22.1 (2014-04-13 19:28:35 CEST)
Jun 30 22:55:13 vuuno user.notice kernel: Linux version 3.1.1 (build@buildserver) (gcc version 4.8.2 (GCC) ) #1 SMP Sun Apr 13 19:54:47 CEST 2014
Jun 30 22:55:13 vuuno user.info kernel: Fetching vars from bootloader... found 11 vars.
Jun 30 22:55:13 vuuno user.info kernel: Options: sata=1 enet=1 emac_1=1 no_mdio=0 docsis=0 pci=1 smp=1 moca=0 usb=1
Jun 30 22:55:13 vuuno user.info kernel: Using 512 MB + 0 MB RAM (from CFE)
Jun 30 22:55:13 vuuno user.info kernel: CPU revision is: 0002a044 (Brcm4380)
Jun 30 22:55:13 vuuno user.info kernel: FPU revision is: 00130001
Jun 30 22:55:13 vuuno user.info kernel: Determined physical RAM map:
Jun 30 22:55:13 vuuno user.info kernel:  memory: 10000000 @ 00000000 (usable)
.
.
.
Jun 30 22:55:14 vuuno user.info kernel: VFS: Mounted root (ubifs filesystem) on device 0:12.
Jun 30 22:55:14 vuuno user.info kernel: devtmpfs: mounted
Jun 30 22:55:14 vuuno user.info kernel: Freeing unused kernel memory: 232k freed
Jun 30 22:55:14 vuuno user.notice kernel: scsi 2:0:0:0: Direct-Access     Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI: 4
Jun 30 22:55:14 vuuno user.notice kernel: sd 2:0:0:0: [sdb] 120845300 512-byte logical blocks: (61.8 GB/57.6 GiB)
Jun 30 22:55:14 vuuno user.notice kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jun 30 22:55:14 vuuno user.debug kernel: sd 2:0:0:0: [sdb] Mode Sense: 45 00 00 00
Jun 30 22:55:14 vuuno user.notice kernel: sd 2:0:0:0: Attached scsi generic sg1 type 0
Jun 30 22:55:14 vuuno user.warn kernel: scsi: killing requests for dead queue
Jun 30 22:55:14 vuuno user.notice kernel: sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Jun 30 22:55:14 vuuno user.info kernel:  sdb: sdb1
Jun 30 22:55:14 vuuno user.warn kernel: scsi: killing requests for dead queue
Jun 30 22:55:14 vuuno user.warn kernel: scsi: killing requests for dead queue
Jun 30 22:55:14 vuuno user.notice kernel: sd 2:0:0:0: [sdb] Attached SCSI removable disk
Jun 30 22:55:14 vuuno user.warn kernel: scsi: killing requests for dead queue
Jun 30 22:55:14 vuuno user.warn kernel: scsi: killing requests for dead queue
Jun 30 22:55:14 vuuno user.warn kernel: scsi: killing requests for dead queue
Jun 30 22:55:14 vuuno user.warn kernel: scsi: killing requests for dead queue
Jun 30 22:55:14 vuuno user.warn kernel: EXT4-fs (sda1): warning: maximal mount count reached, running e2fsck is recommended
Jun 30 22:55:14 vuuno user.info kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
Jun 30 22:55:14 vuuno user.warn kernel: procmk_init
Jun 30 22:55:14 vuuno user.info kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
Jun 30 22:55:14 vuuno user.warn kernel: dvb_bcm7413: module license 'Proprietary' taints kernel.
Jun 30 22:55:14 vuuno user.warn kernel: Disabling lock debugging due to kernel taint
Jun 30 22:55:14 vuuno user.info kernel: DVB: registering new adapter (vuuno)
Jun 30 22:55:14 vuuno user.warn kernel: enable MII = 0
Jun 30 22:55:14 vuuno user.warn kernel: Booted !
Jun 30 22:55:14 vuuno user.warn kernel: NEXUS_Frontend_GetUserParameters 0 0
Jun 30 22:55:14 vuuno user.warn kernel: bcm7413: hotplug_callback():
Jun 30 22:55:14 vuuno user.warn kernel: Hotplug - status.connected 1
Jun 30 22:55:14 vuuno user.warn kernel: bcm7413: hotplug_callback():
Jun 30 22:55:14 vuuno user.warn kernel: Hotplug - connecting HDMI to display 0xe
Jun 30 22:55:14 vuuno user.warn kernel: [GPIO]Default
Jun 30 22:55:14 vuuno user.warn kernel: [GPIO]RST Default
Jun 30 22:55:14 vuuno user.warn kernel: [GPIO]fpga secu
Jun 30 22:55:14 vuuno user.warn kernel: [GP]:brcm_pwm_init
Jun 30 22:55:14 vuuno user.info kernel: brcm_demux_init: $Id: bcm7335_demux.c,v 0.6 $
Jun 30 22:55:14 vuuno user.warn kernel: [VID]: <6>bcm7335_video_init
Jun 30 22:55:14 vuuno user.warn kernel: [AUD]: <6>bcm7335_audio_init
Jun 30 22:55:14 vuuno user.warn kernel: DVB: registering adapter 0 frontend 0 (Vuplus FE)...
Jun 30 22:55:14 vuuno user.warn kernel: bcm7413: bcm7335_frontend_init(): vtuner1 : 2
Jun 30 22:55:14 vuuno user.warn kernel: [MPVR]: >> misc_pvr_init
Jun 30 22:55:14 vuuno user.info kernel: input: dreambox advanced remote control (native) as /devices/virtual/input/input0
Jun 30 22:55:14 vuuno user.info kernel: [LCD]: registered
Jun 30 22:55:14 vuuno user.err kernel: ^[[0;35m[CI]:^[[0;0m0 1
Jun 30 22:55:14 vuuno user.info kernel: [CI]: registered ci0 0
Jun 30 22:55:14 vuuno user.info kernel: [CI]: registered ci1 0
Jun 30 22:55:14 vuuno user.info kernel: [DFP]: registered dbox fp
Jun 30 22:55:14 vuuno user.info kernel: [DFP]: Scart 9597 is found 4
Jun 30 22:55:14 vuuno user.info kernel: [SC]: registered sci0
Jun 30 22:55:14 vuuno user.info kernel: [SC]: registered sci1
Jun 30 22:55:14 vuuno user.warn kernel: system_time_set wakeup mode get
Jun 30 22:55:14 vuuno user.warn kernel: system_time_set wakeup mode get 0xc2
Jun 30 22:55:14 vuuno user.warn kernel: fpga update driver loaded
Jun 30 22:55:14 vuuno user.warn kernel: AVerMedia A867 driver module V1.0.27 loaded.
Jun 30 22:55:14 vuuno user.warn kernel:  - By ItalySat.it
Jun 30 22:55:14 vuuno user.info kernel: dvb-usb: found a 'AVerMedia A867 DVB-T Recevier' in warm state.
Jun 30 22:55:14 vuuno user.info kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
Jun 30 22:55:14 vuuno user.info kernel: DVB: registering new adapter (AVerMedia A867 DVB-T Recevier)
Jun 30 22:55:14 vuuno user.warn kernel: DVB: registering adapter 1 frontend 0 (A867 USB DVB-T)...
Jun 30 22:55:14 vuuno user.info kernel: dvb-usb: AVerMedia A867 DVB-T Recevier successfully initialized and connected.
Jun 30 22:55:14 vuuno user.info kernel: usbcore: registered new interface driver dvb-usb-a867
Jun 30 22:55:14 vuuno user.info kernel: usbcore: registered new interface driver usbserial
Jun 30 22:55:14 vuuno user.info kernel: USB Serial support registered for generic
Jun 30 22:55:14 vuuno user.info kernel: usbcore: registered new interface driver usbserial_generic
Jun 30 22:55:14 vuuno user.info kernel: usbserial: USB Serial Driver core
Jun 30 22:55:14 vuuno user.info kernel: USB Serial support registered for FTDI USB Serial Device
Jun 30 22:55:14 vuuno user.info kernel: ftdi_sio 1-2.3:1.0: FTDI USB Serial Device converter detected
Jun 30 22:55:14 vuuno user.info kernel: usb 1-2.3: Detected FT232RL
Jun 30 22:55:14 vuuno user.info kernel: usb 1-2.3: Number of endpoints 2
Jun 30 22:55:14 vuuno user.info kernel: usb 1-2.3: Endpoint 1 MaxPacketSize 64
Jun 30 22:55:14 vuuno user.info kernel: usb 1-2.3: Endpoint 2 MaxPacketSize 64
Jun 30 22:55:14 vuuno user.info kernel: usb 1-2.3: Setting MaxPacketSize 64
Jun 30 22:55:14 vuuno user.info kernel: usb 1-2.3: FTDI USB Serial Device converter now attached to ttyUSB0
Jun 30 22:55:14 vuuno user.info kernel: usbcore: registered new interface driver ftdi_sio
Jun 30 22:55:14 vuuno user.info kernel: ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
Jun 30 22:55:14 vuuno user.warn kernel: [VID]: VIDEO_SET_STREAMTYPE 0
Jun 30 22:55:14 vuuno user.warn kernel: [VID]: VIDEO_SELECT_SOURCE 1  
Jun 30 22:55:14 vuuno user.warn kernel: [VID]: VIDEO_PLAY 1  2 0
Jun 30 22:55:14 vuuno user.warn kernel: [VID]: VIDEO_CONTINUE 1  1
Jun 30 22:55:14 vuuno user.warn kernel: [VID]: VIDEO_CLEAR_BUFFER 1  1 0
Jun 30 22:55:14 vuuno user.warn kernel: [VID]: VIDEO_STOP 0  1
Jun 30 22:55:14 vuuno user.warn kernel: [VID]: VIDEO_SELECT_SOURCE 0  
Jun 30 22:55:14 vuuno user.info kernel: NET: Registered protocol family 10
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: Found user 'avahi' (UID 998) and group 'avahi' (GID 997).
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: Successfully dropped root privileges.
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: avahi-daemon 0.6.31 starting up.
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: Successfully called chroot().
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: Successfully dropped remaining capabilities.
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: Loading service file /services/sftp-ssh.service.
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: Loading service file /services/ssh.service.
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: Joining mDNS multicast group on interface eth0.IPv4 with address 172.31.106.100.
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: New relevant interface eth0.IPv4 for mDNS.
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: Network interface enumeration completed.
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: Registering new address record for fe80::21d:ecff:fe04:356 on eth0.*.
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: Registering new address record for 172.31.106.100 on eth0.IPv4.
Jun 30 22:55:14 vuuno daemon.info avahi-daemon[482]: Registering HINFO record with values 'MIPS'/'LINUX'.
Jun 30 22:55:15 vuuno daemon.info avahi-daemon[482]: Server startup complete. Host name is vuuno.local. Local service cookie is 1218575850.
Jun 30 22:55:15 vuuno user.err kernel: [SC]: !!!unknown cmd 0x5407
Jun 30 22:55:15 vuuno user.warn kernel: [VID]: VIDEO_SET_STREAMTYPE 0
Jun 30 22:55:15 vuuno user.warn kernel: [VID]: VIDEO_SELECT_SOURCE 1  
Jun 30 22:55:15 vuuno user.warn kernel: [VID]: VIDEO_PLAY 1  2 0
Jun 30 22:55:15 vuuno user.warn kernel: [VID]: VIDEO_CONTINUE 1  1
Jun 30 22:55:15 vuuno user.warn kernel: [VID]: VIDEO_CLEAR_BUFFER 1  1 0
Jun 30 22:55:15 vuuno daemon.info avahi-daemon[482]: Service "vuuno" (/services/ssh.service) successfully established.
Jun 30 22:55:15 vuuno daemon.info avahi-daemon[482]: Service "vuuno" (/services/sftp-ssh.service) successfully established.
Jun 30 22:55:16 vuuno user.warn kernel: [VID]: VIDEO_STOP 0  1
Jun 30 22:55:16 vuuno user.warn kernel: [VID]: VIDEO_SELECT_SOURCE 0  
Jun 30 22:55:18 vuuno user.err kernel: [SC]: !!!unknown cmd 0x5407
Jun 30 22:55:19 vuuno user.err kernel: [LCD]: unknown cmd 0x1015
Jun 30 22:55:19 vuuno user.warn kernel: [CI]:ci_dev_open
Jun 30 22:55:19 vuuno user.warn kernel: [CI]:entering.. A NEXUS_DvbCi_Open
Jun 30 22:55:19 vuuno user.warn kernel: [CI]:NEXUS_DvbCi_Open done..
Jun 30 22:55:19 vuuno user.warn kernel: [CI]:Installing callbacks
Jun 30 22:55:19 vuuno user.warn kernel: [CI]:Forcing card check
Jun 30 22:55:19 vuuno user.warn kernel: [CI]:Card insertion status changed
Jun 30 22:55:19 vuuno user.warn kernel: [CI]:entering.. B NEXUS_DvbCi_Open
Jun 30 22:55:19 vuuno user.warn kernel: [CI]:NEXUS_DvbCi_Open done..
Jun 30 22:55:19 vuuno user.warn kernel: [CI]:Installing callbacks
Jun 30 22:55:19 vuuno user.warn kernel: [CI]:Forcing card check
Jun 30 22:55:19 vuuno user.warn kernel: [CI]:Card B insertion status changed
Jun 30 22:55:19 vuuno user.info kernel: [CI]: CI interface initialised
Jun 30 22:55:19 vuuno user.warn kernel: [CI]:ci1_dev_open
Jun 30 22:55:21 vuuno user.warn kernel: DVB: registering adapter 0 frontend 0 (vtuner fe)...
Jun 30 22:55:23 vuuno user.debug kernel: eth0: no IPv6 routers present
Jun 30 22:55:42 vuuno user.warn kernel: [AUD]: AUDIO_SET_MUTE 0
.
.
.
Jun 30 22:55:46 vuuno user.warn kernel: [AUD]: AUDIO_CHANNEL_SELECT 0
Jun 30 22:56:00 vuuno authpriv.notice login[569]: ROOT LOGIN  on '/dev/pts/0' from '172.31.106.99:45212'
Jun 30 22:56:39 vuuno user.warn kernel: [VID]: VIDEO_STOP 1  1
Jun 30 22:56:39 vuuno user.warn kernel: [AUD]: AUDIO_STOP 65196
.
.
.
Jun 30 22:56:43 vuuno user.warn kernel: [VID]: VIDEO_GET_SIZE aspect: 1 0
Jun 30 22:57:04 vuuno user.warn kernel: DVB: registering adapter 0 frontend 0 (Sundtek DVB-T (III) (0/0))...
Jun 30 22:57:12 vuuno user.warn kernel: [VID]: VIDEO_STOP 1  1
Jun 30 22:57:12 vuuno user.warn kernel: [AUD]: AUDIO_STOP 6519648
Jun 30 22:57:12 vuuno user.warn kernel: [AUD]: AUDIO_CONTINUE 6519648 0 aph=0x0

According to this log the drivers loaded by the kernel the following order:
- internal DVB-S2 tuner,
- internal DVB-S2 tuner frontend,
- Avermedia A867 driver (dvb-usb, dvb-usb-a867)
(I logged in the box via telnet and manually started the)
- Sundtek driver

I think the internal DVB-S2 tuner and the "legacy" USB tuner drivers always loaded earlier by the kernel than your driver - but I'm not sure to 100%!

I saved this log and I'll compare this with a "driver autosart case" bootlog.

I'm  sharing my conclusion soon...  

One more question: your driver uses one shared object loaded by the e2 ("/opt/lib/libmediaclient.so"). What does it do exactly?

Best regard,
Gábor

[Sundtek]

libmediaclient.so is the driver interface library. As from your backlog I don't see that there's anything wrong actually.
What does /opt/bin/mediaclient -e show up when the DVB-T only tuner doesn't work?
I think there have been some users having a similar setup in the past successfully.

[szirog]

Last night I checked the autostart bootlog compare by the inserted one - unforunately the two logs are same.
On both cases the system starts first the internal tuner, internal frontend, Avermedia A867 USB stick drivers and last the Sundtek driver.
So this idea/way is closeable.

What does /opt/bin/mediaclient -e show up when the DVB-T only tuner doesn't work?
Unforunately the output of this command are same on both cases - I have inserted this into my third post.

If we check the gist there is only one little difference between the working and the non-working cases:

when the configuration works	||	when the configuration doesn't work
---------------------------------------	||	----------------------------------------------
internal tuner driver inicialization	||	internal tuner driver inicialization
internal frontend driver inicialization	||	internal frontend driver inicialization
Avermedia USB stick driver inicialization	||	Avermedia USB stick driver inicialization
enigma2 (first) start	||	Sundtek driver inicialization
Sundtek driver inicialization	||	enigma2 (first) start
enigma2 restart	||

On the working case before the Sundtek driver inicializaton the e2 has yet standed up once and there isn't any e2 restart. Because of I have tried several times the Sundtek driver re-inicialization + e2 restart on the non-working case and it doesn't help we can lock-out this from this issue. Left is relation of the e2 (first) start and the Sundtek driver inicialization. But this thread I cannot examine further, just the Sundtek can...

And one more fact: on the working case when I watch something from the Sundtek DVB stick there isn't correct signal strength indication on the e2 OSD (e2 always shows "0%" or "0dB" signal strength) and on the other tuners (internal, Avermedia USB stick) this function is working properly (e.g.: "89%" or "17dB").
When my USB sticks don't work (I want to autostart the Sundtek driver) the e2 shows signal strength on Sundtek tuner also - but there isn't picture and sound (and this is true on the Avermedia USB tuner also).

So my question is (sorry if I repeat myself): not possible that your driver couldn't recognize correctly before the first e2 start which stick is its and which isn't its?

Best regards,
Gábor

[Sundtek]

Whenever you access the tuner /opt/bin/mediaclient --lc should show up mediasrv below frontend0 maybe this helps.
We tested multiple tuners on our side and there hasn't been any problem, our driver even checks if other interfaces are already allocated (this is what I mean settopboxes have to support this).
Even in the past some users got it work that way, maybe you can try to contact them? We did not change anything in that area actually.

maybe you can try to rename /dev/misc/vtuner0 to /dev/misc/vtuner1 and /dev/misc/vtuner1 to /dev/misc/vtuner0
Possibly they mix up something when registering the second one before the first one.

However that said we do not really support mixing various USB tuners on the USB bus (we do not lock it out either) because different chipsets can cause different issues on the USB bus / controller. And we certainly do not want to dig into other devices which are not manufactured by us. It even was a difficult task to optimize the drivers for our previous series and the current ones which we manufacture (MediaTV III/SkyTV IV series introduce new usb chipsets in our product line) to work together at the same time.


http://www.vuplus-support.org/wbb3/index.php?page=Thread&threadID=21091

As far as it goes back nothing changed since then, so you might give the other image a try maybe.

[szirog]

First: I thank you for the patience of the Sundtek Support and also their ideas.

This helped me that I found the correct solution for the driver autostarting issue - but unfortunately this prove something doesn't work properly in the Sundtek driver.

One substantial fact: the Vu+ Uno STB has got only two "vtuner" devices ("vtuner0" and "vtuner1") which always automatically created by the system during the boot process independently there is/are (extra) tuner(s) connected to the STB or not. When enigma2 start (at end of the boot process or when manually re-started) it links this devices to /dev/dvb/adapter[N]/frontend[n] devices.

After this here is my solution:
- remove the "vtuner_skip0=vtuner0" option from /etc/sundtek.conf,
- before the driver start ("/opt/bin/mediasrv -d" in either startup file) I exchange the (/dev/misc/) vtuner0 and vtuner1 devices,
- and whoooala: the Sundtek driver and its autostart also work perfectly!!!
After this the second and third tuner position changed in enigma2 (Tuner A: internal DVB-S2, Tuner B: Sundtek DVB-T (III) Tuner C: Avermedia A 867 DVB-T) and all of them work!

After this I can't understand what is the problem of Sundtek driver, exactly what is the problem with the co-operation between the enigma2+libmediaclient.so and mediasrv - but something must be wrong because it cannot work with the same driver options if I try to autostart it and if I try to manually start it - this cannot be a normal situation (In other words: if I don't exhange during the boot process the two vtuner devices the driver cannot be autostarted correctly)!

I hope Sundtek Support will find the real reason of this issue sometime in the future!

Thank you again for your support!

[Sundtek]

No this only proves that something's wrong with the Interface on the STB. If there are 2 nodes both should be accessible without interfering each other and as you've seen it does interfere with each other.

We wrote our own vtuner module for other settopboxes and know what can easily go wrong here so I'm not surprised that VU+ does not support this for 100%, but for 90% at least.

If 2 of our devices are used the first tuner takes vtuner0 the second one vtuner1 and everything is fine.
We have seen in the past when registering vtuner1 before vtuner0 then there might be an issue with some STBs. This code is within the broadcom driver package among all STBs.