If you don't have a crashlog then look at journalctl (or upload it with "journalctl | pastebinit").
It's a known issue with the current inputstream.rtmp add-on. Will be fixed with 7.90.005, not sure if there's going to be a temporary fix in the meantime.
Normally when people refuse to provide a debug log it's because they're running the crap add-ons that aren't supported here. What are the chances of that being the case here...?
This bug was fixed in Kodi master on 5 Jun fix failing activation of startup window, replaces 94daf3be7539449550… by FernetMenta · Pull Request #9916 · xbmc/xbmc · GitHub - the version of Kodi in your build dates from 6 May.
You can try forcing NFSv4, see the options I'm using, but I'd inagine that is automatically negotiated by the operating system and the server.
Following works for me with FreeNAS:Code
- [ ! -d /storage/freenas ] && mkdir /storage/freenas
- [ ! -d /storage/data ] && mkdir /storage/data
- mount -t nfs 192.168.0.3:/mnt/share /storage/freenas -o $NFSOPTS
- mount -t nfs 192.168.0.3:/mnt/share/data /storage/data -o $NFSOPTS
Your sources.xml looks fine to me.
Something is messed up. Run the following:
and paste the link.
Note that the libnfs library used by Kodi to access NFS filesystems does not support NFSv4 so you'll need to ensure you have an NFSv3 server, otherwise you'll have to use OS NFS mounts in LibreELEC.
What lrusak is saying is that the LE build doesn't support what you are trying to achieve. You'll need to patch the various systemd scripts for kodi, connmand etc. to deploy your files to /storage from within your image. You don't want to copy a folder called "/storage" to your image as that will be very confusing (as LE already mounts a /storage partition), but you could put your own files in a folder called /usr/storage which should then be copied to your image, and then deploy your files from /usr/storage.
However, it's probably a solution that will break at some point when other updates are applied to master, and it might be easier to deploy your static files from a tar file. Presumably you're creating a custom image for more than just these WiFi credentials, as that's a lot of work for something that's fairly trivial.
Why don't you use 192.168.1.0/24 as it says in the Wiki?
I'm not sure if 192.168.1.0/255.255.255.0 will work - what that says to me (and it's only used in a comment) is a network 192.168.1.* configured with mask 255.255.255.0 - not that you should configure the export in that way. I could be wrong, so someone else may have to advise.
And if you want a read-only export, change "rw" to "ro".
and when i search for a nfs share i don't see any, when i put 192.168.1.2/mnt/Cyberdojo to try it, i don't see any....
Not all NFS servers advertise their shares in a way that is compatible with Kodi, unfortunately. My ReadyNAS NFS server would advertise it's shares (I think because it runs a Rendezvous service) but my FreeNAS NFS server does not, so when setting up my FreeNAS NFS shares I simply typed them in and didn't bother trying to navigate using the folders when adding the source in the GUI.
Also, you did restart your NFS server after adding the new share? Some servers/services may need this.
This is how my FreeNAS NFS source looks to me in Kodi:
Once the source is added it's possible to navigate the NFS share in Files, or scan the library (in my example above, all sub-folders/directories below the media folder are accessible to Kodi).
Read only is possible, just configure the NFS export with the "ro" setting. Based on your configuration, the problem is most likely that you've granted access to the wrong IP address.
If you continue to have problems, post your /etc/exports file, and a link to your full Kodi debug log (use a pastebin site for the debug log, then paste a link).
... and here's a crashlog from last Monday ...
based on Milhouse : LibreELEC devel-20160724223031-#0724-geb89f33
The reason for that crash is due to a patch included in the #0724 build (and since removed). Please don't confuse this thread with details from my builds - they are quite different to 7.90.xxx. Crashes or problems with my builds should only be reported in the relevant Kodi forum test builds thread.
Are you sure you meant to restrict access to 192.168.1.0 - that's likely to be an unusual IP address for a LibreELEC client (more likely to be the IP address of your router/gateway). Or did you mean to grant access to the entire subnet, ie. 192.168.1.0/24 in which case you're missed off "/24".
Does the user on your Fedora system have id 1000? What user owns the files in the share, and when logged in as this user on Fedora what is the output of the "id" command?
Glad you got it sorted. I once worked at a firm that deployed 200 Compaq PCs which then experienced strange and intermittent network problems. Eventually we discovered that Compaq had programmed all 200 network interface adapters with the same identical MAC. Fortunately we were able to reprogram them all but that was a PITA... Maybe the same clown that programmed those network adapters is now working at WD!
The problem is that the file system label, "Elements", is the same on both drives so they're both being mounted from the same mount point, /media/Elements. Consequently only the first disk is mounted correctly. The second disk fails to mount correctly because the mount point is already in use.
Solution is to change the file system label on one of the drives. Connect it to a Windows machine and change the label, ie. "Movies". Then both drives should mount correctly, one from /media/Movies and the other from /media/Elements.
Can you boot your Pi with no drives connected, then plug in your movies drive (which presumably will be mounted) to the hub, wait 30 seconds, then (still with your movies drive connected) plug in your TV shows drive to the hub.
Wait another 30 seconds then run the following command, and paste the links:
I would suggest trying the latest LibreELEC x86 test build from this thread: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - these builds are more bleeding edge than 7.90.003.
Once you have confirmed you still have a problem with VC1 material, post a full debug log after playing one of your VC1 movies - enable debug logging, reboot, play your movie, then "cat /storage/.kodi/temp/kodi.log | pastebinit" and paste the link in the test builds thread with a detailed explanation of the problem. One of the Kodi VideoPlayer developers will hopefully then be able to suggest a solution, which will be to post a bug on freedesktops.org, wait for AMD to fix their driver, or if you're lucky there will be a bug fix in VideoPlayer.