search

xbianonpi / xbian

XBMC on Raspberry Pi, Bleeding Edge
https://xbian.org
GNU General Public License v3.0
294 stars 44 forks source link

Xbian/Kodi not keeping NFS connection alive #687

Open Smultie opened 9 years ago

Smultie commented 9 years ago

My NAS is set to hibernate after 20 minutes of no activity. I found that watching a movie from my NAS, through an NFS share, is not keeping the connection alive. My NAS goes to sleep and Xbian crashes, not even reacting to SSH.

Anyone with a possible solution?

RPi2, fully updated Synology DS213 Kodi 14.2-BETA2 Git:2015-02-25-c4ce8e3-dirty

mk01 commented 9 years ago

@Smultie

and Gotham was running ok on the same setup ? XBMC is (and always has) closing idle connections, but never caused this troubles.

do you have the NFS mounted on RPI, or you just have defined remote source pointing to NFS in XBMC ?

Smultie commented 9 years ago

@mk01 I'm not 100% sure Gotham worked okay, but I can't remember the issue ever happening before. I must say the issue only occurs after I've paused the movie/tv-show I'm watching, so that might be another pointer in the right direction.

I've just defined the remote sure in Kodi, so no fancy fstab stuff.

mk01 commented 9 years ago

@Smultie

ok, then what you described is exactly what is expected to happen. it was like this (on RPI) since I remember - even I remember some nasty discussions why RPI is not better for its purpose than ATV1/2 (and the reason was supposedly impossibility to return back to TV after hours and just press "PLAY").

what I'm not sure - is that it is "RPI" only (for sure not). IDLE connections are closed after some period of time by default (no platform dependent). while reading xbmc source, the idle test happens each 500ms for all of this:

in general all that (and no more) is exactly what I know about this. never was looking more into it because no personal interest (I use ldap pushed domain wide automount lists - what means XBMC clients do use LOCAL folders - which are auto mounted on request) and considering XBMC this is the way it works and always worked (what I remember).

while reading the code further it looks like XBMC should keep some small reads as keepalive for the open files, but that that for sure depends on DVDPlayer handling of pause (too much code to read in one evening). could be that it simply is just strange combination of factors (with your NFS server).

I suppose it is worth opening a topic at xbmc forums and simply ask - how it should be (the programmers expectation). then we (you) have a point/fact to start from.

Smultie commented 9 years ago

Thanks for your extensive reply @mk01. One last remark, which might be Xbian related ISO kodi-related is the fact that when above situation occurs, I can't access the Pi over SSH anymore. While I somehow can understand the fact that hibernate crashes Kodi, I can't really fathom why it would also bring the complete OS to its knees.

mk01 commented 9 years ago

if I understand it right:

  1. you play movie from XBMC source NFS -> which is NAS
  2. you hit PAUSE and forgets about RPI
  3. after a while, NAS sleeps (hdd down, eth down?)
  4. you remembers RPI again and wants to PLAY movie (continue)
  5. but RPI is dead too ?
Smultie commented 9 years ago

Yeah, that's basically it.

1) Watch movie/tv-show 2) Take a shower 3) Come back, resume 4) Pi crashes, won't reply to CEC/SSH/etc. Have to replug the power to get it to boot again.

On Fri, Feb 27, 2015 at 12:47 AM, Matus Kral notifications@github.com wrote:

if I understand it right:

  1. you play movie from XBMC source NFS -> which is NAS
  2. you hit PAUSE and forgets about RPI
  3. after a while, NAS sleeps (hdd down, eth down?)
  4. you remembers RPI again and wants to PLAY movie (continue)
  5. but RPI is dead too ?

— Reply to this email directly or view it on GitHub https://github.com/xbianonpi/xbian/issues/687#issuecomment-76300745.

mk01 commented 9 years ago

@Smultie

https://github.com/xbmc/xbmc/issues/6278

and I have seen more, just cant find now again. that seems more to be symptomatic than random - although highly possible that limited to a final number of combinations (xbmc vs DEVICE/TYPE/MANUFACTURER/whoknows).