Mountpoint "Use as HDD"

[MrQuade]

MrQuade also has a V2 that can be used to test "Use as HDD replacement" on a diskless box without opening it.

Hint noted btw I will see if I have some time over the long weekend to have a go.

[prl]

Thanks.

[Grumpy_Geoff]

MrQuade also has a V2 that can be used to test "Use as HDD replacement" on a diskless box without opening it.

As long as there's no microSD card inserted and using AUTOFS
If fitted, he'll have to mount the share using "use as HDD" option as the FSTAB type, as the microSD mounted as /media/hdd won't permit the use of the AUTOFS type.

[prl]

OK, picky, but really I don't count a V2 with a microSD recording drive as "diskless".

[prl]

On another matter, I discovered in other testing that AutoMount.removeMount() and AutoMount.removeMountFinished() are quite a mess (now fixed).

The original code looked like it was supposed to just do the minimum to unmount the share and remove the share from automounts.xml and the system files, but that was badly broken, so the code was changed so that it processed the whole automount table But it didn't get that right, either, so that if there was more than one mount, and a mount was deleted, some of the remaining mounts were marked as not mounted, even though they were.

One of the code's features gets my "hardest way ever to remove an entry from a Python dict" award:

Code: Select all

removeMountEntry(self, mountToRemove):
	automountstmp = {}
	for sharename, sharedata in self.automounts.items():
		if sharename != mountToRemove:
			automountstmp[sharename] = sharedata
	self.automounts = automountstmp

rather than:

Code: Select all

removeMountEntry(self, mountToRemove):
	if mountToRemove in self.automounts:
		del self.automounts[mountToRemove]

The actual loop in AutoMount.removeMount() has a whole bunch of other code in it (some of which is badly wrong), which hides that that's basically what the loop is doing, but that's the bit that removes the entry from the internal version of automounts.xml. There doesn't need to be a loop for the other things that the code needs to do, either.

[peteru]

Not surprising, since a lot (perhaps most) of the Python code has been written by people who were either new to Python at the time or even new to programming.

[MrQuade]

I have had a quick play with this patch and some bits seem to be working much better.

I definitely can't see any difference between pressing OK, EXIT, or letting the confirmation popup timeout, so we can scratch that one off the list as "inexplicably sovled".

Here's a third NetworkBrowser alpha patch for the following bugs:
#740: Apparent failure of "Use as HDD" on autofs network mounts

Haven't tried playing with this feature yet.

#741: Some network mounts are not correctly recognised in MENU>Setup>Network

The mount status did appear to be consistent between the two screens in all tests.

#742: More than one network mount can be set to Use as HDD replacement
#743: After disabling "Use as HDD" on autofs network mount symlink is not removed

Will get to these ones too.

#744: The mounted/unmounted icon sometimes doesn't update for AUTOFS network mounts

I didn't spot any inconsistencies here, but didn't specifically test for it.

#745: Buggy sort order in Mountpoints management
#746: [NetworkBrowser] Problems with default options

Didn't test these. Required a bit more under-the-hood checks, but assume prl is able to verify these adequately already.

#747: [NetworkBrowser] Problems with username/password requests

Working as expected. Unexpansion provided no prompt, but re-expansion prompted again.....very handy for misclicks.

#748: [NetworkBrowser] Inconsistency on mount update popups

Yep, all good there. no matter how the popup was dismissed.

#749: [NetworkBrowser] Incorrect share sometimes selected in Network Browser

This one also seems to work nicely now.
Note that having same-named NFS and CIFS shares may or may not be good practice, but it is the default arrangement for QNap NAS devices, and I suspect will be similar on other consumer NAS devices.



I found a new bug though. Or at least one that has not been reported to date. it has to do with deletion of failed mounts.


Say I have a number of mounts to a server that are all configured and working. Some are NFS and some are CIFS.

I then create a mount to a share, and save it, but I do not have permissions to access that share, so the mount fails.

It shows up correctly as failed, and all other mounts to that same server continue to work fine.

If I then go and delete that failed mount, then one of the other working mounts, specifically the one listed immediately before that deleted failed mount will then itself fail.

If I open up the newly failed mount, and re-save it, it starts working again.

I didn't dive into the config files to try to work out what was going on there, but it did seem that deleting a failed mount would poison it's preceding neighbour somehow. It didn't seem to matter if that preceeding mount was CIFS or NFS, both types would fail.

[prl]

Say I have a number of mounts to a server that are all configured and working. Some are NFS and some are CIFS.

I then create a mount to a share, and save it, but I do not have permissions to access that share, so the mount fails.

It shows up correctly as failed, and all other mounts to that same server continue to work fine.

If I then go and delete that failed mount, then one of the other working mounts, specifically the one listed immediately before that deleted failed mount will then itself fail.

If I open up the newly failed mount, and re-save it, it starts working again.

That sounds like the bugs in AutoMount.removeMount() and AutoMount.removeMountFinished() that I have nearly fixed. If it is that bug, the NetworkBrowser screens will show failed mounts, but in fact the mounts will not have failed.

[prl]

I'm off for two weeks holiday in the Kimberley, and I won't be doing any Beyonwiz stuff while I'm away. I'll be back on 11 May.

[MrQuade]

That sounds like the bugs in AutoMount.removeMount() and AutoMount.removeMountFinished() that I have nearly fixed. If it is that bug, the NetworkBrowser screens will show failed mounts, but in fact the mounts will not have failed.

In my case, the mounts actually failed.

[Paul_oz53]

I'm off for two weeks holiday in the Kimberley, and I won't be doing any Beyonwiz stuff while I'm away. I'll be back on 11 May.

Enjoy the break Peter!

Regarding AutoMount.removeMount(), I don't know if it's relevant or not but I have noticed on the Lounge U4 a "phantom" mount.

In auto.network there's an entry

Code: Select all

Study -fstype=cifs,user=,pass=,rw,iocharset=utf8,cache=loose ://192.168.1.117/StudyU4

which does not exist in automounts.xml.

The entry, if it were activated, points to a non-existent folder. Realizing that, I deleted the entry using the Mount manager some time ago. That it persists in auto.network suggests that its removal was not executed correctly.

I have since taken steps to rectify the error but it made me wonder if some sort of consistency check between auto.network and automounts.xml should be implemented.

It may be that the inconsistency is a result of the bugs now being addressed by prl and, going forward, the error should cease to arise. If so, it may be a case of "belts and braces" if a consistency check is implemented but it would be good to know that it has been considered if it is not implemented.

[MrQuade]

I'm off for two weeks holiday in the Kimberley, and I won't be doing any Beyonwiz stuff while I'm away. I'll be back on 11 May.

Have fun. Make sure you visit Matsos Brewery if you travels take you near Broome!

[MrQuade]

Ahh damn.

I forgot to uninstall this patch from my V2 prior to the latest update. (fortunately not the "production" PVR)

There is some interference with the update, so will need to install from USB again I think.

I guess a reminder to prl to re-base the patch when he returns from his holiday .

[peteru]

I had a bit of a peek at the whole mess that is the "use as HDD replacement" option. In my opinion, this should have never existed. I've also encountered a few comments from people involved with other distros that pretty much agree that this is a "Dumb Idea"™

I think the smartest way forward is to remove this option and simply provide a "How To" guide for people who want to run diskless and record to a network drive.

[MrQuade]

I don't have a problem with that. Though the other browser fixes are still very worth having .

[peteru]

Yes, definitely. That whole plugin is a horrible mess.

I would not mind seeing a more user friendly "option editor", where you can select some common options from lists. For example "read-only, read-write" and "SMB1, SMB2, SMB3, default".

[Paul_oz53]

Yes, definitely. That whole plugin is a horrible mess.

I would not mind seeing a more user friendly "option editor", where you can select some common options from lists. For example "read-only, read-write" and "SMB1, SMB2, SMB3, default".

Couldn't agree more. Use as hdd replacement is easily replaced by setting explicit save locations.

Being able to quickly edit options as you suggest is also a welcome idea.

[prl]

Sorry that I haven't kept up with the discussion here. I fell on one of the walks on our Kimberly trip and cut my leg up quite badly, though fortunately no broken bones and I was able to walk out after I'd been patched up a bit. I've been on "rest with leg elevated" since I got back, which is pretty incompatible with doing much on the computer.

Today I got cleared to use my leg normally, though "no 5km runs"

I should get back onto the stuff I've been doing on the NetworkBrowser plugin in the next few days.

[prl]

I tend to agree with peteru that the "Use as HDD replacement" option was a bad idea, but I think that it can be made to work reasonably well - many of its problems are tied in with a more generic problem of NetworkBrowser not correctly handling changes in its parameters that cause changes in the mountpoint of the share.

But in cases where "Use as HDD replacement" can't be used (automount share used for HDD replacement when the box has an existing real HDD mount), there should be clear feedback given about the failure, and I haven't worked out how to do that cleanly yet.

[peteru]

At the end of the day, the existing approach to the "HDD replacement" functionality is a system administration policy issue that does not belong in an application. I think that trying to implement the option by going down the path of stuffing around with mount points is a bad choice. As the saying goes, "It's never too late to turn back when you are on the wrong path."

As far as I can see, the main purpose of this option is to easily switch all the default paths that would normally point to the HDD to point to a different place. Specifically, the mount point of a network share. In my opinion, this should be accomplished by having the enigma2 code only use paths that are constructed using variables. When that is done, changing the default location for volatile storage should be simple enough.

There are very good reasons to not change the mount points at the system level. One of the most obvious is the interaction with other software running on the system, such as the DLNA and SMB servers.

Having said that, I think that the existing mechanisms used to change the recording and timeshift locations should be sufficient to achieve the functionality. My vote would be to remove the "Use as HDD" option, test the correct operation of the existing mechanisms for changing default locations and then write a short how to guide to setting up for "diskless" operation. Less code complexity, less potential for unexplained issues due to complex and uforeseen interactions and greater understanding of the system configuration by the end user.

[peteru]

I fell on one of the walks

Welcome back!

Sorry to hear about your adventures taking the wrong turn. I hope you make a full and speedy recovery.

[Gully]

Sorry that I haven't kept up with the discussion here. I fell on one of the walks on our Kimberly trip and cut my leg up quite badly, though fortunately no broken bones and I was able to walk out after I'd been patched up a bit. I've been on "rest with leg elevated" since I got back, which is pretty incompatible with doing much on the computer.

Today I got cleared to use my leg normally, though "no 5km runs"

Sorry to hear about this but glad to hear you are well on the mend.

[prl]

Thanks

[Paul_oz53]

Sorry that I haven't kept up with the discussion here. I fell on one of the walks on our Kimberly trip and cut my leg up quite badly, though fortunately no broken bones and I was able to walk out after I'd been patched up a bit. I've been on "rest with leg elevated" since I got back, which is pretty incompatible with doing much on the computer.

Today I got cleared to use my leg normally, though "no 5km runs"

Sorry to hear about this but glad to hear you are well on the mend.

+1 - My housemate has had surgery on her ankle so I can empathize.

[prl]

Sorry that I haven't kept up with the discussion here. I fell on one of the walks on our Kimberly trip and cut my leg up quite badly, though fortunately no broken bones and I was able to walk out after I'd been patched up a bit. I've been on "rest with leg elevated" since I got back, which is pretty incompatible with doing much on the computer.

Today I got cleared to use my leg normally, though "no 5km runs"

Sorry to hear about this but glad to hear you are well on the mend.

+1 - My housemate has had surgery on her ankle so I can empathize.

I performed the surgery on myself, using large rocks

[Gully]

I performed the surgery on myself, using large rocks

That sounds like your first mistake! Or was it your second one!