Problems accessing Humax from Windows computer

The package version is 3.6.25-1 but for reasons that are unclear and designed to confuse it only delivers SMB level 2 support

Samba version 3: SMB protocol version 1, 2 (3.6 on).
Samba version 4: SMB protocol version 1, 2, 3 (4.1 on).


So doesn't the 4 year-old update KB469342 fix the issue? Perhaps the Windows versions in use should be revealed.

Also, the linked article is unclear as to whether the delay mapping solution equally fixes the SMB1 issue that the ProviderFlags key is said to address.

Finally, the 20th century was good, in parts, but why are people still "mapping drives to letters" instead of bookmarking the UNC path?
 
why are people still "mapping drives to letters" instead of bookmarking the UNC path?
Because dealing with long UNC paths is a PITA. Abbreviation is good. Or at least it would be if Micro$oft could make stuff work properly... which they can't, repeatedly.
 
The file manager I use (DOpus) doesn't need to map network drives if the drive shows up by discovery, under "Network". Doesn't the standard file manager do the same? Unfortunately they don't always, and (yet to investigate) my HDR4 has dropped off the network completely (as a share).
 
Finally, the 20th century was good, in parts, but why are people still "mapping drives to letters" instead of bookmarking the UNC path?
Because I am an old dog! ;)

The ProviderFlags fix seems to have cured my problem on a Windows 11 computer, will apply to a win 10 computer later
 
The file manager I use (DOpus) doesn't need to map network drives if the drive shows up by discovery, under "Network". Doesn't the standard file manager do the same? Unfortunately they don't always, and (yet to investigate) my HDR4 has dropped off the network completely (as a share).
With the wsdd2 package being unreliable the humax doesn't always show up under Network, The network drive mapping works even if the Humax doesn't appear in the Network list
 
Back
Top