Verzoek aan diegenen die NFS gebruiken

[Tonskidutch]

clever...

 

dat vraag je maar eens aan een linux hacker.

 

ik heb de kennis niet maar wel gezien van zo'n hacker.

 

cheers

 

uh als toevoeging...

de laptop van bureau was gestolen , maar Mac adres bekent...

wel opgespoort dus.

 

cheers

[Urkel]

Okay, point taken.

Alle mac adressen die ik vermeld heb had ik al een pietsie gewijzigd en tevens zit alles achter mijn firewall.

Tengx anyway.

 

 

Goed even terug naar het onderwerp.

Ik heb zelf ook nog wat getest met 2 opmerkelijke resultaten. Ik heb een DVD geripped en omgezet naar een gewoon MPEG2 bestand met MPEG1 layer2 stereo audio er in.

Dit bestand heb ik afgespeeld op de DB en zag de volgende 2 opmerkelijke zaken.

 

1) Op punten dat het beeld helemaal zwart was kwamen er geen errors meer bij op eth0 in de DB. Als het beeld bijna zwart was waren er duidelijk minder errors dan als dat het beeld licht is. D.w.z. dat de hoeveelheid errors afhankelijk is van de bitrate van de stream.

Ik ga meten wat de bitrate is in het zwarte deel van het MPEG bestand en ga dan 2 dingen doen.

- een stream maken met compleet zwarte beeld. Deze ga ik afspelen en kijken wat er met de error count gebeurt.

- een stream maken met gewoon beeld, maar die niet boven de bitrate uit komt van het zwarte stuk in de DVD rip. Deze ga ik ook afspelen en kijken wat er gebeurt met de error count.

 

Hopelijk wordt mijn vermoeden bevestigd dat de DB het gewoon "druk" heeft en als het decoderen van een frame wat tijd kost dat hij niet genoeg tijd meer heeft om op tijd de ethernetadapter uit te lezen.

 

2) Gedurende het afspelen van de DVD rip heb ik geen hakkel of stotter gezien in het beeld. Dit in tegenstelling tot live TV kijken en het bekijken van opnames die gemaakt zijn. Er zijn regelmatig haperingen en stotteringen in het beeld te zien als er live TV gekeken wordt of als er naar een opname gekeken wordt. Het bekijken van een opname kan zelfs resulteren in een freeze van het beeld zonder dat de DB crasht.

Wat leer ik hier uit? De MPEG stream die via de ethernet adapter binnenkomt zal voor een groot deel dezelfde "weg" door de DB heen volgen als dat een stream dat doet die van de ontvanger afkomstig is. Dat gezamelijke deel is dus in orde en introduceert de haperingen en het stotteren niet. Het haperen en stotteren wordt dus geïntroduceerd in het deel van de ontvanger wat de stream wel aflegt en de stream vanaf de ethernet adapter niet aflegt. My best guess is dat dit een driver is. Aan de heren en dames image bouwers dus het verzoek om daar eens de aandacht op te richten.

 

Waarom de ene box wel last heeft van die haperingen en de andere box schijnbaar niet is nog een mistery.

 

I'll keep you posted.

 

CU

 

Urk

[Gast]

Hoi Urkel

 

Dat het zwarte beeld minder errors veroorzaakt kan ik bevestigen. Had film die ik vanmiddag voor de test gebruikte opgenomen van kiosk, en voor het begin krijg je een aantal seconden een bijna zwart beeld met een grote witte secondenteller te zien. De errors liepen toen langzamer op dan bij een druk bewegend beeld.

 

Ik heb ook nog zitten denken of het interessant zou zijn om een netwerk-monitor te installeren die de stream van de db naar de server kan meten bij de verschillende images, zowel bij het opnemen als bij het weergeven. Als de hoeveelheid data bij weergave gelijk is (zou wel logisch zijn) ben ik benieuwd hoe het dan met de opname zit: daar zouden verschillen in drivers zichtbaar kunnen worden, of denk ik dan heel krom? En weet iemand een goed Windows pakketje waarmee ik netwerkactiviteit kan meten tussen 2 andere machines?

[Tonskidutch]

hyena is zo proggie..

 

maar je/we hebben het over een stream die vele beeldframes naar een medium probeerd te schrijven... (NFS)

 

er is een lastige term GOP die bij verkeerd weergegeven frames dus een errormelding geeft, hetgeen gedeeltelijk door encodeer software kan worden overbrugd maar bij teveel errors tot tot ellende lijdt

 

de hdd in de dreambox en dan overhevelen lijkt daarom de meest betrouwbare.

 

ik moet bekennen ik heb nog geen enkel positief signaal kunnen opnemen op dvd na die veelvuldige bewerkingen.

dus eenvoudig is het naar mijn mening ook niet...

 

ondanks alle tips en adviezen.

 

ik heb nu officieel gelicenseerde software ervoor TMPenc express 3.0 en ben ongelukkig met betrekking tot het resultaat.. 46 uur voor een film en geen bruikbare ts video/audio.

 

cheers

[Urkel]

Als je een switched netwerk heb met een unmanaged switch, dan kun je snifferen wel vergeten.

 

Bij opname vanaf de tuner naar NFS loopt de stream door de "driver" heen die het stotteren introduceert en die zal 1:1 naar de NFS share gestuurd worden. Het stotteren zal dus ook in de opname aanwezig zijn en bij het afspelen zie je die dan ook weer terug.

 

Bij benadering zal de hoeveelheid netwerk verkeer van DB naar NFS bij een opname hetzelfde zijn als van NFS naar DB bij een weergave. De opname is namelijk de TS (transport stream) en bevat alle audio en ook teletext die de oorspronkelijke stream ook bevatte. Als je opneemt via NGRAB wordt denk ik alleen de video pid en audio pid over de ethernet kabel verstuurd waar je op "afgestemd" staat. Het resultaat is dan een PES stream met alleen video en 1x audio en geen teletext. Ook hier zal bij opname en weergave in principe net zoveel netwerkverkeer gegenereerd worden.

 

Ik bedenk mij net dat de ontvanger de hele transponder tegelijk ontvangt. Dus alle video en audio streams die op die transponder uitgezonden worden. Door het afstemmen op een bepaald station filtert de DB de juiste video pid en audio pid er uit om die weer te geven op het beeld en eventueel op te nemen op welk medium dan ook.

Het stotteren zou veroorzaakt kunnen worden doordat het filteren niet helemaal goed gaat.

De Topfield 4000 had in den beginne ook een bug die werd "Big Files" bug genoemd. Opnames waren soms heel erg groot voor een uurtje opnemen. Denk aan >10GB voor een uur. De TF nam dan grote delen van de transponder op ipv alleen de juiste video pid en audio pid. Dit resulteerde vaak in een opname die niet meer af te spelen was en als dat wel lukte zat die vol met haperingen en stotteren.

Zou het "filter" in de DB misschien niet zijn werk goed doen?

 

Urk

[Gast]

Heb nu geen tijd meer (niet vanwege voetbal), maar ik zal aankomend weekend eens kijken of ik stotters in de opnamen kan bespeuren. Ik kan een dvd rippen en afspelen, als het goed is heb je dan de afspeel-stotters te pakken. Een opgenomen bestand lokaal op de pc afkijken zou dus eventuele opname-hiks in kaart moeten brengen...

 

Heb inderdaad een unmanaged switch, dus de stream analyseren is dan een slecht idee.

[Gast]

Qos packetplanner regelt het netwerkverkeer !

de naam packetplanner zegt het al het regelt de parketjes

( netwerk bestaat uit parketjes die verzonden worden en is er 1 verzonden en goedbevonden dan volgt de volgende.)

is er echter 1 niet goed over gekomen dan wordt ie opnieuw gestuurd (dat heet snelheids verlies)

Qos packetplanner bepaalt ook wie er voorang krijgt met het netwerkverkeer !!!

 

dit is dus in te stelen door de gebruiker .

 

Wat veel mensen trouwens ook fout doen is meer dan alleen

Tcp-IP protocollen gebruiken dit leverd ook vertragingen op.

wat veel voorkomt is tcp-ip en netbui

 

een kleine verklaring waarom :

het paketje wordt over tcp-ip verzonden en ook tegelijk via netbui protocol..

over het algemeen heb je netbui voor thuis niet echt nodig .. (behalve soms met windows ME) das in sommige gevallen een drama besturingssysteem voor netwerken !!

 

PS dit is behoorlijk off topic, maar voor mensen met enige netwerk kennis en NFS probeerselen wel degelijk nuttig <img src="/ubbthreads/images/graemlins/smile.gif" alt="" />

[Gast]

MP3 afspelen via NFS is image afhankeijk !

[Gast]

Welke type dreambox?

[Gast]

Urkel De rechten kwestie heb ik al nagelopen. (Geprobeerd een map aan te maken via de dreambox). Het feit is dat wanneer je een opname strart de files wel op de share verschijnen ze blijven alleen op de grootte van 1 byte.

 

Ik zelf denk dat het of aan de image ligt of aan de beperking van de 5620 Dreambox

[Urkel]

Ondersteunt de 5620 ook NGRAB?

Indien ja, installeer dan eens een NGRAB server. Onder Linux stelt dit vrijwel niets voor. Je moet dan ggrab downloaden, effuh compileren en sserver opstarten.

 

Met een beetje Linux kennis heb je die in een paar minuten draaien.

 

Urk

[bartbnl]

Ik heb hier net ook even gekeken. Op zo'n anderhalf uur speeltijd, redelijk stabiel tussen de 4% en 5% overruns tov het aantal RX packets (dus wel minder dan de 9% uit het eerste bericht in dit topic, maar nog steeds behoorlijk veel). Ik gebruik een oudere Ronaldd (van oktober vorig jaar), maar kan me eigenlijk niet voorstellen dat dit aan het image ligt, hooguit nog aan drivers die erin zitten. Dan nog zitten er nog genoeg lagen in de netwerk-stack die correctie doen, want ik heb qua beeld geen problemen kunnen ontdekken. Het blijft natuurlijk wel zonde dat er fouten optreden die gecorrigeerd moeten worden.

 

Mijn hardware: windoze xp PC met een 3com gigabit op-het-moderbord netwerk chip. Dan via een 5-poort 100mbit switch naar de router die ook als switch fungeert. De router is weer met de dreambox doorverbonden (serienr. begint met 3, mocht dat nog wat zeggen over de netwerk chip in de box).

 

Al met al best veel kabel en tussenstops dus, maar zolang de hogere lagen in de netwerk protocol stack alles corrigeren zal ik me er niet zo heel erg druk om maken...