79 replies to this topic

[atilaks]

Sundtek considers stopping support for STBs.

Sundtek Support: we had a meeting today I think we will stop working on settopboxes since it takes too much time and our driver is just in a perfect state right now
Sundtek Support: this week is supposed to be the last week

So please keep that in my mind when you go buy their products. Sundtek drivers are closed source.

Edited by litemotiv, 21 December 2012 - 16:36.
Changed title to better reflect thread contents

[Erik Slagter]

That's bs from them, because new kernel versions need driver adjustments (and at least a recompilation of the driver).

[Pr2]

Hi,

Sad news, Sundtek always provide a good support so far for the STB. Unfortunatelly they didn't seems that Xtrend want to cooperate with them.

Anyway, who knows an USB DVB-C tuner reference supported out-of-the-box by OpenPli images with Open Source driver?

[Carl]

Hi,

Sad news, Sundtek always provide a good support so far for the STB. Unfortunatelly they didn't seems that Xtrend want to cooperate with them.

Anyway, who knows an USB DVB-C tuner reference supported out-of-the-box by OpenPli images with Open Source driver?

Sundtek is not opensource and that's the problem.
How can you cooperate with a company which gives zero info...

[pieterg]

Anyway, who knows an USB DVB-C tuner reference supported out-of-the-box by OpenPli images with Open Source driver?

have a look here:

http://www.linuxtv.o...B-C_USB_Devices

any of these devices for which a standard kernel driver is mentioned, should work with OpenPLi.

[Taykun345]

We paid premium price for their (cheap looking) stick and now we are stuck with no support?

Edited by Taykun345, 10 October 2012 - 19:37.

[atilaks]

I am sick and tired of all problems we have with Sundtek devices and I never liked the fact that their drivers are not open source.
I've just ordered pctv 520e (dvb-c/t usb tuner). Will let you know how it works when it arrives.

[sundtek]

I am sick and tired of all problems we have with Sundtek devices and I never liked the fact that their drivers are not open source.
I've just ordered pctv 520e (dvb-c/t usb tuner). Will let you know how it works when it arrives.

I see you are the one who contacted us and probably got frustrated in the end because we didn't give you hints how to debug your system. Imagine if everyone comes to us and asks how to debug it.


You won't find any other device which delivers better support. After working for several years on those things we are highly disappointed about some settopbox companies who don't just catch up with bugreports.

* Dreambox: DM7020 doesn't support decoding paytv
* VU+ and all others (except Dream), they don't clean up external tuners on a soft restart
* VU+ only delivers 0.5ampere for 2 USB Ports which knocks out one port, what we get back is that our tuners crash the entire settopbox because enigma cannot handle hotplugging when a tuner disappears due too less power.
* Video Jitters, reason the signal is passed through the internal tuner which seems to amplify it on some settopboxes and it somewhat ends up disturbed on external tuners
* The virtual tuner interface itself is totally messed up among different settopboxes, we started to rewrite and redo everything several months ago in order to work around there, it introduced some issues for some time but they should be fixed now; This was a massive amount of work and finally it seems like it proved that it was a good thing to do since we don't completely depend on the virtual tuner interface anymore.
* DM800HD (yes there are still some users out there), require special handling on everything
* CAM Pairing and some settopboxes doesn't work with external tuners
* AC3 Audio (without downmix) we still get feedback that it doesn't seem to work with some settopboxes (another bug of broadcom modules probably), several settopboxes are affected by that.


Now guess how many bugreports we get from other Embedded Systems (eg. NAS, ARM, Mips) or PC systems, kind of NONE. Why? Because those systems have a decent system stability and quality.

We we even visited VU+, they wanted to check but nothing happened in that area.

That's bs from them, because new kernel versions need driver adjustments (and at least a recompilation of the driver).

we don't need a recompilation, our driver works everywhere as it is. That's the challenging part of it. Any Linux System which has sufficient hardware performance can run it, starting from Linux 2.6.15 on which was released around 2006/07.

Instead of pushing us permanently it would be a better turn to send mails to the manufacturers to check their interfaces. Because those things are causing the suffering parts. When working on something like that for years it's just getting frustrating on our side, especially since all other systems than settopboxes required just a small percentage of the work which has been done for settopboxes.

Edited by sundtek, 11 October 2012 - 03:20.

[atilaks]

I see you are the one who contacted us and probably got frustrated in the end because we didn't give you hints how to debug your system. Imagine if everyone comes to us and asks how to debug it.

so go and write wiki about debugging, instead of complaining and ignoring your clients...

if stbs drivers are so messed up why users of dvb-t usb tuners supported in kernel are not reporting these problems?

[atilaks]

and another thing... you keep blaming drivers, they are not perfect I know, but many times you fix smth for one box you break it on another... so stop complaining and test before you release a new version for christ sake!

[littlesat]

you keep blaming drivers, they are not perfect I

For Sundtek they are horrible....

And not only for them.... see what our users did also struggle VU+DUO drivers, for a long time spontanious crashes so they were fixed to a december 2011 release of OpenPLi. And recently users of the DM8000 that are using a lot of memory due to e.g. a lot of gathered EPG and use newest drivers in OpenPLi3.0 -> they must use swapfiles trying to avoid OOMs.... And it takes a lot of time -or even- forever before the box-manufacturers fix their "bugs"....

[sundtek]

you keep blaming drivers, they are not perfect I

For Sundtek they are horrible... .

And not only for them.... see what our users did also struggle VU+DUO drivers, for a long time spontanious crashes so they were fixed to a december 2011 release of OpenPLi. And recently users of the DM8000 that are using a lot of memory due to e.g. a lot of gathered EPG and use newest drivers in OpenPLi3.0 -> they must use swapfiles trying to avoid OOMs.... And it takes a lot of time -or even- forever before the box-manufacturers fix their "bugs"....

Our problem is that we support all images, and all settopboxes with a single driver so basically all bugs are added together...
However the actual problem of the initial poster is solved, after he reported it within 1 or 2 days.

Edited by sundtek, 11 October 2012 - 07:16.

[atilaks]

I know what you mean with a december 2011 release, that's the last one before

but my problems where actually caused by changes made by sundtek to solve some problems on dreambox...
sundtek was 'kind' enough to tell me they are going to look into it the LAST time, nobody knows what will happen in the future...

vuduo drivers were not updated since august 24. so if smth suddenly stops working where could be the reason? in vuduo drivers?

[mirakels]

Instead of pushing us permanently it would be a better turn to send mails to the manufacturers to check their interfaces. Because those things are causing the suffering parts. When working on something like that for years it's just getting frustrating on our side, especially since all other systems than settopboxes required just a small percentage of the work which has been done for settopboxes.

It looks like you state valid points, but all you create is the old world where supliers go fingerpointing about who is to blame.

Why are there often no problems on ANY box for hardware with open source drivers? Because people are willign to debug this and are then able to contact the right people to discuss issues. Be it the supplier of the device or the supplier to which the device is connected.

So why are you struggling with keeping it it all to yourself. Is your hardware so sensitive or is it so secret that you want to keep all development closed? Thats fine, but then take the complaints from the users and help them out! You can do that in two ways:

1- just fix the problem the user is reporting and don't bother the user wether it is your fault or someone elses.
2- offer the user to get a cashback so he/she can buy a different device from a competitor.

But on this forum we support and love open software and hardware so I gues the best way is to open up your sources. At least it will give you the benefit of selfsupporting users that won't bother you anymore...

Edited by mirakels, 11 October 2012 - 07:27.

[sundtek]

I know what you mean with a december 2011 release, that's the last one before

but my problems where actually caused by changes made by sundtek to solve some problems on dreambox...
sundtek was 'kind' enough to tell me they are going to look into it the LAST time, nobody knows what will happen in the future...

vuduo drivers were not updated since august 24. so if smth suddenly stops working where could be the reason? in vuduo drivers?

if something breaks on our side it should be reported to us, if we cannot reproduce it with our box we certainly need feedback from more sources (eg 2 or 3 users).
The future is that the current chipsets of all DVB-C/T dongles on the market will vanish and new solutions have to be rolled out. We'll keep up support for old devices, the current driver package already includes DVB-C/T/T2 drivers for the upcoming generation. Unfortunately the Hardware is postponed due Settopbox changes.
We optimized the chip selection in order to be able to add T2 support to the DM800HD

[atilaks]

@sundtek
please consider adding changelog to your drivers... it is frustrating to see so many new versions showing up without knowing what has been changed, extremely frustrating when you want to debug/test smth... I simply do not want to try every one of them to see if my problems are solved...

and could you please confirm that you are finally stopping support for STBs from next week?

[jeffphil]

If I may make a suggestion it is admirable that you have a one driver for all system but I do think it might also be a good idea to have taylored drivers for each stb in this way a fix for one stb will not break another. Also it would have to simplify the drivers

[sundtek]

@sundtek
please consider adding changelog to your drivers... it is frustrating to see so many new versions showing up without knowing what has been changed, extremely frustrating when you want to debug/test smth... I simply do not want to try every one of them to see if my problems are solved...

and could you please confirm that you are finally stopping support for STBs from next week?

Changelog is available in German at the moment (http://support.sundt.../board,6.0.html , Linux Driver), english changelogs will be updated from mid next month on since a new employee will join Sundtek for working on Documentation and other things.
Support will continue.

[atilaks]

that's not the changelog I had on my mind (last update 9. april) but I am glad to hear you will continue support, eot

Edited by atilaks, 11 October 2012 - 08:16.

[Erik Slagter]

we don't need a recompilation, our driver works everywhere as it is. That's the challenging part of it. Any Linux System which has sufficient hardware performance can run it, starting from Linux 2.6.15 on which was released around 2006/07.

Until a kernel abi/api changes and the module won't load. This is not the right approach (and you probably know it).

In the first place I agree with mirakels, why not simply publish the code or even better, have it added to the kernel tree. Is the code so bad we can't see it? If the code is in the linux tree, the (potential) users won't have to worry about new kernel versions breaking their sticks. A second best alternative would be to have the interface between the kernel and the driver in source and have the source drag in a binary blob which is the closed source driver. That way at least the interface to the kernel is stable. I don't know Linus will like it though.