Erik Slagter

Overigens heb ik dit wel eens gedaan, een processor zonder koeling draaien. In tegenstelling tot moderne processors zaten daar nog geen beveiligingen in, dus die was wel stuk na een paar minuten. Stuk, gewoon stuk. In stilte de geest gegeven. Een processor is geen warmte-element (al zou je af en toe gaan twijfelen). De warmte ontstaat door het schakelen van miljoenen transistors, miljoenen keren per seconde. Elke transistor produceert daarbij een heel klein beetje warmte (daar zorgt men wel voor, elke geproduceerde warmte is onnodig stroomverbruik), lange leve de CMOSFET die bijna geen schakelverlies heeft.

Wat gebeurt er bij een oververhitting: het silicium op de die (de chip) gaat smelten. Niet branden dus, maar smelten. Met het smelten gaan de specifieke structuren en halfgeleider-eigenschappen verloren. Een daarvan is het kloksignaal en de gating. Zodra die weg zijn gebeurt er niks meer op de chip. Gesmolten(-geweest) silicium is een isolator, er loopt dus geen stroom meer en de chip wordt dus ook niet meer warm.

Dit is dus een proces wat uit zichzelf stopt. Het is geen nucleaire meltdown ofzo.

Als je ontplofte laptops ziet, dan is dat de (lithium-)accu die oververhit is geraakt. Dan kan vrij makkelijk gebeuren en ondanks alle beveiligingen, altijd mogelijk, zeker als de accu fysiek beschadigd raakt.

Heeft hier dus niks mee te maken.

I do understand Wanwizard's concerns though. In the past we've had several times that we couldn't draw a release for a long time because too many things weren't working properly, major stuff. So let's at least wait until 8.2 is completely stable and then after the merge, as many people as possible should be testing it. I will volunteer too.

BTW I am not against providing the VU+ transtreamproxy in a package for those who can't get it working with our own tools (streamproxy and enigma). But there will be no support at all and it should be clearly marked as such (and also that it's not a plugin).

Given the fact that the OE copy of the transstreamproxy seem to work on Gigablue / Xsarius / Qviart broadcoms,. and the source of that proxy is available, it should be possible to find the differences?

Believe me I tried. I spent about 100 hours on it and I can't lay my finger on it. I think that is enough.

So what we need is someone who is willing to spend even more time on it or just knows what the actual interface is. It seems to me that GB could be giving us that information.

What we also need is a buddy that can help brainstorm on how to implement this properly in Enigma. Instead of just me spending lot of time and then the only feedback being "you broke everything".

IMHO it makes sense to use a symbol other than underscore for this, good to hear!

Blindscan is a long time ago for me!

I abandoned the whole concept because it appears it's rubbish. It takes ages to complete, doesn't nearly find all transponders and last but not least, will often leave the tuner in a funny state where a reboot is required. I think the hardware is very well capable of doing a decent blind scan, but the implementation by the manufacturers (drivers layer) is really bad. The fact we need to use an external binary that directly connects to the I2C subsystem (completely bypassing the driver layer) is already a tell-tale sign.

 

Yes you need a Unicable lnb for it . 

 more info and details can be find here 

https://wiki.openpli.org/Unicable_/_Jess

https://en.wikipedia.org/wiki/Single_cable_distribution

No it's not required to use SCR. It's just that with SCR there are more possibilities. If you use quad LNB's for all five positions, you can connect five committed switches and branch up each tuner to one of the five switches. The FBC tuner will, as usual, offer limited extra flexbility. The alternative is to use quadro LNB's and a 5x4-to-1 multiswitch which will have the same features and limitations.

If you want all leaf tuners from your FBC tuner to be able to operate independently, then you will need SCR. Options are Unicable and JESS, the last one as either switch or multiple LNBs.

- Unicable: very affordable but only allows two positions to be used, for your setup you'd need three (!) switches and a way to combine them (some of them are able to do that)

- JESS switch: absolutely the most flexible solution, buy a 5x4-input to 4-userband switch, 5 quadro LNB's and you're ready to go. Pretty expensive though

- JESS LNB's: less easy and less flexible than using a JESS switch, but far better affordable. Prepare to do some work though (like programming the LNB's, the programmer isn't included and you need to buy it separately) and making sure the LNBs fit. It seems it can be a pain to get them fitting on the dish. Also support in Enigma is less robust than for JESS switches (due to the LNB needing to boot every time it is selected; a JESS switch is always powered on).

Or find another maintainer...

Waarschijnlijk.

Klinkt heel simpel, even compat-libs installeren alle ouwe, niet-onderhouden meuk werkt weer als een zonnetje. Dat is echt te simpel gesteld. Maar je kunt het altijd proberen, opstarten zal-ie dan wel weer doen, maar of hij lang en correct zal blijven draaien?

Ik begrijp ook niet waarom mensen maar zo vast blijven houden aan mgcamd. Maar er zijn wel meer dingen die ik niet begrijp.

@Erik, bedankt voor je reactie. Ik vind het bijzonder eerlijk dat je dit probleem meldt. Sommige anderen zouden het zeker niet melden.

Het probleem waar MIPS-ontvangers-eigenaars nu tegen lopen (hopelijk: liepen) was een combinatie van drie problemen die samen dit opleverden. Eén van de problemen was mijn schuld, ik kan kort of lang kletsen, maar het is niet anders. Waar gehakt wordt vallen spaanders... Heeft te maken met experimentele opname van Broadcom transcoding in Enigma, wat nog best lastig is, het "past" niet zo goed in Enigma. De bedoeling is dat dat straks allemaal werkt, dan kunnen we streamproxy afschaffen en dat lost heel wat klachten op (zoals: problemen met authenticatie en verkeerde geluidsspoor).

Het heeft te maken met de webif in feite.

Request gaat webif->streamproxy->webif->enigma. Je ziet één keer webif, maar in feite zit die er twee maal tussen. Dat is zo omdat streamproxy een extern programma is en zelf geen services kan selecteren of demuxers instellen, dat moet hij via de webif doen. De interface die daarvoor gebruikt wordt, is een algemene interface. M.a.w. niet alleen streamproxy kan die gebruiken. Vandaar dat de mannen van webif daar ook verplichte authenticatie op hebben gezet, terwijl streamproxy dat in feite al gedaan (gechecked) heeft. Dat maakt het extra complex, want daardoor moet streamproxy de auth kennen en ook gebruiken op die URL. Als daar iets misgaat, dan werkt het hele zaakje niet. Ik heb hemel en aarde bewogen om de heren van de webif zo ver te krijgen dit anders aan te bieden, maar geen resultaat. Er zijn wel aanpassingen geweest die noodzakelijk waren om compatible te blijven met webif, vandaar dat het gedrag tussen OpenPLi 7.2 en 7.3 anders kan zijn geworden.

Ik kijk even in de log en ik zie "-sid,2898ff8131bb0d06bb0285f9ddc36eda5ad50e0fc4c3bfe9fe4adc0fd54b7612" als user. Dat betekent dat de webif niet wil dat streamproxy de auth doet, maar deze transparent weer teruggeeft. Da's iets "nieuws" in webif, inderdaad ergens tussen 7.2 en 7.3 veranderd waarschijnlijk. Ik heb aanpassingen gedaan in streamproxy om dat te laten werken, maar het lijkt er op dat ze het formaat veranderd hebben? Of dat bij ons, de patch die op owif nodig was hiervoor, niet meer toegepast wordt.

Ellende allemaal.

Daarom heb ik in 8.0 Broadcom transcoding naar binnen Enigma verplaatst, dan ben je van al die ellende verlost, er is helemaal geen webif meer nodig. Authenticatie werkt gewoon zoals bedoeld. Je zou onze RC eens kunnen proberen. Daar zit nog een probleempje in waardoor opnames soms vastlopen, maar daar wordt aan gewerkt.

This is the layout I used about a year ago at my nephew’s home in Germany.
 
1 simple Triax TD 78 dish.
1 Triax multibeam mount. Max. 4 positions.
2 x inverto Widebeam lnb’s 
1 x Inverto Unicable switch. 
 
When you want this setup for four satellites, simply use this hardware twice and connect them to each other through this schematic diagram. 
You also need one or two power injector and a combiner. Possibly the reseller has to setup the Unicable switch for the right lnb’s. WB or Quattro. Look at the picture below.

 
BTW this only works if the switches have support for combining. The combiner is very simple, it does nothing more than an impedance adapted connect-through.
 
Similarly you can "cascade" two four-input JESS switches on one cable, if you configure one of them to be address "EFGH".
 
Another option, which I am using. If you don't mind having two cables into your house instead of one and you don't care there will be static assignment of tuners to either cable, you can simply use two switches (with either 2 or 4 inputs, whatever you like, but 2 inputs has the advantage you can use cheap Unicable switches) and connect both outputs directly to both inputs of your receiver(s). Then assign tuner A and one or more from C D E F G H to the first switch and assign tuner B and one or more from C D E F G H to the second switch. A leaf tuner (C D E F G H) can only be connected to either one. A root tuner needs to be connected to it's physical input ( A B ).
 
In my case I have the more frequently used positions one one switch and less frequently positions on another, then I assign most tuners to the input from the first switch and the two that are left to the other switch. Works like a charm. It can keep the costs really down if you limit yourself to four positions (so you can use Unicable in that case).

I have 8 LNB's. For that to work you will need a switch setup that will accept eight quattro (!) LNB's and eight LNB inputs. If you only have two positions, you can get away with a Unicable switch, which are quite affordable. Using two cables and two switches and two FBC inputs, you can extend that to four positions. For more than four positions, it will get expensive, anyway. At least, if you want all eight tuners to be independent.

Some switches also accept quad LNB's, but they're more expensive, so why bother. Mine doesn't.

EDIT: I see wanwizard already mentioned this.

There are basically two possibilities. As the FBC tuner only has two physical inputs, you're limited to that. That means you either just use the two inputs with automatic assignment, like you do with directly connected tuner or a DiSEqC setup. Or that you re-arrange the transponders in a way that all transponders you want receive are on the same cable, that is what SCR (Unicable, JESS) is all about.

So either you have the automatic assignment, which means you'll have one (or two, depending on how many inputs are physically connected) transponders guaranteed and up to eight transponder if you're lucky (same quadrant).

Or you're using SCR and you'll always have eight transponders available.

SCR and DiSEqC are mutually exclusive by design. Aside the fact they're using similar signalling techniques may confuse each other.

If you want the full FBC functionality (eight independent tuners), you'll have to invest in a SCR switch or SCR LNB's. The latter seems to be a lot cheaper, but also has some drawbacks.

VU+ is an interesting manufacturer compared to the others. On one hand they tend not to fix bugs (or take a long time to do so) but on the other hand, on hardware level they're really good (regarding both stability and capabilities). If you have the resources, I'd definitely advise the Duo4kSE (just the SE version!), which is in fact an Ultimo4k without a legacy tuner slot. Stability on the Ultimo4k (and it looks like Duo4kSE as well) has been quite good, better than quite a bit of other receivers I've seen.