Erik Slagter

This one

Eight LNB's connected using the two FBC inputs, plus a "conventional" dual tuner, plus FBC C tuner, makes 18 tuners, all of them usable without restrictions, no problems seen so far...

Ik lees hier "scherpe prijs", daar wil ik toch even op reageren. Niks is voor niks en alles komt met een prijs. De ervaring leert dat de allergoedkoopste ontvangers (veel) minder bugfixes krijgen en sommige features missen. Als je daar geen last van hebt, prima, vooral doen. Maar anders toch even over nadenken.

 

Werkt hier ook prima. Wat zijn je overwegingen, criteria?

 

Ja, ik was benieuwd of de Vu ook nadelen had vergeleken met de et9500.

Maar lees alleen maar goede/betere recenties.

De et9500 is rock solid qua drivers, daar kan geen enkele andere ontvanger tegenop. Maar de Solo4k heeft natuurlijk wel een hele rij meer/andere features.

Vandaar dat ik benieuwd ben naar jouw overwegingen.

Werkt hier ook prima. Wat zijn je overwegingen, criteria?

It has nothing to do with power.

It's very simple to check. If you VU+ receiver has a "file" called /dev/bcm_enc0 it can do transcoding. If it doesn't it can't.

R.I.P. Open Source.

Ok

In short. Bad code: "Great" variable names like tp, c1, c2, lcheck,... , static variables, strange checks like tp == 3 (don't know why), no documentation. I tried to understand the code but gave up.

I also don't like the editor. You cannot easily delete all cuts. It's easier to delete the .cuts file via telnet. And why is a marker included the cutted file?

 

I wouldn't wonder if the code contains several bugs. There are several strange parts.

I would write the program from scratch if I had enough time.

I know exactly the feeling (enigma...) But it's undoable to rewrite it all. Let's start with the fix for h265. AFAIR we have never added h265 support.

Een PC is geen STB. Je slaat de plank compleet mis. Bewegende onderdelen hebben last van warmte (of meer: variatie in warmte), zoals een harddisk dus. Zolang er geen bewegende onderdelen in een apparaat zitten, is alleen de temperatuur op de "die" (de chip zelf, binnen de behuizing van het IC) van belang, zolang die onder de ongeveer 120 graden blijft, is er niks aan de hand. Als de lucht heel erg warm wordt (vanaf pak 'm beet 60 graden) gaat dat invloed hebben op de andere onderdelen, met name electrolytische condensatoren, maar zo ver komt het zelden.

Dat dus even tegenover het "ik voel..." verhaal van hierboven.

Thank you..I think Enigma 2  is finished...

Enigma2 never has been designed for such use. I am not into Netflix etc. at all, so for me it still great. If you want to watch such services, why don't you buy a supported mediaplayer?

When the times comes, you will be able to do an upgrade.

Erik, kan je kort aangeven waarom nooit met CI+ te beginnen? Volgens mij gebruikt ziggo nog CI (zonder +) maar ik kan het mishebben

Ten eerste, als het even kan moet je CI+ vermijden omdat het alleen maar beperkingen aan de gebruiker oplegt. Als je dan toch moet, dan heb je pech, want CI+ is inherent onverenigbaar met een open ontvanger. Soms hier en daar krijgt men het wel werkend, maar het is altijd illegaal en geen enkele garantie dat het volgende maand ook nog werkt.

Why create the symlink manually?
Don't users have to use the  update-rc.d  command to create or delete the symlink?

Yes you can use update-rc.d but I think it's more cumbersome than to create a few symlinks yourself.

Daarom spreken we ook over "frames" voor complete beelden en "fields" voor even/oneven "halve" beelden. Bij interlaced is het aantal fields 2 x het aantal frames, bij progressive is het aantal fields gelijk aan het aantal frames.

Als je maar een zeer beperkte bandbreedte hebt (wat bij analoge tv zeker het geval was), dan is interlacing een heel mooie techniek omdat je iets aan resolutie (spatiale resolutie) inlevert maar daarvoor veel temperele resolutie terugkrijgt (vloeiendheid van beweging). Het oog+hersenen merken gebrek aan dat laatste veel sneller op dan het eerste. Dat was destijds dus echt wel een goed idee. Je ziet dat in sommige programma's wel eens gebruik wordt gemaakt van zeer portabele camera's en op de een of andere manier nemen die dan in 25p op (in plaats van 50i). Ik zie daar de lol of nut niet van, maar het gebeurt. En ja, je ziet het echt meteen. Geen gezicht.

Echter tegenwoordig is er aardig wat meer (virtuele, door compressie) bandbreedte en nu zou je best alles progressief kunnen uitzenden (in 50p wel te verstaan, niet 25p, dat is een achteruitgang). De laagste trap van UHD voorziet daar dan ook in: 1920p50/p60. Alle andere UHD resoluties zijn ook progressief (als in: 50/60p, niet "nep" 25/30p). Dat gaat dus uiteindelijk allemaal vanzelf goed komen.

Dan de deinterlacing. Dat wordt door de hardware in de SoC gedaan. Je kunt geen software+cpu maken die dat snel genoeg in real-time kan doen. Daarvoor zit dus een toegewijde transistors. Valt dus niet zoveel aan te fine tunen. Hoeft ook niet, want de deinterlacer in de nieuwere Broadcom SoC's doet prima werk, totaal geen klachten.

Waar je wel zelf invloed op heb, is over je geen deinterlacing, wel deinterlacing of weave+bobbing doet. Dat is niet hetzelfde.

- geen deinterlacing (of scaling) doe je als je zorgt dat de resolutie van de ontvangen service altijd precies overeenkomt met wat je uitstuurt. Daarvoor moet je dan dus de autoresolution plugin gebruiken. In dat geval doet de SoC helemaal NIETS. Dit werd in het verleden nogal eens gedaan omdat men de deinterlacer/scaler van de TV beter vond dan die van de ontvanger. Ik geloof niet dat dat tegenwoordig nog erg relevant is.

- zodra de SoC moet schalen moet die ook "iets" met de deinterlacing doen. Interlaced schalen wordt heel erg lelijk (en heel soms zie je het wel eens langskomen op tv zenders). In dat geval maakt de SoC voor de schaling van het interlaced materiaal een virtueel progressief materiaal (door om-en-om fields te herhalen en in te vullen: weave+bob). Dit is géén deinterlacing. Afhankelijk van of de output progressief moet zijn wordt daarna alsnog deinterlaced of niet.

- Als je (HDMI) output op 50p staat (aanrader!) dan zal de SoC nooit deinterlacen, zonodig, bij interlaced materiaal, een weave+bob doen. Dit is in tegenstelling tot deinterlacing een verliesvrije operatie.

- Als je (HDMI) output op 50i staat, dan zal de SoC in het geval van progressief materiaal (720p....) moeten gaan interlacen. Absoluut géén aanrader.

Dat is wat je zelf aan invloed heb. Zorg dat die output op 50p staat, dan haal je het maximale er uit. Echt deinterlacen (niet bob+weave) kan de televisie zelf altijd beter dan de ontvanger, omdat hij direct verbinding heeft met de panel en daardoor wat slimme kan doen, die een los apparaat niet kan doen.

 

In hotkey knop aan HDMI-in toewijzen

 

Thanks werkt nu, is er ook nog een tip om dit van een andere partij te realiseren of lukt dit niet binnen PLI?
https://wiki.vuplus-...p?title=HDMI-IN

???????

Goed dat je wget noemt. Ik weet nu weer wat het probleem is. Het is inderdaad een probleem (maar niet per se een bug) in wget. In sommige distributies (in ieder geval Fedora) wordt in wget de config optie standaard aangezet dat alles wat als gzip compressed binnenkomt automatisch gunzipped wordt. Dat is prima als het gzippen transparant door de web server gebeurt, dat is wat je wilt. Maar het probleem is dat wget het ook doet als je een .gz file download. Wat je dan krijgt is een file die endigt op .gz maar niet meer gzipped is. Probeer het maar, bij de VU+ downloads krijg je files die je direct met tar kunt uitpakken. De checksum klopt dan uiteraard ook niet meer.

Workaround is om je in home directory de file .wgetrc aan te maken en daarin op te nemen:

compression=none