18 replies to this topic

[clabs]

I have an ET8500 that is being used as a client box via Remote Channel Stream Converter. The server is a Vu+ Duo2

 

This was running fine with a slightly older version of Openvix (3.2.004). I didn't want to be left behind so updated to latest build (3.2.036) to take advantage of Gstreamer updates. Since that time, RCSC no longer works smoothly. From booting up, the first 3 or 4 channels changes work fine but subsequent channel changes mostly result in a frozen or very laggy picture. This is with FTA channels and seems worse with HD channels although SD channels are also affected.

 

Restarting the receiver get the picture working fine again. It does seem pretty random and often, if you zap to a different channel and then back again, the picture is OK again, but not always. If you stay on a working channel, that will generally carry on working properly without issue. Sometimes, the frozen picture recovers after some time and sometimes, it slowly degrades further and becomes just a screen of random dots.

 

I initially thought this might be a network problem so have replaced/substituted network cables and Gigabit switches without any improvement. I flashed back to 3.2.004 and RCSC works perfectly again. Also, I can stream HD movies stored on the Duo2 HDD without any problems whatsoever so to me that proves there is not a network problem - correct?

 

I did post on the Vix forum but received no replies so I am guessing this is fairly isolated and that there are not too many ET8500 users there.  

 

Today, I tried the latest version of OpenPLi (OpenPLi-4.0-beta-et8500-20160202_usb). Basic installation, stock skin, no picons, fixed IP address. The only addition was the RCSC plugin from your feeds. The results are exactly the same - first 3 or 4 channels working fine and then the same stuttering/stalling. The same seems to be true of all the other OEalliance images I have tried. I had a look at the OEAlliance Github and it looks like there were a whole load of merges just after Vix 3.2.004 in readiness for the Gstreamer update. That was around 6th September 2015.

 

I realise that this is not the Vix forum, but I am posting here a) In the hope that there might be another ET8500 user who may be able to confirm this for me and there certainly seem to be some very knowledgeable people here who at the very least might be able to make some suggestions of anything else I might try.

 

Thanks for having me and for reading this far.

 

Best regards, Mark

 

 

 

 

[clabs]

Just an update on this.

 

RCSC problems still exist so I thought I would try Fallback Remote Receiver. I initially had high hopes but unfortunately, Fallback displays exactly the same behaviour as RCSC - frozen/laggy pictures after a few channel changes. As before, a reboot sorts the problem out and then reappears after 2, 3 or 4 channel changes.

 

I am assuming from the above that RCSC and Fallback share the same mechanism to handle streams. Is that a correct assumption?

 

I am no coder and I also don't really know where to go looking in Github to find the mechanism that makes this stuff work. I also don't expect anyone to go out of their way to fix this but if anyone could at least point me to where I could begin  looking then that would be certainly be a start and very much appreciated.  

 

Thanks for reading and best regards, Mark

Edited by clabs, 8 February 2016 - 22:12.

[WanWizard]

Yes. A stream is a stream, no matter what the client.

 

OpenPLi 4 still uses the old Gstreamer 0.10, unlike most of the other images, so if that also has a problem, it's unlikely to be related.

 

What is the network between the two boxes? And what image runs on the Duo2?

 

I use streaming via the fallback tuner, through an OpenVPN tunnel, over the internet, without problems (I do use a transcoded stream), so in the basics there is nothing wrong with the mechanism.

[clabs]

Hi WanWizard and thank you for the reply.

 

I agree about GStreamer not being the problem because as you say, still the same results for me with latest OpenPli and also an older build of ATV that also uses older GStreamer.

 

The network between the 2 receivers is Duo2 > TPlink GB switch downstairs > TPlink GB switch upstairs > ET8500. Cat 5 cables between all devices. I also brought the ET8500 downstairs and tried Duo2 > TPlink GB switch > ET8500 with new short Cat 5 cables. Finally, I tried Netgear GB switch > ET8500.

 

Duo2 is currently running Vix 3.2.036

 

I know that Fallback and RCSC are usually very bomb-proof. It works fine for me with an Vu+ Ultimo and of course with an earlier image build on ET8500. And the only other posts I see about problems with RCSC is because people are using wireless as part of their setups. So, it also seems that this issue is isolated to the ET8500. Actually, I have read about some similar problems with Wetek. But I guess both have a pretty small user base.

 

The reason I might seem fixated on Vix is simply because they run on build numbers with an image download archive so I found that easier to slowly work back and forth to see more clearly where the problem started. I did have an earlier build of PLI that worked but I have downloaded and tried so many different images and I somehow lost that working image during my testings 

 

Is there an archive anywhere for VTI?

 

I suppose the next thing I can try is a different image on the Duo2 (although I want to avoid that if possible for the sake of domestic harmony :-) )

 

Any other suggestions that I might try?

 

Thanks for your response though - really appreciate it.

 

Best regards, Mark

[WanWizard]

I don't know, I don't have a 8500 or a Duo2 connected at the moment, so I can't check. Maybe someone else can.

 

And for VTI (or VIX) questions you're on the wrong forum I'm afraid.

 

I might be worthwhile to make a full backup of your Duo2 (I assume they have tools for that too?), and install OpenPLi 4 to test. Both VTI and VIX are based on the original VU+ image, and quite different from OpenPLi, especially in their streaming implementation.

[clabs]

Hi WanWizard and thanks again for the reply.

 

Yes - it would be handy if any other ET8500 users could try RCSC/Fallback from another receiver and see if they have similar problems.

 

In the meantime, I will do as you suggest and try the latest build of OpenPli on the Duo2 to see if that makes any difference. VIX does have a pretty good full image backup tool so it is fairly easy to switch back again if required.

 

So far as asking if there was an archive of older images available, I of course meant for OpenPli as I would like to try a build for the ET8500 dated around last August. So, if anyone can help with that, it would be appreciated.

 

Cheers

[WanWizard]

Our archive goes back a maximum of 6 months.

 

I have restored the oldest one we have, from August 13th. Don't run an update after you installed it, as it will update the box to today's image. It might take some time to have it appear online due to the scheduled sync of our mirrors.

[Erik Slagter]

Streaming, be it explicitly or implicitly using Remote Stream Converter or Fallback Tuner does NOT use gstreamer. At all. You can forget about that.

 

HTTP streaming is very latency-sensitive, it's not designed to workaround packet jitter, because normally the transport streams come in over the tuner and each packet will have exact the same timing, so no need for jitter buffering.

 

Still there seem to be some variance between manufacturers/drivers when it comes to stream jitter handling. There is nothing in the userspace code from the image thas ANY influence on this, it's 100% driver and hardware determined.

 

So if you really want fluent streaming, make sure you network is latencty-jitter free and make you get yourself a receiver that handles streams best.

 

I believe I explained this all not very long ago. Use the search function?

[clabs]

WanWizard

 

Thanks very much for taking the trouble to restore that August build for me. I just flashed that image and everything working fine again.

 

Erik

 

Thank you for your comprehensive explanation. That certainly clarifies (and simplifies) things for me and makes fault finding much simpler. So it is either network infrastructure, poor receiver performance or drivers. Other devices on my network are working perfectly and so is the ET8500 with older builds so I feel that proves that both of these are not the problem. But there was a driver update on 7/9/2015 which is very close to the time that my problems started and has not worked correctly with subsequent driver updates.

 

Would I be able to copy the older drivers into the newer image without any problems or is that too simplistic?   

 

Thanks for your input and help guys - really appreciate it.

 

Best regards, Mark

[WanWizard]

If the kernel signature hasn't changed then yes, you can do that.

 

But I don't think you have to. The dvb drivers are in a separate package. You can find the package with this command:

opkg list-installed | grep dvb-modules

You can then prevent the modules from being updated with the command

opkg flag hold <package-name>

After this you should be able to update the image to the latest version, without getting a driver update.

 

Note that if there is a kernel update, and you install that without installing the drivers, you end up with a non-booting box. So make sure you have a backup handy.

[clabs]

Thanks WanWizard

 

When you say "kernel signature", do you mean the version number that is listed in the information/about page? If yes, then yes, it did change, from 3.14.21 to 3.14.21

 

In any case, I tried the commands you suggested and:

 

opkg list-installed | grep dvb-modules

 

Produced:

 

et-dvb-modules-et8500 - 3.14.21+20150417-r0.0

 

Then:

 

opkg flag hold et-dvb-modules-et8500 - 3.14.21+20150417-r0.0

 

Produced:

 

Package is not installed.

 

I am guessing that answers my kernel signature question?

 

Does that mean I should try and manually install the older drivers?

 

So sorry for all my newb questions - I hope I am learning but thank you for trying to help me.

 

Cheers, Mark

 

 

 

[WanWizard]

No, you only need the package name

opkg flag hold et-dvb-modules-et8500

In linux, kernel module binaries are compiled for a specific kernel. The kernel is identified by a signature, say a sort of internal version number. If the binary is compiled for a different signature than the kernel itself, the binary refuses to load.

 

This is a built-in protection to make sure the kernel (the OS itself) doesn't crash.

[clabs]

WanWizard

 

Thanks for setting me straight - and for the explanation about the kernel signature.

 

I really like that neat trick you showed me to upgrade the image whilst omitting certain modules. But unfortunately, there WAS a kernel update at the same time as the driver update so, as you predicted, that resulted in a non-booting box.

 

So, that kernel signature pretty much stumps me so far as changing anything driver-wise, right?

 

Just so I understand this better - is the kernel something that is produced by the box manufacturer, or is that built by the teams that build the images?

 

Once again, really appreciate your patience and help.

 

Cheers, Mark

[WanWizard]

The kernel is build by the teams, but it is build based on info in the BSP, the hardware abstraction package that is provided by the manufacturer.

 

A new kernel build can be triggered by a version upgrade, a change of compiler version, but it can also be triggered by adding or changing kernel modules, like usb drivers or recently for some models the OpenVPN tun driver. A version change or a compiler version change always changes the signature, other changes sometimes do.

 

As the BSP parameters are the same as those that were used to compile the drivers by the manufacturer, there is nothing the teams can do to influence this process. New drivers will not load on an old kernel, old drivers will not load on a new kernel.

[Erik Slagter]

So how about a bug report towards xtrend to possibly resolve the issue?

Edited by Erik Slagter, 11 February 2016 - 10:19.

[WanWizard]

Sounds like a plan...

[clabs]

WanWizard - thanks very much for the explanation - it has really helped my understanding of how things hang together.

 

Erik - I did post a bug report to ET yesterday. Whether I did this in the correct fashion is another matter! I didn't find anywhere on their website to specifically report bugs so I simply set out the issue and sent by email to master@et-view.com

 

Does that sound about right?

 

As this issue seems to be very isolated (in the 6 months I have been experimenting to try and find a solution, I didn't find a single other report of this happening to anyone else), the realist in me is telling me that nothing will come of it. But at least they are now aware.

 

Thanks very much for your help and advice guys )

 

Best regards, Mark

[clabs]

Just to update this...

 

I know I said that I didn't expect anything to come from filing a bug report, but today I received the following reply: 

 

"Dear Mark,

 

Thank you for your thorough bug report.

 

This will definitely help to have a closer look at this problem.

 

Your e-mail will be directly forwarded to the technical department.

 

Thank you once again.

 

Best regards,

your Xtrend team"

 

I have to say that I was quite surprised to receive anything back at all, least of all a fast and personalised one from a real human being. I know there is no guarantee that it'll be fixed but it does give a little faith that they are at least looking at it so well done and thank you, Extrend.  

Edited by clabs, 11 February 2016 - 21:38.

[Erik Slagter]

Nice.