Playing a recording sometimes makes UI unresponsive until end of recording

[andrewgreenwood]

Some background to my setup: I had an issue with LibreELEC (Krypton) 8.2.5 MR where Kodi's UI would completely freeze quite often when seeking backwards/forwards with either recordings or live TV. In an attempt to resolve this or at least be able to try and aid with debugging it, I'm trying out alpha builds of LibreELEC and have built it from source on 5th November.

The original problem seems to be gone but now there is something else happening: On some occasions, starting playback of a recording shows a circle in the middle of the screen while the recording plays. This remains on screen until the recording ends, at which point I am returned to the list of recordings as expected. During the entire playback however, I am unable to use the UI at all (can't seek forward/backward or even bring up the play/stop buttons.)

So far I have only experienced this when playing back recordings through the MythTV add-on. Other videos seem to play correctly, though admittedly a majority of the things I play are TV recordings so there is the possibility that this could be a Kodi issue in general.

Hardware is: Raspberry Pi 3 (model B) connected via ethernet (network booted with TFTP/NFS) Kodi version is: 18.0-BETA5 Git:newclock5_18.0b5-Leia LibreELEC version is: devel-20181105114526-e019ab9 9.0 MythTV backend is: 0.28

I manually generated a core-dump on the most recent occasion this happened (it's ~500MB large) but didn't have debug logging enabled at the time. I will try and capture some more of these if useful.

[janbar]

• Yes, the download circle in the middle of screen is a recent kodi-18 issue. I had it few times and I needed to press the touch 'X' to stop the playback (or remote key stop). If you can reproduce this issue then you should open a ticket in Kodi tracker. Also you can generate the debug report from the core dump with gdb. It could be useful for the team. gdb path/to/the/kodi-binary path/to/the/core | tee report.txt

• About freezes using Kodi Krypton, they were known issues from kodi caused by internal dead locks. The team has worked hard to fix those issues in kodi-18. So please don't rollback to kodi-17 ;-).

[andrewgreenwood]

I definitely don't want to go back to Kodi 17 as the freezes were a massive frustration. There is a more severe but separate issue I am having with Kodi 18 and MythTV which I'll report to the relevant place when I have more info (something causing issues with MythTV backend since using Kodi 18).

I'll check if I can stop the playback using the remote next time it happens. Thanks for the suggestion.

Also thanks for the debug report command. I'll collect a few more dumps and open a ticket for the Kodi devs. I'm familiar with using gdb in general but initially didn't realise that Kodi used dozens of threads so it was a pain to go through each one to look at the stack trace.

[janbar]

Do you use the latest release of the addon 5.8.19 ?

For all linux the auto-upgrade of binary addons is disabled and it is in charge of the distro maintainers to provide updated package.

[andrewgreenwood]

I'm using version 5.8.13 of the addon. I can try building a new one from source later on if it might help?

[janbar]

Yes it should be better to use the latest (5.8.19) because it includes a fix for recording api, imo not related with this issue but never say never.

[janbar]

I tested with an old version of the addon without issue on Linux x64. As I can remember the issue occurred quite often on android armv7. I will try it this evening.

[andrewgreenwood]

It seems I may have been using a version below 5.8.13 as today I experienced something that is a known issue (timeline seeking not working). Looking at the file timestamps, the PVR add-on was last updated overnight automatically.

Anyway, I've now built 5.8.19 this evening and am using it now. I'll try and force the problem to happen when I can but there are a few things being watched on TV this evening so it won't be today. I'll update this if/when I have more information.

Just for info on how I built the add-on (partly for my own future reference but it may be useful to anyone else that wants to do this): It seemed easiest to just modify LibreELEC's sources to download the latest commit since its build system also takes care of cross-compiling etc. This involved editing this file in the LibreELEC repository: ./packages/mediacenter/kodi-binary-addons/pvr.mythtv/package.mk ...and replacing PKG_VERSION with the commit along with commenting-out PKG_SHA256.

[andrewgreenwood]

After many attempts, I have made the problem happen with 5.8.13. I've generated a coredump and debug log file (both quite large, I'll upload them somewhere later but am just digging through them myself for now to see what I can find).

I basically just played a recording, stopped it, played it again, etc. over and over.

The only buttons on my remote control that responded were the rewind/forward and play/pause (which would perform those actions) and the numbers. If I pressed numbers, it showed them as time input at the bottom of the screen. I pressed "1" a few times so that it ended up being a time beyond the end of the recording - at which point, playback stopped as it reached the end of the recording and the problem went away.

From a quick look at the window init/deinit log messages, I see DialogBusy doesn't get deinit'ed when the problem happens. So I'm guessing that's the "busy" circle.

Example window init/deinit messages when there is no problem: 00:14:02.173 T:1938247696 DEBUG: ------ Window Init (MyPVRRecordings.xml) ------ 00:14:03.317 T:1938247696 DEBUG: ------ Window Init (DialogBusy.xml) ------ 00:14:03.388 T:1938247696 DEBUG: ------ Window Deinit (DialogBusy.xml) ------ 00:14:09.072 T:1938247696 DEBUG: ------ Window Init (DialogBusy.xml) ------ 00:14:09.853 T:1938247696 DEBUG: ------ Window Deinit (MyPVRRecordings.xml) ------ 00:14:09.854 T:1938247696 DEBUG: ------ Window Init (VideoFullScreen.xml) ------ 00:14:09.861 T:1938247696 DEBUG: ------ Window Deinit (DialogBusy.xml) ------ 00:14:19.292 T:1938247696 DEBUG: ------ Window Init (VideoOSD.xml) ------ 00:14:19.372 T:1938247696 DEBUG: ------ Window Init (DialogSeekBar.xml) ------ 00:14:19.512 T:1938247696 DEBUG: ------ Window Init (Custom_1109_TopBarOverlay.xml) ------ 00:14:21.542 T:1938247696 DEBUG: ------ Window Deinit (VideoOSD.xml) ------ 00:14:21.543 T:1938247696 DEBUG: ------ Window Deinit (VideoFullScreen.xml) ------

When it showed the circle during playback: 00:15:20.985 T:1938247696 DEBUG: ------ Window Init (MyPVRRecordings.xml) ------ 00:15:21.858 T:1938247696 DEBUG: ------ Window Deinit (DialogSeekBar.xml) ------ 00:15:21.971 T:1938247696 DEBUG: ------ Window Deinit (Custom_1109_TopBarOverlay.xml) ------ 00:15:23.569 T:1938247696 DEBUG: ------ Window Init (DialogBusy.xml) ------ 00:15:24.981 T:1938247696 DEBUG: ------ Window Deinit (MyPVRRecordings.xml) ------ 00:15:25.024 T:1938247696 DEBUG: ------ Window Init (VideoFullScreen.xml) ------

Both of the above sets of log entries are from the recording list being shown, to the video being played (so the "deinit" for DialogSeekBar etc. are probably from the previous time I stop playback.)

So it seems it doesn't do a deinit for DialogBusy sometimes (which would normally be followed by an init of VideoOSD, DIalogSeekbar and Custom_1109_TopBarOverlay).

I'll see if I can find anything else out from the logs and coredump. Anyway I mainly just wanted to confirm this is still problematic with the latest version of the MythTV addon (though, as you say, the bug is probably in Kodi itself.)

[janbar]

:+1: Good work ! Yes the DialogBusy still displayed over the playback. Probably a queued job was missed or a job was stopped before closing it.