Beeker

BTW: for vsftpd

init 4
opkg update && opkg upgrade
opkg install vsftpd --force-reinstall
reboot && exit

We need to build from scratch, what i didn't except. So it take long time. Feed is down now.

Black screen with h265 should be fixed now.

https://github.com/D...cc68fa3b986e94d

With telnet:

init 4
opkg install enigma2 --force-reinstall
init 3

Now dm7080 AKA Goliath build against test1 branch OpenPLi with test1 branch meta-dream.

https://github.com/D...ream/tree/test1

and

https://github.com/O...core/tree/test1

Other boxes which are building against test1 branch are:

-dm8000

-dm7020hd

-dm7020hdv2

dm900,dm820 and dm520 not tested yet.

As you see in description, it's a bit complicated to get it working, but it can be done.

I encounter some fetch problems, so i added the source in case you don't have them.

This should be solved the boot problem dm7080 and dm820 with this new Openembedded-core.

This requires a complete rebuild from scratch.

For those who want to test/try it...Go your way and report. Especially dm7080..which encounter boot problem with rc-6.0/develop branch.

Thanks.

dmm-bsp for dm500hd,dm800se and dm7020hd.

How does it work.

cd openpli-oe-core
git submodule add https://github.com/Hains/dmm-bsp.git

Add the BSP layer to makefile. something like this.

	$(CURDIR)/openembedded-core/meta \
	$(CURDIR)/meta-openpli \
	$(CURDIR)/meta-dream \
+	$(CURDIR)/dmm-bsp \
	$(CURDIR)/meta-vuplus \
	$(CURDIR)/meta-xsarius.pli5 \

And remove the file /meta-dream/image_types_nfi.bbclass.

Now you can build all 4 boxes(including dm8000).

Now it's equal to before the 'big dreambox cleanup' plus unionfs 2.6.
But in future openembedded-core update it needs gcc7 support+patch and some changes in the rootfs code.
I have them all for dm8000, but they can be used for other boxes as well.

So it's very handy to have a common bsp-layer which follow OpenPLi core.

Later i make seperate branches with kernel 3.2.75 (we are now at 3.2.68) and kernel 3.2.90.
For those who want to experiment.
Although kernel 3.2.90 does build and works flawless, i have to take a closer look at the patches.
Master branch will stay on kernel 3.2.68.
 
I do what i can,  help is always welcome.
That's it for the time being.

I'm busy with it. To setup an extern BSP layer for dm500hd, dm800se and dm7020hd. And if possible dm800.

Now OpenPLi has dropped all dreamboxes except dm8000.

It's not official yet. But it's almost ready.

Please, can you add this supplement:

https://forums.openp...m7020-hd-files/

It is missing on Openpli-5. If you care..

 

In my hands the test passed with positive results for dm7020hd.

gutemines dFlash exclusive binaries Ver 13.7, tested and working also very well.

Openpli-5 seems a little faster (for example fullbackup making and updating takes less time).

All the things there, including this, what I spoke in front (youtube, dvb-usb-em28xx, etc.).

For me is just missing openopera, what I use to view the HbbTV (openopera (1.0-r0)

Missing are some popular softcams, like mgcamd and some others. Possible, that you will find that it is not necessary there as oscam is default installed. Or, What I noticed, that  I got some errors on feed compiling, thid may be related that also.

IPTV streaming content works much better, five plus, good job!

In my opinion is dm7020hd ready for PLi 5. Of course, if you do not decide that dm is out of 5. It's your decision.

PR created for drivers.

https://github.com/O...e-core/pull/196

About scam and mgcam, see commit:

https://github.com/O...8a78291fa06b1d2

Besides that. In latest openembedded-core, python-cryptography 1.7 has also dropped openssl 0.9.8.

 

Some days I've used it with may box, and everything is very stable. How do I do this? I have installe apache2 with apt-get install apache2

I can see root@Debian:/var/www/html#

How to symlink the ipk folder there and what do I need to modify on my box? I see there a lot of plugins in the folder ipk and I want rather make the personal feed then.

 

Or install apache on your build machine and symlink /var/www/html/feeds/openpli-next to that ipk dir. You have a live personal feed then.          

 

In my case.

cd /var/www/html

sudo mkdir feeds

cd feeds

sudo mkdir openpli-5

cd openpli-5

sudo mkdir dm8000

cd dm8000

sudo ln -s /home/<username>/openpli-oe-core/build/tmp/deploy/ipk/dm8000 dm8000 

sudo ln -s /home/<username>/openpli-oe-core/build/tmp/deploy/ipk/all all

sudo ln -s /home/<username>/openpli-oe-core/build/tmp/deploy/ipk/mips32el mips32el

Be aware this is a example. You can adapt it to your own box(es)/path's/situation.

But the opkg config files must correspond with the path to the symlinks.

With this example. all-feed.conf for instance.

src/gz openpli-all http://<ip-adres/hostname>/feeds/openpli-5/dm8000/all

There is no official openpli-5. So i assume openpli dev's will bump the number to 5 when openpli-5 is ready ?

But indeed, it's very confusing when build a openpli-5 image for the first time.

Use master-next branch.

git clone -b master-next https://github.com/O...pli-oe-core.git

Latest exteplayer3 does not build.

I had to add:

SOURCE_FILES+=" external/ffmpeg/src/bitstream.c"
SOURCE_FILES+=" external/ffmpeg/src/latmenc.c"
SOURCE_FILES+=" external/ffmpeg/src/mpeg4audio.c"

To the recipe.

Somehow, my ffmpeg is not found?  I have

DEPENDS = "ffmpeg"
RDEPENDS_${PN} = "ffmpeg"

But i had to adapt a lot to the 'include' paths.

diff --git a/external/ffmpeg/src/latmenc.c b/externa;/ffmpeg/src/latmenc.c
index f9e1c89..c47807d 100644
--- a/external/ffmpeg/src/latmenc.c
+++ b/external/ffmpeg/src/latmenc.c
@@ -22,10 +22,10 @@
  /* ***************************** */
 /* Includes                      */
 /* ***************************** */
-#include <ffmpeg/get_bits.h>
-#include <ffmpeg/put_bits.h>
-#include <ffmpeg/mpeg4audio.h>
-#include <ffmpeg/latmenc.h>
+#include "../get_bits.h"
+#include "../put_bits.h"
+#include "../mpeg4audio.h"
+#include "../latmenc.h"
 
 /* ***************************** */
 /* Makros/Constants              */

diff --git a/external/ffmpeg/src/mpeg4audio.c b/external/ffmpeg/src/mpeg4audio.c
index 5a95013..c339b2a 100644
--- a/external/ffmpeg/src/mpeg4audio.c
+++ b/external/ffmpeg/src/mpeg4audio.c
@@ -20,9 +20,9 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#include <ffmpeg/get_bits.h>
-#include <ffmpeg/put_bits.h>
-#include <ffmpeg/mpeg4audio.h>
+#include "../get_bits.h"
+#include "../put_bits.h"
+#include "../mpeg4audio.h"
 
 /**
  * Parse MPEG-4 audio configuration for ALS object type.

diff --git a/bitstream.c b/bitstream-02.c
index 7c8a2a2..6883f05 100644
--- a/external/ffmpeg/src/bitstream.c
+++ b/external/ffmpeg/src/bitstream.c
@@ -29,7 +29,7 @@
  */
 
 #include <libavutil/avassert.h>
-#include <ffmpeg/put_bits.h>
+#include "../put_bits.h"
 
 
 void avpriv_align_put_bits(PutBitContext *s)

diff --git a/output/writer/mipsel/aac.c  b/output/writer/mipsel/aac.c 
index d14c0e6..6af7cc7
--- a/output/writer/mipsel/aac.c 
+++ b/output/writer/mipsel/aac.c 
@@ -40,7 +40,7 @@
 #include <sys/uio.h>
 
 #include <libavutil/intreadwrite.h>
-#include "ffmpeg/latmenc.h"
+#include "../../../external/ffmpeg/latmenc.h"
 
 #include "stm_ioctls.h"
 #include "bcm_ioctls.h"

iff --git a/container/container_ffmpeg.c b/container/container_ffmpeg.c
index 507621e..f5faec5 100755
--- a/container/container_ffmpeg.c
+++ b/container/container_ffmpeg.c
@@ -48,7 +48,7 @@
 #include <libswresample/swresample.h>
 #include <libavutil/opt.h>
 
-#include <ffmpeg/mpeg4audio.h>
+#include "../external/ffmpeg/mpeg4audio.h"
 
 #include "common.h"
 #include "misc.h"

Then build fine.

Tested myself..same result..

But still the question...Do openpli-dev's accept these bbappends?

If not:  so be it.

If yes: Can we send a pull request?

With latest openembedded-core, meta-openembedded en bitbake you can expect more problems.

Bitbake breaks the e2openplugins en openpli-plugins (ok a lot of them, not all).

I have solution for that, but the hardest part for me is the now swig.

Swig has been updatet to version 3.0.10 (since yesterday). And it's building fine but enigma2 totally crashing at startup due to -no module named libimport-

For now back to 3.0.8.

Anyway ..it's not over with the misery.

 

This problem occurs when gstreamer recipes is .bb file(full),but when I use .bbappend file(short) - ok.

Actually this problem has always been there since now more then 3 to 4 years. Was there with gst-0.10 up till now indeed today 1.9 (by me) but is related to rtmp and will definetelly not be always there but on some times of the day. It also has nothing to do with hls it will occur when switching over from that specific rtmp channel to any other media using the player(which uses gstreamer mediasinks). So switching from that rtmp channel to a file based media will cause same crash. But not always it may vary and so You have the wrong impression that test with x is ok with Y not. If You test very deep and foor a week long You will notice that it actually happens regularly on whatever gstreamer version you have. From whatever stream or media (using the mediasinks) you are going to . And yes gstreamer may hang up on gstreamer stop by a rtmp//  link based media not always but many times why  ? that must be found out but it only occurs when using rtmp and is there already since gst 0.xx   till now up to 1.11.

 

About rtmpdump. rtmpdump is very old in meta-openembedded.. from july 2011.

https://git.ffmpeg.o...mp.git/shortlog

i have bbappends to update rtmpdump to latest git revision and a tiny adapting on patch. openpli-oe-core/meta-openpli/recipes-multimedia.

No cure..no pay

It rebuild gstreamer-plugins-bad.

So update gstreamer-bad or force install at least gstreamer-bad-rtmp.

For dreamboxes we can use this for bbappends.It's machine specific.

buildtools-tarball.bbappend and uninative.tarball.bbappend(both are equal).

TARGET_ARCH_dm8000 = "mipsel"
TARGET_OS_dm8000 = "linux"

TARGET_ARCH_dm800se = "mipsel"
TARGET_OS_dm800se = "linux"

TARGET_ARCH_dm7020hd = "mipsel"
TARGET_OS_dm7020hd = "linux"

Perhaps it can be simplified.I tried dm***, dm%%% etc instead of each machine(just dreambox doesn't work), but i can find the right syntax.

This shouldn't break ARM builds..