79 replies to this topic

[Pr2]

Hi,

I just want (again) to say that so far I always get a very efficient support from Sundtek, I already grant them several times access to my box for troubleshooting and they always fix the problems when it was on there side.

I still have one issue with sound (a very specific problem), Sundtek conclude that the bug was on the Xtrend side. Xtrend pretend that they cannot get in touch with Sundtek, I put Xtrend (at least the contact person that I have that is in touch with Xtrend) in contact with Sundtek myself but this Xtrend contact guys never answer while Sundtek was willing to help to fix this issue.

To Carl, arguing that Sundtek is not open-source is not a real argument, since Xtrend drivers nor VU+ drivers are open-source neither...

Problem with some Sundtek changes, yes I also face this problem, but you can always download an older version of the driver and install it. Then you contact Sundtek and warm them of the problem and they fix it. Indeed you sometimes have to be patient 1 or 2 days for them to access your box and test but they did it.

I can also imagine that Sundtek cannot purchase all the possible STBs on the market for testing their drivers on every system, so end-user testing feedback and testing is important for them.

I just hope that Sundtek will finally continue to support our beloved STB or see how collaboration between OpenPli and Sundtek can be improved to have Sundtek officially supported by Openpli has downloadable and online upgradable package. This can perhaps avoid lots of frustration on both sides.

[Rob van der Does]

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

And ET & VU & DM & ..... are open of course??

[pieterg]

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

And ET & VU & DM & ..... are open of course??

AFAIK ET & VU & DMM do not produce usb-dvb modules, so that's irrelevant in this discussion.

[sundtek]

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.

We do not have kernel drivers, that's why we don't have the recompile issue!

[Erik Slagter]

So you are submitting a closed source binary (executable) then? Hmmm...

[sundtek]

So you are submitting a closed source binary (executable) then? Hmmm...

End of discussion from our side. We only participate to this forum for technical reason because some users asked us to do so not because we want to talk about someone's view upon what we do or not.

[atilaks]

@Pr2
Well good for you if they connected to your box several times already. They did it only once for me, long time ago, when I had some problems with channelscan.

Yesterday I got 'oh no, yet another complaining stb customer' + 'we will probably stop supporting stbs' + 'our driver is a state of the art, it is not our problem' kind of a response from them.
To cheer me up I have been told 'we will look into it, the last time, on our test boxes', but they didn't even ask in details what is wrong.
Why couldn't they just connect to my box when the problem was already there? Or guide me to dig it more for them?

When I asked how to debug, I was told to go and try different openpli versions + different vuduo modules + different sundtek drivers (that's plenty of combinations), without any hints how to actually examine the REAL problem.
I really insisted, just a few words where should I start or whatever would be just fine, but I only heard 'debuging is creative' - go find it yourself. Sundtek, seriously? That's your answer?

I understand what you mean by just revert back to a previous driver version, but it is not as easy as it sounds in my case.
I get a choppy video/audio on dvb-c channels (both encrypted and fta).
My problem cannot be easily reproduced - it just shows up randomly, sometimes after couple hours of watching, sometimes after restart, sometimes when recording is in progress, sometimes it does not occur for a whole day.
The only way to recover from it is to do a restart.
I actually suffer from it more or less since OpenPLI switched to kernel 3.1 back in dec 2011.

Now it is very difficult to state which drivers are problem-free, as it is so random and you never know what has been changed between development versions.
Some drivers are better some are worse, or is it just a pure luck?
However it looks like they fixed something in the latest drivers, as they are not crashing so quickly, but I cannot tell if my issue with choppy/freezing video/audio is also fixed, time will tell.

Interesting is, what has happened, that Sundtek changed their plans and decided to keep supporting stbs? Bad press?

Edited by atilaks, 11 October 2012 - 15:49.

[Carl]

To Carl, arguing that Sundtek is not open-source is not a real argument, since Xtrend drivers nor VU+ drivers are open-source neither...

I mean that the simular product with opensource dvb-usb are working well.

Maybe sundtek hoped that manufactors of settopbox fixed the sundtek problems in their boxes.

[sundtek]

@Pr2
Well good for you if they connected to your box several times already. They did it only once for me, long time ago, when I had some problems with channelscan.

Yesterday I got 'oh no, yet another complaining stb customer' + 'we will probably stop supporting stbs' + 'our driver is a state of the art, it is not our problem' kind of a response from them.
To cheer me up I have been told 'we will look into it, the last time, on our test boxes', but they didn't even ask in details what is wrong.
Why couldn't they just connect to my box when the problem was already there? Or guide me to dig it more for them?

When I asked how to debug, I was told to go and try different openpli versions + different vuduo modules + different sundtek drivers (that's plenty of combinations), without any hints how to actually examine the REAL problem.
I really insisted, just a few words where should I start or whatever would be just fine, but I only heard 'debuging is creative' - go find it yourself. Sundtek, seriously? That's your answer?

I understand what you mean by just revert back to a previous driver version, but it is not as easy as it sounds in my case.
I get a choppy video/audio on dvb-c channels (both encrypted and fta).
My problem cannot be easily reproduced - it just shows up randomly, sometimes after couple hours of watching, sometimes after restart, sometimes when recording is in progress, sometimes it does not occur for a whole day.
The only way to recover from it is to do a restart.
I actually suffer from it more or less since OpenPLI switched to kernel 3.1 back in dec 2011.

Now it is very difficult to state which drivers are problem-free, as it is so random and you never know what has been changed between development versions.
Some drivers are better some are worse, or is it just a pure luck?
However it looks like they fixed something in the latest drivers, as they are not crashing so quickly, but I cannot tell if my issue with choppy/freezing video/audio is also fixed, time will tell.

Interesting is, what has happened, that Sundtek changed their plans and decided to keep supporting stbs? Bad press?

We are watching the situation, we are very angry - to frustrated about with some settopbox companies because of their non existing support (here we can only write that Dream is actually the only company which is a little bit different than the others, if they say they will look into it they will do it - unlike others where we got feedback that they will look into it and nothing happens). Watch back in this thread there's a list of settopbox bugs related to external tuners which are unresolved for years, they don't dare to do anything about it.
Some issues lead us to do some very difficult workarounds.
Send a mail to the STB manufacturer to change that behavior, and honestly just saying that they are overloaded or have other priorities cannot justify that they can't spend one or two days on having a look at those things.

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

[atilaks]

Some issues lead us to do some very difficult workarounds.

Great! You get a credit if you do an effort to find a workaround. A huge credit!
And we would be more than happy to help you.

Send a mail to the STB manufacturer to change that behavior, and honestly just saying that they are overloaded or have other priorities cannot justify that they can't spend one or two days on having a look at those things.

Well they don't really care about sundtek usb tuners or other usb tuners. You are not the only one who is ignored
Just accept the fact they will probably never fix their code, so find a smart workaround instead of complaining if you want to sell your products to STB users.

Regarding list of bugs... I do not care about AC3 audio, or not being able to connect two usb tuners to vuduo - I just want your device to work stable enough, so I can record and watch when it suits me. Simple as that.

I think the latest drivers solved my problem with choppy video/audio on vuduo + openpli 2.1. So far so good. Looks like it was possible after all.

Btw, you were just out of luck yesterday, when your support (who ever it was) talked to me and said all these things

Edited by atilaks, 11 October 2012 - 21:06.

[Carl]

Send a mail to the STB manufacturer to change that behavior, and honestly just saying that they are overloaded or have other priorities cannot justify that they can't spend one or two days on having a look at those things.

Which companies are saying this. Did you even send test samples to the companies in Korea for solving the issues? Your making me curious.

[sundtek]

Send a mail to the STB manufacturer to change that behavior, and honestly just saying that they are overloaded or have other priorities cannot justify that they can't spend one or two days on having a look at those things.

Which companies are saying this. Did you even send test samples to the companies in Korea for solving the issues? Your making me curious.

We have been there physically. And yes some samples have been shipped to many companies, including sample streams with affected channels (better don't name particular ones since most eg. cannot handle the ac3 issues, or clean up the external tuner interface (except Dream)), if some company still would require samples they are free to contact us. Fact is the list of bugs for external tuners which can be seen in the previous post, they are open for longer than a year now.

[hemertje]

where is there?

feel free to call manufacturers here, so users can correspond about it to those manufacturers that it is there task to solve problems between them and sundtek...

[littlesat]

Are there also issues with X-trend boxes? I never heard of it????

[Pr2]

@littlesat,

Yes they is at least one issue with Xtrend box too, I have an ET-9000 + Sundtek DVB-C.
It is also a sound issue, when zapping to a particular channel, I need to unplug / replug the DVB-C cable in the stick to get the sound. Sundtek investigate and find that it is a problem on the Xtrend side.

The difficult part of the trouble shooting is that this channel is a kind of feed, so it must have broadcast on this feed to test it live.

[hemertje]

is this the same as the tuner-B satellite problem?

[Rob van der Does]

is this the same as the tuner-B satellite problem?

That problem is related to the local oscillator for tuner B, so very unlikely to be related to external tuners.

[littlesat]

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....

Edited by littlesat, 12 October 2012 - 10:57.

[atilaks]

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....

No such problems when mgcamd is used.
VuDuo + OpenPLI 2.1

[littlesat]

So you tell Cccam an issue an mgcamd not??? The cam has nothing todo with the tuners??????