•   
  • 1
  • 9
  • 10
  • 11
  • 12
  • 13(current)
Important -  Skinners: Please test PR13754
Yep, accused you too early Smile Sorry. But thanks for taking care and making @garbear aware of it.
Reply
(2018-09-13, 22:41)ksooo Wrote: @scott967 could you please try this testbuild to check whether listitem.dbtype now works for music videos? => http://mirrors.kodi.tv/test-builds/windo...pe-x64.exe

It would be great if you could also do some deeper regression tests as well as I needed to change some important bits and pieces for the fix and want to make sure there are no bad side effects.
 Did some testing.  Good news is ListItem.DBType shows musicvideo correctly now in the music / musicplaylist windows and videos windows unaffected.

But I have a (sort-of) regression.  This is for music m3u playlists containing songs and / or musicvideos.  Before PR13754, ListItem.DBType was null for either songs or musicvideos in both music and musicplaylist windows.  With the test build we actually have this behavior restored.  With original PR13754, ListItem.DBType was set as songs for both songs and musicvideos.  So in some sense ListItem.DBType was improved by PR13754 (for songs) though in error for musicvideos.

In all three builds (Pre-PR13754, Post-PR13754 and this test build) Container.content infolabel is "songs" for all music m3u playlists.

I'm not sure how relevant m3u playlists containing music videos are, just reporting my test results.

From a skinner perspective, knowing the correct DBType for a listitem is valuable as the information available to display to user is different for songs compared to music videos.

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Krypton
Leia
Reply
(2018-09-15, 04:18)scott967 Wrote:
(2018-09-13, 22:41)ksooo Wrote: @scott967 could you please try this testbuild to check whether listitem.dbtype now works for music videos? => http://mirrors.kodi.tv/test-builds/windo...pe-x64.exe

It would be great if you could also do some deeper regression tests as well as I needed to change some important bits and pieces for the fix and want to make sure there are no bad side effects.
 Did some testing.  Good news is ListItem.DBType shows musicvideo correctly now in the music / musicplaylist windows and videos windows unaffected.

But I have a (sort-of) regression.  This is for music m3u playlists containing songs and / or musicvideos.  Before PR13754, ListItem.DBType was null for either songs or musicvideos in both music and musicplaylist windows.  With the test build we actually have this behavior restored.  With original PR13754, ListItem.DBType was set as songs for both songs and musicvideos.  So in some sense ListItem.DBType was improved by PR13754 (for songs) though in error for musicvideos.

In all three builds (Pre-PR13754, Post-PR13754 and this test build) Container.content infolabel is "songs" for all music m3u playlists.

I'm not sure how relevant m3u playlists containing music videos are, just reporting my test results.

From a skinner perspective, knowing the correct DBType for a listitem is valuable as the information available to display to user is different for songs compared to music videos.

scott s.
Thanks for testing. If pre-PR13754 behavior is restored, I'm done. Fixing other bugs is not on my list. This should be done by the devs responsible for m3u playlists in this case as I cannot judge on what is correct.
Reply
(2018-09-15, 08:52)ksooo Wrote: Thanks for testing. If pre-PR13754 behavior is restored, I'm done. Fixing other bugs is not on my list. This should be done by the devs responsible for m3u playlists in this case as I cannot judge on what is correct. 

Fair enough. Don't see any problem with that.

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Krypton
Leia
Reply
I may have found a bug related to this PR, see:
https://forum.kodi.tv/showthread.php?tid=336117

It's working in Krypton but not in Leia (18.0+git20181002.0201-6fb44a8)
Reply
Regardless the PR discussed here caused the change in behavior (i doubt this, btw) the new behavior seems correct to me.

The values returned in Krypton seem wrong to me as those are not paths at all. And parent (folder) path being equal to own path seems even more wrong
Reply
Fair enough but the "new behavior" doesn't solve the problem that the correct path (favourites.xml) isn't available via infolabel. Honestly, I don't care if I get this information via ListItem.Path/FolderPath or a new ListItem.Property(path). The point is that this information should be available for skins (like it was in krypton), so that we can get rid of script.favourites and use the built-in favourites feature of KODI.

Anyway, I don't want to hijack this thread if you think that it's not related to this PR but can we please get this fixed? Adding a new ListItem.Property(path) would take 5 mins of coding ...

Thanks!
Reply
(2018-10-04, 12:49)bkury Wrote: Fair enough but the "new behavior" doesn't solve the problem that the correct path (favourites.xml) isn't available via infolabel. Honestly, I don't care if I get this information via ListItem.Path/FolderPath or a new ListItem.Property(path). The point is that this information should be available for skins (like it was in krypton), so that we can get rid of script.favourites and use the built-in favourites feature of KODI.

Anyway, I don't want to hijack this thread if you think that it's not related to this PR but can we please get this fixed? Adding a new ListItem.Property(path) would take 5 mins of coding ...

Thanks!

Then go ahead, take 5 mins of your spare time and code it, test it and submit a PR, please.

Oh, you're not a dev? Then you never ever should tell devs how much time it will take to implement something. 5 mins is pure nonsense. Devs really don't like that kind of supervision, believe me.

If you want somebody else than yourself to fix it, open a trac ticket, please.
Reply
You are right. I'm sorry, I should have phrased it differently ...
I just wanted to report a bug but I found it odd that an active/experienced dev like you replied with "new behavior seems correct to me", when it's clearly not the case.

Anyway, again sorry ...
Reply
I think I have another issue.

VideoPlayer.Title

When a video is played from file (not in library) prior to this PR the filename was returned in $INFO[Videoplayer.Title].  Now the infolabel is empty.

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Krypton
Leia
Reply
(2018-10-17, 03:57)scott967 Wrote: I think I have another issue.

VideoPlayer.Title

When a video is played from file (not in library) prior to this PR the filename was returned in $INFO[Videoplayer.Title].  Now the infolabel is empty.

scott s.
.


Are you using latest Kodi master? IIRC, there was an issue with this which I fixed recently.
Reply
(2018-10-17, 07:05)ksooo Wrote:
(2018-10-17, 03:57)scott967 Wrote: I think I have another issue.

VideoPlayer.Title

When a video is played from file (not in library) prior to this PR the filename was returned in $INFO[Videoplayer.Title].  Now the infolabel is empty.


Are you using latest Kodi master? IIRC, there was an issue with this which I fixed recently.  
  
OK Pulled the 1015 nightly and you are right, it's fixed.  Sorry to not check it before posting.

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Krypton
Leia
Reply
This might be related as the timeline fits, it stopped working correctly between Alpha1 and Alpha2.

Best way I can put it is that Container(9000).ListItem.Property() works everywhere but inside a list control control.

It works here
Code:
                <control type="image">
                    <visible>String.IsEqual(Container(9000).ListItem.Property(submenuVisibility),movies)</visible>
                </control>
but it doesn't work in any control inside this control
Code:
                <control type="list" id="8000">
                    <control
                        <visible>String.IsEqual(Container(9000).ListItem.Property(submenuVisibility),movies)</visible>
                    </control>
                </control>

The second one is always false, it has no access to the content in control 9000, neither does anything else in a control, so variables that use a condition based on Container(9000).ListItem.Property() are always false.

Thread where I originally posted this. It shows that even a label with that as the string is empty.
Using two 2820FYKH0 Intel NUCs, a Revo 1600, and a Foxconn NT-330i - All running OpenELEC. :)
Reply
  •   
  • 1
  • 9
  • 10
  • 11
  • 12
  • 13(current)
 
Thread Rating:
  • 0 Vote(s) - 0 Average



Logout Mark Read Team Forum Stats Members Help
Skinners: Please test PR1375400