79 replies to this topic

[atilaks]

I am using mgcamd on my vuduo, newest drivers from sundtek and I can switch between dvb-s and dvb-c without problems. Including fta and paytv channels. I did not try cccam for a long time, but last time I tried cccam with sundtek drivers from 20120628 everything was ok.

Edited by atilaks, 12 October 2012 - 11:42.

[Taykun345]

In my experience, Nova-T that i bought for 18EUR on ebay, works better than 80EUR sundtek stick. I dont have problem with dvb-s and dvb-c switching, but i have slow zapping speed on DVB-C FTA channels and instability issues (need to install new drivers now). VU+DUO here!

[Pr2]

Hi,

Sundtek DVB-C is stable for me both SD and HD, the sound problem that I have seems very specific I send a PM to Littlesat to explain him the whole details.

If you experiment problem with DVB-C channels (especially HD), please try to amplify the signal received from your cable operator.

When my cable operator officially switch me from analogic to DVB they install an amplifier in my home, I was one of the first to test the DVB-C and signal was strong at this time. So even without the amplifier I was able to watch my DVB-C channel (both SD and HD), later on it seems that they decrease the signal power on their cable so the amplifier became mandatory! SD channels are OK without amplifier but for HD channels it is now clearly mandatory.

Hope this help.

[sundtek]

Sundtek investigate and find that it is a problem on the Xtrend side.

I have a Nova-T stick on my ET9K and never problems...

Could Sundtek describe what the issues are regards the drop out of audio (that happens with more boxes)?

In short the biggest issue with Sundtek is that when switching to DVB-S and then back to DVB-C that nothing van be tuned.... especially I read about VU+Duo. Could this also be power supply related? I remembered it was fixed in the past but seems to reoccur now....

There's no issue switching between DVB-S back/forward DVB-C. The other issue is using 2 Sticks on a VU+Duo which does not deliver enough power for it, switching to the second USB Stick will make the system reset one stick (1 stick requires 300-350mA, 2 600-700mA, while VU+Duo only delivers 500mA on the back USB ports. I think someone mentioned that the front USB port also delivers 500mA but that's not really clear)

AC3 Audio streams are not properly detected, maybe the STBs need some hint what stream is used.
It somewhat seems like some companies do not support AC3 at all, while others don't seem to support AC3 when the picture is 720x576 (maybe their code supposes to be SD with MPEG audio only - which would be a wrong assumption).


When disabling the external tuners, the tuners will still be registered in /proc/bus/nim_sockets even though they are gone until a full reboot is done. Only Dream cleans up those interfaces properly.

[littlesat]

What do you mean with disabling external tuners?

[sundtek]

What do you mean with disabling external tuners?

when reinitializing the vtuner interface it does not clean up, the old registered instance will still remain.

[Carl]

What do you mean with disabling external tuners?

when reinitializing the vtuner interface it does not clean up, the old registered instance will still remain.

Thank you for this information. I have checked it and the nim socket doesn't cleanup after remove of the device as you told.
Were does this information will been informed as I haven't heard or read about this problem before.

Do you have more information about other problems as well

Edited by Carl, 12 October 2012 - 18:27.

[atilaks]

I think the latest drivers solved my problem with choppy video/audio on vuduo + openpli 2.1. So far so good.

Nope, the problem is still there. After zapping to a dvb-c channel, video/audio is stuttering and message shows up: Service not found (SID not found in PAT). I watched dvb-s and dvb-c channels and some recordings for a couple of hours without any problems when the problem suddenly showed up.

[sundtek]

I think the latest drivers solved my problem with choppy video/audio on vuduo + openpli 2.1. So far so good.

Nope, the problem is still there. After zapping to a dvb-c channel, video/audio is stuttering and message shows up: Service not found (SID not found in PAT). I watched dvb-s and dvb-c channels and some recordings for a couple of hours without any problems when the problem suddenly showed up.

try to put the parameter "dmhwpidfilter=off" into the first line in /etc/sundtek.conf

[sundtek]

I think the latest drivers solved my problem with choppy video/audio on vuduo + openpli 2.1. So far so good.

Nope, the problem is still there. After zapping to a dvb-c channel, video/audio is stuttering and message shows up: Service not found (SID not found in PAT). I watched dvb-s and dvb-c channels and some recordings for a couple of hours without any problems when the problem suddenly showed up.

You wrote it works for some hours, that's clearly a bug in the broadcom drivers. Something that has to be forwarded to VU+ again.
It's working perfectly fine on Dreamboxes long term.

What you can do here is to test different drivers from VU+

That the tuner is still in a working state is easy to figure out, you can just run

/opt/bin/mediaclient --cat /dev/dvb/adapter1/dvr0 | /opt/bin/mediaclient --pipecount 1000

to see if video data is coming through (or pipe it to the harddisk and watch the channel on a PC).
And

/opt/bin/mediaclient --lc

to see if Enigma has set up the PIDs correctly.

Edited by sundtek, 13 October 2012 - 02:06.

[atilaks]

thanks, I will try that

[sundtek]

thanks, I will try that

or try to use another image, if it works you can just swap the vu+ modules from /lib/modules/*/extra to openpli, that should certainly also help the openpli devs to figure out what's usable and what not. At least that worked last time in January/February this year.

Edited by sundtek, 13 October 2012 - 13:38.

[atilaks]

/opt/bin/mediaclient --cat /dev/dvb/adapter1/dvr0 > /media/hdd/test.ts

I zapped to a dvb-c channel -> video stutters.
At the same time I used mediaclient to cat to a file (enigma2 still zapped to a dvb-c)
There is no stuttering when I play the file on the box.

Is there anything I can do with enigma2 logs to understand what happens?

[sundtek]

/opt/bin/mediaclient --cat /dev/dvb/adapter1/dvr0 > /media/hdd/test.ts

I zapped to a dvb-c channel -> video stutters.
At the same time I used mediaclient to cat to a file (enigma2 still zapped to a dvb-c)
There is no stuttering when I play the file on the box.

Is there anything I can do with enigma2 logs to understand what happens?

Dream had some configuration files in /proc/stb, not sure if those still exist with your settopbox.

--avoffset=n AV PTS offset
/proc/stb/audio/pts_offset
/proc/stb/vmpeg/0/pts_offset
value in milliseconds

you can try to run /opt/bin/mediaclient --avoffset=500 (to add a 500ms cache on kernelside, it just writes some values to /proc/stb/*/pts_*) but as mentioned not sure if it's still available on your box.
I think we had something like a stuttering video problem earlier this year, swapping kernelmodules solved the issue so you might change the VU+ driver version and test again, chance that VU fixes it if they didn't have it in a previous version wouldn't be bad I think.

[atilaks]

thanks, will try different modules and avoffset, it's going to take some time...

[adrouven]

Just reading this complete topic I must say that I am a little disappointed in the behaviour from Sundtek. I do understand that they are frustrated about the little to no support they get from STB manufactures but on other hand they them self have taken the decision to bring a very commercial product with closed source drivers on the market. Knowing that STB manufactures them self also bring hybrid STB on the market Sundtek could know that there will be little to no support for any third party supplier. That's simple marketing!

So what can Sundtek do to my humble opinion:

1) Stop all support and lower the price from there product significantly
2) Go on like you have don, buy some problem STB's, stop complaining and make a workaround. Just do your yob and give your customers what they have paid for. Make a list of STB manufactures that won't cooperate public with the specific problems so your customers can for them self decide if your product is the right one to buy
3) Stop your direct support to customers and print that clearly on all your product, make all the software open source and give a little technical and maybe also financial support to the open source teams.

[atilaks]

i found out smth interesting...

When I restarted enigma2 when stuttering problem showed up there was no difference.

When I stopped enigma2, restarted multimediastack ('mediaclient --shutdown and mediaclient --start') and started enigma2 everything went back to normal.... hmmm....

so far no luck with avoffset or hwpidfilter, I have yet to try previous vuduo modules...

Edited by atilaks, 14 October 2012 - 12:36.

[sundtek]

Just reading this complete topic I must say that I am a little disappointed in the behaviour from Sundtek. I do understand that they are frustrated about the little to no support they get from STB manufactures but on other hand they them self have taken the decision to bring a very commercial product with closed source drivers on the market. Knowing that STB manufactures them self also bring hybrid STB on the market Sundtek could know that there will be little to no support for any third party supplier. That's simple marketing!

So what can Sundtek do to my humble opinion:

1) Stop all support and lower the price from there product significantly
2) Go on like you have don, buy some problem STB's, stop complaining and make a workaround. Just do your yob and give your customers what they have paid for. Make a list of STB manufactures that won't cooperate public with the specific problems so your customers can for them self decide if your product is the right one to buy
3) Stop your direct support to customers and print that clearly on all your product, make all the software open source and give a little technical and maybe also financial support to the open source teams.

Customers paid for a working Linux driver that's it nothing more and nothing less. If someone uses our working part on something that won't allow it it's not our fault and yes it will remain unsupported from our side if there's nothing that can be done. If we have some bugs we fix them.
The initial idea of this was to support dreamboxes, that has been done and that is working.

If you buy a car you won't go to the manufacturer of the seats to ask to find workarounds if the tyres are broken, even though the manufacturer of the seat claims to support that particular brand - because the car maker provides interfaces for adding it. It's the duty of the car maker to provide proper interfaces for this, if they cannot keep up with fixing their issues they shouldn't provide any specs for adding seats.

Finally you write you are disappointed about Sundtek, so you would also blame the seat manufacturer for broken interfaces of the chassis manufacturer, even though the seat manufacturer already did whatever they could do and practically there is no more workaround available for that, that's nothing but ridiculous. As a customer you should be more than happy to get support from particular companies, and be unhappy about those who cause the problems and don't give any support. That the seat manufacturer will be angry sooner or later about such behavior and just knock off support for the particular chassis manufacturer until they start to move some fingers is also pretty much clear.

The same applies to the settopbox providers, if they claim to provide interfaces then they are in the duty of providing workable interfaces not half baken technology and tell the customers "YES WE SUPPORT". No one ever forced them to add any interface, if they cannot handle it they shouldn't do that. At this time only VU+ seems to have an issue with it. We supported Dreamboxes first, VU+ tried to copy the interface from them and some of their distributors came to us telling us hey it also works on VU+. Even Xtrend seems at least to take care about their interfaces and what they promise to their customers.

This is the last message about that nonsense issue, all further messages will be restricted to technical response only, everything else will be ignored.

Edited by sundtek, 14 October 2012 - 17:39.

[atilaks]

I finally settled on vuduo modules 20120820, sundtek dev driver 20121010_220349, mgcamd, last OpenPLI 2.1.

To release more RAM I disabled in inet.d all not needed processes like samba, dropbear, avahi.
I did also modified modutils to not load at startup all wifi modules I do not need right now.

So far so good.
Thank you for all your help.

[babs]

Atilaks IS your problem completely solved now ??? I have a similar issue with a Sundtek DVB-C/T

Thanks