33 replies to this topic

[gorski]

ET images are OpenPLi based, aren't they? Well, then... Let's see...

 

Attached are all the files needed and info... well, here it is, so you can see if you wanna download it and test...

 

Plugin DeviceManager

Dear Xtrend-User,

This plugin will replace the MountManager. It is recommended to remove the MountManger before installing the DeviceManager!

Functional overview:
Initialize (Partitioning) und formatting of internal and external devices on your Xtrend-STB (SATA/ESATA/USB-disks, USB-pen-devices, SD-cards etc.)
Partitioning and formatting will be done with integrated OpenPLI-Enigma2 methods, options and optimizations
Automatically creation of the "movie"-folder for the first plugged device on your Xtrend-STB (Use as Recordingmedia)
File system support for EXT3/4, FAT32, NTFS*
Distinction between FastMount (non boot resistent) and FixedMount (permament boot-resistent mount via fstab with UUID)
Fast and clean removal of FastMount-devices via "Blue-Button"
Pre defined mount points for FastMount and FixedMount devices, including the possibility to use user defined mount points
Filesystem check and with auto-repair (if possible) included
Display Disk temperature (if supported)

Installation:
If your Xtrend-STB is online, then you have only to install enigma2-plugin-systemplugins-devicemanager_1.0-r0_mipsel.ipk
If there is no online connection, you have to install first ntfsprogs_2012.1.15-r5_mipsel.ipk, and dosfstools_2.11-r2_mipsel.ipk
After installation, please do a reboot of your STB.

Advice: please be sure, to remove your USB-device with DeviceManager. If you just remove your device, it could result in data loss and filesystem damage.

Usage:
Start plugin via Menu - Setup - System - Devicemanager.
Use the colored buttons, arrow-keys and ok button.

*To use NTFS devices in read-mode, you have to install this plugin.
More information in this thread.

Attention: All existing Data on Memory Device will be wiped, if you decide to initiliaze and format!

Code pieces are taken from skaman. Thanks for it.

Plugin will be provided by the Board-Team of Xtrend-home.de for Xtrend-United

 

The thing is: autofs and Device Manager together? Can that work as you want it/need it?

 

Mount Manager in PBNIGMA does not create problems for Device Manager and does not need to be removed. In fact, it is complimentary, as it does slightly different things, from memory... Of course, in PBNIGMA autofs is stopped!

 

My question would be: must autofs be stopped so one mounts devices as one needs/sees fit?

 

To my mind users should have the choice/flexibility and to do do that s/he needs info. Once one is informed, to me, this is a much better option, than coders idea for all users, regardless of their needs/wants... That's why I appreciate a good Device Manager...

 

But... haven't had the opportunity to test this one - however, I remembered many users asking for it, so here it is to test...

Attached Files

•  Plugin DeviceManager.zip   345.29KB   431 downloads

[hemertje]

i see no benefits from our mountmanager?

[gorski]

Can OpenPLi Mount Manager (I haven't seen it in a while, so I ask):

 

-initialise/partition a device (in any format you like, various proportions/size),

-mount a partiton (at any point/any way you want it to be),

-create a SWAP file (where you want it, various size),

-Expand the STB's flash (at least PBNIGMA one can)

 

???

 

Last I saw in OpenPLi was autofs doing things but not necessarily the way user needs it to be...

[MiLo]

A quick scan reveals that the code it littered with "os.system" and "os.popen" calls, so the plugin is not likely to work well.

Edited by MiLo, 14 December 2013 - 12:11.

[gorski]

Oh, I think I'll have to mess with it, after all...

[gorski]

I've spoken to a developer and he told me he tested your claims and after 100s of calls couldn't find any effect on memory etc.

 

And if it were true half the E2 plugins would not have been able to work at all etc. etc.

 

He has a question: could you be more specific, as to what precisely isn't working with those calls, Milo?

[athoik]

Hi,

There is a huge problem calling os.system in embedded systems (The problem is the fork mechanism).

It is know that calling os.system (and friends) from within Enigma2 process soon or late you will get out of memory, especially in the older boxes with low memory. Most probably changing to eConsoleApp will be the solution.

http://openpli.org/f...e-2#entry373437

[gorski]

As I said - tested without problems found. Unless there is something concrete, perhaps, to properly investigate?

[MiLo]

The "os.system" calls should not be needed at all - Python can do anything the shell can do. No need to fork a shell and ask it to do something. Calling os.system is usually a result of the programma's lazyness or lack of knowledge.

Those rare cases where you need to start a separate process, use eConsoleApp. That is the only stable way to do this. Calls to os.system and os.popen WILL fail on many systems.

[gorski]

But not so on Enigma2 he tested a lot.

 

So, back to the question: can you be more specific, please? You know, so it can be verified...

 

Thanx.

[pieterg]

If MiLo's points did not yet convince him, you're probably not talking to a developer.
One more point; remember you're forking a process with a virtual address space of >200MB in most cases, just to call a simple shell function.
vfork is usually a better option (and guess what, eConsoleApp is using it)

[MiLo]

So, back to the question: can you be more specific, please? You know, so it can be verified...

What do you want to know? What is unclear to you?

Edited by MiLo, 16 December 2013 - 11:40.

[gorski]

That was uncalled for, pieterg, especially since I told you he tested it a lot ("hundreds of calls") and couldn't find anything of the sort Milo suggested.

 

So, he asked, "Where is this paranoia grounded?" I mean, it sounds like a valid concern - IF it can be proven to be true...

 

Then, one could get on about trying to change it, of course, hence all these questions, ultimately to improve things.

 

Which naturally leads me to the Q: have you guys implemented it in OpenPLi E2, please?

[gorski]

So, back to the question: can you be more specific, please? You know, so it can be verified...

What do you want to know? What is unclear to you?

 

Not to me - I am a lay person, not a developer, I just test etc. -- but to him. He tested your assumption and couldn't find any evidence to support your claim, having spent some time trying to prove your hypothesis.

 

So, can you, please? I mean, evidence, not broad suppositions and suspicions etc.

 

It looks very important to me, since we are occasionally having problems with memory in E2, ergo one should ask these Qs, in order to get somewhere and then maybe get a strategy to get out of these problems.

 

Therefore, what you have written is taken seriously, tested and... we're none the wiser for now... unless you can prove your claims, so we know what not to do, what to avoid and then which way to turn and how to implement changes...

 

Thanx!

[pieterg]

That was uncalled for, pieterg, especially since I told you he tested it a lot ("hundreds of calls")

That's not how you convince a developer.
For example, I could write code with a (deliberate) race condition, and then run it hundreds of time, 'proving' there is no race.
If you know something is wrong, you should fix it. Or if you know there are better alternatives, you should use them.

[gorski]

I beg to differ: this is not how you talk to a colleague - by insulting him first (for simply asking for some proof, real pointers)...

 

Moreover, in this case we have a problem in E2 - running out of memory in some cases, so a real issue. We agree?

 

Then, Milo points a finger but there is no real proof. It seems he should help us first, since he had an idea...

 

So we can get the culprit and act....

[pieterg]

I've told you the culprit, fork. Use vfork instead.
I didn't realise that you would take that as an insult. I think we should stop this discussion, clearly we're talking at different levels.

[gorski]

Why kill a thread, when we can actually clear up the misunderstanding and get somewhere, do some good, if only...

 

Here is the misunderstanding bit:

 

If MiLo's points did not yet convince him, you're probably not talking to a developer.

 

That, to me, given the fact I told you he spent quite a bit of time testing Milo's hypothesis ("hundreds of these calls monitored") and found nothing, is insulting. I.e. condescending. Especially because we have not seen any evidence so far that this really is the case.

 

So, the logical thing is to ask a question: can we have some proof of that hypothesis, please?

 

At that point it is not enough to keep repeating the mantra but to back up the hypothesis with some hard and verifiable facts.

 

Why? So you knowledgeable guys can actually pinpoint the culprit for various problems we might have, in relation to those parts of E2.

 

Reasonable, I hope we can agree, course of action?

[pieterg]

1. read the manpages of fork and vfork, and imagine the difference cloning a >200MB address space
And if you prefer to see results, try to load as much epg into e2 as you can on your lowest memory box, make sure the remaining memory is consumed by page cache (fast forwarding through a large recording usually does the job) and then fork it. You will eventually get ENOMEM results (even though system memory is available, and fork does not copy the actual pages, just copying the parents page tables will eventually fail)
2. remember that python code runs in the e2 mainloop thread, so os.system & friends block everything (eConsoleApp runs in its own background thread, and does not block the e2 gui)

Even when you ignore 1, 2 is a big enough reason to avoid os.system, as MiLo pointed out.

[gorski]

Yes, having seen the previous thread with memory problems and EPG Import - this (what you just wrote) was the initial motivation to test it all. So, all this is known - in principle - and it stands - in principle.

 

However, once he tested it in E2 reality - it didn't pan out. That is all there is to it. Hence the question - some pointers in E2 reality, please?

 

Because he could not find any evidence in E2 actual functioning to prove the hypothesis...

 

Thanx!