Soll auch in der Dream 800/8000 funzen
wechseln in den ordner
/lib
sichere aber deine originale vorher
rechte auf 644
im ulc http://ulc.zebradem.com/filemanager.ph…Twin/Programme&
Soll auch in der Dream 800/8000 funzen
wechseln in den ordner
/lib
sichere aber deine originale vorher
rechte auf 644
im ulc http://ulc.zebradem.com/filemanager.ph…Twin/Programme&
Das ist ne ganz ganz schlecht Idee, denn das ist eine lib von der DM800, die macht in der DM8000 mit OE1.6 image oder auf der VU+ große Probleme...
Der Fix muss von den CCcam Machern kommen.
Du solltest aber auch dabei schreiben das das nur für die OE 1.6 Images ist ;).
Was nebenbei bemerkt bei der Vu+ noch viel zu buggy ist.
Bin erst mal wieder zum 1.5er zurück.
cu
Stimmt ist für OE 1.6 Images, aber auf meiner Vu+ funzt es.
Ich hab das VTi "Vu+ Team Image" - V 2.0 - 19.08.2010 OE 1.6 auf der Box und muss sagen ich hatte noch keine Probleme.
Das funktioniert schon, aber die lib ist von der DM800 und es keine gute Idee, die auf der DM8000 zu nutzen oder halt VU+, denn es kann alles extrem instabil werden.
Erklärung aus IHAD:
ZitatAlles anzeigenHi,
das ganze ist ein Problem dadurch, dass die neuen Toolchains (Compiler / core libs) im 1.6er OE bei der dm500hd und dm8000 nicht mehr gleich sind zu dem der dm800.
Die dm500hd und dm8000 benutzen die Hardware FPU für Berechnungen mit Kommazahlen.
Das alte binary was da benutzt wird (ccamd) ist mit der OE 1.5 Toolchain kompiliert worden. Für ohne Hardware FPU. Damit läuft es dann im 1.6er OE für die DM800 fehlerfrei weil das Rückwärtskompatibel ist.
Auf der DM8000 und DM500HD aber nicht. Die ABI ist da einfach verschieden.
Allerdings stellt sich da die Frage wieso da nur zur Berechnung einer ECM Zeit überhaupt mit Kommazahlen hantiert wird. Wenn man sich nicht sonderlich doof anstellt, sollte sowas problemlos auch mit Fixen Zahlen funktionieren. Also ohne mit Berechnungen mit Kommazahlen ausführen zu müssen.
Das austauschen der libgcc ist ein sehr schlechter Workaround. Damit werden dann Plugins die viel Gerbrauch von der FPU machen dann sehr langsam.
Die beste Lösung wäre, wenn das im ccamd gefixt wird. Also den entsprechenden Code umbauen, so dass keine double/floats.. was auch immer benutzt werden. Und dann wenn es wirklich auf allen Boxen in jedem OE noch laufen soll mit dem alten 1.5er OE zu kompilieren.
Code der mit der 1.6er Toolchain kompiliert wurde, wird nicht mehr in einem alten 1.5er Image funktionieren. Was aber über kurz oder lang dann auch egal ist.
und
Zitatim prinzip verwendet das ganze system die fpu.
wenn du die deaktivierst, wirst du merken, dass halt alles n bissl langsamer geht.
was sicher nicht mehr gehen wird, sind sehr rechenintensive sachen, wie zB der dts-downmix.lass doch einfach so wies ist, soooo überlebensnotwendig ist die doofe cccam ecm zeit zu kennen ja wirklich nicht, und wenn doch, stell doch auf oscam um, die kann auch cccam client und server sein, und bei der funst die ecm zeit!
Naja, mal abgesehen von einigen anderen Schwächen ist das Image für mich erst wieder interessant wenn es den NFS Server dafür gibt. Den brauche ich nun mal.
cu
Ich habe die Datei die Hausi hoch geladen hat auch mal ausgetauscht(orginal gesichert)
Hardware DM 8000 mit OE1.6
Newnigma 3.01
Gemini 5.01
Rennt seit 4 Tagen ohne wenn und aber und bekomme wieder ECM Zeiten
klar, dass du ECM Zeiten bekommst, aber du musst natürlich auch damit leben...
ZitatDas austauschen der libgcc ist ein sehr schlechter Workaround. Damit werden dann Plugins die viel Gerbrauch von der FPU machen dann sehr langsam.
Versuch macht klug
Ich nutze die libgcc der 800er auf meiner 500HD seit ich 1.6er Images (Newnigma) auf der Box habe.
Habe noch keinen Nachteil oder Performanceeinbussen bei den von mir genutzten Plugins feststellen können.
Also einfach probieren bis eine andere Lösung (Anpassung der CCcam) da ist.
Wenn´s nicht rund läuft nimmt man eben wieder die originale libgcc.
cu
So hab jetzt auch lange getestet, bin wieder zurück zur orginalen.
Hatte echte probleme mit mkv dateien einige konnte ich schauen einige nicht, mit der orinalen libgcc_s.so.1 funzen alle mkv videos
Mit ein Grund warum ich immer noch das OE 1.5 Image (VTI 1.3) nutze.
Da stellt sich das Problem mit der lib erst gar nicht ;).
cu
Seit CCcam 2.2.0 ist das Ersetzen der lib nicht mehr notwendig.
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!