theothernt / AerialViews

A screensaver for Android TV devices including Nvidia Shield, Fire TV, and Chromecast with Google TV. Inspired by Apple TV's video screensaver.
GNU General Public License v3.0
418 stars 32 forks source link

Exiting Aerial while Kodi is running causes Kodi to quit #59

Closed fexofenadine closed 2 years ago

fexofenadine commented 2 years ago

What were you trying to do... Exit screensaver while Kodi is running/paused

And what actually happened (ie. describe the bug)... Android TV quits back to main menu, opening Kodi again starts from scratch (seems to have force-quit). Other screensavers seem to resume play without quitting playing app/video

What kind of device do you have? (eg. Nvidia Shield, Sony TV, etc)... Nvidia Shield TV Pro

theothernt commented 2 years ago

Thanks for reporting this. I've heard this issue started happening with the latest release, are you able to confirm that and/or possibly try the previous version of Kodi as well?

fexofenadine commented 2 years ago

I certainly can. It's not particularly trivial to perform though as I've been on Kodi nightlies for the last few years (so rolling back is harder). Also I think this has been happening for at least the last few AV builds, I stopped using it awhile back because of this bug, hoping it would resolve itself, so I'm not sure if that's helpful. I will try out a few different versions of each though and let you know how I go

fexofenadine commented 2 years ago

Ok so downgrading as far back as Aerial Dream 0.98.2 still has the issue. It must be something Kodi has changed, or maybe even an OS upgrade...

Will test downgrading Kodi as soon as I have a block of time in the next day or two.

If its the Shield's Android OS, I'm not going to be able to roll that back though I don't think. It's Shield OS 9.0.2 (Android 11). I have a feeling it was working under Android 10 but don't quote me

fexofenadine commented 2 years ago

0.98.2 didn't have the issue when it was first released BTW, so at least we know its a Kodi or Android change thats screwing with AV's operation

theothernt commented 2 years ago

Thanks for all that testing, it does narrow it down a bit. My initial suspicions were...

  1. Memory pressure. When the screensaver starts, the foreground app (Kodi in this case) is asked to suspend and free up some memory but doesn't free up enough so Android kills the app. A crash in the foreground app is more likely, I think.
  2. Player conflict. Something about how Kodi plays videos conflicts with how Aerial Views plays videos (I use ExoPlayer which is provided by Google though). Unlikely, just a guess on my part.

A couple of other things to test if you have time...

  1. The last major release of Kodi. I've read that the latest release (Matrix) is not in the Play Store, but the previous version is?
  2. In Settings > Performance & Debug > Buffer strategy, set it to 'Smaller buffer'
  3. If you're playing 4K or 4K HDR videos, try the 1080p version

Also, do you play videos back locally or from a network share?

fexofenadine commented 2 years ago

Ok np I'll give it a shot

I play my videos using NFS shares from a NAS, with a MySQL (MariaDB) database

It actually seems to quit to menu even if Kodi isn't paused/playing. So it can just be sitting on the list of movies, and will quit out when AV is dismissed

The Shield has plenty of ram so I dont think its resources, but could definitely be the OS backgrounding the app. Its interesting that screensavers like xscreensaver's GLMatrix don't cause kodi to quit though

fexofenadine commented 2 years ago

Ok Aerial Views 1.2.2 is behaving fine with Kodi 19.3 on Android TV 8.0

fexofenadine commented 2 years ago

Sorry, misunderstood what you meant by local/network playback. Yes i typically stream the screensaver videos over SMB locally.

Ok 2 more combos:

Android tv 8.0 (this is my old bravia tv) with Kodi 20 nightly and Android 13 alpha (on pixel 6) with kodi 20 nightly

Both working fine with AV 1.2.2

Could be an Android TV 12 issue, or the Shield itself, or as you say, resources

On the problematic setup, Shield w/ Android 12, Kodi 20, AV 1.2.2, setting the buffer to smaller resolves the issue

Setting the buffer back to default with 1080p videos also resolves the issue

On a separate note, the Play store has version 19.x of kodi (Matrix). The nightlies are 20.0 alpha (Nexus)

theothernt commented 2 years ago

Thanks again for all that testing!

So am I correct in saying that the current 'fix' for this is to use the 'Smaller buffer' setting? and do you play 4K HDR vids formally?

(I may look into changing the default buffer to make it smaller for everyone)

Also, you mention Android 12 on the Shield but is it Shield Experience 9 / Android TV 11 ?

Re: Kodi. It seems like there's a bug. It's normal for apps to suspend or even reduce memory usage while suspending but Kodi seems to have an issue doing that.

Aerial Views does use a decent amount of memory/RAM for video playback but that's that nature of playing video - at some point video frames must be decompressed into a frame buffer, which is what uses all the RAM. If the screensaver were only displaying images or using OpenGL, for example, far less RAM is required.

fexofenadine commented 2 years ago

Yes I'd say there are 2 workarounds, one reduce the buffer size, or two reduce the video resolution. I don't know what the ideal solution there is, but maybe even just some text advice, or changing the default to smaller buffer, with option of increasing it at the user's decision? Is there an impact to having a smaller buffer for all users? Any benefits to setting it larger?

Fuck youre right sorry its Android 11 not 12 I'm exhausted lol

fexofenadine commented 2 years ago

Oh yeah I typically play 4k HDR and/or 4k SDR videos

theothernt commented 2 years ago

Yes I'd say there are 2 workarounds, one reduce the buffer size, or two reduce the video resolution. I don't know what the ideal solution there is, but maybe even just some text advice, or changing the default to smaller buffer, with option of increasing it at the user's decision? Is there an impact to having a smaller buffer for all users? Any benefits to setting it larger?

The buffer setting is only useful for remote connections (ie. over the web) as internet connections and the connection to the server itself can vary. For local playback and LAN playback, it's not really needed. What I'll do is... if you're only playing videos from local storage or the LAN, I'll use a small buffer regardless.

You've done a ton of testing, please take a break 🥳

theothernt commented 2 years ago

Ok, so I've made a small change in the code so that if you're running only local or network videos, the buffer will be set to a small size. That should fix the issue for most people, I hope.

Were you going to report the issue to the Kodi project?

fexofenadine commented 2 years ago

I'm not sure I really know how to describe the issue to them - is it that kodi gets suspended when another app (even a screensaver) takes focus? Is it just RAM-intensive apps do you think?

I meant to add, thanks very much for looking at this, I love all the work you put into this project, it really makes it a pleasure to report things and to use such a quality piece of software

fexofenadine commented 2 years ago

God, it's happening again, I dont think I changed anything. Buffer is still set to smaller, haven't upgraded or reinstalled anything. Don't even think I've rebooted the device.

I can be just on any kodi menu (ie not even playing/pausing a video) and when I dismiss Aerial, kodi restarts

Happy to try anything you can think of but I'm at a loss here.

theothernt commented 2 years ago

It might be helpful to get some logs on what's happening with Kodi, but to do this you'll have to install some Android developer tools, enable developer mode on the Shield, connect to it then save a text file - if that sounds ok? (actually, do check if Kodi has a logs option in it's settings, it may have an option to save

Can you try playing remote videos only (ie. turn off local and network vids)?

theothernt commented 2 years ago

I'm not sure I really know how to describe the issue to them - is it that kodi gets suspended when another app (even a screensaver) takes focus? Is it just RAM-intensive apps do you think?

It might be that. Although if Kodi crashes the instant that Aerial Views ends (ie. you can see it crash then restart right afer the Aerial View window disappears) then it might not be memory related, it would be more related to how Kodi resumes itself after a suspend by the OS.

I meant to add, thanks very much for looking at this, I love all the work you put into this project, it really makes it a pleasure to report things and to use such a quality piece of software

And thank you, I appreciate it. It's been a fun project so far and everyone has been patient and helpful when describing issues, asking for features etc. It's also nice to see the usage stats going up and crash % (which is very small) going down over time 😅

fexofenadine commented 2 years ago

Ok so. Kodi does do its own logging which is nice. It logs to ./temp/kodi.log until it restarts the app, at which point it renames kodi.log to kodi.old.log

After the most recent crash, the last few lines of kodi.old.log are:

2022-06-06 17:48:57.866 T:21615 INFO <general>: Got MEDIA_BUTTON intent: 127, up:false 
2022-06-06 17:48:58.079 T:21615 INFO <general>: Got MEDIA_BUTTON intent: 127, up:true 
2022-06-06 17:52:01.638 T:21649 INFO <general>: NFS: sending keep alive after 180 s. 
2022-06-06 17:53:59.690 T:21649 INFO <general>: CWinSystemAndroid::DestroyWindow

I think the Got MEDIA_BUTTON intent lines is me pausing the video, and the NFS keepalive is likely what it sounds like. The DestroyWindow command, however looks suspicious as hell. Is that coming from the OS?

The next log seems to just show a normal startup sequence so nothing revealing there. I can post the whole log somewhere if you like, though it does have some sensitive stuff in it that I'd need to redact first

I cant seem to reproduce the issue with streamed videos, and today even the issue i am reporting is only happening intermittently (not every single time the screensaver activates), so it's not possible for me to say it only happens with local SMB videos

Hope this reveals something but I don't expect I am supplying enough info

Edit: actually the time stamps in the log support what I was saying, the screensaver is on a 5 minute timeout atm while I'm testing this, and that lines up with the gap between pause and crash

fexofenadine commented 2 years ago

Also interesting to note is that it looks (from the timing) that Kodi is crashing when AV starts, rather than when it ends(?)

theothernt commented 2 years ago

At least to me, it doesn't tell me too much. I don't know if CWinSystemAndroid::DestroyWindow is a normal part of closing a window (destroy is actually a normal term, not always used when something goes wrong eg. onCreate vs onDestroy).

If you want to continue looking into this further, then I'd suggest the advanced logging options mentioned on the Kodi wiki. As you see from the logs above, <general> seems like normal messages, I'd expect to see <error> or Exception being mentioned if things going wrong.

Also, I should have asked before, but is there a reason you're running nightly builds of Kodi? ... as it does imply there will be bugs which get fixed later and are not in the 'stable' release from the Play Store, etc.

fexofenadine commented 2 years ago

The issue seems to have resolved itself, I dont know what I did that did it. It may have been preventing "Energy Optimisation" of both apps. I'm happy to close this issue. Thanks for taking the time to investigate it.

WRT the Kodi nightlies, I like trying out new stuff so that was why I originally installed it. Unfortunately it's a complete pain to revert to stable because I use a SQL db and every update migrates the existing data to a new instance which isn't backwards compatible. If i use an older db version at this point it's going to involve significant data loss. Additionally, Android doesn't allow downgrades, so I need to uninstall it first, which would mean doing significant work to get it back to the configuration that I'm used to. I'll be installing the next stable that supercedes my nightly but no idea how long that will take (I did this previously but accidentally out of habit installed a nightly over it and got back into the same pickle).

So TL;DR it's laziness primarily

theothernt commented 2 years ago

Thanks for persisting with the issue but glad it worked out 👍🏻