More Mount problems

[hugson]

I own a T2 (Kernel 3.14.2).
Yesterday I needed to create 6 server mounts. I eventually succeeded in this, but it took around 3 hours because of the many bugs and crashes I experienced. I will try and describe the most serious of them.

1) Setup / Network/ Mount Manager.
I created a new CIFs share, using a share name of "1 Recent". After it was created Mount Manager displayed a share name of "1".
When I tried to use this, I got a message saying that no such network folder existed (Q: why is BeyonWiz trying to use share name to access the share?).
So I returned to Mount Manager and edited the share name, this time removing the space in position 2. Upon re-entering Mount Manager after saving my changes, the share name remained "1".
So then I deleted the share, and Mount Manager duly showed the name had been deleted.
But Media Manager continued to show a share called "1". So now I selected "1" in Media Manager, pressed the Menu button and selected Delete. This caused a system crash and reboot.
I eventually resolved this issue by using Mount Manager to create a new valid share called "1". Then I used Media Manager to open this new share. Then I used Mount Manager to delete this share. Finally Media Manager agreed that "1" was indeed gone.

2) I created a new CIFs share, using a share name of "1.Recent". After it was created Mount Manger displayed a share name of "1Recent".
So I exited out of Mount Manager, then went back in and edited this new share, inserting the period into the share name. This time it worked and was remembered. (And the same problem occurs if I use "," or "-" instead of ".").

3) Regardless of whether I instruct Media Manager to save the last folder I accessed, or always to return to the list of devices, the last folder is always retained.

I have listed only 3 problems here, but the solutions I have reported took a lot of time to discover, with many other attempts failing in one way or another.

My conclusions are:
- the BeyonWiz developers are very poor at testing - it doesn't appear to me that they have a rigorous and repeatable set of tests to apply to new software
- the BeyonWiz developers have no understanding of how to trap errors before they occur (e.g. use a Try mechanism, or precede the Delete statement with an IF test to establish that the object to be deleted does actually exist). When the Media Manager crashes on trying to delete a non-existent share, this well demonstrates what I mean.

[prl]

Could you post the crash log for any crashes you experienced?

The Mount Manager (and most of the mechanism for dealing with network shares) isn't in the Beyonwiz-managed part of the source code. It's in an Open Embeded (OE) Alliance plugin. But that wouldn't stop me or any of the other Beyonwiz developers to from submitting fixes for the problems you describe.

There are very few Beyonwiz developers. Most of them contribute their skills voluntarily. If you don't think much of their work, you could always contribute your skills to improve the average level

Most of the software in the Beyonwiz T series wasn't developed by Beyonwiz (or even those volunteer developers). The firmware is based on the OE Alliance enigma2 PVR platform (and in particular the OpenViX fork of that firmware base). That doesn't mean that Beyonwiz isn't ultimately accountable in some way for problems with the product, but fixes to the problem will generally be made by the above-mentioned developers.

The problems you were having with characters like space and "." in mount names may be attempts by the plugin to get around various limitations on names in the filesystems that might be shared over Windows sharing, but I'm not sure.

I do know about how to catch and handle Python Exceptions, and I am acquainted with the use of if statements to avoid or handle error conditions (though the method you suggest carries an inherent race condition). I've even posted about it recently.

[Grumpy_Geoff]

I'm using firmware 20170808,

I just tried creating a CIFS share named "1 Recent" to a folder on my Windows 10 box. The space was dropped from the share name and ended up as "1Recent". The share operates fine.

I tried creating another as '2.Recent" and it was named "2Recent". I renamed it using Mountpoints management as "2.Recent".
In Movie List, YELLOW/Location then showed "1Recent", "2Recent" and "2.Recent".
I checked /media/autofs/ and it correctly listed only "1Recent" and "2.Recent". I restarted the UI and it was back to the correct two. I didn't try to access the share "2Recent" that had already been renamed.


I normally have the Movie List Actions setting 'Return to last selected entry' as "yes". I set it to "no" to test. I confirm Movie List always displays the last folder.

[MrQuade]

I own a T2 (Kernel 3.14.2).

The Kernel version is largely irrelevant. You need to report the firmware date if you want to convey what revision firmware you are running (as per Grumpy Geoff's post).

I can't comment specifically on the issues you saw, but there is one thing you need to remember when using the Mount Manager to create mountpoints.

After you have created your mountpoint, and the little messagebox popup appears with a countdown timer, you must *not* hit EXIT to cancel the popup, you should instead press OK. If you press EXIT, then the mount creation is aborted and the job is only half-done. You can end up in a bit of a mess if you have a bunch of half-made mountpoints.

[prl]

...
After you have created your mountpoint, and the little messagebox popup appears with a countdown timer, you must *not* hit EXIT to cancel the popup, you should instead press OK. If you press EXIT, then the mount creation is aborted and the job is only half-done. You can end up in a bit of a mess if you have a bunch of half-made mountpoints.

I didn't know that.

[MrQuade]

I didn't know that.

It was one gocha that bit me *way* back.
viewtopic.php?f=43&t=9620&p=128442#p128442