Hmmm dann suche ich mir auch mal ein Image dass auf 3.1.0 basiert, für die DM8000 sollte dies wohl kein Problem sein, aber bei der DM7020HD dürfte es ein Problem werden.
Danke auf jeden Fall für das Feedback.
Hmmm dann suche ich mir auch mal ein Image dass auf 3.1.0 basiert, für die DM8000 sollte dies wohl kein Problem sein, aber bei der DM7020HD dürfte es ein Problem werden.
Danke auf jeden Fall für das Feedback.
Noch kurz eine Frage und zwar schreibst Du dass es mit dem
OoZooN-Image-dm8000-20111028
Image wieder sauber läuft, basiert dieses Image dann noch auf 3.1, sprich ist dass das letzte Image dass auf 3.1 basiert?
Kannst Du mir vielleicht auch sagen ob das folgende Image für die DM7020HD
OoZooN-Image-dm7020hd-20111028
ebenfalls noch auf 3.1 basiert, falls ja könnte ich nämlich dieses mal bei meiner DM7020HD versuchen.
Vielen Dank
Ich hab leider keine 7020hd und kann dazu leider nix sagen.
Mach dir doch erst mal mit dflash ein Backup, kopier das dann auf den PC (falls man nicht mehr an die Box rankommt :D)
Dann kannst du doch in Ruhe mal das Ozoon ausprobieren.
Okay, aber bei der DM8000 ist es so dass das OoZooN-Image-dm8000-20111028-Image noch auf 3.1 basiert?
Kann ich dem Fall also einfach das Image installieren und anschliessend das GP3 Plugin installieren und dann ist wieder alles wie gehabt?
Gruss
OoZooN-Image-dm8000-20111028
Hier kommt ein neues DM8000 Image aus dem Enigma²
"experimental" OE 1.6 zweig.
Enigma stand ist 28.10.2011 die plugins sind vom 28.10.2011
die treiber vom 02.09.2011
neuer kernel 2.6.18-r14.1
secondstageloader ist 84
ist kurz nach dem Zeitraum wo das E2 3.2.0 veröffentlich worden war
Bin jetzt etwas verwirrt, vom Datum her dachte ich auch dass es ja eigentlich auf 3.2 basieren müsste, doch als "gruftolm" davon geschrieben hat, war oder bin ich nun nicht sicher ob es nun auf 3.1 oder 3.2 basiert.
Nach mir war doch das
experimental-dm8000_20110928.nfi
das letzte Image dass auf 3.1 basiert hat, oder liege ich da falsch?
Gruss und Dank
da weiss ich auch nicht mehr
Ich hatte diese experimental geflasht auf der 8K und updates gemacht und bin heute auf dem Stand 27.11.2011 (also 3.2.1 experimental) .. und da habe ich keine Ruckler beim Streamen
von den Qnap's ...
Habe ich Dich korrekt verstanden Du hast im Moment dieses Image auf Deiner DM8000?
experimental-dm8000_20111127.nfi
Und damit hast Du über NFS keine Ruckler mehr?
Gruss
nein nicht das DMM experimaental !
das OoZooN-Image-dm8000-20111028 experimental und die Updates gemacht
ich hatte noch nie Ruckler ... alle mounts in auto.network angelegt ...
Ah okay vielen Dank.
Ich sehe jedoch schon dass man wohl einige Images durch testen muss bis die Sache wieder klappt.
Also ich hatte bis vor kurzem immer direkt auf die HD aufgenommen und wollte nun auf die NAS-Aufnahmen umstellen und dazu habe ich zuerst auf beiden Boxen das Script (von der ersten Seite) ausgeführt und anschliessend meine NFS-Mounts entsprechend erstellt und dachte dass es dass dann war. Leider musste ich bei meinen ersten Aufnahmen feststellen dass es vorallem bei HD-Aufnahmen zu Rucklern kam. Mir war dann auch nicht klar liegt es an der Aufnahme, sprich hatte die schon Ruckler oder kamen die Ruckler erst durch das abspielen.
Ja und da ich von den Aufnahmen auf ein NAS überzeugt bin, suche ich natürlich nun eine Variante die die Aufnahmen wirklich sauber auf mein NAS (Synology DS509+) über Gigabit Ethernet schreibt.
Gruss
Zur Info:
Mein Post von vorhin im DMM Board:
__________________________________________________
So ich habe folgendes gemacht:
Hardware: DB8000 über Netgear-GB-Switch am QNAP 419P+
1. experimental-dm8000_20111130.nfi frisch geflasht
2. Grundeinstellungen durchlaufen Standard Kanallisten etc. (keine Settings etc. zurückgespielt, hatte ich bei früheren Tests übrigens auch nicht gemacht)
3. In auto.network NFS Freigabe eingetragen "Video1 -fstype=nfs,rw,soft,nolock,tcp,rsize=16384,wsize=16384 192.168.5.5:/Video1 > Neustart
Ergebnis: keine Ruckler mehr, auch nicht bei Bluray-Rips
Diese Einstellungen hatte ich aber auch früher getestet (mit exp. vom 21.11.2011), da hat es noch geruckelt.
Hab jetzt noch GP3 installiert einige Plugins etc
Ergebnis: Läuft einwandfrei keine Ruckler mehr
hast Du irgendwas an der NFS-Performance gemacht ?, da ich immer genauso wie oben beschrieben getestet hatte und es hat definitiv extrem geruckelt.
in den ganzen Changelogs an den Images wird ja leider nichts eingetragen (kann man dann eigentlich auch wechlassen )
Fazit: Alles ist wieder gut... THX
_____________________________________________________--
Ich bekomme das schripts nicht ans Laufen.
Hier die Fehlermeldung in Telnet:
root@dm800:/tmp# ./test.sh
: not foundline 21:
: not foundline 22:
: not foundline 26:
expr: non-numeric argument
./test.sh: line 39: syntax error: unexpected word (expecting "do")ptname.sh
Was mache ich falsch?
So sieht der zu editierende Teil meines Scripts aus:
ZitatAlles anzeigen#!/bin/sh
# IP of your NFS server
serverip=192.168.0.35
# exported directory on your NFS server
exportdir=\dreambox\nfs\Timeshift
# mount point on dbox
dboxmountpoint="/media/timeshift
# filesize to transfer in MBytes.
# At least 8 MByte. Good values are 32 or 64 MByte.
# Try 128 to be more accurate (takes much longer!)
filesize=64
# block sizes to test in KBytes, possible values are 1 2 4 8 16 32.
# values have to be separated with spaces. See examples below.
# blocksizelist="4 8 32"
# blocksizelist="16"
blocksizelist="4 8 16 32"
# wether to enable synchronous reading, writing. Possible values are "yes"
# or no. Normally synchronous reading or writing should be slower than
# asynchronous, so to save some time most people would say "no" here.
enablesynctests="no"
Hallo,
ich hatte früher auch schon mal mit diesem oder einem ähnlichen script so meine Probleme.
Kürzlich hatte ich dann nfstest aus dem bluepanel benutzt, damit hatte es dann geklappt.
Viele Grüße
ZitatOriginal von AltGr
Ich bekomme das schripts nicht ans Laufen.
Schuss ins Blaue anhand Deiner Meldungen: Hast Du eventuell falsches Zeilenende (also DOS) in der Datei? Bitte per ASCII FTP auf die Box übertragen oder auf der Box mit einem UNIX Editor anlegen.
Die test.sh habe ich mit pspad erstellt. Also Linux.
Hier die Fehlermeldung.
root@dm800:/tmp# ./test.sh
: not foundline 21:
: not foundline 22:
: not foundline 26:
expr: non-numeric argument
./test.sh: line 39: syntax error: unexpected word (expecting "do")
root@dm800:/tmp#
Den Text habe ich aus Posting 1 über Copy & Paste in PSPad eingefügt.
also meine geht, probier mal testweise
aber anpassen nicht vergessen
Vielen Dank, das hat geklappt.
Hier das Ergebnis:
Results for write throughput:
28.256 Mbit/s with tcp,async,wsize=32768
26.843 Mbit/s with udp,async,wsize=8192
26.843 Mbit/s with udp,async,wsize=32768
26.843 Mbit/s with tcp,async,wsize=8192
26.843 Mbit/s with tcp,async,wsize=4096
25.565 Mbit/s with udp,async,wsize=4096
25.565 Mbit/s with udp,async,wsize=16384
25.565 Mbit/s with tcp,async,wsize=16384
Results for read throughput:
16.268 Mbit/s with tcp,async,rsize=32768
15.790 Mbit/s with udp,async,rsize=8192
15.790 Mbit/s with udp,async,rsize=16384
15.339 Mbit/s with udp,async,rsize=4096
15.339 Mbit/s with udp,async,rsize=32768
15.339 Mbit/s with tcp,async,rsize=8192
15.339 Mbit/s with tcp,async,rsize=4096
15.339 Mbit/s with tcp,async,rsize=16384
Was nehme ich jetzt, damit Timeshoft ohne permanente Ruckler läuft?
Die Werte sind ja nicht berauschend. Oder kann das daran liegen, dass gerade ein HD-Sender läuft?
tcp und 32768?
kannst du doch ganz einfach testen wenn du umschaltest - aber berauschend sind deine werte wirklich nicht!
wenn du mein ergebnisse vergelichtst, das ganze per wlan!
bist du dir sicher das da was nicht stimmt?
ansonsten wäre tcp 32768 schon das beste, nur eben viel zu wenig!
Ich würde ja glauben, dass es am NAS liegt, wenn es nicht so wäre, dass es bei der Dream 500 HD keinerlei Probleme mit Timeshift gibt.
Ich bin ratlos.
teste doch einmal das ganze bei der 500hd und noch bei der 800er auf sd oder im standby per telnet
zur Zeit sind 35 Mitglieder (davon 6 unsichtbar) und 1.814 Gäste online - Rekord: 5.681 Benutzer ()