Renamed entries in ModSettings but old ones remain in Shares

[geordie]

I am connecting my Hummy to a couple on NAS drives and I decided to rename the connections. The ModSettings entries are correct and the folders have the right names but the Shares folder has entries for the new names and the old ones.

Will the old Shares entries go? They are still there after 4 hours. The Hummy was restarted for other reasons and they are still there. I definitely don't want to delete the old shares folders because I think it will delete my remote stores (when I click on the old names, I can see the files).

Any ideas?

 

[Black Hole]

This should have been posted in the Custom Firmware section, but I've asked for it to be moved.

What you describe seems very odd, I am a network-shares-automount user but I can't say I have seen hang-over shares survive a reboot. Of course, you might only think you've done a restart: just putting it into standby and out again isn't enough unless the boot splash screen gets displayed. You have to wait for disk activity to stop and the HDD to be powered down, as signalled by the USB +5V and the Ethernet lights (if in use) going off. If the HDR is within 15 minutes of making a recording, or if it goes into delinquent half-awake, that won't happen.

The reliable ways to reboot are to power-cycle (switch on the back), or WebIF >> Diagnostics >> Reboot.

 

[Black Hole]

Did that solve it?

 

[geordie]

I tried a reboot like you said and the old names are still showing.

For one old link, it still points to the new link.

For the other old link, it doesn't seem to point anywhere. It shows an empty folder.

I will leave it and see what happens. They old link names in the Shares folder are a pain but not critical. I just cannot risk removing them because I don't know what it will do.

 

[Black Hole]

I've just realised you are using shareFolder=on. That is a complete no-no so far as I am concerned, my advice is to leave shareFolder=off and only access the external shares as virtual USB devices (Media >> Storage >> USB).

shareFolder=on creates a folder with a redirection to the external share, so (as you suspect) using standard tools to delete it will succeed in recursing the share and deleting the files on that. The cross-linking also confuses the available space calculation, and the DLNA indexer will recurse it inappropriately (the Humax firmware was not written to cope with that kind of situation, all it knows is there are a load of files in its file system).

The USB list works dynamically according to [Modsettings], if it lags for some reason a reboot sorts it. There is no facility to delete whole USB mounts.

I have no idea how virtual links to shares get updated, but I guess something has been left behind. What I suggest you do is turn off the external share device (thus preventing access), or disconnect the network, and then delete the offending item in the file system (or, in my view, delete the lot!).