MiLo

Could you explain the criteria exactly?

1. If "/hdd" points to something that exists, it will use that.
2. If /media/hdd exists (may be symlink or mountpoint), it will use that.
3. If there are non-removable disks, it will use the largest(*) one.
3. If there are (other) local disks, it will use the largest(*) one.
4. Otherwise, it'll use the largest(*) available mount.

(*) Currently the formula for "largest" is: (total size) + (free space).

Booting is de procedure
waarbij eerst de systeemcomponenten worden getest door het BIOS (of UEFI) en vervolgens
de bootloader wordt geladen en opgestart. En zo stapsgewijs je satreceiver tot leven komt.

Niet in het geval van de (meeste) satreceivers. Alleen PC-achtigen gebruiken tot nu toe BIOS en UEFI. Hoewel UEFI ook zijn weg aan het vinden is naar het ARM platform.

De sat receivers lijken meer op gangbare embedded MIPS en ARM systemen, die booten doorgaans als volgt:

- De ROM code start op. Dit is een stuk programmatuur dat helemaal niet te wijzigen is, het zit in de chip ingebakken.
- De chip heeft doorgaans enkele kilobytes aan RAM ingebouwd. Soms is dit simpelweg het cache geheugen van de CPU, meestal is het dedicated "on-chip memory" dat later nog voor andere zaken wordt ingezet.
- De ROM probeert nu een 'image' van een geheugen (meestal NOR flash) in te lezen in dat RAM, en start dan op wat erin zit. Dit programma heet de "first stage bootloader" of FSBL. Op dit punt is nog steeds alleen het on-chip RAM actief.
- De FSBL weet meer van het systeem waar de chip op draait, en voert deze configuratie in het systeem in. Een van de belangrijkste taken is om het externe geheugen (meestal DDR DRAM) draaiend te krijgen. Vanaf dat moment is er "ademruimte" en zijn er megabytes RAM te over.
- De FSBL gaat nu de "second stage" inlezen naar het externe geheugen, en start het op. Soms zijn deze twee stages samengevoegd (als er voldoende on-chip RAM is bijvoorbeeld).
- De second stage loader, meestal U-Boot of een afgeleide daarvan (op onze settops doorgaans wel), heeft dan als taak om het operating system (Linux in ons geval) in te laden en op te starten. Meestal leest het de kernel en een eventueel configuratiebestand van NAND flash geheugen in, en start het op. Deze second stage kan bijvoorbeeld ook een USB stick uitlezen en naar het flash programmeren, of bijvoorbeeld een web-servertje implementeren om dat te doen (zoals op de dreamboxen).

Het bootstrappen is voor deze machines het aanbieden van iets waar de ROM wat mee kan. Soms hoef je alleen maar een speciaal bestandje op een SD kaart te zetten, soms moet je een NOR of andere flash chip voorprogrammeren en eraan solderen, en soms kun je alleen via een speciale debugger interface (JTAG) of een seriele poort een first-stage loader aanbieden, die je van daaruit naar flash over kunt zetten middels zijn eigen code.

Gelukkig voor ons heeft de fabrikant er minstens de eerste twee stages al in voorgeprogrammeerd en kun je volstaan met een stickje...

Experimented with the et9x00 image, and this is basically what I came up with. You need both IMGDEPLOYDIR and DEPLOY_DIR_IMAGE during image creation,
so bluntly setting one or the other won't work.

This patch for "meta-xtrend" however should fix the build and work well for both the newer and older OE versions. Only build-tested it, but seems to generate something that makes sense (e.g. no "0" sized kernel)

Multiboot messes with mounts. Don't use it, or ask the developers to fix it.

Waar hangt die box aan vast? Want de andere kant adverteert ook maar 100Mbps:

        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full

dus alleen al daarom zal die interface niet naar Gbps gaan.

Heb je misschien per abuis een cross-kabel aangesloten? Dat levert ook dit gedrag op gigabit adapters, met een crosskabel vallen ze automatisch op 100Mbps terug.

@samsamsam
I think second post in this thread by @MiLo tells everything, we just need to create pull request for ffmpeg recipe in openpli-oe-core, Openpli will not do it for us.

If you want to propose a change, nothing beats a patch or pull requests in explaining what you want changed.

If you want something changed in a "core" openembedded component, I can help get a patch for OE integrated.

...
A person who is using ffmpeg should take the time to analyse the whole build process and standard configure compile files to find out exact what is needed and what not. That is a hell off a job and does required an experienced user and very good knowledge of configure files. Find out also and thats the most important what must be installed to the stb. Like conversion tools and so on are not required on a stb that's for a pc. On a stb only the minimum required codecs . We have by most stb's only a couple off audio codecs who are required that's it. Video codecs is zero. And on the fly conversions off video from one videocodec to another videocodec (which is supported in a stb) is so cpu intensif that hd is impossible and sd really on the edge.
...

For most packages that create tools and libs in a single build, the results are split up after building. The more fine-grained split-up (e.g. one lib per package), the more efficient the dependencies of other packages will become.

So the trick is not so much to configure everything away, the trick is to package things efficiently so that in the end, only the needful things get into the image. And people who want to do software video transcoding on the box can still install the extra tools.

Use os.path.join() instead of string manipulation (... + '/' + ...) to merge path names in Python.

I wanted to add that change the log level in enigma2.sh certainly not a simple way to enable the log for not experienced user.
There is a high possibility that the user can do anything wrong.
I think that it should be realized through the config.
As I understand it has not yet offered a good solution how to do this.

I think that no one is actually ever going to ask a user to do so. My suggestion therefore would be to postpone implementing this until after it's been demonstrated that we really really need it.

There are way too many settings already in E2, adding yet more isn't going to make things better.

But what is it that you want? I thought this was about reducing the eDebug overhead?

RSync by default calculates checksums and tries to "partially" update files.

If the files aren't being "changed" but just added/removed, there's a "whole file only" flag that you can pass to rsync, which will then skip the useless checksumming, resulting in much better speeds.

Zram was argued against by none other than Graugans and Delfi, m8.... Just so you know...

We tried zram years ago, and it only made things worse, not better. I'd suggest digging up the history of that from the commit logs and forum comments.

(Maybe it helps when most of the system's memory is occupied by copies of unused Java code.)

I guess the device is similar to those magic magnets that you can place on water pipes to reduce calcium...

As an experiment, if you run:

echo exfat-fuse >> /etc/filesystems

(note the "etc", not "proc"!) to append exfat-fuse to the list of "filesystems to try first", does the hot-plug work then?

There's a very simple and easy way to speed things up. You don't even need to be a developer!

Just don't buy the box until after the support is there. That's all there is to it. Same goes for any new box - if you want an OpenPLi image for it, the worst thing you could possibly do it go buy it!