Kodi Community Forum

Full Version: Possible bug using playlist rule within skin structure
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi all,

I've been toying around with modifying the Estuary skin for my own use, but I don't believe this is a skinning issue, so I thought I should post here. Apologies if I've chosen the wrong forum, but I don't believe this to be skin or OS-specific. In any case, I'm not sure if this is a bug or if it is working as intended, but I'm having an issue with using the "playlist" rule when trying to merge playlists. It seems if the playlists I'm referencing are in the skin's "playlists" folder, then they appear to be either ignored or not found, however if the referenced playlists are in Kodi's profile/playlists/video folder, then they work just fine. Is there any way to incorporate those playlists to work while being included with the modified skin, or will I have to maintain the referenced playlists externally to the skin?

For example, on my home screen, I have an "Animation and Family" section that displays random family and animated movies. The smart playlist for "Animation" and the one for "Family" are in the "profile/playlists/video" folder, and the combined playlist that references them both is located in the skin's "playlists" folder. If I move the animation and family playlists into the skin's "playlists" folder, then the smart playlist that combines them for display does not properly detect and/or utilize them, and the returned results are wrong (in the case of match=all) or no results at all (in the case of match=one). If those playlists are external to the skin (in the profile/playlists/video folder), then they all work as they should.

So my question is, is this behavior a bug? Should playlists be able to be referenced whether they are part of the skin or not, when being combined, or are they supposed to only be referenced externally?

Thanks for any help answering this. I don't want to register this in any bug trackers or anything until/unless I can confirm that it is indeed erroneous behavior or not.

Playlists (for reference)

random_animation-family_movies.xsp: (This is the playlist included within the skin's folder that combines the other two playlists.)
Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<smartplaylist type="movies">
    <name>random_animation-family_movies</name>
    <match>one</match>
    <rule field="playlist" operator="is">
        <value>random_animation_movies</value>
    </rule>
    <rule field="playlist" operator="is">
        <value>random_family_movies</value>
    </rule>
    <limit>25</limit>
    <order direction="descending">random</order>
</smartplaylist>

random_animation_movies.xsp: (This includes animated movies. Works if in profiles/playlists/video, doesn't work if it's in the skin's playlists folder.)
Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<smartplaylist type="movies">
    <name>random_animation_movies</name>
    <match>all</match>
    <rule field="genre" operator="contains">
        <value>Animation</value>
    </rule>
    <rule field="path" operator="doesnotcontain">
        <value>Short Films</value>
    </rule>
    <rule field="time" operator="greaterthan">
        <value>00:45</value>
    </rule>
    <order direction="descending">random</order>
</smartplaylist>

random_family_movies.xsp: (This includes family movies. Works if in profiles/playlists/video, doesn't work if it's in the skin's playlists folder.)
Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<smartplaylist type="movies">
    <name>random_family_movies</name>
    <match>all</match>
    <rule field="genre" operator="contains">
        <value>Family</value>
    </rule>
    <rule field="path" operator="doesnotcontain">
        <value>Short Films</value>
    </rule>
    <rule field="time" operator="greaterthan">
        <value>00:45</value>
    </rule>
    <order direction="descending">random</order>
</smartplaylist>
I've noticed this before as well. I'd call it a behavior. That doesn't make it less annoying, but I think it was an intentional choice.
I thought that may have been a possibility. Thanks, I won't bother filing a bug report on it, but I will hope they choose to change it in the future.