When I choose one <unknown> the subtitle comes around. So I guess it has to return the right number for teletext to use...

Here is some pictures from Peter Pan 2017 - stealth (beta) vs. OpenPli 6.0 (not a dreambox, but E2 anyway)

<ukjent> (norwegian) is the same as <unknown> in english by the way.

Same channel SVT1

Since older software could catch these numbers, it should be possible to implement this in newer software also. I can understand if its not "developed" yet for oe2.5, but it should be possible to do the same thing as long as older software can do this from todays satellite providers. As OpenPli does.

Cant really see why getting the numbers out should mess with trackautoselect, as I asume it also will do that with only <unknown> returned. And as long as it returns numbers, you could filter them out by leaving numbers out of the logic. Cause you will most likely never know what subtitle laguagea a number returns anyway. For a tuner owner it might give a big logic, cause these numbers often is the same for each providers channels. Or are remembered by the user for spesific channels.

All numbers in first column that mr_vice shows are the numbers that are not returned in oe2.5.

So if its possible, it should be fixed. And in my and many others opinion it is an important issue. Maby not for germans, but for plenty other countries that wants to use dreambox tuners.

Thanks guys! Lets hope they fix this once upon a time. An lets hope that such a small fix can make others than germans to use dreamboxes. Up in north we have tons of ttx subtiles on lots of channels. Pretty anoying to have to test every ttx subtitle to find what you want.

I think this was no issue on oe2.0 and earlier versions, but may have come with the oe2.2 images. It has been an issue for a while for sure.

Meanwhile I just discovered that two channels on 4.8 actually shows language (countries) for TTX subtitles. So it might only be the subtitles with TTX page numbers that are missing. Have not seen any channels with that yet.

As far as my knowledge in python gets, I see that the only thing returned for TTX is when data have language names in it. Else it will return "und". Its for these returned strings we need to do something extra to get the page numbers. Such code is missing as I can see.

The OpenPli may be a damn bad comparsion, and I also asumed they used oe2.5 for their latest images. My bad!

So basically, what you are telling me is that it is not possible to do the same thing in oe2.5? Or that it takes more time to develope a solution for it? Are you working on it? Was you aware of this?

We are just wanting to help you guys, you know.

Someone told me that OpenPli images have a solution for this, and we have checked the same channel with both Dream Property image and Openplis's 6.0 image. DP image shows <unknown> for 10 SVT1 subtitle ttx pages. OpenPli shows teletext page numbers for all 10 TTX pages.

I have gone through som coding and found that enigma2.py for openpli have used attribute 'subtitle" from iPlayableServicePtr to catch page numbers. This attribute is not available in enigma2.py from DP image.

Hi,

Is this a known problem for everybody, or is it pr satellite problem. Nordic 0.8 and 4.8 will alway show <unknown> for TTX subtitles. Have not tested other satellites yet...

Today it just startet to compile again! Thanks if there where any case fixed!

Was testing an build for latest updates on git (4.3.1r13), but got this error when compiling for dm820:

gcc-runtime-5.3.0-r0 do_install: oe_runmake failed

Is there known issues regarding this?

This was also the case for my dm520. That connection is far too loose to be called an professional connection! Just telling this if other have the same issue.

@LazyT
No problem, shit happens!

@antrag
YES, the latest updates from DP (enigma2: 4.3.1r7) did the trick! Building images like a charm again!

@LazyT, why did you give me a "deslike"?

We are three developer here having a problem that might be an issue. Not nice to deslike someone without saying why!

Yes, have tried to delete build directory. Same shit. That has never helpt for any problem I have had by the way...

We are just telling this to make admin of git aware of an potensial issue. I will do the Satrunner method now, cant wait for ever.

I got a similar problem after my git pull last evening. After pull I testet a compile for dm900 image. Seems that there is som issue with the skincomponents in enigma2-plugins section?

ERROR: enigma2-plugins-4.3.2+gitAUTOINC+ca0e981b22-r0.pp4 do_packagedata: The recipe enigma2-plugins is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
   /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime/enigma2-plugin-skincomponents-channelselectionshorttitle
 Matched in manifest-dm900-enigma2-plugin-skincomponents-channelselectionshorttitle.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime/enigma2-plugin-skincomponents-eventlist
 Matched in manifest-dm900-enigma2-plugin-skincomponents-eventlist.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime/enigma2-plugin-skincomponents-eventposition.packaged
 Matched in manifest-dm900-enigma2-plugin-skincomponents-eventposition.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime/enigma2-plugin-extensions-curlytx
 Matched in manifest-dm900-enigma2-plugin-extensions-curlytx.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime/enigma2-plugin-extensions-curlytx.packaged
 Matched in manifest-dm900-enigma2-plugin-extensions-curlytx.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime/enigma2-plugin-skincomponents-channelselectionshorttitle.packaged
 Matched in manifest-dm900-enigma2-plugin-skincomponents-channelselectionshorttitle.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime/enigma2-plugin-skincomponents-reftopiconname.packaged
 Matched in manifest-dm900-enigma2-plugin-skincomponents-reftopiconname.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime/enigma2-plugin-skincomponents-reftopiconname
 Matched in manifest-dm900-enigma2-plugin-skincomponents-reftopiconname.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime/enigma2-plugin-skincomponents-eventlist.packaged
 Matched in manifest-dm900-enigma2-plugin-skincomponents-eventlist.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime/enigma2-plugin-skincomponents-weathercomponent.packaged
 Matched in manifest-dm900-enigma2-plugin-skincomponents-weathercomponent.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime/enigma2-plugin-skincomponents-eventposition
 Matched in manifest-dm900-enigma2-plugin-skincomponents-eventposition.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime/enigma2-plugin-skincomponents-weathercomponent
 Matched in manifest-dm900-enigma2-plugin-skincomponents-weathercomponent.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime-reverse/enigma2-plugin-skincomponents-channelselectionshorttitle
 Matched in manifest-dm900-enigma2-plugin-skincomponents-channelselectionshorttitle.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime-reverse/enigma2-plugin-skincomponents-eventlist
 Matched in manifest-dm900-enigma2-plugin-skincomponents-eventlist.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime-reverse/enigma2-plugin-extensions-curlytx
 Matched in manifest-dm900-enigma2-plugin-extensions-curlytx.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime-reverse/enigma2-plugin-skincomponents-reftopiconname
 Matched in manifest-dm900-enigma2-plugin-skincomponents-reftopiconname.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime-reverse/enigma2-plugin-skincomponents-eventposition
 Matched in manifest-dm900-enigma2-plugin-skincomponents-eventposition.packagedata
 /home/ppteam/dreambox/krogoth/opendreambox/build/dm900/tmp-glibc/sysroots/dm900/pkgdata/runtime-reverse/enigma2-plugin-skincomponents-weathercomponent
 Matched in manifest-dm900-enigma2-plugin-skincomponents-weathercomponent.packagedata

@Reichi
You might come in an situation when the only thing you want to change is the files, not whats in the recipe, do you mean it looks for changes in the files belonging to the recipe also? And by that, you do not need to use an PR in those situations either? Lets say you edit plugin.py for PluginSort, do the compiler check for changes (WORK DIR) in that file before deciding to increment PR for that recipe! I also want to have my version number as custom PR .= ".pp1". You say its not required, but will it be used if I use it, and will it mess up things?

Just finished compilation of a dm900 image now. I tried to do it with your solution regarding making an .append to enigma2-plugins_4.3.1.bb. This was for adding my changes to plugin.py for PluginSort plugin. And it works!!! Thanks so much! This has been an pain in the as for me to crack around. By the way, this does not work with plugins belonging to enigma2. Or I think belonging to enigma2... I want to do my own stuff in SoftwareManager, Satfinder and GraphMultiEPG, but those changes was not excepted in enigma2-plugins_%.bbappend. But when I did the do_install_append() in the enigma2_4.3.1.r4.bbappend that I have made, it worked nicely! My question is then, how do you know wich bbappend file to use from what plugin you wish to install? I have looked through a bunch of recipes, but cant find som place where it tells me that those 3 plugins mentioned should belong to the enigma2_%.bbappend... I just want to know before I have to get it blown in my face by compiler tellling me there is some faults around.

@gutemine
Thanks man! I will look more into QEMO. Might come in handy one day!

@gutemine
Thanks! An emulator that worked would be fine! Our files does system IO's. The problem is I dont have the raw codes anymore, and just dont want to do the job over again. But, it might be the only solution. Work work work... damn this dreambox world!

@Reichi
I have found some suggestion that an PR .= ".1" would be the right way to bump a custom update in a bbappend. Can you confirm that this is a good solution that will make everything good to go.

Thanks @Reichi!!

I will try it out! I asume that with plugins contained with enigma2.plugins you also mean every plugin defined or added to packagegroup-opendreambox-enigma2? Lets say I added PluginSort in there, will your suggestion work?

What if I do my changes in my bbappend file, how is the right way to get my updates done? Change the PR for my bb or bbappend file? Untill now I have made my own PR number within the bb files to force an update from the bbappend files, but that may mess with updates (pull) from DM, wouldnt it? Never thought of that! Just want to do this right without having my feed files messed up over time...

And one more problem regarding dm900 and armhf. Is it possible to run mipsel executables in this platform? Or do we have to recompile our old stuff for armhf? I mean, is it possible to trick systemctl to run mipsel with some options, so to speak? Maybe hoping for to much here?

If I want to put my own custom plugin.py lets say for the PluginSort extension. How should this be done. I cant seem to find any recipes for plugins wich I can make an bbappend to.

To start with I will say that I suck in understanding how to build images with custom changes! Converting OE 2.0 images to OE 2.5 has been an nightmare (for me).

Finally I successfuly built an OE 2.5 image for dm820. No fault at all. Then I startet to build an image for dm900. I then got a "QA Issue: No GNU_HASH in the elf binary:" fault for all my custom recipes that includes binary files. I have googled and googled, but can not get suggested fix's to work for my recipes.

I have tried this:

TARGET_CC_ARCH += " ${LDFLAGS}"

... did not work.

I will paste one of my recipes that do work fine for dm820, just to mention...

DESCRIPTION = "Image binary files"
MAINTAINER = "foo <foo@gmail.com>"
LICENSE = "CLOSED"


PN = "foo-image-binfiles"
PR = "r4.3.0"
SRCDATE = "20170427"
PV = "cvs${SRCDATE}"


FILES_${PN} = "/"


S = "${WORKDIR}/foo-image-binfiles-${PR}"


# Next line will prevent binaries to be stripped for empty spaces
INHIBIT_PACKAGE_STRIP = "1"


do_install() {
        install -d ${D}${bindir}
        install -m 0755 /home/dreambox/import/usr/bin/inadyn ${D}${bindir}
        install -m 0755 /home/dreambox/import/usr/bin/.emulist ${D}${bindir}
        install -m 0755 /home/dreambox/import/usr/bin/chttpd ${D}${bindir}
        install -m 0755 /home/dreambox/import/usr/bin/ppd ${D}${bindir}
        install -m 0755 /home/dreambox/import/usr/bin/oscam_1.20.mips ${D}${bindir}
        install -m 0755 /home/dreambox/import/usr/bin/list_smargo.mips ${D}${bindir}
}

What is wrong and how to fix this problem?

Thanks!

Sorry if this issue is explained elsewhere.

First one question. Is the pootle project the same for both OE2.0 and OE2.2? In other words, is the same MO file used in both platforms?

I find a lot of text in OE2.2 pointing to menu places like this:

"Please verify if your default storage device is attached or set up your default storage device in menu -> setup -> system -> recording paths."

The text above will be wrong in the new menu system for OE2.2. And wrong for OE2.0 if fixed to match OE2.2 menu system.

Or am I totally wrong here!?