Sundtek Support Forum
English => VU+ - VU Duo Settopbox => Thema gestartet von: tentacle am November 03, 2011, 02:12:50 Vormittag
-
Hallo, I have this combination: USB DVB-C/T tuner Sundtek MediaTV Digital Home, VU+ UNO, SMiT Conax Chipset Pairing CAM with UPC czech smart card (cable TV UPC in Czech Republic). All DVB-C programs I tune successfully, but only free (not encoded) programs works. On TV LG LE8500 all DVB-C programs works OK(CAM with card works with TV DVB-C tuner fine). Help. Need I any drivers, special plug-in or adjustments for VU+ UNO ? I try different images in VU+ UNO (VTI Team, Blackhole, AAF Summer Image ...) but there is still problem with encoded programs (black screen). Thanks.
-
According to our information this is exactly what they (VU+) wanted to work on 1 year ago and we actually thought that they solved that problem already. Direct CAM support is something VU+ needs to offer within their infrastructure.
We'll forward this to the corresponding contact person and see what the answer will be.
-
Hmm, bad news :( , but thank you very mouch for the time being. Perhaps better news to arrive.
-
Actually another user just reported that CAM support worked for him, it's getting difficult now he had issues with his CAM module itself? Can you check your CAM module somehow?
-
CAM with card is certainly OK. In other devices with DVB-C tuners works flawlessly - all programs displays correctly (free and encoded) there. Only in VU+ UNO with Sundtek MediaTV Digital Home is this problem.
-
This is a topic which VU+ wanted to fix 1 year ago already, we are going over those issues again with them next week.
We were quite surprised to hear that this still doesn't work. For next week we will try to get some official information from VU what they support and what not, the limitation is not on our side, if any updates are required on our side we'll certainly work on it.
-
I have exactly the same problem. As this is already some time, have you achieved any progress with Vu+ Duo support to be able to watch encrypted channels using Conax CAM?
-
This is a topic which VU+ wanted to fix 1 year ago already, we are going over those issues again with them next week.
We were quite surprised to hear that this still doesn't work. For next week we will try to get some official information from VU what they support and what not, the limitation is not on our side, if any updates are required on our side we'll certainly work on it.
Some progress after 10 months or can i DVB-C USB finally throw in the trash :( ??? !!!!
-
This is a topic which VU+ wanted to fix 1 year ago already, we are going over those issues again with them next week.
We were quite surprised to hear that this still doesn't work. For next week we will try to get some official information from VU what they support and what not, the limitation is not on our side, if any updates are required on our side we'll certainly work on it.
Some progress after 10 months or can i DVB-C USB finally throw in the trash :( ??? !!!!
Instead of posting something like that in our forum you should call your vendor or settopbox manufacturer as they claim to support external tuners. We support the external interface for 100% (and not less than 100%) if your settopbox supplier doesn't push Marusys no change will happen for you, obviously we have done our best here to support issues which are completely out of our hands here.
We visited Marusys within the last 10 months, and contacted them several times and even got answers, however for some usecase they cannot test it and the code that has to be modified is in their hands not in ours.
If there is anything that can be done from our side to help supporting CAM Modules we can certainly help.
-
Hello.
It seems, the army of unhappy customers with the Vu products and Sundtek is increased ;)
By me.
According to mentioned above issues with the some examples Conax CAM modules, and acts of contacting between Sundtek and Marusys, may be it is possible to use yours contact-line (Sundtek<>Marusys) to offer to the Marusys of the my-own (daily, one or two later evening hours) time and resource to be as a beta-tester on resolving of discussed problems ?
Yes, I am do not have the specific hardware(JTAG for example or other factory-line devices). But, because I have some linux-skills, I can collect a logs, run some debug applications, an so on to provide that information to the manufacturer.
What do you think ?
-
Unfortunately this is not a problem on our side, it's completely out of our scope and we have no access to the datapipe which can pipe the TS video stream through the CAM.
It needs a modification within the VU+ System drivers. Marusys is not that big every mail sent to them arrives at the right people. The other problem is that they don't have many resources for such development.
One of our distributors was talking with them a long time ago but nothing happened either in the direction to support CAM modules.
-
Unfortunately this is not a problem on our side, it's completely out of our scope
Yes, I've read about it.
and we have no access to the datapipe which can pipe the TS video stream through the CAM.
But, thanks for the little details.
My post here - it was a hope what is the distance between you and Marusys - is much closer, than between me (or any other Vu customesr) and them. And you have some direct mail contacts with them, or you have the meetings from time-to-time on the some of international expo's, because your works - is inside the same field.
Push the supplier? You know, is the much more than the nothing. At least in Russia, with the "strange bussiness", where the one side, the most of suppliers targeted at the only one way: collecting a cash. And the other side, most of customers goes to the any supplier, which can offer the best price.
As a result - the connection line on the way [customer]->[supplier]->[manufacturer] in the most of cases are broken.
Anyway, Thank you for your reply.
-
Today my cable provider starts sending an update for their Conax modules.
In short words, their instruction is - "just switch to the any our channel and waiting for automatic updating starts".
Due to I am writing this message here - no automatic update starts in my case. Also, no updates found if I navigate to the CI-menu with the "Update Firmware" option in module menu.
Is this the same smell from Marusys drivers as described above about decrypting encrypted channels ?
Or it is a little bit different situation? Dead module ?
-
Hmm.. must be within the Marusys drivers, we pick the TS Stream from our device on it and copy it into the interface from Marusys, everything further is a black box for us.
-
we pick the TS Stream from our device on it and copy it into the interface from Marusys
Is there any way to backtrace this operation?
May be some parts of TS (other than VPID and APID), wich is comes from your device, in some (in my) cases stay ignored by Marusys drivers ?
In your side is no demultiplexing (by the chip for examble)? full TS "as is" redirecting to the Marusys side ?
-
There are 3 Options availabe:
1. Software PID Filter (default on PCs)
/opt/bin/mediaclient -P off -d /dev/dvb/adapter1/frontend0
2. Hardware PID Filter (default on eg. dreambox and other boxes)
/opt/bin/mediaclient -P on -d /dev/dvb/adapter1/frontend0
3. Passthrough, ignore all filters
/opt/bin/mediaclient -P passthrough -d /dev/dvb/adapter1/frontend0
Aside of that you can always read what is passed to the settopbox by running
/opt/bin/mediaclient --cat /dev/dvb/adapter1/dvr0 > /media/hdd/stream.ts
-
There are 3 Options availabe:
/opt/bin/mediaclient -P off -d /dev/dvb/adapter1/frontend0
/opt/bin/mediaclient -P on -d /dev/dvb/adapter1/frontend0
Oops. How your device remember chosen options? config file/flash cell? Or It option automatic ajusted by the driver's intellect?
Before I am start using this stick with the VU+ STB, I performed a some tests on PC (with the set of different softwares). May be it is the point of problems? Some PC software enables HW/SW PID filtering and this config is deep stored into the device ?
-
You can read through the driver configuration file
http://wiki.sundtek.de/index.php/TreiberKonfiguration
the commands are instant options, as soon as you run them they will be active immediately
-
http://wiki.sundtek.de/
BIG Thanks for the manpage! I am completely missed this page (installation/configuration steps I've got from forum messages only).
I'll checkup the my configs by this evening.
-
I'll checkup the my configs by this evening.
Something strange in that kingdom.
first: by default I am do not found the /etc/sundtek.conf file.
When I create it (even if it contains only commented lines), the tuner fails to start.
The example file I've take from wiki page.
second: if I pass the command
/opt/bin/mediaclient --tsscan /dev/dvb/adapter1/dvr0
it does nothing. Just freezes. It unfreezes by Ctrl+C
If I pass one of that command:
/opt/bin/mediaclient -P off -d /dev/dvb/adapter1/frontend0
or
/opt/bin/mediaclient -P passthrough -d /dev/dvb/adapter1/frontend0
no changes at all:
--tsscan - still freezes;
- no success on encrypted channels;
- no success on firmware update
It is I am doing something wrong ?
PS.
I am check the -e output. It contains next:
root@vuuno:~# /opt/bin/mediaclient -e
**** List of Media Hardware Devices ****
device 0: [Sundtek MediaTV Digital Home (USB 2.0)] DVB-C, DVB-T, REMOTE-CONTROL
[SERIAL]:
ID: U120622043728
[DVB-C]:
FRONTEND: /dev/dvb/adapter1/frontend0
DVR: /dev/dvb/adapter1/dvr0
DMX: /dev/dvb/adapter1/demux0
[DVB-T]:
FRONTEND: /dev/dvb/adapter1/frontend0
DVR: /dev/dvb/adapter1/dvr0
DMX: /dev/dvb/adapter1/demux0
[REMOTECONTROL]:
INPUT0: /dev/mediainput0
BUT!
I am do not see these devices in /dev/ folder:
root@vuuno:~# ls -l /dev/dvb
drwxr-xr-x 2 root root 540 Jan 1 1970 adapter0
root@vuuno:~#
-
The driver is started with the --no-nodes option that's why it doesn't work.
however you can try to use following mediaclient version until the next driver version will be avialable:
http://sundtek.de/support/mediaclient
This version will support the --no-nodes option of the driver (that means that the node itself is not existent in /dev/dvb)
Edit:
official driver is udpated for that to support drivers which are started with --no-nodes
-
official driver is udpated for that to support drivers which are started with --no-nodes
Okay, I catch the new driver, and --tsscan is work for now. Thank you very much.
But, I want return to the on-topic problem.
I try to run once this command at this morning, and see the output starts with a lot of fake (zeroes) CAID's. Two or three dozen. I cant attach a log at this moment, but I can do this at this evening.
May be this is the point of unrecognized encryption by the driver of Marusys.
But anyway, at this evening I'll do some more tests with the mediaclient.
The last question: --no-nodes - it can be overridden to force nodes creation ? It can be useful to TS exploration with the dvbsnoop utility.
Or there are exists an another way to work with dvbsnoop (to perform comparing between different TS's from different tuners)?
-
Well you can check back with Marusys.
You can check it on a regular PC or start the driver manually on the settopbox.
The devicenodes are not created due bugs in some Enigma2 versions.
Shut down enigma2, and run /opt/bin/mediaclient --shutdown; /opt/bin/mediaclient --start
Before running dvbsnoop etc. run export LD_PRELOAD=/opt/lib/libmediaclient.so
-
Before running dvbsnoop etc. run export LD_PRELOAD=/opt/lib/libmediaclient.so
I am not reach the success with the dvbsnoop. Even I run command described in quotation.
It is required the devicenode, or I don't know how I can run dvbsnoop on the DVB-C tuner. Starting dvbsnoop without specifying the device - fails. With the targeting on "virtual" node - fails too
Output for mediaclient --tsscan - is (with "cuts"): it starts with a lot of (~80 times) messages like
CAT:
CA system: 0b00
CAT:
CA system: 0b00
CAT:
CA system: 0b00
CAT:
CA system: 0b00then, follows the normal recognition
PMT PID: 0x0064
Encrypted: Yes
Service running: Yes
Provider Name: OnLime
Service Name:
--> 0x0065 (ITU-T Rec. H.262 | ISO/IEC 13818-2 Video or ISO/IEC 11172-2 constrained parameter video stream)
--> 0x006e (ISO/IEC 13818-3 Audio)
--> 0x0096 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x00c8
Encrypted: Yes
Service running: Yes
Provider Name: OnLime
Service Name: c 1
--> 0x00c9 (ITU-T Rec. H.262 | ISO/IEC 13818-2 Video or ISO/IEC 11172-2 constrained parameter video stream)
--> 0x00d2 (ISO/IEC 13818-3 Audio)
--> 0x00fa (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
when I wrote the morning's message - I have been mistake by myself, because not paid enough of time.
What is the leading "stream" with the messages about "CAID" ? Is this normal for DVB ?
How can I understand a PID where the EMM/ECM transmission present ? It sould be a single PID for all channels. Do I am right?
And two comments on output of --tsscan command
#1 The first service - is not encrypted. It can be watched on totally FTA devices. And STB show this channel not marked as encrypted.
#2 The names of the services transmitted in cyrillic. Due to it correct displayed on STB, I think they are transmitted in UTF-8
The described quotation of --tsscan commnd taken with the "-P off" option.
PS.
I would like you not tired?
-
capture the TS stream to hard disk, dvbsnoop is not fast enough to do realtime analysis.
/opt/bin/mediaclient --cat /dev/dvb/adapter1/dvr0 > /media/hdd/test.ts
CAT/CA system is just printed whenever such packet comes in.
Service name is probably not printed because of the russian character set on the console (only ASCII is printed, it's just for informational purpose on the console)
-
interesting observation.
On the different channels, stick chooses different pid-space to HW filtering.
What is the algorhythm ?
For example, on the one cable-channel(I mean the frequency-holder; like "transponder" on DVB-S) PID-list is
root@vuuno:~# /opt/bin/mediaclient -w -d /dev/dvb/adapter1/dvr0
Using device: /dev/dvb/adapter1/dvr0
ID | PID
----------
0000 | 0x0000 - 0
0001 | 0x0065 - 101
0002 | 0x006e - 110
0003 | 0x0096 - 150
0004 | 0x0064 - 100
0005 | 0x0012 - 18
root@vuuno:~#
on the second (where the all channels is encrypted) is the
root@vuuno:~# /opt/bin/mediaclient -w -d /dev/dvb/adapter1/dvr0
Using device: /dev/dvb/adapter1/dvr0
ID | PID
----------
0000 | 0x01f4 - 500
0001 | 0x01f5 - 501
0002 | 0x01fe - 510
0003 | 0x0046 - 70
0004 | 0x0012 - 18
0005 | 0x0f02 - 3842
0006 | 0x0bbb - 3003
0007 | 0x1388 - 5000
0008 | 0x0039 - 57
root@vuuno:~#
And another observation.
When I try to remove some(even the one) PID from the list (via pass the "-x NNNN" command), STB starts to show a broken MPEG decoding, like a low-signal on DVB-S. As mentioned in wiki-documentation, it may be due low speed of USB connection?
-
Enigma is setting up those IDs depending on the channel.
-
As I ask before - how can I understand on which PID present the CA messages ? This is to check the HW filtering list.
-
you can capture the stream and look at it with dvbsnoop. All the logic is in Enigma here.
-
you can capture the stream and look at it with dvbsnoop. All the logic is in Enigma here.
Ok, I'm done with this. I am just take a couple of the days to learning myself about containment of the DVB-streams basics, and what I am found.
Your side take a set of pids from Enigma2 ? Or parse PAT && CAT && PMT itself ?
This is important, because resulting set of pids on encrypted channels is totally incomplete.
This is what using the your side on encrypted channel by default (just switch on to channel and dump the pid set):
root@vuuno:~# /opt/bin/mediaclient -w -d /dev/dvb/adapter1/dvr0
Using device: /dev/dvb/adapter1/dvr0
ID | PID
----------
0000 | 0x0000 - 0
0001 | 0x00C9 - 201
0002 | 0x00D2 - 210
0003 | 0x00FA - 250
0004 | 0x00C8 - 200
0005 | 0x0012 - 18
root@vuuno:~#
And this - is the dvbsnoop analysis(with cuts to reduce the message size), performed on TS, catched when HW pid filter is switched off (no matter where - on STB or on the PC with the ProgDVB). Missed pids marked as Bold.
CAT-table:
------------------------------------------------------------
TS-Packet: 00000001 PID: 1 (0x0001), Length: 188 (0x00bc)
------------------------------------------------------------
{cut}
TS sub-decoding (1 packet(s) stored for PID 0x0001):
=====================================================
TS contains Section...
SI packet (length=18):
PID: 1 (0x0001) [= assigned for: ISO 13818-1 Conditional Access Table (CAT)]
Guess table from table id...
CAT-decoding....
Table_ID: 1 (0x01) [= Conditional Access Table (CAT)]
section_syntax_indicator: 1 (0x01)
(fixed): 0 (0x00)
reserved_1: 3 (0x03)
Section_length: 15 (0x000f)
reserved_2: 262143 (0x3ffff)
Version_number: 2 (0x02)
current_next_indicator: 1 (0x01) [= valid now]
Section_number: 0 (0x00)
Last_Section_number: 0 (0x00)
MPEG-DescriptorTag: 9 (0x09) [= CA_descriptor]
descriptor_length: 4 (0x04)
CA_system_ID: 2816 (0x0b00) [= Norwegian Telekom]
reserved: 7 (0x07)
CA_PID: 90 (0x005a)
CRC: 734917485 (0x2bcdf36d)
PMT-table:
------------------------------------------------------------
TS-Packet: 00000001 PID: 200 (0x00c8), Length: 188 (0x00bc)
------------------------------------------------------------
{cut}
TS sub-decoding (1 packet(s) stored for PID 0x00c8):
=====================================================
TS contains Section...
SI packet (length=53):
PID: 200 (0x00c8)
Guess table from table id...
PMT-decoding....
Table_ID: 2 (0x02) [= Program Map Table (PMT)]
section_syntax_indicator: 1 (0x01)
(fixed '0'): 0 (0x00)
reserved_1: 3 (0x03)
Section_length: 50 (0x0032)
Program_number: 2 (0x0002)
reserved_2: 3 (0x03)
Version_number: 16 (0x10)
current_next_indicator: 1 (0x01) [= valid now]
Section_number: 0 (0x00)
Last_Section_number: 0 (0x00)
reserved_3: 7 (0x07)
PCR PID: 201 (0x00c9)
reserved_4: 15 (0x0f)
Program_info_length: 6 (0x0006)
MPEG-DescriptorTag: 9 (0x09) [= CA_descriptor]
descriptor_length: 4 (0x04)
CA_system_ID: 2816 (0x0b00) [= Norwegian Telekom]
reserved: 7 (0x07)
CA_PID: 260 (0x0104)
Stream_type loop:
Stream_type: 2 (0x02) [= ITU-T Rec. H.262 | ISO/IEC 13818-2 Video | ISO/IEC 11172-2 constr. parameter video stream]
{cut}
Summary, HW filter misses at least two Pids:
CA_PID: 90 (0x005a) - common TS for EMM/ECM transmission
CA_PID: 260 (0x0104) - per channel TS for EMM/ECM transmission
But.
I must to say, if I add this pids manually to pid set, nothing happens. Channels still encrypted.
This is may caused by one of two reasons. Or by both.
1) due to using pairing Conax cam - it needs some more information, than provided by standart pids (90 && 260). It may needs some additional pid. But I am not shure - it is a hypothesis.
2) due to incomplete handshake between smartcard and CAM, the CAM rejects all data incoming from this CA pids, and it affects to the pid set, which your side takes from enigma.
Described here - covers an encryption issue. Not an updating firmware. Firmware issue - is still not cleared for me - how it regulated by EBU standarts (where and how declared additional pids with the new firmware data).
-
Enigma2 sets up all the PID Filters as mentioned.
The PIDs are not incomplete, all Enigma Boxes work that way, maybe some configuration is incomplete on your side.
The source of your problem is Marusys, you better try to push them (we notified them but don't get any feedback from them either).
-
DVBSnoop does not show up any PID dependencies.
Yes, but I am read some handbooks, and try to calculate dependencies by myself, via analysis output of dvbsnoop or (find it right now) tsr.exe (win32 stream analyser).
The source of your problem is Marusys, you better try to push them (we notified them but don't get any feedback from them either).
I am do not have the magic-button or other tool to push them. I write couple letters to support@vuplus.com, but no response returns back.
Do you mean, if I am manually reconstruct a correct pid-space, and manual add the calculated pids in filter - enigma will still ignore them ?
in both cases - for CA issue and OTA issue?
PS.
In case of OTA (by read this book: http://www.digitag.org/SSU_Handbookv1.0.pdf), I see in the TS a fake-channels, their PMT's, and linkage to their data Pids.
AfterEdit:
---------
maybe some configuration is incomplete on your side
What it can be, for example ?
-
If you run -P passthrough it will offload the entire TS stream to the settopbox and won't pre-filter anything - all PID filters are ignored that way.
But if Enigma does not handle the TS stream on the other side that step is just worthless.
-
If you run -P passthrough it will offload the entire TS stream to the settopbox and won't pre-filter anything - all PID filters are ignored that way.
But bandwidth issue of USB implementation in STB is may cause a losing some packets... Or no?
-
There is no Bandwidth issue on those settopboxes.
-
But if Enigma does not handle the TS stream on the other side that step is just worthless.
It is possible to handle the TS stream for moving it to the CAM-bus ?
There are exist any implementation on any STB, to watch scrambled channels with your equipment ?
I know, this question is addressed not personally to sundtek, but I think, you know the answer. It because I see the conflict with the DVB standart in part of CA-handling.
In the DVB standart (part which describes the CA-subsystem http://www.dvb.org/technology/standards/En50221.V1.pdf) descrambling is described as "part" of demodulator. It means, that CAM received the full stream from the RF-in. Before any of demultiplexor (ie pid-filter).
Can you explain - it is possible to modify standart's described schematics to inject the scrambled DVB stream in the correct point of the STB schematics? It is totaly can be controlled by the software, not the hardware limitations ?
The answer will indicate the potential success with the Marusys: is there any way to software - driver - manage, or it is completely impossible, and the Marusys equipment is not compatible with sundtek tuners in a part of watching pay-tv channels.
-
Technically it does not matter if the CA Module is directly behind a demodulator or not (Smardtv used to have a USB CI Adapter in the past), but it definetely depends on the design of the settopbox if the injected ts stream can be passed to the CA Unit.
In case of your VU that means that only Marusys can give you the right answer to this question.
Its not necessary to put the whole ts stream to the cam, only the particular pids are enough
-
Thank you for your commentary
-
And finally, due to impossible to watch PayTV with on-topic problem and Marusys position on handling issues, it is possible to use some kind of CI-panel with your tuners on FreeBSD (my home server is running on it) ?
Do you produce yours own CI-panels ?
Or there is no way?
I'm searched trough your forum, and I've seen your announcements about SmarDTV devices. What is the situation on current moment ?
-
There was a lot forward and backward with SmartDTV, finally we stopped it.
There might be the possibility to work on our own CI device from next year on, but first our new tuners have to be ready for the market.
-
possibility to work on our own CI device from next year on, but first our new tuners have to be ready for the market.
You'll keep a backward compatibility with the old tuners on these CI devices?
-
of course, some of our customers heavily depend on our backward compatibility.