[djh_]

I'm finding a number of instances of animations firing upon certain state changes in Kodi where it actually isn't desirable. In this particular example, going to the next or previous track in a music playlist or album is firing whatever uses the Player.HasAudio condition. If my Now Playing widget is up, which does have an opening animation, I don't want that animation repeating over and over as I'm cycling through tracks. Can anyone think of a workaround?

Another such issue involves multiimages. Whenever the MusicPlayer changes track, the multiimages I'm using cycle images irrespective of whatever timings they've been set. That's just weird.

[realcopacetic]

I'm finding a number of instances of animations firing upon certain state changes in Kodi where it actually isn't desirable. In this particular example, going to the next or previous track in a music playlist or album is firing whatever uses the Player.HasAudio condition. If my Now Playing widget is up, which does have an opening animation, I don't want that animation repeating over and over as I'm cycling through tracks. Can anyone think of a workaround?

Another such issue involves multiimages. Whenever the MusicPlayer changes track, the multiimages I'm using cycle images irrespective of whatever timings they've been set. That's just weird.

Would it be possible to do it somehow with a window property to determine when the player is visible/hidden? And only clear the property when player stops rather than on next/previous? Probably something you would already have thought of!

[djh_]

Update: Seems that any change of music track causes not just the home page animations to reset, but also the background multiimage to update. Is it reloading the window or something?

[jurialmunkey]

Have you got some example code? I can't reproduce this issue at all. Player.HasAudio works as expected for me.

I tested by putting this in MyMusicNav.xml

xml:


<control type="image">

    <width>100</width>

    <height>100</height>

    <texture>common/white.png</texture>

    <visible>Player.HasAudio</visible>

    <animation effect="slide" start="1820" end="0" time="5000">Visible</animation>

    <animation effect="slide" end="1820" start="0" time="5000">Hidden</animation>

</control>

I press play on a music track and the box slides slowly from right to left of screen where it waits until I press stop. The animation continues as normal regardless of whether I press pause, skip, change track, fast-forward or rewind.


It sounds like you have some other condition or animation in a parent group/window.

I can't reproduce the multiimage issue either (tried with a randomised imagepath and image stayed consistent).

[djh_]

The problem with the animations firing is precisely due to the Player.HasAudio/Player.Playing visibility condition. It's not just animations, either, because a control with that visibility condition will flicker upon track changes, whereas with visibility set to true that doesn't happen. That control can be outside of any groups and exhibit the same behaviour. It happens no matter what the control or where in the skin that control is placed.

And it happens is Estuary, too. All the fade animations for controls restart when changing tracks. This is in both Kodi Leia stable for Windows and a Milhouse build for Linux.

Update: I'm starting to suspect DialogBusy is the culprit, at least in Estuary. Because I'm pulling most of my content from NFS, it's triggering the busy dialogy whenever I skip tracks. That causes the flicker in Estuary, while in Aeon I don't use DialogBusy and so that xml is pretty much blank. I'm wondering if invoking that window is causing the underlying window contents to refresh somehow.

Update update: Yup, removing the DialogBusy file entirely fixed the issue with the multiimages refreshing. The animations are still firing, though, so maybe that's a separate issue.

Update x3: Whatever the underlying reason, the Player.HasAudio visibility is what's causing the animation problems. Changing that to true will fix whatever control, though obviously that's not a solution.

[jurialmunkey]

Try setting reversible="true" in your Hidden animation. I can reproduce with non-reversible animations.

When switching tracks, it looks like Player.HasAudio is momentarily false (because the player doesn't have audio for a moment) which then triggers the Hidden animation. A non-reversible hidden animation (or not having a hidden animation at all) will force the visible animation to trigger when the control becomes visible again. A reversible animation just walks back the animation frames instead, so since it is only momentary that will mask it.

EDIT: Another work-around is to check instead Player.Playing:

Code:

<visible>!String.IsEmpty(MusicPlayer.Title) + Player.Playing</visible>

@DaveBlake - Do you have any insight into this issue of Player.HasAudio being momentarily false when switching tracks? Seems like a bug to me but maybe it's intentional or not possible to fix...


---

I still can't reproduce the multiimage issue though. Do you have some example code?

[djh_]

Try setting reversible="true" in your Hidden animation. I can reproduce with non-reversible animations.

When switching tracks, it looks like Player.HasAudio is momentarily false (because the player doesn't have audio for a moment) which then triggers the Hidden animation. A non-reversible hidden animation (or not having a hidden animation at all) will force the visible animation to trigger when the control becomes visible again. A reversible animation just walks back the animation frames instead, so since it is only momentary that will mask it.

EDIT: Another work-around is to check instead Player.Playing:

Code:

<visible>!String.IsEmpty(MusicPlayer.Title) + Player.Playing</visible>

@DaveBlake - Do you have any insight into this issue of Player.HasAudio being momentarily false when switching tracks? Seems like a bug to me but maybe it's intentional or not possible to fix...


---

I still can't reproduce the multiimage issue though. Do you have some example code?

That's fixed it! Awesome. Cheers.

As I mentioned earlier, the multiimage issue was caused by DialogBusy popping up briefly, even though I'd pretty much emptied the xml. The multiimages on my homescreen have visible conditions based on whichever option in the wraplist is in focus, so it's possible that DialogBusy was momentarily unfocusing the wraplist when called, causing the multiimage to reload when it closed again. That was fixed by just removing DialogBusy entirely, though plan B would have been to change the wraplist/multiimage behaviour to something like a conditional variable.

[jurialmunkey]

Try setting reversible="true" in your Hidden animation. I can reproduce with non-reversible animations.

When switching tracks, it looks like Player.HasAudio is momentarily false (because the player doesn't have audio for a moment) which then triggers the Hidden animation. A non-reversible hidden animation (or not having a hidden animation at all) will force the visible animation to trigger when the control becomes visible again. A reversible animation just walks back the animation frames instead, so since it is only momentary that will mask it.

EDIT: Another work-around is to check instead Player.Playing:

Code:

<visible>!String.IsEmpty(MusicPlayer.Title) + Player.Playing</visible>

@DaveBlake - Do you have any insight into this issue of Player.HasAudio being momentarily false when switching tracks? Seems like a bug to me but maybe it's intentional or not possible to fix...


---

I still can't reproduce the multiimage issue though. Do you have some example code?

That's fixed it! Awesome. Cheers.

As I mentioned earlier, the multiimage issue was caused by DialogBusy popping up briefly, even though I'd pretty much emptied the xml. The multiimages on my homescreen have visible conditions based on whichever option in the wraplist is in focus, so it's possible that DialogBusy was momentarily unfocusing the wraplist when called, causing the multiimage to reload when it closed again. That was fixed by just removing DialogBusy entirely, though plan B would have been to change the wraplist/multiimage behaviour to something like a conditional variable.

Ah yeah I've had problems with Container(ID).ListItem references and dialogs being active in the past, so your hunch about the multiimage and the wraplist losing focus is probably correct.

[DaveBlake]

@DaveBlake - Do you have any insight into this issue of Player.HasAudio being momentarily false when switching tracks? Seems like a bug to me but maybe it's intentional or not possible to fix...

Poking about in the code, the HasAudio info bool exposes the CApplicationPlayer::IsPlayingAudio() method and that in turn checks if the current player (could be paplayer or videoplayer - both can play music) is playing and has audio only. So I guess yes this could well be momentarily false during switching tracks, after all the playing process does stop between tracks even if playback itself sounds gapless.

I would say this was by design, the code is over 7 years old, although the player events changes in v18 may have resulted in skinners experiencing different behaviour with this. I honestly don't know, I'm the music library guy and player magic was done by others.

I have not read into the issue here, but maybe you want to check that the current playlist has items to play rather than that the player is playing something.

[Hitcher]

I've noticed the busy dialog appearing very briefly when listening to music with the visualiser running and I'm sure this wasn't always the case.

[djh_]

Cheers all.

I think the fact we're only talking about this now probably makes it a non-issue, especially as there's a workaround. Nothing's still affected in my skin, at least.

[djh_]

I've noticed the busy dialog appearing very briefly when listening to music with the visualiser running and I'm sure this wasn't always the case.

It's certainly been the case for a while. I've been taking some epic - and involuntary! - breaks while doing Aeon 2, and I stripped that busy xml out ages ago. At least a year.

[Hitcher]

Tested Krypton and I've not seen it there but it's definitely in Leia.