375 replies to this topic

[Erik Slagter]

Als er een liefhebber is die er tijd voor uittrekken, prima, maar ik schat die kans niet zo groot in.

[Rob van der Does]

Jongens jongens, dit is iets wat je eenmalig moet doen. We gaan daar echt geen uren manwerk in stoppen. Daarvoor hebben we veel belangrijkere issues die spelen.

Definieer 'eenmalig'. Ja, het moet 'eenmalig' na flashen/verse setup/wisselen van serverbox.
En vergeet niet dat het invoegen van letters bij een VU onder PLi niet mogelijk is. Natuurlijk zijn er work-arounds voor, maar we hebben het hier over de GUI.

[WanWizard]

En dat laatste was de reden om de "http" er automatisch voor te zetten. Zodat je met een SMS keyboard uit de voeten kunt.

 

En er staat me bij dat er wat dat VU+ probleem progressie was, maar daar weet Erik wellicht meer van (of hij verklaart me voor gek, kan ook ).

[Erik Slagter]

Die issue is er niet meer, zolang je niet de alphanumerieke remote control gebruikt (want die wordt als numeriek gezien en daar moet je alsnog gaan SMS'en, maar het kan dus wel degelijk).

[dolphs]

<snip snip> OpenVPN tunnel naar thuis start, en ik kan overal waar ik ben (en er een beetje bandbreedte is) TV kijken alsof ik thuis ben.

 

Ik doe de fallback overigens naar de transcoder poort (8002) van mijn box thuis, dat kan beter tegen de omstandigheden van het internet, en heeft minder bandbreedte nodig.

​Hi ​WanWizard ben dan tock stinkend nieuwsgierig naar jouw instellingen in sysctl.conf qua kernel tuning, eg:

- net.core.default_qdisc

- net.ipv4.tcp_congestion_control

- net.core.rmem_max 
- net.core.wmem_max

- etc.

 

en ook wel server.conf + client.conf van openvpn - de keys hoef ik dan net weer niet te weten ;-)

Ben zelf na geholpen te zijn door " Pippin " vorig jaar ook redelijk in de materie ingewerkt ( denk ik dan ) maar ach het kan altijd beter toch ...

Op dit moment druk aan het knutselen met twee nanopineo2 plankjes en dat bevalt prima vanwege de goede kernel support vanaf 4.13.x en dus ook hardware matige AES ....

 

Oh ik zou bijna vergeten waar ik nou echt nieuwsgierig naar ben en dat is de 8002 port voor transcoding.

Dat betekent dus dat je je HD beeld cut naar SD, op zich ook wel logisch want je geeft aan dat je het met WiFi in hotels moet doen: good luck zeg ik dan om >=8Mbit te halen, meestal niet dus ...

Het zou mooi zijn als ik ook een buffertje kon inbouwen van 1-2 seconden voor 1-1 streams ( port 8001 ), zodat ik waarschijnlijk helemaal geen last meer zal hebben van een "hick" .

Meen dat Erik ooit al eens had aangegeven om "1" naar "14" ( oid ) te zetten , maar dat gaf niet het gewenste resultaat - kan het bewuste topic even niet vinden ...

 

Edoch moet eerlijk bekennen dat Mooz HD ( http://DM8000:8001/1:0:19:BBD:3:1111:E08B0A8:0:0:0 ) nu de hele avond al staat te schallen ( 3 uurtjes ) en tot dusver nog maar 1 hickje meegemaakt, dus w.b.t. kernel tuning en openvpn config denk ik dat ik redelijk warm ben, alleen eerste 10-20 seconden wil ie nog wel eens even moeite hebben ... Zo zie je maar waar je een DM8000 nog  uitstekend voor kan gebruiken, inderdaad perfect streaming servertje i.c.m. zo'n nanopineo2 :-)

[WanWizard]

Ik heb een OpenVPN server in mijn firewall, dus die gebruik is als server. Ik gebruik een HD2400 met 4 tuners als transcoder box. Ik heb nergens enige kernel tuning gedaan.

 

Zonder transcoding is er nauwelijks naar te kijken, om te beginnen heb je dan geen enkele buffering, bovendien is 8Mbps (sustained) toch al luxe, mijn DSL heeft maar 9999Kbps upstream.

 

De client kan kan ik ook weinig over zeggen, OpenVPN geinstalleerd, mijn firewall genereert keurig een pakketje met config en certificaten, dus weinig handwerk nodig.Ik moet alleen handmatig het init script activeren (symlink in /etc/rc3.d, omdat het OpenVPN pakcage in 6.0 dat niet deed. Dat is voor 6.1 gefixt.

[dolphs]

Helder- trouwens dit topic had ik het over " update serviceref van 1: naar 4097 " , helaas leek dat niet te helpen in mijn geval. 

Edited by dolphs, 17 December 2017 - 07:13.

[Rob van der Does]

En dat laatste was de reden om de "http" er automatisch voor te zetten. Zodat je met een SMS keyboard uit de voeten kunt.

 

En er staat me bij dat er wat dat VU+ probleem progressie was, maar daar weet Erik wellicht meer van (of hij verklaart me voor gek, kan ook ).

 

 

Die issue is er niet meer, zolang je niet de alphanumerieke remote control gebruikt (want die wordt als numeriek gezien en daar moet je alsnog gaan SMS'en, maar het kan dus wel degelijk).

 

Hmm, ga ik zo meteen proberen. Vanaf de geboorte van de eerste PLi-for-VU+ tot een paar dagen geleden was dat zeker een issue.

[Erik Slagter]

Niet getranscodeerde services over internet, moet je echt niet aan beginnen. Ook al is je bandbreedte nog zo groot, het blijft problematisch. De transcoded transport stream heeft een net wat andere opbouw waardoor het veel beter over internet gaat.

[WanWizard]

Grootste probleem is jitter. De "gewone" stream is erg timing gevoelig, er is geen enkele buffering aanwezig, dus elke hickup in het transport is zichtbaar in beeld.

[Erik Slagter]

Ik zie vaak dat het helemaal niet werkt, terwijl er ruimschoots voldoende bandbreedte is, en ook nog met weinig jitter.

[Rob van der Does]

Maar als ik GiThub goed heb gevolgd en begrepen, is dit opgelost in E2 (wat PLi voorheen nooit wilde) en niet in de drivers (wat VU nooit wilde).

Nu nog het dedicated toetsenbord (achterzijde AB)? 

 

Dat blijft vereisen dat VU de drivers aanpast, om dat het probleem blijft dat beide inputs aangeven dat ze alphanumeric zijn.

[Erik Slagter]

We hebben het nu anders opgelost, wat een vergelijkbaar probleem in een eventueel toekomstig product van wat voor merk dan ook, ook meteen oplost. We gaan er nu vanuit dat als er maar één remote control is (en bij VU+ is dat zo, omdat ze alle remote input unified hebben), dat die dan altijd een numerieke remote control is. Mocht dat toch een alfanumeriek device zijn, dan is er volgens mij nog geen man over boord, het enige is dat je dan overal (ook) een SMS-keyboard er bij krijgt. Er zit dus geen "if (vu+) then" constructie meer in. De aanpak van VU+ om alle input unified te maken is op zich niet verkeerd. Het heeft alleen het bekende nadeel dat je niet kunt zien wat voor devices er achter zitten en wat het karakter daarvan is.

 

Ik heb het overigens ook nog geprobeerd met een USB keyboard en dat werkt prima.

[dolphs]

Avond, 

 

Niet getranscodeerde services over internet, moet je echt niet aan beginnen. Ook al is je bandbreedte nog zo groot, het blijft problematisch. De transcoded transport stream heeft een net wat andere opbouw waardoor het veel beter over internet gaat.

 

Permanente​ ​oplossing is mogelijk, indien je af en toe een hickupje accepteert - ben nu een jaar aan het "experimenteren" en heb goede resultaten tussen RO ( fiber ) en NL ( vdsl2 ) ...

Maar waar ik eigenlijk nooit stil bij heb gestaan is, of die transcoded transport stream ( 8002 ) port gebruikt kan worden ZONDER compressie, dus indien een Vu+ ( Xtrend ) wordt gebruikt ( lees decoder met transcoding opties ).

 

Dus ipv " http://192.168.x.y:8001/1:0:19:7925:2C6:600:E080000:0:0:0 " gewoon " 8002 ", zonder verdere opties en dan zou ik die buffer hebben en bovendien HD blijft HD?

Kan mij uit het verleden wel herinneren dat ik die transcoding gebruikt heb maar dan alijd incl compressie omdat ik in de veronderstelling was dat dat mandatory parameters zijn en dan heb ik het niet over een upload die maar 6Mbit aankan. Als dat zo is dan zou ik dat volgend jaar nog eens kunnen proberen en de DM8000 swappen voor een ET10000 :-).

Edited by dolphs, 19 December 2017 - 15:58.

[WanWizard]

Nee. 8002 is de transcoder poort, en daar zit een getranscodeerde stream achter.

 

Als je overigens een oude bak met transcoding gaat opzoeken, zou ik persoonlijk eerder een HD2400 opzoeken in plaats van een ET10000, gegeven de driver ellende van dit moment.

[Erik Slagter]

Je kunt wel transcoderen met "minimaal" kwaliteitsverlies, volgens mij kun je gewoon 1080p25 kiezen als resolutie en dan een flink hoge bitrate. Je raakt alleen de interlacing kwijt en bij snelle beeldwisselingen heb je even blokjes.

[WanWizard]

Is dat zo? En is dat dan specifiek aan jou streamproxy? De Webif bied in de settings alleen 480p, 576p en 720p aan als opties.

 

edit: ff snel geprobeerd: http://172.16.1.43:8...=2?interlaced=0 maar dit werkt niet, de transcoder maakt er 1280x720 van.

[Erik Slagter]

Ik heb op dit moment (even nagekeken in de source) 1080p toegestaan voor de VU+ UHD machines. Of dat terecht is weet ik niet, zou ik eens moeten proberen. Idem voor de andere ontvangers. Ik kan zelf wat dat betreft de VU+ UHD ontvangers proberen, de hd2400 en et10000 niet, dat zal iemand anders moeten doen.

[Erik Slagter]

Testen levert op dat de VU+ UHD ontvangers ook geen 1080p ondersteunen (of niet meer, dat is niet helemaal duidelijk). Ik heb de streamproxy meteen aangepast.

[WanWizard]

De HD2400 dus niet.

 

Ik heb net de ET10000 ook nog geprobeerd, maar ook die doet het niet, wat al te verwachten was.