[Info] Status Treiber und Features (Stand immer wieder aktualisiert)

Nachricht

#641

Was sollen die denn da tun wegen der SSD Geschwindigkeit?
Ich glaube da wird nix gross möglich sein da mehr Tempo rauszuholen (die Schnittstelle gibt eben das her was sie hergibt).

Grüsse
Pike

#642

Denk auch nicht das es was mit treiber zu tun hat.
Routinen sitzen standart im kernel

#643

Ein Test mit jbleyel hat laut seinen Angaben damals schon gezeigt das da noch Möglichkeiten sein sollten.
jbleyel hatte damals meine mit seiner Hilfe erstellten Testergebnisse direkt zu den Zuständigen gesendet.
Und jbleyel sollte sicher wissen wovon er spricht ;-)

Gleiche Geschwindigkeitsdefizite sind ja auch bei der OctagonSF8008 und da ja per USB 2/3 mit externer SSD.

Problem des Schnitteditor ist laut @Captain auch schon länger von ihm an die Zuständigen gemeldet worden.

Erinnert mich leider wieder an die Zeiten der OctagonSF 4008 , glaube so hieß die Problembox damals.

MfG

#644

sf4008 und sf8008 sind in vielerlei Hinsicht nicht zu vergleichen.

Beschränkend auf USB-Schnittstelle und Hisi ist die Umsetzung USB3 doch seit langem als etwas hakelig bekannt.
Da gilt es einfach den Kompromiss zu finden wo die potentielle Performance nicht die Stabilität negativ beeinflusst.
Was nutzt dir ein theoretischer Wert eines Speedtest, wenn nach kurzer Zeit der USB3 Übertragung diese selbst einbricht wegen der Fehlerkorrektur.
Was bleibt ist eben ein USB3, der etwas mehr kann als ein USB2, aber eben niemals an die Leistung eines PC-USB3 herankommen wird.

#645

kueken hat geschrieben:Was bleibt ist eben ein USB3, der etwas mehr kann als ein USB2, aber eben niemals an die Leistung eines PC-USB3 herankommen wird.

Ich kann diese Schlussfolgerung nicht teilen.
Es geht um Prozessorgeschwindigkeit, Mogibits, Kerne usw.
Ob es ein x86-Prozessor oder ein Arm ist, spielt für den Kernel keine große Rolle.
Wenn der Kernel mit einem kaputten Compiler kompiliert wurde und nicht richtig funktioniert, liegt das am Compiler und nicht am Prozessor.

#646

Daher schrieb ich ja das sich jbleyel auch so geäußert hat das da noch was optimiert werden könnte.
Auch hatte ich hier 3 Probleme genannt.
Zum Beispiel auch aktiver Hub nötig und Schnitteditor-Funktion.

#647

listener hat geschrieben:Wenn der Kernel mit einem kaputten Compiler kompiliert wurde und nicht richtig funktioniert, liegt das am Compiler und nicht am Prozessor.

und das heißt was?
Woher weißt du dies?
Um welchen Kernel und um welchen Compiler geht es?

Ich verstehe inhaltlich nicht worauf du hinaus willst.

#648

kueken hat geschrieben:und das heißt was?
Woher weißt du dies?
Um welchen Kernel und um welchen Compiler geht es?

Ich verstehe inhaltlich nicht worauf du hinaus willst.

40 Jahre Programmiererfahrung
ab 6502 z80 8080 über x64 plc embedded.
Ich weiß, was ich sage

#649

puh...
Das überzeugt mich nicht.
Aber du wirst ja dann bald die Lösung ins Git bringen, denn du scheinst deinen Äußerungen nach genau zu wissen wo das Problem sich befindet.

Grüße

#650

Nein
Bin mit anderen lustigen Dingen beschäftigt
Ob ich einen PR mache, weiß ich nicht, ein PR ist überschrieben
worden Was ich nicht mag.
Das Kodi-Team kann mich für Erweiterungen kontaktieren

#651

listener hat geschrieben:...
Das Kodi-Team kann mich für Erweiterungen kontaktieren

Das schriebst du bereits.
Da wir überhaupt kein"Kodi-Team" haben, wird das NIE passieren.
Das ist auch der Grund, warum es hier nur einen "Kodi-Sammler" gibt.
Da dürft ihr gern legale Dinge diskutieren. Aber echten Support gibt es möglicherweise in einem Kodi-Forum.

#652

Ok danke fuer die neue info
Captain poste hier das kodi-team mein PR ueberschrieben hat.
Alle software is legaal der benutzer kan illegale sachen machen.
Ich benutze kodi um zu streamen von mein gb4k und dateien abspielen.
Ich finde es schoen um neben enigma2 auch was anderes mit meiner box
zu tun.
Wen ich auf github schaue was mit kodi angepast is komt fast immer cantain

#653

Gut.

Und hier geht es ja nicht um Kodi und die Anpassungen die ich auch von dir im git nie gesehen habe, sondern um Treiber von Octagon.
Hier hattest du behauptet der Compiler und der Kernel und sonst was seinen dir klar, das die fehlerhaft sein.
Des weiteren erweckst du den Eindruck,d as du genau wüsstest was dort defekt sei.
Des weiteren erweckst du den Eindruck, das dies für dich mit all deiner "Erfahrung" ein Klacks wäre dies zu reparieren.
Aber du reparierst es nicht, weil du lieber alle damit beschäftigst mitzuteilen, das dies alles ja ein Klacks sei dies zu reparieren.
Wir befinden uns hier im OpenSource!
Wer eine Idee hat, der macht ein Commit im git und dann geht es weiter..

Weder mir noch sonst jemanden nutzt dein angebliches Wissen etwas, wenn du es nirgends zeigst.
Wenn man dich direkt kontaktiert, dann fragst du das was du angeblich weißt, wie man es einfügt.
So zumindest bei Kodi.

Also zeige doch bitte wo hier der Compiler bzgl USB3 und oder dem Anschluss des Verbindung zum Kernel der Hisi hier einen Fehler hat.
Vor allem um welchen "Compiler" geht es deiner Meinung nach?

#654

nana
es geht um treiber.
treiber sind meistens kernel module.
der kernel
in december ist der build enviroment angepast.
der compiler konte der kernel nicht compilieren.
da haben die im kernel assembler code
eine aenderung gemacht sodas der compiler wieder
durchlauft.
seit december lese ich nur problem die
mit kernel und treiber zu tun hat.
random finden von block devices.
alsa functioniert nicht mehr und
mehr.
da ist jetz was faul.
usb lauft auch ueber den kernel.
in die ecke mus es gesucht werden
wen es schlecht lesbar ist sorry hab mit telefon geposted

#655

Und nochmal mein Senf dazu.
Habe damals mehrere Tests zur Festplatten-Geschwindigkeit gemacht wegen interner ssd bei OctagonSF8008 SUPREME und auch mit OctagonSF8008 USB2 und auch 3 mit externer SSD.
Habe dafür einige Zeit zusammen mit jbleyel investiert.
Somit eigentlich auch für esmos und seinen Spezis in Asien.
Wobei ich sehr bezweifle ob das Spezialisten sind ;-)
Wahrscheinlich nur halt billig ;-)
Alles nach jbleyel seinen Vorgaben.
Diese Auswertung hat jbleyel direkt an die Entwickler weitergeleitet.
Bis Dato keine Reaktion bzw Änderung.
Und nochmal , jbeyel ist nicht irgendwer hier im oatv sondern für mich der eigentliche Imagespezialist allgemein.
Und wenn er sagt das da noch einiges an Performance möglich wäre, glaube ich ihm zu 100 %.

#656

Habe dafür einige Zeit zusammen mit jbleyel investiert.

Demnach bist du ja im Besitz eine inofffiziellen Treibers der dann ja irgendwas kann, was der aktuelle Treiber nicht kann.
Zum Einen hätte dies ja für dich die Vorteile, das du über angeblich größere Performance der Schnittstelle (USB3) verfügst und zum anderen würde dies auch heißen, das es nicht mit irgendwelchen Kernel oder Compiler Ideen zu tun hätte.

Mir bleibt wirklich nur ein Achsel Zucken zurück.
Die sf8008 ist ne gute Kiste und der USB3 war immer bekannt als vorhanden, aber eben nur bedingt leistungsfähig.
Interne SSD Anbindung hätte ich daher nie als LeistungsHighlight gesehen, sondern eben als eine tolle Sache es nicht selber rein zu basteln.

Ist ne gute Hisi und für den Preis ein Schnapp.
Andere aktuelle Dinge gibt´s halt gerade nicht.

Sie werden aus meiner Sicht kaum einen verbesserten Treiber bzgl Performance freiwillig zurück halten.
Aber ich kann mich ja auch irren.

#657

Wer hat was gesagt von einem anderen Treiber, Testtreiber.
Ich habe davon nichts geschrieben.
Wir haben von beiden Boxen diverse Werte ermittelt mit dem was aktuell vorhanden war.

@kuecken,
Richtig lesen was geschrieben wurde scheint nicht Deine Stärke zu sein.

#658

Es gibt sehr viel zu verbesseren in die openatv images bei die treiber.
Die E2 boxen ist ein sehr altes concept basiert aud linuxtv (LinuxTV.org - Television with Linux)
Momentaan probleem beim kernel vermute in multitask slicer
Ich gehe nicht daaran arbeiten habe in dei 1990 iger genug fuer den kernel geschrieben.
Die gles treiber sind eine katastrofe und bei die meisten boxen das man den eindruck bekomt
das die source under die hersteller ausgetauscht werden.
Wen ich die source bekomme wil ich es mal ansehn.
Das die treiber besser koennen kan man sehn in raspberry und android die den gleichen soc benutzen

Boostracerking · #659

kueken hat geschrieben:puh...
Das überzeugt mich nicht.
Aber du wirst ja dann bald die Lösung ins Git bringen, denn du scheinst deinen Äußerungen nach genau zu wissen wo das Problem sich befindet.

Grüße

Wenn der User @listener solange Erfahrung hat. Dann wird er sich auskennen. Ich denke du hast nicht so viel Erfahrung. Außerdem sollten das die Receiver Hersteller beheben. Den die bekommen das Geld. Die sollten ja die Fehler an das geweillige DEV Team leiten und dafür sorgen das sie die Fehler beheben.

Wenn der Entwickler @jbleyel schreibt da könnte man noch was Optimieren, dann muss es auch stimmen.

Also gleich 2. Entwickler sagen, dageht viel mehr. Nur der Hersteller und das Team muss sich halt die Arbeit machen, nicht weglaufen von Arbeit.
Man muss halt Richtig Programmieren. Die meisten Hersteller Kopieren sich den Code und fertig. Aber das reicht nicht. Der Code muss komplett überarbeitet werden.

Egal wie oft man im Image Optimiert reicht es nicht. Wenn die Geräte Treiber nicht dafür Optimiert werden für das jeweilige Gerät, dann wird da nicht viel änderung kommen.
Der Kernel läuft auf 4.4.35 Der Kernel wird nicht mehr im Linux.org supportet.
Heutzutage bringen Hersteller unfertige Geräte auf dem Markt oder auch Software, und denken sich, dabei das wird schon passen aber das geht leider nicht so, den spätter kommen die Probleme. Es wird an der Entwicklung gespart.

#660

das wird alles absurd lächerlich hier....
Sind wir bei MonthyPython?

Was weißt denn du?
"ich denke....."
Schön, toll, das ist doch schon mal ein Anfang, ein Schritt in die richtige Richtung.
Die meisten schaffen nicht mal mehr das.
Jetzt nutze deine Fähigkeit des Denkens dazu ins git zu gucken und suche die drölftausend Commits des aus deiner "Denke" betreffenden Users.

Ach ihr macht das schon.
Ihr schafft das.