Hi,
I have some strange NFS issues which might have popped up after the October update.
I’m running Emby with the Emby for Kodi addon to sync the library. Previously I was using the direct path option (the nfs-path is shared to Kodi) and this worked quite well but I had some issues where the progress between Kodi and Emby was not in sync. So I switched to the Add-on option (playback is through a http-stream from Emby). This also did not work as I wanted to last week I switched back to the old direct setup with NFS.
The next morning I discovered my Movies and TV Series were empty. Strangely enough the Music-library was still there. I resynced and everything popped up again. Everything played again. Strangely enough the next morning the issues resurfaced. I’ve tracked it to this:
2020-11-02 00:00:01.378 T:3807457504DEBUG: Skin Helper Service --> Kodi_Monitor: sender plugin.video.netflix.SIGNAL - method: Other.library_auto_update - data: ["bnVsbA=="]2020-11-02 00:00:01.390 T:3790672096DEBUG: Skin Helper Widgets --> Kodi_Monitor: sender plugin.video.netflix.SIGNAL - method: Other.library_auto_update - data: ["bnVsbA=="]
2020-11-02 00:00:01.479 T:3807457504DEBUG: Skin Helper Service --> Kodi_Monitor: sender plugin.video.netflix.SIGNAL - method: Other._return.library_auto_update - data: ["xxx="]
2020-11-02 00:00:01.508 T:3790672096DEBUG: Skin Helper Widgets --> Kodi_Monitor: sender plugin.video.netflix.SIGNAL - method: Other._return.library_auto_update - data: ["xxx="]
2020-11-02 00:00:01.608 T:3807457504DEBUG: Skin Helper Service --> Kodi_Monitor: sender plugin.video.netflix.SIGNAL - method: Other.request_kodi_library_update - data: ["yyyyyyyyyyyyyyyy="]
2020-11-02 00:00:01.609 T:3790672096DEBUG: Skin Helper Widgets --> Kodi_Monitor: sender plugin.video.netflix.SIGNAL - method: Other.request_kodi_library_update - data: ["yyyyyyyyyyyyyyyy="]
2020-11-02 00:00:01.680 T:2330243296DEBUG: Thread JobWorker start, auto delete: true
2020-11-02 00:00:01.682 T:4072505360DEBUG: ------ Window Init (DialogNotification.xml) ------
2020-11-02 00:00:01.708 T:2330243296 NOTICE: CleanDatabase: Starting videodatabase cleanup ..
2020-11-02 00:00:01.716 T:2560622816 NOTICE: EMBY.objects.monitor -> [ xbmc/VideoLibrary.OnCleanStarted ]
2020-11-02 00:00:01.756 T:3807457504DEBUG: Skin Helper Service --> Kodi_Monitor: sender xbmc - method: VideoLibrary.OnCleanStarted - data: null
2020-11-02 00:00:01.756 T:3807457504DEBUG: Skin Helper Service --> Kodi_Monitor: sender plugin.video.emby - method: Other.ReportProgressRequested - data: [{"Report":false}]
2020-11-02 00:00:01.771 T:2330243296DEBUG: NFS: Context for 192.168.1.2/mnt/Movies not open - get a new context.
2020-11-02 00:00:01.815 T:3790672096DEBUG: Skin Helper Widgets --> Kodi_Monitor: sender plugin.video.emby - method: Other.ReportProgressRequested - data: [{"Report":false}]
2020-11-02 00:00:01.823 T:1805357280 NOTICE: EMBY.hooks.monitor -> -->[ q:monitor/ReportProgressRequested ]
2020-11-02 00:00:01.908 T:2330243296DEBUG: NFS: Connected to server 192.168.1.2 and export /mnt/Movies
2020-11-02 00:00:01.908 T:2330243296DEBUG: NFS: chunks: r/w 131072/131072
2020-11-02 00:00:01.910 T:2330243296DEBUG: CUtil::GetMatchingSource: no matching source found for [nfs://192.168.1.2/mnt/Movies/XXXX.YYYY/XXXX.YYYY.mkv]
# showmount -e 192.168.1.2
Export list for 192.168.1.2:
/mnt/Movies (everyone)
I’m not sure what is starting the Database clean.
The movies play through the NFS-share without issues and I can mount it and access the path so I don’t know why I get this error.
Any ideas?
In My OSMC>network is the “wait for network” option checked. If not I would try that. There is also an option in `settings>system>power saving" to set the network timeout but I don’t remember how those two options differ and which would be the one to use. Ultimately it looks to be an Emby add-on issue. A clean library initiated from Kodi asks if you want it to delete your library if a source goes missing and apparently this add-on is lacking that same courtesy.
I don’t think this is a connectivity issue. I’ve had my DB cleaned out while I was playing a movie… the movie kept playing till the end and when it finished and got back to the main screen the entire DB was empty with the exception of the movie I was playing 
On a second glance at your snippet I see there is suspecious looking path [nfs://192.168.1.2/mnt/Movies/XXXX.YYYY/XXXX.YYYY.mkv]. I have never touched Emby but i’m guessing that they are translating paths from one into the other as part of this linking process and “mnt/” is getting added when it shouldn’t (or alternatively nfs://192.168.1.2 shouldn’t be there).
I you look at the showmounts it is the full path of the share (I’m running FreeNAS and all is mounted on /mnt). I can manually mount the share mount -t nfs 192.168.1.2:/mnt/Movies /mnt and it will give me full access to the share.
Kodi would normally treat a kernel-mounted share as if it were a local resource. The underlying file system protocol is handled by the operating system. The format nfs://192.168.1.2/mnt/Moves is what we normally see in sources.xml.
I would try increasing the timeout anyway. It looks like it only waited 2ms between being connected to the share and deciding that file wasn’t there.
Congratulations! I see you’ve been a member of this forum for over 5 years. Not bad going.
So to celebrate this splendid anniversary, could you provide us with some logs? 
2 Likes
Yes, 5 years and I know there’s the grab-logs tool and to be honest I was waiting for this reply… It was also the standard answer our 1st line gave to customers when there was an issue: I worked for years in support where we had a tool that grabbed 1000’s of irrelevant information from the customer’s system in order to get 1 relevant thing. I hated when newbies would ask a customer to run it just to get the type of a broken disk…
So I tend not to like scripts like that and try to provide relevant information. 
Working in security/privacy I don’t really like to use such an intrusive tool which publishes information freely available to anyone on the internet. And censoring my ENTIRE catalog that is being erased in the log-file is not something I’m jumping to do
So I’ll put my Vero in debugging again around midnight and see how much of a hassle it is to clean the output.
Fair enough. So are you using a Kodi-based mount or kernel based mount? (I think I might have misinterpreted the situation, something which would, of course, have become clearer with logs.)
Sorry to be such annoying about this. Happy to provide logs but only those that are needed.
I’m not mounting any share on my Vero via the kernel; all is done by Kodi. Emby shares the nfs-path to the files. When I play a file it shows so:
2020-11-04 22:35:46.549 T:4071886864 NOTICE: VideoPlayer::OpenFile: nfs://192.168.1.2/mnt/Shows/XXXX.YYYY/Season.01/XXXX.S01E01.YYYY.mkv
So this works without issues. But this was from the debug log I created 2 days ago for the same file:
2020-11-02 00:00:43.663 T:2330243296 DEBUG: CUtil::GetMatchingSource: no matching source found for [nfs://192.168.1.2/mnt/Shows/XXXX.YYYY/Season.01/XXXX.S01E01.YYYY.mkv]
This really gets me puzzled. To play the file the share works but upon clean it doesn’t? This has been going on for a couple of days now. I can kernel-mount the share and access all the files, it plays without issues from Kodi but around midnight some script (I suspect script.skin.helper.service) launches a clean on the DB and starts erasing everything.
As a veteran of this forum you know the score as well as anyone. It is a standard refrain on this board that we cannot be expected to work with snippets, yet you have done exactly that and are asking us to provide answers without providing us with the means to do so. I don’t know why you are having the problem and I have no way of knowing. Please reconsider your position.
Sorry. Wouldn’t reconsider… but in other news my DB just wasn’t cleaned out. Not for 100% sure what the cause is (I will do some more tests tomorrow) but I think this was the issue:
Emby adds to sources: smb:// and http:// to sources.xml but not nfs://
I added it manually:
<source>
<name>Emby</name>
<path pathversion="1">smb://</path>
<allowsharing>true</allowsharing>
</source>
<source>
<name>Emby</name>
<path pathversion="1">http://</path>
<allowsharing>true</allowsharing>
</source>
<source>
<name>Emby</name>
<path pathversion="1">nfs://</path>
<allowsharing>true</allowsharing>
</source>
If so, I will report this back to the Emby for Kodi guys so they can fix it.
Confirmed this is the fix. Ran texturecache.py vclean and the library stayed intact; removed the line, restarted Kodi and ran the same command: library got cleaned. Added the line again and repeated: library intact.
I’ve informed the developed of the Emby for Kodi addon of this bug.
Thanks for the assistance.
1 Like