anudanan

Der dvb_aoi user ist nur in der Gruppe 1 und kann daher nicht auf die ORF Karte zugreifen, da diese nur in group 2 ist.

Du kannst zwei Wege gehen

bei dem dvb_api Eintrag 

group = 1,2 anstatt group = 1

schrreiben oder im QRF Reader in der oscam.server

group = 1 anstatt group = 2

schreiben

Das geht auch über die oscam WEB GUI. Nach den Änderungen am besten oscam neu starten oder die Box neu starten

On my et9200 with openpli 4.0 it works fine

Or maybe the reason for the check in httpserver.py is that exactly if streaming with auth is enable and the streamingservice must be requested with auth (user/pw auf passwd user or transient users). That means streamproxy must give the user/pw given in the URL from the client to OWIF if streamproxy requested the service

I use on my uno4kse a shell script

/etc/init.d/rcS.local

openpli starts that on systemsstart (with /etc/inittab) with a last link S95local in the rcS.d directory

You must only create the /etc/inid,d/rcS.local as a script file and set it so executable

It works perfectly on my system

Ja, man muss sich die blaue Taste da wieder selber komplett zusammenbauen, wenn man diese belegt. Also PIP use, aber das geht. Sobald man mehr als eine Funktion auf eine Taste legt, dann wird ein Auswahlmenu angezeigt, was man genau machen will

Du kannst unter Menu/Einstellungen/Experte/Tastenbelegungen die Tasten belegen. 

Ich glaube, die blaue ist da nicht belegt, sondern benimmt sich in Standard so, dass dort das Erweiterungsmenu angezeigt wird

Wenn du die aber belegst, kannst du da auch mehrere Dinge drauflegen, das geht bei jeder Taste. Dann kommt immer ein Menu, wenn man eine Taste mit mehreren Funktionen belegt

Beim openPLI wird die Info über die Festplatten so zusammengebaut, wie du das bei dir gesehen hast.

Das wird hier in der About.py erzeugt

https://github.com/O...creens/About.py

Das kann bei anderen Images anders sein. Enigma ist ja nicht gleich Enigma

Ich habs bei dem normale PLi-HD mal probiert. Da tut das jetzt auch mit schwarz in der 1. Infobar

In der skin.xml vom PLi-HD steht für die Infobar

Da steht vermutlich

backgroundColor="transparent" 

Da kannst du 

backgroundColor="black"

reinschreiben. Das Schlimmste was passieren kann ist, dass du bei einem Tippfehler dann einen Greenscreen bekommst. Um den zu beheben dann wieder die alte skin.xml dahin kopieren. Achte auf Gross-/Kleinschreibung

Also vorher immer die funktionierende sichern

Vielleicht habe ich heute abend noch was Zeit, mir die skin.xml in dem Skin mal anzuschauen und bei den beiden Infobars die Transparenz rauszunehmen. Soll das dann einfach schwarz undurchsichtig  im Hintergrund der beiden Infobars dann sein?

Welche my PLIHD skin.ipk war das genau? Dann installiere ich die mal auf meiner Box und schaue mal, was ich da ändern kann.

In den Systemeinstellungen und A/V kann man noch die OSD Transparenz einstellen, Ändert das bei deinem Skin etwas?

Notfalls kann man sicherlich noch in der SKIN Datei selber die Transparenz abklemmen, falls es keinen anderen Weg gibt. Da muss man aber eine skin.xlm Datei im Verzeichnis /usr/share/enigma und dann im passenden Skin Order ändern. Da gibt es einen Screen Infobar, wo das sicherlich änderbar ist

After many tests with nice and different clustersizes if have found from my point of view the true reason for the poor /O performance to/from the hdd if the box make many write and read operations to/from the drive

The actual I/O scheduler for block devices like drives has tree methods to schedule the orders to the disk

NOOP. easy fifo method

dreadline: different queues and sortings for matching the sector numbers and some deadlines to prevent starving of drive orders

cfq : faire schedule based am time slices for different processes. This is the default scheduler

you can see the setting with

cat /sys/block/sd*/queue/scheduler

I don´t know exactly why cfq doesn´t work so efficient for the enigma box application if I make many recording in parallel to mcut and mv/cp commands but fact is, the i/o load is between 80-100 percent,  if you use massiv write and read operation, but the write transferrate to the disk is often poor. The idle load often is zero Sometimes you see only some Mbyte/s write performance to the hole drive for all recordings if you make mcut on mv/cp in parallel to the recordings. Maybe the timeslice doesn´t match the real time requirement of recording jobs. The result are interrrupts in the recordings and a poor GUI responsibiltiy. That is not what I expected from a modern box

Now I´ve tested the method  deadline. Setting is possible on runtime with

echo deadline >/sys/block/sdx/queue/scheduler

sdx = sda,sdc,sdc ...

for each drive

The result is phantastic: The box doesn´t make interrupts in the recordings if other jobs make massiv read operations. The reaction of the GUI ist much more better than with cfq.

For example with the cfg schedule if you are in the movielist and you select a movie which is recording in background (many records are running), very often you see a spinner or it needs time to show the size of the file. Now with deadline scheduler it is very quick. No waitings. I´ve seen that waitings also on my old et9200 box, They also use cfq scheduler but there it works better., I don´t know why cfg works better an MIPS than on ARM.

I´ve tested deadline with 14 parallel recordings and a cutting queue with mcut for other movies and moving movies with mv command (from EMC). The recording jobs now write all there datablocks to the disk and mcut and mv/cp get the restpower of the box for disk I/O. The command top now shows very often higher idle loads for the two cores and the I/O load is in a expected range

The problem with cfq are on all images. I´ve tested VTI, openATV and openpli. All use the same 4.1.20 kernel for unokse.

Now with the solution deadline I´m very happy and the box works as I expected. Other users may testet it and if all are happy, it would be great if the openpli  team will integrate deadline to the default scheduler during kernel compilation or later with startscripts on runlevel 

Zum Thema nodelalloc habe ich noch was getestet, da ich ja auch das Speicherzählproblem habe, aber im Grunde noch ein viel massiveres Performanceproblem mit der HDD hatte.

Erstmal zu Historie nochmal, ich mache dazu jetzt hier keinen neuen Thread auf. Ich werde das nochmal in englisch im passenden Thread MoveCut sometimes slow von mir erläutern.

Ich bin einen großen Schritt weiter in meinen ganzen Untersuchungen, warum die uno4kse und vermutlich auch andere Boxen immer so eine schlechte Performance haben, wenn man parallel viele Filme aufzeichnet, dann eine Schneidequeue mit MovieCut betreibt und noch Filme verschiebt (bei mir mit EMC und letztendlich dem Linux mv Kommand). Das war bisher bei der uno4kse nicht zu machen. Ständig gab es Aussetzer in den Aufzeichnungen, die Box war nur träge zu bedienen. Das scheint immer dann zu passieren, wenn neben vielen Schreibevorgängen auch noch Prozesse sehr viel lesen wollen (mcut, mv)

Insbesondere, wenn man im Filmmanager ( EM oder den eingebauten im openPLI) sich mit der Markierung auf einer Filmdatei befindet, in die gerade geschrieben wird, sich also vergrössert, habe ich sehr oft den Spinner gesehen, bis die Dateigröße angezeigt wurde. Das kenne ich von meinen älteren Boxen auch schon. Das Linux tool TOP zeigt dann auch immer an, dass die CPU Kerne sich fast nur noch im I/O befinden, obwohl die Gesamt-Transferrate zu der HDD teilweise zum Erliegen gekommen ist oder nur ein paar MByte/s beträgt und dann mal wieder hochgeht. Das hat mir keine Ruhe gelassen, weil ich einfach nicht eingesehen habe, dass diese modernen Maschinen das nicht besser hinbekommen können. Die notwendige Transferrate zur hdd für obige Aufträge sollten die eigentlich hinbekommen und insbesondere müssen ja die Aufnahmen verlustfrei geben. Die Restleistung der Box darf dann auf Schneiden und Verschieben gehen, aber nicht umgekehrt. Bisher wurden die Aufnahmen letztendlich von den anderen Schneide- und Verschiebeprozessen verdrängt.

Nach vielen Versuchen mit openpli, openatv, VTI kam das Ergebnis raus, dass die alle das gleiche Problem haben. Alle setzen auch auf Linux 4.1.20 auf.

Auch Versuche mit größeren Clustern auf der Platte, verschiedenen Mount Optionen, dem Verwenden von dem nice Kommando für mcut/mv haben alle keine echte Verbesserung geschafft.

Dann habe ich mich mit dem I/O Scheduler für die Block Devices, also die Platten geschäftigt.

Der im Kern eingebaute Scheduler kann drei Betriebarten, NOOP, deadline, cfq

https://www.thomas-k...x_I/O_Scheduler

Default ist cfq, der aber scheinbar mit der Applikation als Receiver nicht wirklich gut klar kommt, weil er jeder Applikation die gleich Zeit zukommen läst, unabhängig vom Datenaufkommen.

Ich habe dann mal deadline ausprobiert, kann man ganz einfach im Betrieb umstellen mit

echo deadline > /sys/block/sdx/queue/scheduler

sdx ist dann das passenden hdd interface, meist sda. Bei mehreren Platten muss das für jede eingestellt werden

Anzeigen der Einstellung geht mit

cat /sys/block/sd*/queue/scheduler

Die Wirkung was dramatisch. Die CPU-Core Load geht drastisch im I/O Bereich zurück. Die hdd zeigt vernünftige Durchsatzraten. Die Wartezeiten bei der Anzeige der Dateigrößen im Filmmanager sind weg. Überhaupt ist die Bedienung bei viel Plattenlast einfach wieder vernünftig flüssig.

Habe dazu nochmal 14 Aufzeichungen gemacht, parallel Filme geschnitten und Filme verschoben. Nun ist es so, wie erwartet. Die Aufzeichnungen bekommen ihre Daten auf die hdd geschrieben und die anderen Aufträge kommen auch noch dran, bekommen aber dann halt die Restleitung, was ja ok ist. Wenn nicht aufgezeichnet wird, geht Schneiden/Verschieben natürlich schneller

Bei dieser ganzen Aktion habe ich auch nochmal die mount option nodelalloc ausprobiert und die geht damit auch problemlos und damit ist es Workaround für das falsche Zählen des freien Plattenplatzes machbar.

Für mich gibt es damit folgende Empfehlung, die ich an das openpli Team weitergeben möchte

nodelalloc als mount Option kann eingebaut werden., Ich habe es in die fstab aufgenommen bei mir

der i/o Scheduler sollte von cfq auf deadline umgestellt werden. Entweder irgendwie im Kernelbau umstellen der nachträglich bei den startscripten der Userlevel (3-5) aufnehmen mit

echo deadline >/sys/block/..... (wie oben geschrieben)

Für mich war die Box nach diese Änderung nicht mehr wiederzuerkennen. Bin mal gespannt was meine Frau dazu sagen wird, die hat das noch nicht probiert, ist aber bei diejenige, die hauptsächlich die Box in dieser Hinsicht fordert.

Wer das auch mal probieren will, kanns gerne machen und Feedback geben, am besten dann im Thread im englischen Teil über moviecut sometimes slow