Feature Request: Mount Editor in OpenWebif

[vidarak]

I'd like to be able to add/edit/remove mount points/options in the web interface. It's cumbersome to do this via the remote.

[Schimmelreiter]

I doubt this might come anytime soon:
OpenWebif is used on many different boxes running many different images.
There are differences between those different images in how they handle automounts.

My suggestion would be to learn a bit more about how things work on the box itself, then many settings can be kept and restored over reinstallations and even over switching images.

I wouldn't even waste a thought on the idea of creating network mounts using the remote but simply add them to /etc/auto.net (or /etc/auto.network on other images).
And that's where we come to differences:
Some images use /etc/auto.net, some /etc/auto.network and others create mount commands on the fly from a file named /etc/enigma2/automounts.xml ...

At the moment, OpenWebif would need to detect how automounts are stored (see above) and it would need to perform a lot of OS level browsing for network infrastructure in order to locate shares in the first place.
As long as there is no unified API which works across different images (Just like EPGRefresh and AutoTimer are supposed to offer identical API calls on any image) to locate and add shares, it is unlikely it can be done inside OpenWebif.

[jbleyel]

I have checked the automount (plugin) and i think we can integrated this feature if automount.xml exists.
All other box images without automount.xml can be integrated later.

[Schimmelreiter]

I can't stop you, but that's a waste of time.
At least I do not know any image using /etc/enigma2/automounts.xml for sure, I think VTI used that, but besides that ...
Neither OpenPLi nor HDMU nor oe-a based images do ...

[vidarak]

Thanks for discussing it :-) I can tell that my OpenPLI 4 definitely use /etc/enigma2/automounts.xml.
I actually cannot remember seeing anything else...

[RobvanderDoes]

ViX uses /etc/enigma2/automounts.xml as well.

[RobvanderDoes]

And XTA as well.

[jbleyel]

Thanks.
I will take a look and try to integrate an simple api for testing.
Then we can integrate the UI in openwebif.

[Schimmelreiter]

Hm ...
I don't have an automounts.xml on my box since ages and it's auto-mounting fine (via auto.net resp. auto.network).

[andyblac]

vix does not use automount.xml to mount the shares. it is purely use to save a list that network browser knows what it used. thats all, vix uses FSTAB or AUTOFS. so will be useless unless webif will edit these files at same time.

[Schimmelreiter]

Hah!
So I'm actually right ... :)
And editing autofs (config files) would be image/distro dependent:
OpenPLi uses /etc/auto.net directly, while
OpenATV (And other oe-a images probably too) store the mounts in /etc/auto.network

/etc/auto.master would need to be parsed in order to know which one gets used:
OpenATV auto.master:
/media/autofs /etc/auto.network --ghost
OpenPLi auto.master:
/media/net /etc/auto.net --ghost

[lupomeo]

FIrst of all You should look to Black Hole that is the main image Opewebif
was created for

2014-09-14 8:41 GMT+02:00 Schimmelreiter notifications@github.com:

Hah!
So I'm actually right ... :)
And editing autofs (config files) would be image/distro dependent:
OpenPLi uses /etc/auto.net directly, while
OpenATV (And other oe-a images probably too) store the mounts in
/etc/auto.network

/etc/auto.master would need to be parsed in order to know which one gets
used:
OpenATV auto.master:
/media/autofs /etc/auto.network --ghost
OpenPLi auto.master:
/media/net /etc/auto.net --ghost

—
Reply to this email directly or view it on GitHub
#182 (comment)
.

[RobvanderDoes]

[QUOTE]FIrst of all You should look to Black Hole that is the main image Opewebif was created for[/QUOTE]
Wow, that's an interesting remark......
Open WEB-IF was mainly made for just one image? And that image is simply a VU-image with some add-ons.
LOL....

'Open' = for all!

[Schimmelreiter]

I could hardly refrain from making some sarcastic comment.
Happily someone else jumped in :)

[lupomeo]

Yes the original author and creator of OpenWebif is meo that is the coder
of Black Hole image that started OpenWebif on Black Hole image extending to
all images.
THE MAIN DIRECTIVE of the author is that OpenWebif have to be compatible
with all images. Functions related to single image ARE NOT ALLOWED.
When you add a function to OpenWebif you have to look mainly to
compatibility with Black Hole and Vti images because are not Pli based.
The you should look to Pli images and all derivate.

2014-09-14 9:11 GMT+02:00 Rob van der Does notifications@github.com:

[QUOTE]FIrst of all You should look to Black Hole that is the main image
Opewebif was created for[/QUOTE]
Wow, that's an interesting remark......
Open WEB-IF was mainly made for just one image? And that image is simply a
VU-image with some add-ons.
LOL....

—
Reply to this email directly or view it on GitHub
#182 (comment)
.

[RobvanderDoes]

I agree that one should strive for compatibility with all.
But there comes an end to that: as VTi & BH are based on ancient DMM clones of E2 and a not up-to-date OE it will be no surprise that at some point backwards compatibility will end.

And I certainly don't agree with "to look mainly to compatibility with Black Hole and Vti images ". Ancient images should not be 'the main' reason to stop innovation. If it can't be done otherwise backwards compatibility should end in favour of new development.

[Schimmelreiter]

I totally agree.
"Life punishes those who delay." (Mikhail Gorbachev)

And this applies to any image.
In the past, this has mainly been OpenPLi, which regularily fails to keep step.
First they stopped updating Twisted so bam OpenWebif suddenly stopped to work on their DM 500/DM 800 images when previously deprecated Twisted functions became removed and HAD TO BE replaced by their successors.
Now it's their AutoTimer/EPGRefresh whose ancient versions simply can't be used by OpenWebif at all ...

It's simple:
If image devs fail to keep up with the development (And there wouldn't be any need for new images or even daily updates if we just stopped any progress), they will some day be forced to either quickly catch up in multiple places at once or to freeze one still developed plugin after the other for their image, effectively stopping to release truely new versions.

[vidarak]

My OpenPli 4 (updated just a few days ago) doesn't have an /etc/auto.anything. It does have my single mount point stored in /etc/enigma2/automounts.xml. I'm not sure where you see that OpenPLI uses /etc/auto.network??? Maybe it supports both...

[Schimmelreiter]

/etc/auto.net, /etc/auto.master and /etc/auto.network belong to the autofs package.
Without autofs installed you can still mount, e.g. through fstab, but this will result in complete box freezers (Only power off resolves) when using true CIFS shares due to bugs in Samba's implementation of CIFS (Actually it's even worse, the bug resides inside the Linux kernel).

OpenPLi by default does NOT use autofs but prefers to keep their image locking the box. Also their version of autofs is broken and they know it, but refuse to fix it.

[milosoftware]

On 09/14/2014 09:54 AM, Schimmelreiter wrote:

OpenPLi by default does NOT use autofs but prefers to keep their image
locking the box. Also their version of autofs is broken and they know
it, but refuse to fix it.
Just send them the fix or the link to it.
"They" have it already since ages:
http://openpli.org/forums/topic/33382-autofs-does-not-start-after-reboot-box/?view=findpost&p=419992

I could handle that myself (As you can see in the post following the linked one) but I stopped maintaining a bunch of hotfixes for the whole image (e.g. replacing epgrefresh and autotimer) and switched to OpenATV 4.2, they care, their image works out of the box.
This also removed the bugs I was never able to fix in OpenPLi, e.g. artefacts on playback of recordings and 3rd party videos.

[RobvanderDoes]

You can also word it a bit different: adding more and more functionality to the Open WEB-IF, relying on both embedded (E2-)functionality and plugins, will make it far more complicated to be compatible with all.
In the end we wouldn't want all images to be the same, would we :)

[Schimmelreiter]

adding more and more functionality to the Open WEB-IF, relying on both embedded (E2-)functionality and plugins, will make it far more complicated to be compatible with all.
In the end we wouldn't want all images to be the same, would we :)
It's all "options":

You do not need to use epgrefresh if you don't want to, but if you want to, the image has to have a version of epgrefresh already installed that is at least "semi current".
No coder with a clear mind will even start trying to stay compatible with OpenPLi's ancient plugin versions:
Schwerkraft Version 2.1.4
oe-a Version 2.1.3
openpli version 1.0.1

But I think we are getting OT.
I just wanted to underline the fact that compatibility isn't a one-way road.

[andyblac]

and the main reason i started oe-a the aim was for ALL teams to join and everyone use a common OE, which would bring common API's, but alas some teams heads where just to big. 😄

[lupomeo]

You have not to agree or not.
YOU HAVE TO RESPECT ORIGINAL AUTHOR directives.

2014-09-14 9:35 GMT+02:00 Rob van der Does notifications@github.com:

I agree that one should strive for compatibility with all.
But there comes an end to that: as VTi & BH are based on ancient clones of
E2 it will be no surprise that at some point backwards compatibility ends.

And I certainly don't agree with "to look mainly to compatibility with
Black Hole and Vti images ". Ancient images should not be 'the main' reason
to stop innovation. If it can't be done otherwise backwards compatibility
should end in favour of new development.

—
Reply to this email directly or view it on GitHub
#182 (comment)
.

[RobvanderDoes]

Shouting doesn't help you.... :(
And 'directives' are certainly not the way forward :)
Besides: the only relevant 'directive' I found is "This file is open source software; you can redistribute it and/or modify it under the terms of the GNU General "
So no limitation to modifying for dedicated images.
Please show some respect for all the contributors to this plugin.

[lupomeo]

You seems to not understand.
I AM the Creator and Original Author of OpenWebif and you have to respect
my directive.
OpenWebIf have to stay compatible with Black Hole image and all other image.
if you don't like make your fork and leave the main version.
STOP and respect.

2014-09-14 14:04 GMT+02:00 Rob van der Does notifications@github.com:

Shouting doesn't help you.... :(
And 'directives' are certainly not the way forward :)
Besides: the only relevant 'directive' I found is "This file is open
source software; you can redistribute it and/or modify it under the terms
of the GNU General "
So no limitation to modifying for dedicated images.
Please show some respect for all the contributors to this plugin.

—
Reply to this email directly or view it on GitHub
#182 (comment)
.

[jbleyel]

Slow down ....
All new features MUST not support all images.
BUT all new features should NOT break the base functions and MUST be compatible.

IMHO: Too many forks for the different images is not the right way.

[Schimmelreiter]

MUST NOT != muß nicht
:)
MUST NOT = darf nicht

muß nicht = DOESN'T HAVE TO

Scheiß Sprache ...

[RobvanderDoes]

@ Lupomeo: I fully understand that you're trying to add additional license-clauses. But that's not how it works, not in real life and not in virtual life....
Anyway:I think you've got enough good suggestions by now. So please show respect to all contributors and continue the good work.

[lupomeo]

Again i am not adding nothing.
I am the author and i stated from the beginning of the main version that
OpenWebif have to be compatible with all images.
Read all the story from the first post.
Also all E2OpenPlugins were stated to be compatible with all images.
So any new feature have not to break compatibility.
If you don't respect this you will be kicked off from contributors.
Stop this unuseful discussion.

2014-09-14 14:30 GMT+02:00 Rob van der Does notifications@github.com:

@ Lupomeo: I fully understand that you're trying to add additional
license-clauses. But that's not how it works, not in real life and not in
virtual life....
Anyway:I think you've got enough good suggestions by now. So please show
respect to all contributors and continue the good work.

—
Reply to this email directly or view it on GitHub
#182 (comment)
.

[jbleyel]

@lupomeo 👍

[RobvanderDoes]

LOL again a language issue? "not adding nothing" actually means "adding a lot" (language is in this respect the same as maths: negative times negative is positive).

Anyway: I'm glad you accepted all the good advice not to break any image.
But as has been said above: that also requires images (and their plugins) to be up-to-date..

BTW: Please, don't threaten. That's not done.

[ghost]

You advice other for respect and your reply starts with LOL ....

What is the problem ? Everything is explained very clearly:
add new features whatever you want but don't break any function which is needed by some images and which already works.

So this is was meo wrote and jbleyel confirmed.
I fully agree with meo and jbleyel

[RobvanderDoes]

LOL So you don't understand the language-error :)
Must be my fault then, I probably didn't explain it properly.

Anyway: I hope you understood the hints that backward compatibility with ancient images may come to an end at some point. But AFAICS that's not an actual issue (yet).

[lupomeo]

Again @rob
Stop your provocations and sarcasm.

2014-09-14 15:26 GMT+02:00 Rob van der Does notifications@github.com:

LOL So you don't understand the language-error :)
Must be my fault then, I probably didn't explain it properly.

Anyway: I hope you understood the hints that backward compatibility with
ancient images may come to an end at some point. But AFAICS that's not an
actual issue (yet).

—
Reply to this email directly or view it on GitHub
#182 (comment)
.

[RobvanderDoes]

If you see any 'provocations and sarcasm' in my text you haven't understood one single word of what I wrote. I have only been serious, even very serious.

[korzen78]

E2