Schokkerig beeld DM 600 mount met DM 7025+

[Gast miknic]

Uiteindelijk bleek het niet zo moeilijk om een mount in een DM 600 aan te maken naar de harde schijf in een DM 7025+.

De mount werkt en ik kan nu de opgenomen programma's die op de harde schijf staan van de 7025+, bekijken via de 600.

Echter is het beeld schokkerig.

Nu hoop ik dat iemand me kan helpen om dit op te lossen.

 

Ik maak gebruik via een draadloos netwerk. De beide dreamboxen zijn verbonden via het draadloze powerline ethernet adapter systeem van Sweex. Dit systeem maakt gebruik van het stopcontact om zo de signalen met een snelheid van 80 mbs draadloos te versturen.

 

Image van de DM 7025+: LT 5th sp5

Image van de DM 600: PLI Helenite

 

Het zal ongetwijfeld met het netwerk te maken hebben maar ik dacht dat een theoretische snelheid van 80 mbs genoeg moest zijn voor een vloeiende beeld weergave.

 

 

[Satdorus]

Als het via het stopcontact gaat is het toch niet draadloos.

En net wat je zegt het is een theoretische waarde.

Misschien kun je de mount regels (van beide dozen)hier plaatsen dat maakt veel duidelijk.

Heb je bv. gemount via samba,cifs of nfs?

[Tonskidutch]

had je deze methodiek gebruikt > mounten enigma1 op enigma 2 en andersom

 

indien ja, zul je met NFS enkele parameters kunnen testen om te optimeren

rsize=8192,wsize=8192 (x2 of x4)

en evenwel kijken of je router/switch lekkerder werkt met tcp of udp

enkele netwerkapparaten blokken udp en dan is tcp gebruiken vaak de oplossing

bijvoorbeeld zo:

dm7025 -fstype=nfs,rw,tcp,rsize=32768,wsize=32768, ://192.168.1.2/var/hdd/movie

 

niet alles letterlijk overnemen (eigen paden en ip-nummers gebruiken) maar betreffende de parameters een optie om de mount op tcp te laten verlopen.

 

chiao

[Gast miknic]

Bedankt alvast voor de reacties!

Ik heb een JPEG bestand bijgevoegd met een screenshot van de mount. Het gaat om een CIFS mount die ik eenvoudig met de webinterface van de 600 heb gemaakt.

 

Hopelijk kunnen jullie het bestand openen om te zien wat ik (fout) heb gedaan.

 

Ik heb trouwens ook vastgesteld dat nu het IP adres van de boxen veranderd is. Is het mogelijk om alle apparaten een vast IP adres te geven? Moet ik dit in mijn router wellicht aanpassen?

 

bedankt maar weer.

[MrScratch]

Ik zou sowieso een NFS mount proberen ipv CIFS. Dat laatste is voor windows en de dreamboxen zijn Linux machines en dus is NFS veel efficienter.

 

 

[dAF2000]

Probeer 't eens zonder "root" en/of "dreambox".

[Gast miknic]

inmiddels heb ik vanalles geprobeerd. Dus NFS mount met en zonder wachtwoord, CIFS mount met allerlei verschillende opties.

 

Het beeld blijft maar haperen en stotteren.

Hieronder een screenshot van de NFS mount.

Hopelijk weet iemand een oplossing. Bedankt alvast.

[Tonskidutch]

standaard is je NFS mount per udp protokol

probeer in dat webinterface bij de mountmanager het TCP aangevinkt

 

enkele randapparatuur in je netwerk kan (KAN) udp blokken of minder goed doorgeven, dat zou met TCP misschien beter kunnen.

 

chiao

[Gast miknic]

ook als ik TCP aanvink is er geen verschil, het beeld blijft schokkerig. Ik heb ook voor de zekerheid van beide boxen de actueelste image geïnstalleerd.

 

Maakt het trouwens nog uit voor de mount dat beide boxen op een verschillend image draaien?

Of kzou het hele probleem komen doordat een enigma1 box aan een enigma2 box wordt gehangen?

[Tonskidutch]

de mount is ook netwerk afhankelijk

maar

indien in een der images een NFSserver, NFSclient of samba hobbel zit is dat evenwel ook debet aan de problemen maar ik geloof dat Pli en Gemini daar niet door bevangen zijn

 

betreffende het netwerk kan een en ander weldeglijk behoorlijk storen;

kabels

kabels verkeerd aangelegd langs sterk storende bronnen

switch

router

bandbreedte door alle LAN gebruikers

etc

 

ik weet niet wat ik je anders nog moet advieseren anders dan de hosts invullen in bede machine en alle twee herstarten (de NFS server als eerste)

of eens alle mountmanager instellingen weggooien

en het met de fstab methode proberen nadat je de dreamboxen opnieuw hebt herstart

Code:

IP_NFSSERVER:/hdd/movie /media/hdd nfs rw,nolock,rsize=8192,wsize=8192 1 0

na de edit van de client moet die nogmaals herstarten.

 

chiao

[Tonskidutch]

oh ik lees overigens dat er iemand bij IHAD een script fout heeft ontdekt die ook in andere images ZOU kunnen zitten

 

Citaat:

Hallo,

 

auf meiner DM800 mit Gemini 4.1 funktionierte der NFS-Server nicht. Den kann man ja äußerst praktisch mit dem Blue Panel konfigurieren und starten - nur leider konnte ich von meinen PCs aus nicht mounten. Die Fehlermeldung lautete: mount to nfs server 'rpcbin' failed: RPC Error: Program not registered.

 

Ein "rpcinfo -p dreambox" zeigte nur portmapper als RPC-Programm an. Tatsächlich müssen sich auch noch mountd und nfsd zeigen, damit man per NFS mounten kann.

 

Nachdem ich mich hier im Forum schlau gemacht hatte, habe ich die Schritte in dem Script /usr/script/nfs_server_sript.sh manuell in der Konsole ausgeführt. Nach einigem Probieren habe ich zwei Probleme festgestellt.

 

1. Eine Datei namens /var/lib/nfs/etab wurde vom nfsd vermisst. das Programm startet zwar, funktioniert aber nicht, ich nehme an, weil es nicht als RPC-Programm registriert wird. Ich habe in Zeile 43 ein weiteres touch, eben auf diese etab, eingebaut. Danach startete das Script nfsd korrekt.

 

2. Die Variable MOUNTD_PORT_ON in der Config-Abteilung am Anfang des Scripts habe ich auf 0 gesetzt, damit weiter unten das Programm mountd ohne den Port (-p) Parameter augerufen wird. Obwohl das nach Manpage ein zulässiger Parameter ist, klappt es nicht. Ich habe mountd auch auf der Kommandozeile nach der Script-Ausführung nicht mit "-p 2049" starten können. Nun ist 2049 aber ohnehin der Defaultwert und man kann den -p-Parameter einfach streichen.

 

Mit diesen beiden Änderungen klappt das Script auf meiner Dreambox. "rpcinfo" auf meinen PCs zeigt jetzt auch alle erforderlichen Programme auf der Dreambox an und das mounten funktioniert.

 

Gruß

 

jo

met dank aan jo-ken

 

als je dat eens in je dm 7025 analyseert?

 

chiao

 

dat kun je dus wel even checken...

 

[Gast MiLo]

Origineel bericht van: miknic

Het zal ongetwijfeld met het netwerk te maken hebben maar ik dacht dat een theoretische snelheid van 80 mbs genoeg moest zijn voor een vloeiende beeld weergave.

Langzamer was waarschijnlijk beter geweest, ik kreeg met Wifi stukken makkelijker goed beeld wanneer ik hem op "b" mode zette. Een input buffer van 4 seconden was nodig om met VLC fatsoenlijk beeld te krijgen op "g" mode, terwijl met een kabel een buffer van 0,1 seconde al genoeg is.

Probleem is waarschijnlijk het "burst" karakter van de verbinding. Wifi heeft daar ook vaak last van. Hij stuurt nu -een beetje overdreven- in 1 seconde alle data, en dan 4 seconden niks. De dreambox kan dat niet verwerken, zo'n grote buffer heeft hij niet, dus heb je stotterend beeld.

Probeer het eens met een kabel (cross cable tussen de twee aansluiten) en kijk of het dan wel goed is. Hoef je niet verder te zoeken.

[Gast MiLo]

Ik kan niet voor andere images spreken maar in de NFS server van openEmbedded zit een lastige bug bij installatie. Hij moet namelijk ook "portmap" en "portmap-utils" installeren, en die afhankelijkheid werkt niet goed. Ik heb hem in mijn image maar deels kunnen fixen, maar vaak gaat hij bij installeren eerst de NFS server starten en dan pas de portmap. Het starten van de NFS duurt dan een halve minuut ofzo, en dan werkt hij niet. Uninstalle en reinstall en dan werkt hij wel goed. Op MiLo-image werkt hij 100% als je eerst "ipkg install portmap" doet voor je de NFS server plugin download.

 

Voor andere images zou je dit kunnen proberen:

 

ipkg install portmap portmap-utils

ipkg install nfs-utils

 

 

[Tonskidutch]

in dat verband zoals jij schrijft zijn dependencies en dus de afhankelijkheden evenzeer een issue als enkel en alleen lukraak opstarten en installeren.

 

er schijnen bovendien CIFS mounts te laat en dus ongeldig te worden aangeroepen bij automount procedures zo als andere dependencies (afhankelijkheden) die nog niet zijn doorlopen

 

maar ook het udp tcp gedrag inzake de verzonden pakketten op zoek naar een netwerkapparaat kan via dns zomaar effe naar WAN gaan ipv intern LAN blijven

als je een hosts file in die oudere versies van linux niet hebt ingevuld komt een via de dns gaan vaker voor dan ik analytisch en verklarend kan weergeven.

 

chiao