[Masakari]

Hi,

I'm having a bizarre issue that I'm currently unable to solve. The short story is that any folder/directory created on the SMB share on my NAS by my Raspberry Pi (running Ubuntu) cannot be seen by Kodi running on Windows. When I say cannot be seen, I mean it does not appear in the file manager, nor picked up by library scans but strangely references that are already in the DB can still be resolved. This wasn't happening under Gotham 13.2 or before but has only started impacting me since moving to Helix.

The permissions look identical and if it was a permissions issue, it wouldn't explain why Kodi running on Android accessing the SMB share with the same credentials can see the directories.

Windows explorer can see the directories as normal. From the CIFS/SMB mount on the Pi I can see the directories. From non-Windows Kodi clients I can see the directories but my Windows Kodi clients cannot.

Here you can see an image captured on my Windows Kodi vs my Android Kodi (1st is Windows, 2nd is Android):



1. Version of XBMC = Helix 14.0 Git:20141223-ad747d9
2. Windows Version = Windows 7 SP1 64-bit
3. CPU/Architecture = Various (Core 2 Quad, Core i5 2nd Gen, Core i7 4th Gen)
4. RAM amount = Various (4gb, 8gb, 16gb)
5. Detailed Instructions to reproduce the Problem
Windows PC running Kodi connected to an SMB share.
Raspberry Pi running Ubuntu with the SMB/CIFS mounted.
Using Raspberry Pi, create a directory. Using Windows PC create a directory.
From Kodi File manager, browse the SMB share to where the new directories were created. Only the Windows created directory can be seen.

6. Details of all devices relevant to the problem
I have a Synology NAS (DS412+) and an SMB share where all my media is stored.
I have a Raspberry Pi that is responsible for downloading and categorising using tvnamer to place things in the right directory on the share.
I have multiple Windows PCs, Linux PCs, Raspberry Pi's and an Android device that can all access the same SMB share and MySQL database (also running on the NAS)

7. FULL Debug Log:
debug log

[wrxtasy]

There is something strange going on with Kodi SMB clients accessing remote SMB shares that would previously work in Gotham and now fail in Kodi.
Its now happening across all device types when a user installs Kodi.

Possible Solution is here:
Kodi > Videos > Files > Add Videos > Browse > Add Network Location > SMB > Server name > xxxxx.local > OK
- add username and password if required, leave Shard Folder blank.

There will then be a new - smb://xxxxx.local - added to the "Browse for a new Share" list.
Select that and add the shared folders as required.

If xxxxx.local does not work enter the IP address of the NAS / PC sharing the media over the local network.

[Masakari]

Thanks for the reply wrxtasy but I've found a workaround now.

It seems that Kodi's Windows SMB client is now sensitive to the "System" attribute. I spotted this when looking for the hidden attribute on the directories using the attrib command from dos. It doesn't even show up in Windows explorer anymore! In fact, DOS/cmd.exe sees the same file listing that Kodi does in that all the files with the System or Hidden attributes are not displayed.

To get around this, I need to stop the pi from making any more files / directories with this flag set. I found this article http://forum.synology.com/enu/viewtopic....11&t=50790 that mentions that the umask of 026 will stop this from happening. I tested it and sure enough it worked. Under Ubuntu, it still looks like each file on the SMB share has 777 permissions but from Windows I can see that the System attribute is no longer set. I added the options "dir_mode=0751,file_mode=0751" to my /etc/fstab so that files / directories would not set the System attribute by default.

To clean up the 1000's of files and directories that still had the System attribute set, I modified some powershell I found from heyscriptingguy here:
http://blogs.technet.com/b/heyscriptingg...butes.aspx

It's a little rough as it just sets the archive bit which has the side affect of blatting the System and Hidden attributes (you'll obviously need to map your SMB to a drive letter to use this):

Code:

$files = Get-ChildItem -Path "X:\TV Shows" -Recurse
$attribute = [io.fileattributes]::System

Foreach($file in $files)
{
  If((Get-ItemProperty -Path $file.fullname).attributes -band $attribute)
  { Write-Host -ForegroundColor green `
    "$file.fullname has the $attribute bit set"
    Set-ItemProperty -path $file.fullname -name attributes -value "Archive"
  }
  Else
  { Write-host -ForegroundColor blue `
    "$file.fullname does not have the $attribute bit set"
  }
} #end Foreach

For the Kodi devs, revised steps to re-produce:
1. Windows Kodi client with SMB share defined
2. Set the System Attribute on a directory (ie. from cmd "attrib +S directory")
3. Use the file manager to browse
4. Expected that the directory appears but it does not.

I hope this helps someone else.

[a11599]

This is expected. You should not have "System" attribute set on your media files. This attribute is used to mark system critical files, which your media is obiously not. It is coming from the old DOS days. Though somewhat unnecessary these days; its purpose to hide such system files has been kept in Windows as well. Kodi on Windows uses Windows' native networking features to access SMB shares, like you would browse the share with Windows Explorer.

http://en.wikipedia.org/wiki/File_attribute

[Jogee]

Masakari,

Powershell is great, but seems a bit too much for what you needed to do. Unless I've misread something, which is entirely possible.

Why not use the attrib command from a windows command prompt to process the change for you? It can process subfolders if you tell it to. Something like this:

Code:

attrib -s "X:\TV Shows" /s /d

That will remove the system attribute for all files and folders under the path specified. Type "help attrib" at command prompt for more info. You can mix and match attribute changes as well. You might need to run the command prompt as admin.