[messers]

While playing videos from an NFS share on the same machine as the Kodi instance, I am reliably getting behavior that follows this pattern:

• Screen freezes at a particular frame (same frame upon repeated attempt to play video), simultaneously
  
• audio playback continues, simultaneously
  
• controller and keyboard input both fail to cause results as far as I can hear, simultaneously
  
• HTTP access, Yatse Android app acess, and AndUPnP fail to cause results as far as I can hear
  
• Audio playback eventually stops
  

HTTP, Yatse, AndUPnP hopefully cover all the protocols I could be attempting to control Kodi. If I send the KILL signal to "kodi.bin" then "sh kodi" the screen remains on the mentioned frame, and both become defunct processes. If I attempt to reboot at this time the machine takes a long time to power down, which I interpret as it waiting for these two processes. The screen remains on that frame until power down.

I can post the verbose "all the thingsTM" log file upon request. My initial summary is that I only see a few error level messages regarding a failure on my part to mount the partition with my media on it at first which caused a failure to get the respective NFS shares and a few error level messages about NTP timeouts. There are no critical level messages.

I see a lot of info level messages containing the word Platinum which appear to involve connections to my router on port 80. I think it's UPnP related. /DeviceDescription.xml is being requested.

[FernetMenta]

can you dump the call stack when this happens? seems it hangs somewhere in the gfx driver.

[messers]

can you dump the call stack when this happens? seems it hangs somewhere in the gfx driver.

I'll do that. Your inference seems like a good one.

[messers]

can you dump the call stack when this happens? seems it hangs somewhere in the gfx driver.

Can you point me to more information about dumping the call stack, on Linux, and whether or not I need to recompile?

[fritsch]

gdb /usr/lib/kodi/kodi.bin
set output on rausdamit.txt
run

Make kodi hang. ALT TAB out of kodi back to your gdb window and type into it:

thread apply all bt

and press "return" until no output appears anymore. After that post us the rausdamit.txt

[messers]

gdb /usr/lib/kodi/kodi.bin

My version of Kodi doesn't have debugging symbols. Can I get a compiled version with them that matches my current build, or shall I compile with the symbols?

[fritsch]

That's okay for now - we should at least see something, especially if you add your Debug Log, too.

[messers]

I will provide a debug log for the most recent occurrence. While I ran Kodi via gdb, the hang resulted in my being unable to access its output.

kodi.log

[fritsch]

Also post: dmesg | pastebinit

after that hang has happened.

[messers]

I will post dmesg when the next occurrence happens. Will a new debug kodi.log be necessary?

And I am currently writing gdb stout and stderr to a log so that will be accessible to me this time.

[fritsch]

I can't access the old log :-( - so yes.

[messers]

I can't access the old log :-( - so yes.

OK. May I have some suggestions for sites that'll work with the rather large paste?

EDIT: Link possibly fixed.

[fritsch]

You don't run our kodi. Please install it from our git or ppa.

[messers]

You don't run our kodi. Please install it from our git or ppa.

You're correct. I had forgotten about distro packaging. I will see if I can reproduce this on your PPA build.

[messers]

Here is the debugging log from Kodi.

Here is the GDB log.

Here is the output of dmesg, I thought I'd gotten it right away but I had not. This is from a few minutes later.

While the version used originally was the distribution package on Debian, this information is from a git clone of the xbmc/xbmc.git repository which appears to be Krypton Beta 1.

I failed to mention that the Android version of Kodi available of Google Play (Kodi 16.1 Git:2016-04-24-f6ceced) does not experience these crashes. That's not surprising since the theory is a glx crash.