NFS mount on Debian: film afspelen niet stabiel

[Gast]

Ik heb op m'n debian server een nfs export opgezet waarnaar m'n dreambox connect. zo kan ik opnemen op m'n server, films bekijken die erop staan, foto album bekijken.

En zo goed als alles werkt... maaaar...

 

Zodra ik een film heb opgenomen kan ik deze wel terugvinden, maar tijdens het afspelen krijg ik alleen maar zwart beeld.

 

Oude films die ik nog had heb ik ook in deze directorie gezet en die spelen wel goed af.

 

Heeft iemand dit al eens meegemaakt?

 

Daarnaast, om e.e.a. te testen wilde ik op de server een pakket installeren die de ts naar mpeg omzet. Helaas is er wel alles te vinden om dit op een pc te doen, maar niet op een linux server.

[Gast]

Ik zal een kleine logging bijhouden, mocht er ooit nog iemand tegenaan lopen.

 

een tcp dump op de debian server geeft bij normaal afspelen

het volgende weer:

17:51:19.446355 IP 10.0.0.10.3178150620 > 10.0.0.1.nfs: 116 read [|nfs]

17:51:19.446599 IP 10.0.0.1.nfs > 10.0.0.10.3178150619: reply ok 1472 read

17:51:19.446619 IP 10.0.0.1 > 10.0.0.10: udp

17:51:19.446633 IP 10.0.0.1 > 10.0.0.10: udp

17:51:19.446649 IP 10.0.0.1 > 10.0.0.10: udp

17:51:19.446664 IP 10.0.0.1 > 10.0.0.10: udp

17:51:19.446676 IP 10.0.0.1 > 10.0.0.10: udp

17:51:19.447209 IP 10.0.0.1 > 10.0.0.10: udp

 

Dit gaat continue zo door, redeijk leesbaar op het scherm qua snelheid. Echter, zodra de film hangt, dan racen deze pakketten over het scherm. Ook tcpdump geeft ontzettend veel reads in korte tijd tov normaal.

 

Wat ik wil proberen: nfs share over tcp ipv udp.

[Gast]

Inmiddels via tcp de mount opgezet.

tijdens een tcpdump zie ik nu de volgende melding ertussen:

19:01:15.225653 IP 10.0.0.1.nfs > 10.0.0.10.4294967295: reply ERR 1448

 

10.0.0.1 = dreambox 10.0.0.10 = server

 

Weer iets om uit te zoeken.

[Gast]

TCP of UPD, maakt geen verschil uit.

Na een nieuwe server met X geinstalleerd zodat er makkelijk met ethereal kon worden gesniffed kwam ik tegen de mtu-size aan.

 

Aangezien er een maximum van 1500 bytes voor m'n server is ingesteld, en de dreambox van 8x1024=8192 bytes.

Dit zou voor verwarring kunnen zorgen bij retransmissies.

 

op dit moment zijn m'n mounting settings:

nolock,rsize=1024,wsize-1024

 

2b continued.

 

Ben toch benieuwd hoeveel dreambox gebruikers van microsoft of van linux gebruik maken, eens kijken of er een pol te maken valt

[Gast]

he, de nolock,rsize=1024,wsize-1024 settings werken een heel stuk stabielen aangezien de ip pakketten niet meer gefragmenteerd worden. Ik durf nog niet te zeggen of alles nu goed werkt, maar ik de hele dag nog geen problemen gehad

 

Ik heb een bruin vermoeden dat zodra er een ip retransmissie plaats vindt (doordat er een andere hogere prio leesacties uitvoerd, of als je begint te spoelen en hij komt net in een frame/beeld terecht waarvan de data b.v. in het 3e deel van het gefragmenteerde pakket komt hij de kluts kwijt is.

 

Daarna zie ik dan ook (zodra het fout ging) ontzettend veel search requesten die fout gingen.

 

Ik dat ik hiermee iemand een heel stuk ergernis heb bespaard!

 

groeten

[Rexxx]

Hmmm, ik moet eerlijk zeggen een lagere r- of wsize heb ik nog nooit geprobeerd, ben maar CIFS gaan gebruiken, (samba, ook op debian) en dat loopt een stuk beter.

 

Zal als ik weer eens de boel naar een hogere versie breng gaan experimenteren met die 1024 size. Je verhaal van retransmissies die 'out of sync' lopen klinkt logisch voor de problemen die ik met NFS & dreambox heb.

 

/Rexxx <img src="/forums/images/graemlins/rockon.gif" alt="" />

[Gast]

Blij dat ik er nog iemand mee heb kunnen helpen <img src="/forums/images/graemlins/smile.gif" alt="" />

[Barabas]

Citaat:

TCP of UPD, maakt geen verschil uit.
Na een nieuwe server met X geinstalleerd zodat er makkelijk met ethereal kon worden gesniffed kwam ik tegen de mtu-size aan.

Aangezien er een maximum van 1500 bytes voor m'n server is ingesteld, en de dreambox van 8x1024=8192 bytes.
Dit zou voor verwarring kunnen zorgen bij retransmissies.

op dit moment zijn m'n mounting settings:
nolock,rsize=1024,wsize-1024

2b continued.

Ben toch benieuwd hoeveel dreambox gebruikers van microsoft of van linux gebruik maken, eens kijken of er een pol te maken valt

Helaas vergelijk je nu appels met peren. De MTU size heeft niets te maken met de r/wsize (SO_SNDBUF and SO_RCVBUF)

Lees dit stuk maar eens door. ook dit is wel aardig om te lezen.

[Gast]

De stukken zijn interessant om te lezen, ik merk echter wel degelijk verschil, of m'n uiteindelijke conclusie klopt weet ik niet.

 

Bij de controlle dmv een snif zie ik dat ik nu geen gefragmenteerde pakketten heb aangezien ze 1024=nfs data + headers = < 1500 blijven.

Ik heb over het netwerk dan wel iets meer data (requests to write), maar die paar kb/s maakt op 100Mb niet uit.

 

Zijn er dreambox-gebruikers die gebruik maken van een NFS mounting onder linux, liefst debian? met problemen of werkt het vlekkeloos met default settings

[Gast]

Helaas,

 

het werkt toch niet helemaal stabiel.. wordt er nu moe van.

[Barabas]

Probeer op de Debian server eens met Samba te delen en in de Dreambox te mounten met Cifs. Volgens alle meldingen op dit board geeft dit de beste resultaten.

[Gast]

Vandaag cifs gebruikt met samba onder debian.

Helaas ook geen vooruitgang. NFS + Samba werkt goed tussen alle servers, echter de box vertikt het om stabiel te werken.

 

Sommige programma's die ik heb opgenomen speelt hij een beetje af, sommige start ie niet eens.

 

ngrab wil ik nog eens proberen, maar helaas heb ik geen sserver meer (om de stream op te vangen op de linux-server)

 

Daarna ga ik toch eerst een andere/oudere image testen of dit hier wel nog werkt.

[Tonskidutch]

is het een kwestie van oude images en nieuwe..NU

die op de mount een recordings.epl en of zelfs epg date hebben staan (die niet compatibel is met de nieuwe image?)

 

dit staat betreffende zwarte opnames ook her en der ..

 

cheers

[Gast]

hmm, nooit geweten <img src="/forums/images/graemlins/smile.gif" alt="" />

ik ga het proberen en direct een opname starten.

Zoiets geeft nieuwe hoop.

 

Ik kan me idd herinneren dat ik de movie dir heb laten staan, waardoor ook oude bestanden van hydra nog in de movie dir stonden.

 

alvast bedankt tonskidutch!

[Gast]

Zo.

 

eindelijk gevonden wat het probleem is.

 

Het is niet NFS, noch het afspelen van films.

Om een heeeeeel lang verhaal kort te houden:

 

Ik gebruik camx die ik heb geconfigureerd met een radegast server. Zodra ik free2air kanalen zoals L1mburg opnam en bekeek ging alles perfect.

 

Dus toen kwam ik bij de emu uit. Nadat ik deze vervangen had door newcamd+originele kaart in die box ging alles perfect.

 

ik wil wel graag overal tv kijken en zal dus moeten zoeken naar een andere combinatie zodat ik van de radegast server gebruik kan maken. Ik zal me wat meer moeten gaan verdiepen in het configureren van de emu's

 

Wel sterk dat net deze combinatie dus niet werkt:

camx die middels radegast werkt en waarbij het recorden naar het netwerk niet goed gaat. zowel nfs, samba, ggrab.

 

 

THE END!