PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : build E2 with eplayer3



kader_73
09.04.2016, 23:47
hello;
Ii would like to build Enigma2 with only eplayer3 as a MFWORK ; and i had this error


CXX service/service_libenigma_service_a-servicedvbrecord.o
CXX service/service_libenigma_service_a-servicefs.o
CXX service/service_libenigma_service_a-servicemp3.o
In file included from service/servicemp3.cpp:14:0:
../lib/service/servicemp3record.h:7:21: fatal error: gst/gst.h: Aucun fichier ou dossier de ce type
compilation terminated.
make[5]: *** [service/service_libenigma_service_a-servicemp3.o] Erreur 1
make[5]: quittant le répertoire « /home/kader/E2_build/source/enigma2-nightly/lib »
make[4]: *** [all-recursive] Erreur 1
make[4]: quittant le répertoire « /home/kader/E2_build/source/enigma2-nightly/lib »
make[3]: *** [all] Erreur 2
make[3]: quittant le répertoire « /home/kader/E2_build/source/enigma2-nightly/lib »
make[2]: *** [all-recursive] Erreur 1
make[2]: quittant le répertoire « /home/kader/E2_build/source/enigma2-nightly »
make[1]: *** [all] Erreur 2
make[1]: quittant le répertoire « /home/kader/E2_build/source/enigma2-nightly »
make: *** [.deps/enigma2-pli-nightly.do_compile] Erreur 2
kader@debian-kader:~/E2_build/cdk$

is it possible to do it ? if so how to fix it ?

b Regards

ghani
10.04.2016, 17:01
mmmmm habe auch den gleichen fehler meldung!

santa
10.04.2016, 19:56
Man kann meines Erachtens nur noch mix bauen, rein eplayer geht glaub ich nicht mehr

von irgendwo mit Fingern geschrieben

kader_73
11.04.2016, 21:16
hello ,


Man kann meines Erachtens nur noch mix bauen, rein eplayer geht glaub ich nicht mehr
that's what I thought too, hence my question "is it possible to do it or not?".

which leads me to question , is it fair to suggest eplayer3 as option 1? even though the third one is recommended. in my opinion, it will be more convenient to have the choice to choose the gstreamer with or without eplayer3.


b Regards

Audioniek
12.04.2016, 18:25
Hello everybody,

First of all, my ten cents on the subject. Historically E2 was either built with eplayer3 or gstreamer. When I started in this business I had no idea what to choose and what the (dis-)advantages were although I vaguely remember gstreamer was the recommended one. Either choice yielded a working image, and on that level I could not notice any practical differences between the two players either. Then somebody who is much cleverer than I am in this respect, found a way to combine the two and again I had no idea what the (dis-)advantages of that approach would be (one can be that this is the best of both worlds). From then on everybody apparently built E2 with the two framework option, and so did I.

Regarding my git, I simply follow its parent Duckbox Developers maintained by Max in this respect, assuming everything will build without error. Apparently, it does not any more. It is my view that a build option should either work properly or be absent. I will start some research into the matter and perform some test builds. Options that do not build without error will subsequently disappaer from my git, until the the build problem is fixed (if at all possible). This may lead to another situation, namely all three possible image types automatically build with the framework they need (the other two, neutrino and tvheadend use built-in, wrongly spelt in most gits) and with that approach the framework build option would disappear altogether.
Another approach can be to to the latter by definition as building with only gstreamer or eplayer3 brings no advantage anyway, but as stated before I lack the knowledge to make a sound decision on that and therefore would to see some democracy on this.

The reason for the latter is that I tend to keep my git as close as possible to its master, the Duckbox Developers gits maintained by Max. This reduces the amount of handywork to keep it up to date. I hope Max reads all this as well and will leave some feedback on what he would like to see happen.

Starting the first test build now....

Regards,

Audioniek.

Audioniek
12.04.2016, 19:03
Result of first test build (eplayer3 only): Basic part if the image builds without errors, but the build of OpenPLi/E2 aborts with this error:

base/wrappers.cpp:7:18: fatal error: glib.h: No such file or directory
#include <glib.h>

Apparently libglib is not built or cannot be found.

Regards,

Audioniek.

max
12.04.2016, 19:42
Was soll ich dazu sagen, früher gab es auch e2 Image wo man Eplayer oder GSTgst wählen konnte und auch Neutrino wurde früher mit Eplayer gebaut, bis dieser dann extra in stb-hal gekommen ist für Neutrino um beim E2 nichts kaputt zu machen.
Nur GST ist/war auch für mohousch sein neutrinohd2 und daher gibt es halt noch die ganzen Punkte zum bauen.
Ich selber brauche E2 nicht, daher auch der alte stand vom letzten Jahr, als Test für GST 1.0. (macht auch keinen Spaß wenn man alles allein machen muss ;-) )
Und so als Anmerkung die 1 in enigma2-pli-nightly.mk ist nicht umsonst leer, Damit baut zb HDMU das E2, es gibt im Netzt auch 3 aktuelle Gits von E2 die auch nur mit ffmeg laufen, wo man den punkt 1 auch nutzen könnte.
Um dieses nicht alles zu erklären zu müssen, ist irgend wann auch das recommended für e2 und neutrino in make.sh gekommen und wer meint es anders bauen zu müssen, kann sich gerne einbringen und Patche bereitstellen,
die man im git hinterlegen kann.

Für mich ist es immer noch ein Hobby, mit den Jahren kommt es aber auch so, was man nicht braucht wird auch nicht mehr gepflegt.

das waren meine 10 Cent zum Thema um etwas licht ins dunkel zu bringen.

Audioniek
12.04.2016, 21:55
@Max: thanks for your input.If you need/want help maintaining your git, just ask for it and I will be there for you.

Meanwhile I have done a second test build (gstreamer only). Build completes without error (that is: one; the dvb-mediasink git has been changed and its contents no longer needs patching; do a git pull first or edit the patch out if you want to try). Image flashes, starts and seems to run normally (caution: the latter at this point in time means just this:
1. Can tune in an FTA transmitter and display its programme;
2. The programme received can be recorded;
3. The recording can be played back.
All other aspects have not been tried/tested!)

This all leaves me with the impression that the build failure with eplayer3 only may merely be caused by a minor problem that has krept into the build environment ages ago, was never detected until kader_73 did try to build this way and probably also is relatively easy to fix. I will put in some effort toward that goal and report back here when something useful can be reported.

For the near future: build as you see fit with with the git you like and with eplayer3+gstreamer as the recommended and well tried way to go if you build E2.

Quote by Max: "es gibt im Netz auch 3 aktuelle Gits von E2 die auch nur mit ffmeg laufen" Realising this is completely off-topic: is this a way to get E2 running on the 4th generation Fortis receivers (my abandoned pet-project)? Any input is appreciated!

Regards,

Audioniek.

- - - Aktualisiert - - -


is it fair to suggest eplayer3 as option 1?

The option numbers have evolved historically and have, as far as I am concerned, no deeper meaning. This latter aspect is further demonstrated by the recommended comment and even some more info is given in the case of the Open-PLI diff-option (also see the comment by Max about this). In the near future I plan to move this latter option into make.sh, as it breaks the build by becoming interactive at about the 90% level (time-wise speaking). This would also make the build process more consistent; the neutrino variant for instance is asked for in make.sh. A neutrino or tvheadend build never becomes interactive unless a fatal error has occurred.

It is relatively easy to shuffle option numbers around (it merely involves editing some scripts), but for me this adds nothing new or useful as I start all my builds using short scripts.

Regards,

Audioniek.

santa
12.04.2016, 22:09
hi, ich würde mir diese Arbeit nicht machen, es gibt meiner meinung nach keine Vorteile nur gst oder nur eplayer zu nutzen.
Audioniek, gst und eplayer werden ausschließlich nur für wiedergabe von externen files oder streams genutzt!
Also, FTA, decrypt, Timeshift, und wiedergabe von Aufnahmen sind davon unabhängig!

Wer nur den eplayer oder nur den gst wirklich nutzen will, der kann am besten die service id 4099 eben so verändern wie er es braucht.

wenn ich mich recht erinnere ist die 4099 standard gst und zusätzlich wurde die 4097 für den eplayer3 aktivert, was es nicht in mips images gibt.
Deswegen jetzt das ganze git umzubauen macht für mich keinen sinn.

rantanplan
12.04.2016, 22:29
Kann das gedanklich nicht in cent packen und hab da sicher überhaupt keine Ahnung von,
aber Max hat es ja erwähnt....
gibt die Möglichkeit zu schielen. Rein eplayer Images werden halt bei den russischen Image bevorzugt.
Früher Schputnik heute sehr aktiv Taapat.
Vorteile?
Ist wohl alles ne Frage der Ansicht. Eplayer/ffmpg wäre aus meiner Sicht jahrelang deutlich unproblematischer gewesen.
Den Imagebauer sind aber die ganzen libs eher ein Dorn im Auge.
Daher wohl gst und mitlerweile rennt es auch für sh4 gut.

Grüße

Audioniek
13.04.2016, 01:49
Audioniek, gst und eplayer werden ausschließlich nur für wiedergabe von externen files oder streams genutzt!
Also, FTA, decrypt, Timeshift, und wiedergabe von Aufnahmen sind davon unabhängig!

If that is the case we are all building far too complex and too large images and have been doing so for years on end (or I completely miss the point). If playback of external files is what these imageparts are needed for, then I fail to understand something: playing back a recording made by the receiver itself is technically exactly the same process as playing a file on a NAS or a USB-stick, only the location and way of access is different and that is largely resolved by the kernel. This in turn means eplayer3 and gstreamer are needed only to play back file formats other than the format(s) transmitted by the satellite.

I use my phone for making calls (and nothing else, it is very dumb), my car to take me from A to Z and back (I despise cars that only go as far as B) and my satellite receiver for watching and recording satellite tv. I do NOT (mis)use my receiver to do the washing up: it does a very poor job at that. There is better and cheaper hardware out there for playing about any file in any or almost any format stored in about any location including the cloud called a media player; the last one I bought cost about 30 euros and does a better job than my VU+ Ultimo, the last surving MIPS-disaster in my household.

The second thing that amazes me in this context is that neutrino has about the same capabilities as E2 does, does about everything twice as fast in an image that is only one third of the size of E2 and builds in half the time. Neutrino also proves to me that eplayer3 and gstreamer are both just unneeded memory and resource eating ballast that has no place in a satellite receiver, not even one that tries to be what it in my view clearly is not: a media player.

Santa, I do not want to be rude, and I thank you for making me understand (or completely misunderstand) all this.

Regards,

Audioniek.

zdzislaw22
13.04.2016, 08:12
...
I use my phone for making calls (and nothing else, it is very dumb), my car to take me from A to Z and back (I despise cars that only go as far as B) and my satellite receiver for watching and recording satellite tv. I do NOT (mis)use my receiver to do the washing up: it does a very poor job at that. There is better and cheaper hardware out there for playing about any file in any or almost any format stored in about any location including the cloud called a media player; the last one I bought cost about 30 euros and does a better job than my VU+ Ultimo, the last surving MIPS-disaster in my household.
...

I do understand you prefer to have specialized equipment to do any single thing, but this does not mean toys you are using does not have more functions than you use. ;)
For example, even you use your phone just for calling, it also has a webbrowser and email client. Or maybe you have bought old 10 years old cellphone? ;)
The point is, if a hardware & software is capable to do something, we should not block this option because we don't use it. Flexibility is the key.

And finally, sattelite tuner for general user is a blackbox. He does not want to educate why it does not play any avi movie and install/change components. All should work since the beginning. This means to me all functions should be included into image or easily (from RC) installable.
My 2 cents :)

santa
13.04.2016, 08:41
Alles gut, aber heutzutage nutzen die meisten User die e2 boxen für iptv, und das geht nur über gst oder eplayer, um so illegaler die Streams um so besser ist es für die User.

Ohne Mediaportal oder Albatros kämen die meisten User nicht mehr klar, und gerade dabei merkt man was eben e2 für eine bastelsoftware ist, denn es immer wieder mal Hänger oder greenscreens mit reboots.

Der gst ist schon recht groß, und ohne diesen wäre das Image Vielleicht 10MB kleiner, aber es passt ja alles noch rein.

Und Ausserdem merkt man dabei eben welche streams eben mal mit gst und welche mit dem ffm besser gehen.
Man kann nicht pauschal sagen das einer von beiden besser ist, beide haben ihre Vorteile.

Python und e2 sind wie man dabei sieht relativ instabil und benötigt durch viele libs eine Menge Platz, und gefühlt wird es mit jedem update größer.
Aber es gibt dadurch die meisten plugins und somit extrem viele Möglichkeiten es zu personalisieren.

Zusätzlich ist Python manchmal auch etwas langsam, was nit damals den Grund gab tinanit zu erfinden, da komplett in c geschrieben sollte es viel schneller sein.
Aber wie man sieht ist die community viel zu klein, plugins und devs fehlen und somit völlig uninteressant.

Neutrino war Jahre lang was nur für puristen, es hatte keine "Graphische" Oberfläche mit Bildern usw, sondern es wurden lediglich Rahmen gezeichnet, ein Highlight war damals abgerundete Ecken.
Neutrino ist dadurch aber sehr schnell und hat eben auch kein Python als zusätzliche Programmiersprache.
Leider ist auch hier die community kleiner und somit gibt es weniger plugins usw.
Aber Neutrino ist auch schon viel schöner geworden und multimedial sehr gut erweitert worden.
Aber trotzdem sollte man sich sein Image schon selber bauen können um ea gut nutzen zu können, Ich glaub neutrino wird leider sein angestaubtes Image leider nicht so leicht los.

Enigma2 bleibt eben momentan die einzige Alternative für User die es schön bunt haben wollen und man keine Linux Kenntnisse haben muss.

Wir im hdmu sind immer stets bemüht die Images so klein und schnell wie möglich zu halten, aber im Bezug zu gst und eplayer sehe ich den Nutzfaktor dabei nicht.
Das problem ist eben das enigma2 auf mips mit gst programmiert wird, und da gäbe es immer zu viel was zusätzlich angepasst werden müsste um ausschließlich auf ffm zu gehen.

von irgendwo mit Fingern geschrieben

zdzislaw22
13.04.2016, 10:30
@santa: you are absolutely right. Neutrino is lighter and quicker. Actually I have both in one image and can switch beetween them without reseting/restarting tuner. So it is 2 in 1 system.

Led's works to me properly.

Audioniek
13.04.2016, 13:34
I do understand you prefer to have specialized equipment to do any single thing, but this does not mean toys you are using does not have more functions than you use. ;)
For example, even you use your phone just for calling, it also has a webbrowser and email client. Or maybe you have bought old 10 years old cellphone? ;)


First of all, thank you for your 2 cents. I understand your reasoning, but do not agree with it. The reason for that is twofold. The first is that multi functional devices almost always are collections of compromises, none of which is optimal. You gain features, but loose on quality. The second reason is that people tend to forget what a box originally is intended for and even "invent" or ask for new purposes for it, making it do things it was never good at in the first place (the first reason). This very often goes as far as forgetting the actual function the box was designed for and not using that function: "My box can do X, Y and Z, and even AA." When you inform them it can also do A (its original intended function) they are even surprised: "Wow! can it do that too?!" You are right: I will need more than one box for a collection of functions, where it is probably possible to have one box that does them all, but not optimally.
Regarding phones: mine is 12 years old, features actual moving keys you can physically feel and provide tactile feedback, and audible feedback without even using a speaker. It was bought new. It also has a feature called SMS which I do not use. My computer has something called e-mail which is about a gazillion times better and more comfortable. My phone cannot browse the net or send e-mails. I do not need that. Yes, I do need more boxes than you. But I use them for much longer periods saving valuable resources and I enjoy higher quality experience on them.


Flexibility is the key.
That is one approach. I have a flexible approach too, and achieve the same things you do, but along completely different ways. With me, quality is the key feature.

My point is this: while adding features the product becomes bulky, hard to control and maintain and in case of Enigma2 even more unstable (read the observations by other developers). With E2 it is my gut feeling we have reached a point where solving one problem yields two new ones and adding a feature disturbs at least one good working feature we already had. Quality will only return when it is stripped down to a more basic form. Meanwhile people still ask for added functionality. What they actually need is either a new box, or (that is my approach) an extra box with the features they miss in the first one. The latter approach has a higher quality level, is easier to maintain, and for that reason alone is much cheaper in the long run. How many phones have you bought in the last 12 years? Me: zero, and you can reach me on the same number for almost 25 years now.

Thank you for reading all this. Regards,

Audioniek.

zdzislaw22
13.04.2016, 18:41
You and me have completely different view on the things. You prefere multiple specialized devices, I prefer one having all possible funcitons in it. We cannot say yours or mine is wrong, they are different.
What does it mean from programist perspective? It means the compliation environment need to be flexible. If you like device with only one function included, you should have option to compile the image this way, but when I prefer to have everything in it, I also would like to have such possibility and not be blocked by programist, who does not agree with my approach. (nothing personal, just an example).

The only ask I do have is - Whatever will happen with repository, please do not block anything rather create multiple build options to fit as many needs as possible.

Makes sense?

santa
13.04.2016, 19:13
Ich denke jeder User hat andere Ansprüche an seine Box und deswegen ist es super das jeder die Möglichkeit hat alles nutzen zu können.

Sh4 boxen sind vom Hersteller aus gar nicht für Enigma gedacht gewesen. Wer also nur TV schauen will, der kann auch das Hersteller Image weiter nutzen, wer aber ein schnelles Image haben will, der ist bei Neutrino richtig und wer alle Medien wiedergeben will und alles optisch anpassen will, der braucht eben enigma2.

Aber zurück zum Thema, eben nur mit gst und ffm kann man alles wiedergeben, da eben beide auch Nachteile haben.

Zum Thema mobil Phone, Ohne Smartphone wäre ich hier nie erreichbar, da ich kaum zu hause bin und wenn ich zu hause bin, andere Dinge erledigen muss.

Ich lass aber immer öfter mal mein Smartphone liegen um mal das Leben in ruhe genießen zu können, daher @audioniek, Manchmal beneide ich Menschen die kein Smartphone haben in der heutigen Zeit um seine ruhe zu haben.



von irgendwo mit Fingern geschrieben

Audioniek
13.04.2016, 20:19
Yes it does. Regarding my git, it will remain a close copy of the git maintained by Max. The things that are different are different because I like my approach better, or things simply do not work in other gits or are obsolete. Examples of these phenomena are:
- My git refuses to build anything if you forget to put in the .elf files (a sensible thing asked for by a user);
- An example of the second the fixed Harddisk.py in OpenPli. No git has it (it is part of the diff-files maintained by me) but the option Menu -> Setup -> Harddisk -> Initialize works as intended when built from my git. If it would not I would patch the menu option right out.
- An example if the third is the flash environment. My git supports flashing any image that fits in all Fortis models.

You can of course use any git you lkie for the a purpose you see fit. The only task I see here for me as maintainer is provide you with a build environment that gives you a much freedom in build options as possible. For this reason the possibility to build with gstreamer only will remain there, because it yields a valid and working image. The option to be able to build with eplayer3 only will either be fixed or disappear altogether because it no longer feasble to build this way. It up to the user of the git on how he/she wants built her image and I, as maintainer will not imposes choices upon the builder. In fact, I will spend time and effort to add an option: build E2 with ffmpeg only, as schpuntik and taapat are apparently doing in their gits. The whole thing is called open source and anybody can do with the code on offer as they see fit, provided they leave the credits in.

With these last sentences we are back on topic. I thank everybody for their feedback, and learned something.

And to put things in perspective somewhat further: next year I will be celebrating my 60th birthday.

Regards,

Audioniek.

max
13.04.2016, 20:37
Wenn ich auch noch mal ehrlich sein soll, mir gefällt das CDK in DDT auch nicht so richtig, da auch einige Fehler drin stecken.
Mich hat es auch gestört, wenn man etwas ändern möchte das 5 Datein ändern muss.
Daher habe ich auch die letzten Tage auch etwas geändert am CDK siehe hier https://github.com/MaxWiesel/cdk , ist aber noch nicht fertig.

mfg
max

Audioniek
13.04.2016, 20:58
Hello everybody,

Some posts back I said I would report back when there is something to report, and there is. I finally have been able to reproduce the error reported by kader_73 in the first post:



In file included from service/servicemp3.cpp:14:0:
../lib/service/servicemp3record.h:7:21: fatal error: gst/gst.h: No such file or directory
#include <gst/gst.h>


When you open the file servicemp3record.h you will find the lettercombination gst a number of times in the code. The first observation is that E2 apparently needs gstreamer by definition, unless this file and its companion servicemp3record.c and possibly others are modified heavily. The short version of the answer to the question posed by kader_73 is: no, the current version of OpenPli E2 cannot be built without gstreamer.

This was already suspected by several others, and they were right. It may be possible to build with eplayer3 only, but this will need extensive patching within OpenPLi to achieve a negative result: you remove features that currently work as they should and which are taken for granted in MIPS-boxes.

My response (git-wise) will be as announced: the option to build with eplayer3 as the only framework will be removed with one of the next pushes. With these pushes you may expect a new more recent diff for OpenPli and a reworked fp_control, that produces better error messages in stead of segmentation faults when it is fed an incorrect command line, combined with usage messages that work as originally intended.

Regards,

Audioniek.

santa
13.04.2016, 22:01
Interessant, Hier anders herum das selbe Problem:

http://forums.openpli.org/index.php?/topic/41198-serviceapp---gstplayer-and-exteplayer3#entry542407

von irgendwo mit Fingern geschrieben

rantanplan
13.04.2016, 22:14
mhh
ich hab immer noch bestimmt überhaupt keine Ahnung und will mich auch nicht da aus dem Fenster lehnen....

Wo Santa schon auf pli Diskussion hinwies, daher
https://github.com/Taapat/vuplus-fulan-openpli-oe-core/blob/master/meta-fulan/conf/machine/include/oem-fulan.inc

Eigentlich steht da schon das meiste drin, wie man zum reinen eplayerImage kommt.

Grüße

Audioniek
14.04.2016, 21:15
...ist aber noch nicht fertig.
Max,

just a remark: the files audio7105.elf and audio7111.elf are the same; this is also true for their video counterparts. Further simplification is therefore possible but does not make things clearer. I have chosen for the clearer option.

Regards,

Audioniek.

max
14.04.2016, 21:48
ja mag sein, war halt schon immer so ;-)
was ich aber nicht verstehe,
https://github.com/Audioniek/cdk/blob/master/make.sh#L373
das der enable-buildinplayer in zeile 373 raus ist.
Neutrino nutzt nicht den eplayer3 aus apps, sondern den eplayer3 aus stb-hal und somit wird der eplayer3 aus apps umsonst mit gebaut.

Audioniek
14.04.2016, 23:42
@Max:

Die Zeile ist raus, weil dieses Teil der make.sh ein case [Imagetyp] ist. Die case faengt an in Zeile 316. Zeile 373 ist im Teil fuer Enigma2, Enigma2 laesst sich mit built-in nicht bauen. Umgekehrt ist bei Neutrino und Tvheadend built-in die einzige Moeglichkeit der Sinn macht, und die werden immer mit built-in gebaut wobei es bei Tvheadend eigentlich academisch ist: der Box gibt nie video wieder.

Bin gerade daran ein ueberarbeitete make.sh zu pushen, die auch den Enigma2-diff abfragt, damit die Build nie interactiv wird. Diff und revision werden via Umgebungsvariabelen und configure.ac uebertragen (be-einflusst auch enigma2-pli-nightly.mk, die Wartungsfrei wird, also diff-Pflege nur noch im make.sh). Erscheint sobald die jetzt laufende Testbuild OK ist und ich zufrieden bin.

Gruesse,

Audioniek.

max
14.04.2016, 23:53
ok habe ich jetzt gesehen ;-)

TangoCash
14.04.2016, 23:55
@audioniek:

Schau dir mal das an:
https://github.com/TangoCash/tangos-enigma2

Das ist eine E2 Version mit eingebautem eplayer3 (wie bei neutrino)
Zusätzlich kann man dann mit entsprechendem makefile auch so wie neutrino, nicht im selben verzeichniss wie die src sind, bauen.

Audioniek
16.04.2016, 13:54
@TangoCash:

I hope you do not mind me answering in English. I have started out to integrate your eplayer3-E2 into a test build environment based on my git. Currently I have ended up with a very bulky enigma2-pli-nightly.mk but it builds to completion. Resulting image can be flashed into a Spark7162 and starts. There is some basic work to do as the remote does not work at this point (aotom part is OK), but the start assistant shows a picture a with a Dream remote complete with arrows and a timeout counter.

The next steps I plan to undertake is get the basic eplayer3-image working in my test build environment. When that is done, I hope to determine the differences between an gstreamer+libplayer3 OpenPLi and your eplayer3-E2 variant. This will then hopefully lead to either a patch file to patch the gstreamer stuff out, and/or a more streamlined enigma2-pli-nightly.mk. Selection of which image to build is currently done using the diff-level which is in turn evaluated in enigma2-pli-nightly.mk. Along these lines I hope to reach a point you can build any current OpenPli diff for either three framework variants, but there is quite a but of work to be done to get there and may not be achievable.

In my view image size difference is considerable: gstreamer+libplayer3 is just over 60Mbyte, yours is somewhat less than 48Mbyte.

Thanks for your input. Testing, testing, testing....

Regards,

Audioniek.

TangoCash
16.04.2016, 22:20
I also ported the lirc handling into e2 (https://github.com/TangoCash/tangos-enigma2/commit/3fc5c28c9ae0f512d9a0c099e8af2c3f0e51ccc2) ..otherwise my rc wont work also

I just build Neutrino/E2 Dual images, and they are about 42mb

Audioniek
18.04.2016, 23:31
Meanwhile I have got a running image on a spark7162 with the remote control working. Fixing the remote was relatively easy: /dev/input/nevis_ir does not exist in my standard build. Replacing it with "/dev/input/event%d" and using the standard OpenPLi code fixed it for me.

I am now capable of determining the differences between a gstreamer based E2 and yours. Most of of what I saw so far is in Makefiles and can very likely be resolved in the enigma2 diffs so E2 will build with any frame work. This is because you can test with ENABLE_MEDIAFWGSTREAMER in both Makefiles and code. I am not there yet, but getting closer to home.

The main difference is the libeplayer3 code (by schischu, konfetti and others) in the E2 lib/libplayer3 directory, which is not part of standard OpenPLi. So far I use your git to get this part from the net. I was relieved by the fact that the rest of the build environment does not need changes when building with eplayer3 only, all changes are within E2.

Patching on...

Regards,

Audioniek.

TangoCash
19.04.2016, 09:15
I try to keep the changes in the build environment as small as possible, and try not to break other builds, like gst, or other E2 gits in this case.

I also ported E2 to libsigc++-2.0 api, because Neutrino relies on it. (not in git, just by a replace shell script)

The eplayer3 implementation ist not finished yet. At this time the AudioPids and the SubtitlePids are just ignored ;)

And i deactivated the servicemp3(gst based) because eplayer can handle this within. Both needs further investigation/tests.

all other modifications are to keep e2 small, and fast, or fetch my needs.

Audioniek
23.04.2016, 20:51
For those want to build E2 with eplayer3 only, you can now have a try. I have pushed the necessary changes to the git. All diff-levels build to completion with eplayer3 and have been tested on a spark7162. Tested in this case means: Image starts, displays and records an FTA transmitter and can play the recording back. I have not tested anything else, hence the term experimental behind the choice in make.sh.

Almost alll changes have been incorporated into the E2-diff files. The changes I could not handle this way are done in a small extra patch file.

Vielen Dank an TangoCash.

Regards,

Audioniek.

turulbird
05.08.2016, 23:09
E2 eplayer3 usb rev. 996.:

............
init player
init player 191
insmod: can't insert '/lib/modules/ksound.ko': invalid module format
insmod: can't insert '/lib/modules/player2.ko': unknown symbol in module, or unknown parameter
insmod: can't insert '/lib/modules/sth264pp.ko': unknown symbol in module, or unknown parameter
insmod: can't insert '/lib/modules/stmalloc.ko': unknown symbol in module, or unknown parameter
................
LOADING Enigma2
starting Enigma2 ->
PYTHONPATH: /usr/lib/enigma2/python
DVB_API_VERSION 5 DVB_API_VERSION_MINOR 3
ENIGMA2_DEBUG settings: Level=3
STMFBIO_BLT: Invalid argument
Segmentation fault
enigma2 ended <- RTV: 139
*
ERROR


It does not want to work... :(