Threaded Mode | Linear Mode

jakenl · 16th Feb, 2020, 09:38 PM

As of a couple weeks ago Kodi starts to randomly hang while playing audio. Afterwards Kodi (GUI) is completely unresponsive. Even a restart of the service by 'sudo service xbmc restart' takes an awful long time and doesn't result in a working Kodi afterwards. My only solution is a reboot.

I checked out the running mp3 file, but nex time Kodi doesn't have issues playing it. Therefore I enabled debug logging to see if I can catch any additional information, leading to the error. I have added the log from the line where the last just started playing correctly. In the middle of that file Kodi quit on me.

last bit of log file (Click to View)

After such a crash the SSH connection is still responsive, but as soon as I force a 'sudo reboot' the RPI disappears from the network and doesn't come alive anymore, unless I physically pull the plug.

***Nachteule*** · 17th Feb, 2020, 02:36 AM

Nothing suspicious to see ...
Please look into /var/log/upstart/xbmc.log, maybe there are some useful informations

jakenl · 17th Feb, 2020, 06:00 AM

(17th Feb, 2020 02:36 AM)Nachteule Wrote: Nothing suspicious to see ...
Please look into /var/log/upstart/xbmc.log, maybe there are some useful informations

too bad, well I checked the content of xbmc.log, but that doesn't tell me much more:
Sending action: XBMC.Reboot
Feb 16 12:39:06: kodi.bin still alive after 30s, killing it now

I check the previous log file (the 'logrotated' one) and it gives the same 2 lines last week.

***Nachteule*** · 17th Feb, 2020, 07:19 AM

Hmmm, filesystem already checked?

jakenl · 19th Feb, 2020, 03:46 AM

(17th Feb, 2020 07:19 AM)Nachteule Wrote: Hmmm, filesystem already checked?

No, i haven't. I guess I should stop Kodi first and do a manual unmount of the usb device with the data?

Shouldn't a corrupt file not always be corrupt? In my case I have no problem to play the same song after I reboot the rpi

***Nachteule*** · 19th Feb, 2020, 04:03 AM

(19th Feb, 2020 03:46 AM)jakenl Wrote:
(17th Feb, 2020 07:19 AM)Nachteule Wrote: Hmmm, filesystem already checked?
No, i haven't. I guess I should stop Kodi first and do a manual unmount of the usb device with the data?

Shouldn't a corrupt file not always be corrupt? In my case I have no problem to play the same song after I reboot the rpi

I meant the root fs

jakenl · 20th Feb, 2020, 06:53 AM

(19th Feb, 2020 04:03 AM)Nachteule Wrote:
(19th Feb, 2020 03:46 AM)jakenl Wrote:
(17th Feb, 2020 07:19 AM)Nachteule Wrote: Hmmm, filesystem already checked?
No, i haven't. I guess I should stop Kodi first and do a manual unmount of the usb device with the data?

Shouldn't a corrupt file not always be corrupt? In my case I have no problem to play the same song after I reboot the rpi

I meant the root fs

No I haven't done that either. Can you please give a tip how to do that? (I have no SD-card anymore, running from an USB stick instead.

***Nachteule*** · 20th Feb, 2020, 06:58 AM

(20th Feb, 2020 06:53 AM)jakenl Wrote:
(19th Feb, 2020 04:03 AM)Nachteule Wrote:
(19th Feb, 2020 03:46 AM)jakenl Wrote:
(17th Feb, 2020 07:19 AM)Nachteule Wrote: Hmmm, filesystem already checked?
No, i haven't. I guess I should stop Kodi first and do a manual unmount of the usb device with the data?

Shouldn't a corrupt file not always be corrupt? In my case I have no problem to play the same song after I reboot the rpi

I meant the root fs
No I haven't done that either. Can you please give a tip how to do that? (I have no SD-card anymore, running from an USB stick instead.

1st) you have to enable initramfs (can be done in Kodi XBian-Config GUI)
2nd) you have to add rescue parameter in /boot/cmdline.txt
3rd) reboot Pi and after entering in rescue mode run btrfs check /dev/sda2

jakenl · 21st Feb, 2020, 06:51 AM

(20th Feb, 2020 06:58 AM)Nachteule Wrote:
(20th Feb, 2020 06:53 AM)jakenl Wrote:
(19th Feb, 2020 04:03 AM)Nachteule Wrote:
(19th Feb, 2020 03:46 AM)jakenl Wrote:
(17th Feb, 2020 07:19 AM)Nachteule Wrote: Hmmm, filesystem already checked?
No, i haven't. I guess I should stop Kodi first and do a manual unmount of the usb device with the data?

Shouldn't a corrupt file not always be corrupt? In my case I have no problem to play the same song after I reboot the rpi

I meant the root fs
No I haven't done that either. Can you please give a tip how to do that? (I have no SD-card anymore, running from an USB stick instead.

1st) you have to enable initramfs (can be done in Kodi XBian-Config GUI)
2nd) you have to add rescue parameter in /boot/cmdline.txt
3rd) reboot Pi and after entering in rescue mode run btrfs check /dev/sda2

I executed your given commands. After reboot I indeed ended up in the recovery environment. In order to do the fschk, I had to run the command 'rom' to unmount the rootfs before doing the file check.

Luckily / unfortunately I didn't find any errors. I made a picture of the screen:
checking root items
checking extents
checking free space cache
checking fs roots
checking only items (without verifying data)
checking root refs
checking quota groups skipped (not enabled on this FS)
found xxx bytes used, no error found

Afterward, I think I had to enter 'exit' in order to continue boot to Kodi. So far so good, not good since I didnt' find a root cause yet.

***Nachteule*** · 21st Feb, 2020, 06:58 AM

Hmmm, so very difficult to say what the problem is

Kodi has not been updateted for a long time, so must be other reason Confused

jakenl · 8th Mar, 2020, 10:37 PM

My problem is still there. The weird thing is that playing audio fails all the time, but video's play fine. They are both located on different USB-sticks.

Also, I did 2 things in between multiple 'pull plugs' because xbian hangs/can't be accessed anymore:

Did from SSH a 'sudo reboot'. On the screen I see Kodi closing down and it is showing the Xbian log while saying 'unmounting fs'. However, it stays on that screen forever
After another hang up with Kodi, I checked 'df -h' through SSH, but that command makes Raspbian to fail completely, I can't use the cmdline anymore at all.

So, could be this one USB-stick the culprit? What would be the best method to check?
- Put the stick in a Windows PC and do file check?
- Copy the data-backup on pc to my 2nd stick with the video files and check if it still has issues playing form there?

***Nachteule*** · 9th Mar, 2020, 12:06 AM

(8th Mar, 2020 10:37 PM)jakenl Wrote: My problem is still there. The weird thing is that playing audio fails all the time, but video's play fine. They are both located on different USB-sticks.

Ah, ok!

Quote:Also, I did 2 things in between multiple 'pull plugs' because xbian hangs/can't be accessed anymore:

Did from SSH a 'sudo reboot'. On the screen I see Kodi closing down and it is showing the Xbian log while saying 'unmounting fs'. However, it stays on that screen forever

If a process still holds a file open, umount will how work. So, please check which process keeps file open after you have stopped Kodi by running command sudo lsof /mountpoint/of/your/usbstick

Quote:After another hang up with Kodi, I checked 'df -h' through SSH, but that command makes Raspbian to fail completely, I can't use the cmdline anymore at all.

So, could be this one USB-stick the culprit? What would be the best method to check?
- Put the stick in a Windows PC and do file check?
- Copy the data-backup on pc to my 2nd stick with the video files and check if it still has issues playing form there?

Yes, copy files to the 'good' stick would be good idea

Or read all files from that 'bad' stick from the Pi with command

for f in $(find /mountpoint/of/your/usbstick -type f); do echo reading $f; cp -v $f /dev/null; done

plz note that this command can not deal with spaces in filename/dirs

jakenl · 9th Mar, 2020, 08:16 AM

(9th Mar, 2020 12:06 AM)Nachteule Wrote: If a process still holds a file open, umount will how work. So, please check which process keeps file open after you have stopped Kodi by running command sudo lsof /mountpoint/of/your/usbstick

Ah, I wasn't aware of this utility. However, stopping Kodi in these circumstances usually doesn't work. Whether I use 'kodi stop' or 'sudo service xbmc stop' the command won't finish. In normal circumstances these commands work as expected. Good chance that lsof will show a file lock by Kodi on the mp3 file that was playing during the crash, but still interesting to find out.

Quote:Yes, copy files to the 'good' stick would be good idea

I used the 'copy -R method to copy a certain segment of albums to that 2nd stick. I didn't add them to the library yet, to not confuse matters, and now play them by selecting them as files. It is playing as I type and I am now a few tracks further than this morning. Only in the 3rd track I heart a 'scratch' sound. I'll have to see afterwards if I can replicate this when I play the same file from another device on the network, like my laptop.

Quote:Or read all files from that 'bad' stick from the Pi with command

for f in $(find /mountpoint/of/your/usbstick -type f); do echo reading $f; cp -v $f /dev/null; done

plz note that this command can not deal with spaces in filename/dirs

Most albums have plenty spaces in them, but no problem. I have all albums stored on the PC as well and keep it there as a main source of data (with previous crashed USB-sticks in mind).

jakenl · 10th Mar, 2020, 04:13 PM

It must have been the usb stick. Some music tracks didn't even wanted to start when i put the stick in my PC. After a full format I put all the files back on it and now xbian runs fine while playing audio, without crashes.

***Nachteule*** · 10th Mar, 2020, 09:04 PM

Yes, everything pointed to it.

Possibly Related Threads...
Thread:		Author	Replies	Views:	Last Post
	[PROBLEM] Kodi hangs randomly while on playback	guillaumesoucy	6	10,765	11th Jan, 2023 02:32 PM Last Post: celinedion
	Kodi 17.4 is not playing video smoothly.	GastonBA	24	50,524	13th Oct, 2017 04:43 AM Last Post: cairnarvon