I've been using Kodi for a number of years, to pull media from a shared computer drive, and I've always had a great time with it.
Never had any trouble connecting to the drive or having Kodi browse my network for content. Up until last week...
Last week, I swapped out my crappy, provider-supplied Android TV box for an Nvidia Shield Pro.
So many things are better now, but I hit a snag after installing the recent Kodi. This problem seems to be a really popular one, but nothing I refer to has helped me to resolve it.
Obviously, the ability to detect and freely browse my network has been removed. Looks like only SMB2 is supported by Kodi.
(I have all 3 levels of SMB enabled on my computer and in Kodi.) No more letting Kodi just find and open what you've already given permission to access.
It's now necessary to input all the network pointers and even user names and passwords. I get that, but it seems this method doesn't work as intended.
I have tried every form of syntax to add my media drive as a network location - IP addresses, server name, shared network path, user+password, no user no password, Windows backslashes, Android forward slashes, on and on - nothing seems to make Kodi happy.
I have given every possible permission to my drive (more permission than I feel is even sensible). Technically, a user and/or password shouldn't even be necessary, but I still give them to Kodi. I've turned off my firewall. I've made sure my VPN service was off. I've checked for any port forwarding issues on my router (though no port forwarding should be an issue with port 8080, which Kodi uses for this). I've looked for every possible thing I can think of that would stop Kodi from seeing my network shares, and I've drawn a blank.
To clarify, I can access everything from outside of Kodi. Other apps on the same device have no trouble getting at my files.
What is going on with Kodi, Windows SMB and shared drives??
If there's a specific syntax that is needed, in order to add a network source, it would be helpful to have that syntax defined and explained more clearly. I'm no stranger to network protocol, but my experience is not helping me see the solution here.
Granted I am sharing from a Mac not Windows but when I recently tried to share a drive with Kodi on a raspberry Pi and a Firestick I could only get NFS to work. SMB would always fail.
(2020-07-17, 01:57)phillie14586 Wrote: [ -> ]Granted I am sharing from a Mac not Windows but when I recently tried to share a drive with Kodi on a raspberry Pi and a Firestick I could only get NFS to work. SMB would always fail.
I wouldn't be surprised to hear it fails on Mac as well. I'm sure SMB operates the same way on both.
At least NFS does the trick for you. In my case, selecting NFS doesn't do anything at all.
Taking a guess - do you by chance have and non standard characters in your password (i.e. anything not letters or numbers, like *s or @s)?
If so, you need to use an 'encoded' password - i.e. (I think) url encoded. E.g.
Actual password:
z@k456yS*m
Encoded version:
z%40k456yS%2am
The best way to do this I have found is to manually edit your
passwords.xml file in your userdata folder, you end up with something like this:
xml:
<passwords>
<path>
<from pathversion="1">smb://192.168.1.51/SharePath</from>
<to pathversion="1">smb://Username:z%40k456yS%[email protected]/SharePath/</to>
</path>
</passwords>
...and note, the paths in these shares seem almost irrelevant. I have some paths that don't even exist in there. It's a little bizarre. I found a reddit post that says this about it:
So...for anyone else who is curious, here is what I found out by looking at the source code:
To decide which record to use:
first, it will try an exact match of protocol://host/first-directory-only in the <from> tag
if no match is found, it will look for any record that starts with protocol://host in the <from> tag, and it will use the last one it finds (based on the order of the records in the file)
Once it finds the record to use, it only grabs the username and password from the <to> field - it doesn't care about the rest of the url at all, nothing else is substituted
So yeah - the paths barely count really.
This need to encode passwords is not documented in the Kodi Wiki anywhere I've ever seen (and I note the Wiki SMB section has been cleared, which makes sense as the SMB info was pretty crap and dated). I am pretty sure it's the cause of a lot of folks issues with SMB (other than Windows itself very sensibly removing SMB1 altogether, as that is a massive worm-able security issue, and should be purged off the planet...).
...all this being said, I'd advise only using SMB if you absolutely must, for anything with Kodi. I've been using Kodi for over 10 years now, and I am quite comfortable in categorically declaring that SMB is a consistent PITA, and consistently slower than other options to boot. I only use it for some PVR stuff that requires it - absolutely everything else I use NFS for (yes, even with a windows server - Hanewin is a rock solid, very performance NFS server that is inexpensive and has been a godsend over the years...). NFS is just way faster - particularly with folders with LOTS of files, e.g. image folders - and just so easy to keep running consistently for years on end...it's the only way to go IMHO.
Well, thank pitch forks and pointed ears!...
I have my shared media running through Kodi again.
I suspected there was a syntax problem here, and there was. I had been trying every conceivable way to state server names, IPs, and paths, according to the actual name and location of my shared drive.
I discovered 2 places where I was getting it wrong.
1) I had to use the damned network path that Windows keeps under its "network and file sharing", which renames the drive I'm using as something other then the mapped letter I assigned to it.
For example, my drive is simply "I:\", "I:", or "I", while Windows gave it a share name of "\\<servername>\#media".
2) I had to get rid of all the usual lead slashes ("/") I would normally use, except to define the server/drive combination. ("<servername>/#media").
Normally, I would enter a computer's actual name ("\\<servername>") or an IP address for "Server", and use the drive letter to point to the shared source (eg. "\I:\Movies"). The shared network path replaces both, and is seen as the "server". So for me, the server was defined as, "servername/#media", and the folder was defined as, simply, "Movies".
I included my Windows user name and password, and my shared drive is flying. I have 5 different categories of shared media running, each with their own network source (entered the way I described), and it's flying now.
I've scaled back the sharing permissions on the drive to something more sensible - just read only for each of the 2 users in the house and for "NETWORK", and everything is still talking in real time, and resumes correctly after power off/on.
I'm someone who has done a lot of Windows/Mac/Linux/etc networking, but this one almost got away from me. I don't even remember the last time the "Shared Network Path" was ever required in even normal Windows networking.
People who don't generally have to "think in Android", need to know the correct syntax to use in these cases, if you're going to do away with the network detection feature. All provided instruction seems to imply so many methods work, when they really don't. And, entering this information on these devices is quite tedious and awkward to be going through all this unnecessary trial and error. It needs to be made clearer how to properly define the server and source folder. I can see people dumping Kodi and going to something like Plex, simply because they feel they'll never conquer this issue.
For me, this issue is solved. Maybe what I've reported here will help some others who are having the same problem I started with.
(2020-07-20, 02:10)Klojum Wrote: [ -> ]Thread marked solved.
You're welcome, Kodi.
Maybe the Wiki can be updated, someday? (Who do we ask for that?)
One page on Windows SMB has been emptied. The "Adding Sources in Windows SMB" page describes stuff that just doesn't work for most people anymore, and never mentions trying the path that eventually solved it for me. The "Shared Network Path" can be acquired by checking the drives "Properties".
I see lots of crying online over this issue that might be abated.
@
AlphaSet
It is a community wiki, so if you have the solution you can update the wiki once you create an account.
(2020-07-20, 03:37)Karellen Wrote: [ -> ]@AlphaSet
It is a community wiki, so if you have the solution you can update the wiki once you create an account.
Thanks for that. It explains a few things I was thinking.
Though I've been using Kodi a long time, I'm a little new to the Kodi "community".
If I find out my "solution" works for more than just me, I will certainly consider refining it for public consumption and get it up there.
(2020-07-20, 03:46)AlphaSet Wrote: [ -> ]If I find out my "solution" works for more than just me, I will certainly consider refining it for public consumption and get it up there.
That would be appreciated, thanks.
I had to clear the Windows SMB page as it was so outdated and advising how to setup using SMB1 that it was in direct contradiction of current warnings and advice that was being issued on this forum.
(2020-07-20, 04:56)Karellen Wrote: [ -> ]I had to clear the Windows SMB page as it was so outdated and advising how to setup using SMB1 that it was in direct contradiction of current warnings and advice that was being issued on this forum.
I'm still of 2 minds about the decision to disable network detection.
Proper permissions keep things locked down enough, while facilitating access where it's needed. At the same time, the common user still hasn't a clue about these things, and companies seem to worry about being liable for their users' failings, so they err on the side of overkill.
(2020-07-20, 02:09)AlphaSet Wrote: [ -> ]1) I had to use the damned network path that Windows keeps under its "network and file sharing", which renames the drive I'm using as something other then the mapped letter I assigned to it.
For example, my drive is simply "I:\", "I:", or "I", while Windows gave it a share name of "\\<servername>\#media".
It's not renaming anything, drive letters will only mean something to that host machine and will mean nothing to anything else on the network. By default it simply takes the hostname and folder name to create the network path, you can however change this by going to
Advanced Sharing ticking the
Share this folder box and providing the share name of your choice, so here you could call the share
I Drive Movies for example.
Any generic Window file sharing tutorial should have been able to tell you this.
(2020-07-17, 04:29)bossanova808 Wrote: [ -> ]NFS is just way faster - particularly with folders with LOTS of files, e.g. image folders - and just so easy to keep running consistently for years on end...it's the only way to go IMHO.
I thought that was no longer the case with SMB3, from what I understand they are pretty evenly matched.
Personally I find SMB extremely easy to setup and never had a single problem with it, whereas I find NFS a lot more complex to config correctly, beside for network security I prefer using username/password authentication which wasn't possible with NFS.
(2020-07-20, 13:24)jjd-uk Wrote: [ -> ]It's not renaming anything, drive letters will only mean something to that host machine and will mean nothing to anything else on the network. By default it simply takes the hostname and folder name to create the network path, you can however change this by going to Advanced Sharing ticking the Share this folder box and providing the share name of your choice, so here you could call the share I Drive Movies for example.
Any generic Window file sharing tutorial should have been able to tell you this.
You're misreading the point.
Network pointing in Windows has a normal path nomenclature in the style of "\\server_name\drive_name\folder_name" or "\\server_IP\drive_letter\folder_name". (In Android, the slashes just go forward.) This syntax is recognized by pretty much all systems, and referring to the shared network path (assigned by, or given to Windows) hasn't really been necessary for a long time. I've connected large networks containing a mixture of Windows, Mac and Unix machines that all needed to share stuff in various ways.
I know what a share path is. I didn't say anything was renamed. Just that the drive letter was replaced in the share path by a "share name", which I don't recall creating myself.
For me, the shared network path is actually "old stuff". I never used it to connect Kodi to my shared media in the past, nor did Kodi use it when I let it detect and add the source. Published instructions for Kodi has never mentioned it, as far as I can see, even after SMB1 support was discontinued. And if you do refer to the basic "tutorials" you're mentioning, you'd see there are supposed to be 2 slashes in front of the server name, and quite often one slash at the end. That was something else I pointed out wasn't working, as I had to eliminate most of them for Kodi to be happy, even with the shared network path entry. Windows shows this path as "\\...\...\". In Kodi, I tried "//.../.../", which didn't work. I changed it to ".../...", and it connected.
But this isn't really so much about "Windows file sharing". It's about accessing stuff with an Android device. As long as the path is stated correctly, and there is permission, the connection should happen, particularly if a username and password are backing it up. Technically, a mapped drive letter should be recognized, and I should be able to either identify my folder with that drive letter and a slash, or identify my "server" with a following slash and drive letter. And it works for every other app on my Shield, except for Kodi. Mapped drive letters work everywhere else. That's the point of mapping them.
My point was, if Kodi needs a special pointer like a "modified" Windows shared network path, there should be some guidance in that direction. So far, I see everyone chasing after the IPs, server names and drive letters, stated the way Kodi might want, and scratching their heads. Like I started doing. Hence my post.
Sorry but you are confused. Only the Windows machine will know what the drive names or letters refer to, they are never ever used by a remote device over a network connection to the Windows machine where the shares are created.