athoik

I see no reason why a link cannot be posted. Especially when that image correctly states that it is OpenPli derived. As I said in the 'no dream support' thread I expected other groups to create special OpenPli images fro dmm boxes, and (although I speak for myself) I would encourage that. But I also expect the Satdreamgr group to actively support their updates so the OpenPli team does not get bothered with it and can devote their time to new developments...

 

As i said before "Satdreamgr  is 100% OpenPLi (build from OpenPLi sources, original sources not forked).  Changes were made using only .bbapend files and meta-local folder."

 

So that means you get original OpenPLi with minimal changes (like the AC3+ patch for Dreamboxes).

 

We will continue contributing changes back to OpenPLi, hoping that they will be committed (if not .bbappend will do the trick )

 

You can find our images here : SatDreamGR Images

Hello,

One of the problem (for simple users) is the absense of real multiboot solution. Current solutions they are mixing the kernels and causing more problems than solving. Also OpenPLi doesn't support them (because of the problems causing).

I read some old discussions and they where mentioning the kexec system call as the ultimate solution to the problem.

Moreover i see the existance of the kexecboot project where mipsel architecture is supported! Additionally kexecboot exists allready under meta-openembedded.

multi machine support: we build for many architectures using OpenEmbedded (tested on arm, mipsel and x86/x86_64)

Do you think it is possible to use above project and provide multiboot for all mipsel boxes?
Did someone tried that and fail?
If someone has hints, ideas or recomendations i would would like to hear them.

http://en.wikipedia.org/wiki/Kexec
http://kexecboot.org/

We have the patch applied on Satdreamgr image too.

 

Satdreamgr  is 100% OpenPLi (build from OpenPLi sources, original sources not forked).  Changes were made using only .bbapend files and meta-local folder.

 

If OpenPLi has no problem i can post links.

Ok!

Here is the patch.

Here you go:

 

Patch for dvbmediasink.

 

 0001-Handle-DTS-Passthrough-and-Downmix.patch.txt   2.28KB   34 downloads

 

Patch for OpenPli 3.0

 

 0001-Add-a-proper-fix-for-DTS-Passthrough.patch.txt   4.78KB   12 downloads

 

Patch for OpenPli 4

 

First part is allready applied (the one that didn't make caps writeable)

 

Second part is here (not applied yet, it make caps writetable)

 

It this ok?

Hello,

 

Andreas Monzner from DMM commit a change on dvbmediasink (about an hour ago) in order to add support for ac3plus (they listening...).

 

This commit makes DTS downmix patch to fail. So i rewrote it again (but haven't tested yet). I also simplify the check of ac3plus, using cheap access call, since they only look if file /proc/stb/audio/ac3plus exists.

 

Please review the changes and apply or next build will fail.

 0001-Handle-DTS-Passthrough-and-Downmix.patch.txt   2.2KB   32 downloads

This helps? http://openpli.org/f...feed-timefortv/

 

Also if you setup a stream with a service reference from a valid channel you will get epg.

 

Eg...

 

#SERVICE 1:0:1:133:3E1C:13F:820000:0:0:0:http%3a//a.stream.tv:Stream
#DESCRIPTION Stream

 

Service Reference is from Arte HD on 13E.

 

PS. Stream (from magais image) starts with 1: and not with 4097: that means stream is MPEG TS capable?

I will test the same fix on dreambox dvbmediasink.

 

It works also on dreambox dvbmediasink.

 

Here is the patch.

 0001-Fix-ac3-audio-playback-if-aac-track-is-present.patch.txt   3.04KB   15 downloads

Dear All,

 

 

I thing that everyone likes some might interesting in the new features and stability? offered by newer versions of GStreamer.

 

OpenPLi currently has some "experimental" branches (named gst 1.0) where GStreamer API changes applied in order to be able to build images with the new version of GStreamer.

 

Using those branches i have managed to build an image using latest (stable) GStreamer 1.0.7.

 

Of course results are not so good. Almost.. no media work (except some mkv).

 

So i have some questions:

 

1. Do you want/accept patches for gst 1.0 branch?

 

2. Is it possible to update gst 1.0 branch to latest version (and synchronize with HEAD)?

 

3. What would be the starting point for fixing things, eg first try to fix MP3?

 

4. Maybe its better to create "experimental" gst 1.0 on Github so other teams interesting in Gstreamer 1.0 help?

 

I can attach changes already did here, if someone wants to play with GStreamer 1.0. Making one step at a time all of the sudden we are going to have the first Enigma2 with GStreamer 1.0.

 

Regards,

athoik

Ok pieterg,

 

 

Now it must be ready!

 

 

Dear OpenPLi Developers,

 

 

I create a patch, compile the image and issue gone away with patched gstreamer!

 

I added the patch on gst-plugins-good_0.10.31.bbappend and gstflvdemux-max-width-height.patch inside gst-plugins-good_0.10.31 folder.

 

cat gst-plugins-good_0.10.31.bbappend

DEPENDS := "${@oe_filter_out('^(gconf|pulseaudio)$', '${DEPENDS}', d)}"

DEPENDS := "${@oe_filter_out('gtk+', '${DEPENDS}', d)}"



PRINC = "3"



SRC_URI += "file://audioparser-raise-ranks.patch \

            file://gstflvdemux-max-width-height.patch"



EXTRA_OECONF += "--enable-orc"



FILESEXTRAPATHS_prepend := "${THISDIR}/${P}:"

 

Please review this patch

And real dreamboxes have block2mtd in the kernel of their OE 2.0 images so nandsim is not needed at all

 

Did you ever create patch for OpenPLi and they didn't accept it?

 

Can you create patch for the rest of us?

 

Finally what will be the gain (except nfidump) after block2mtd is enabled on OpenPLi ?

Error is not fixed yet on OpenPli 2.1

| make: *** [all] Error 2
| + die 'oe_runmake failed'
| + oefatal 'oe_runmake failed'
| + echo FATAL: 'oe_runmake failed'
| FATAL: oe_runmake failed
| + exit 1
NOTE: package gst-ffmpeg-0.10.11-r1: task do_compile: Failed
ERROR: Function 'do_compile' failed (see /home/athoik/openpli/build-dm800se/tmp/work/mipsel-oe-linux/gst-ffmpeg-0.10.11-r1/temp/log.do_compile.29540 for further information)
ERROR: Task 11 (/home/athoik/openpli/openembedded/recipes/gstreamer/gst-ffmpeg_0.10.11.bb, do_compile) failed with exit code '1'
ERROR: '/home/athoik/openpli/openembedded/recipes/gstreamer/gst-ffmpeg_0.10.11.bb' failed

Using the following patch (idea taken from OpenPli 3.0) build succeds.

diff /home/athoik/openpli/openembedded/recipes/gstreamer/gst-ffmpeg_0.10.11.bb.old /home/athoik/openpli/openembedded/recipes/gstreamer/gst-ffmpeg_0.10.11.bb
23c23,26
< EXTRA_OECONF = " --with-system-ffmpeg "
---
>
> GSTREAMER_DEBUG ?= "--disable-debug"
> EXTRA_OECONF = "--with-ffmpeg-extra-configure=\"--target-os=linux\" ${GSTREAMER_DEBUG}"
>

Please revise the change and commit if applicable on OpenPli 2.1

SRT sub files are not designed to be used in muliples, there are no language or encoding tags, so one media file one srt file, that's the design.

That's why developers redesign.

SRT sub files were an invention to solve the problem of the braindead avi container not supporting subtitles.

Also is the perfect invention to add subtitles (although container has subtitles) without the need to remux.

"Modern" containers like mpeg ts, mkv and mp4 have embedded subtitles and they are tagged with a language code, so you can have multiple. If you want multiple subtitle tracks for a single media file, that's really the way to go and enigma/gstreamer supports that just fine.

I totaly agree with you, although having more options won't hurt right?

Currently, using "single" SRT ISO subtitles is supported (always supported but nobody knew how, i am Greek and i want my ISO SRT files decoded as ISO-8859-7 not the assumed ISO-8859-15, now i can). That's enouph for me.