Kodi Community Forum

(2017-01-11, 18:59)Alanon Wrote: [ -> ][@wise_rice: I've looked into the code, and I remain confused. The way it's set up, it should hide the tile during playback, only it doesn't. The settings in Includes_Furniture include only the contents, not the background itself. The header settings, however, list the proper conditions for visibility. I'd wager that what did the trick was deleting the DialogVolumeBar, since that's what appears when you change the volume anyway. As far as I know, there are no IsDisabled window conditions in Kodi.

As far as the audio flags go, the only line of code I've found commands to display the flag that matches the codec name. If there's nothing displayed but question marks, it means that Kodi didn't find anything among the flags and reverted to its default. I would try to make copies and rename some of the existing aiff flags an see if that helps? I don't really know what other naming convention these files might have? Perhaps they are some special variation of the aiff format that kodi is sensitive to, that need proper representation as a new flag?

I tried again with your fresh Version 1.7 (Very good job, by the way ! The animated Artwork is nice and the Scrollbar is perfect)

Now I only deleted the DialogVolumeBar and left all other files unchanged. This prevents the "volume-Circle" from showing up.
Sadly, it does still show the blue background of the tile. It shows the text "Playing" very quickly and then it fades away together.

Replacing/Changing the Custom_Debug_Overlay did nothing. So we can skip that on our search for the culprit.

Changing the Includes_Furniture file solved the problem. Maybe kodi is in fact accepting IsDisabled window conditions? Or is it something else I have changed?
Here is my file: Includes_Furniture.xml


I noticed a little glitch: When navigating through the movies, It does show the time of the movie again (thanks for that !! This was broken before) but it has a latency (propably due to the online-lookup of the movies standart time?)
Is it possible to move the movie-time icon to the very left? In this way, it does not move all other icons to the left after the search was done and the time is showing up. And it would then also make sense to move the "ending-time" right next to it. To the second position from the very left.
Or is it possible to show the "real" time of the actual file? By checking it on the Storage/NAS? I feel it was like that before...

For the music:
My hi-res music files have a standart .aif ending and are formatted in a normal way (96khz, 24 bit).
There is a aif.png in media>indicator>audio/
But it is not displayed. I don't know why. Only the question-marks


PS: what versions of SkinHelperService and Skin Widgets are you using? Do we need a special github beta-Version?
I get a short message that e.g. the SkinHelperService addons are needed when switching to the skin, even though they are installed (Version 1.0.143 and 0.0.33.) Maybe a normal bug in Kodi or Libreelec when switching skins? It seems to work fine and all necessary addons have a green tick in the skin settings.

Using the alphabet Bar in the addons results in washed out letters of the bar. Can't really distinguish between the active letter (should be blue) and the white ones.
In movies it is working perfectly with the right colors

@wise_rice: For starters, I use the latest Skin Helper and widgets from his repo, it helps with fixing breakages and eases installing this gem of an addon. I was going to mention this, somewhere, but with all the tinkering I forgot.

As for the furniture stuff, perhaps you're right. I'm not a skinner, and I simply know no code. What I've been able to achieve so far is just a result of researching the proper documentation and then applying the logical nature of all code to its conclusions.

About the aifs, have you tested aifs that weren't 96kHz? This is simply a stab in the dark here, but maybe Kodi doesn't read hi-fi files correctly, though I doubt it. Does the same file display a proper flag in a different skin?

The latency you notice is sadly due to the lookup that SH does when retrieving duration. Nothing can be done about it. The version of the skin I was modding, the Krypton one, had mostly a 50:50 solution implemented, where there'd be a lookup, but SH would be used only when there was a discrepancy. This, in turn, resulted in no latency.

However, the problem with any kind of library duration was that it lists the duration in minutes only. We have to wait for Leia for this to finally be corrected. Since Krypton, it seems, the library readouts don't work with the duration script, at least not for me. That script is supposed to manually convert all minutes into the HH:MM format. No one else reported this occurrence, but no amount of prodding produced any results for me. (If anyone would like to test this, I'd be grateful.) In the old skin, I'd get some right, some in minutes, and some just remained empty. So, since most people wanted HH:MM (that's the impression I'd gotten, anyway), literally the only solution to implement that was using SH.

Personally, I'm indifferent to this sort of thing, I can easily switch it back to reading the library values. I'd also toyed with the thought of leaving the library duration at the bottom in minutes, and having the HH:MM in the view flags/dialog info only, or vice versa? But, since I didn't mind either way, I decided to leave things consistent across the board, to start with. It's also no problem to switch the icons around, I'd like for folks to chime in on this.

Now onto the scrollbar. First, the bug might be from the different versions of SH we're using, since I can't seem to reproduce it? Basically, from what I understand, SH scans all the names in the background and makes appropriate shortcuts. It does all the heavy-lifting in the background on its own. There is sometimes an occurrence where the letters don't "populate", when they're all dark gray, but that's rare, and is usually corrected by leaving the window and coming back in. As for the colors. Washed out letters (dark gray) are when the letter is not clickable: when, for example, you have no movies beginning with the letter Q, it will be a dark gray colour. White-ish letters are "default", working letters, and a single solid white letter shows which letter group you are browsing currently. Your highlight color is the default selected letter color.

However, I've noticed now that when I browse the letters using the arrows of my keyboard in the add-ons, the bar itself seems to diffuse or diminish the focus color for some reason. With the mouse this doesn't happen. I've not found a solution to this, since the skin is technically invoking an proper object with defined colors. This might happen due to the dimming effect the skin settings regions have on at all times. It's like by focusing on the bar, it remains in the back layers, behind the dim curtain... No change I've tried to the animations or colour diffusion methods has worked. The best advice I have for now is to try and tweak the colours yourself, to pick a really distinguishable colour. I'll try to dig into this, but from here it looks like this bug has a home...

(2017-01-12, 01:57)Alanon Wrote: [ -> ]@wise_rice: For starters, I use the latest Skin Helper and widgets from his repo, it helps with fixing breakages and eases installing this gem of an addon. I was going to mention this, somewhere, but with all the tinkering I forgot.

Okay. So that is Version 1.0.144 then for Skin Helper Service. Updated everything.

(2017-01-12, 01:57)Alanon Wrote: [ -> ]About the aifs, have you tested aifs that weren't 96kHz? This is simply a stab in the dark here, but maybe Kodi doesn't read hi-fi files correctly, though I doubt it. Does the same file display a proper flag in a different skin?

Yes, tried all kinds of .aif versions. I have no other skin with this function to test.

(2017-01-12, 01:57)Alanon Wrote: [ -> ]The latency you notice is sadly due to the lookup that SH does when retrieving duration. Nothing can be done about it. The version of the skin I was modding, the Krypton one, had mostly a 50:50 solution implemented, where there'd be a lookup, but SH would be used only when there was a discrepancy. This, in turn, resulted in no latency.

However, the problem with any kind of library duration was that it lists the duration in minutes only. We have to wait for Leia for this to finally be corrected. Since Krypton, it seems, the library readouts don't work with the duration script, at least not for me. That script is supposed to manually convert all minutes into the HH:MM format. No one else reported this occurrence, but no amount of prodding produced any results for me. (If anyone would like to test this, I'd be grateful.) In the old skin, I'd get some right, some in minutes, and some just remained empty. So, since most people wanted HH:MM (that's the impression I'd gotten, anyway), literally the only solution to implement that was using SH.

Yes, a lot of times it is showing nothing. could that be changed to show at least something? even if it is in minutes...

(2017-01-12, 01:57)Alanon Wrote: [ -> ]Personally, I'm indifferent to this sort of thing, I can easily switch it back to reading the library values. I'd also toyed with the thought of leaving the library duration at the bottom in minutes, and having the HH:MM in the view flags/dialog info only, or vice versa? But, since I didn't mind either way, I decided to leave things consistent across the board, to start with. It's also no problem to switch the icons around, I'd like for folks to chime in on this.

Okay. You have my thumbs up for it. Lets see what the others are thinking.

(2017-01-12, 01:57)Alanon Wrote: [ -> ]Now onto the scrollbar. First, the bug might be from the different versions of SH we're using (...)
However, I've noticed now that when I browse the letters using the arrows of my keyboard in the add-ons, the bar itself seems to diffuse or diminish the focus color for some reason. With the mouse this doesn't happen. I've not found a solution to this, since the skin is technically invoking an proper object with defined colors. This might happen due to the dimming effect the skin settings regions have on at all times. It's like by focusing on the bar, it remains in the back layers, behind the dim curtain... No change I've tried to the animations or colour diffusion methods has worked. The best advice I have for now is to try and tweak the colours yourself, to pick a really distinguishable colour. I'll try to dig into this, but from here it looks like this bug has a home...

Yes, this is exactly it. Its still there after updating SH to the newest Github version. When invoking it with the keyboard arrows (or a remote) in Addons OR in Music, it is not really behind a grey curtain, its just that the highlight color is extreme close to the normal grey color (even though it should be e.g. blue). I don't understand why it is working in the movies section ( and not in Music or Addons? Might have something to do with the view "List" I use there? Movies are in "Infos List" view and it's OK there.

Again, Thank you for your work on this awesome Skin and for keeping it alive !

Are the online lookups cached / saved somehow?
So that it does not have to reload the duration everytime you scroll through the movies?

@wise_Rice: Wait, are you saying that you still get empty duration containers, even in my mod? The only way that could happen is if the info could not be retrieved online at all. Have you noticed, is it a random occurrence, or does it appear on certain files only?

According to the dev, the script caches all the durations, that's why the latency is so small. The first time it's retrieved, there is a longer period involved, but every consecutive retrieval is faster.

As far as the scrollbar is concerned, you might be on to something, the List view is very special, it might indeed be the reason.

small question please...sorry for the newbee question however...

if i download v1.7 and install from zip, (and I already have 1.6 installed and using it), does 1.7 automatically overwrite 1.6? How will i know which version I have installed?

thanks

@kodee Newbee: Installing like a zip should work nicely. As long as all the contents inside the skin folder is overwritten, the upgrade should always be successful. You can tell by the changelog file, inside which you can see what is new or changed and compare it with the skin settings, etc. You can also see it by the skin version number in your addons info inside Kodi itself. Every new release has some kind of bump in version number.

I don't really know how to use github, make a repo or anything like that, so the zip method is the best I can do for now. I certainly won't be updating the skin without releasing some info here.

(2017-01-13, 13:37)Alanon Wrote: [ -> ]@wise_Rice: Wait, are you saying that you still get empty duration containers, even in my mod? The only way that could happen is if the info could not be retrieved online at all. Have you noticed, is it a random occurrence, or does it appear on certain files only?

Yes. It is some files only. They stay empty. But they show the time ending.
I cached all movies now. Scrolled trough every single one of them and waited for the information to load. It is annoying, but it helps a little bit with the waiting time. Could it lot load the information for all movies at once?

DOWNLOAD 1.8

What's new:
1. Improvements and fixes for the Video OSD.
2. Moved my portion of the changelog to the addon.xml.
3. Restored the addoninfo changelog button to reflect the <news> value.
4. Added a setting for duration formats. script.duration (axbmcuser MOD) is now recommended.
5. Updated required addons list.
6. Small fixes for the Showcase view.

I've updated the changelog button to use the newly added value. If an addon/skin has the <news> segment inside the addons.xml, it will be viewable in the addons info. I've updated my mod to contain a changelog of all my fixes. The space is limited, so sooner or later it'll be decreased even further, to reflect only the very latest versions. That's why the changelog.txt remains as backup. I've read somewhere that upon installation this method should automatically pop-up the news, but I've not gone around testing it...

I've tested the durations thoroughly. It might be the retrieval method, or the data on the web, but there's definitely something buggy going on with SH. Luckily, I stumbled upon an updated duration script, so I was able to update the skin accordingly. The devs repo is included in the link above. In short, there is now a setting allowing for switching between minutes and HH:MM. The minutes are always the library item values. If you have the duration script it will use it by default for HH:MM. If you don't, Skin Helper will be used. You should be able to switch between the formats in either case. I would really recommend using the duration script, as it's much more efficient than SH.

@wise_rice: Before you try out the duration addon, I'd appreciate it if you'd see if the issues you mentioned are resolved as-is. I've tried to add a backup system for the case you described. When SH is used for duration, if by chance it fails to deliver, the duration should revert back to the library value. The opposite should also be true; if somehow duration wasn't scraped, SH will try and retrieve it regardless of the other variables.

(2017-01-17, 05:33)Alanon Wrote: [ -> ]

DOWNLOAD 1.8

@wise_rice: Before you try out the duration addon, I'd appreciate it if you'd see if the issues you mentioned are resolved as-is. I've tried to add a backup system for the case you described. When SH is used for duration, if by chance it fails to deliver, the duration should revert back to the library value. The opposite should also be true; if somehow duration wasn't scraped, SH will try and retrieve it regardless of the other variables.

Without the script or with it: Same waiting time for the duration to appear.
But I think it shows a time for all the movies now, after a while.
I did not have the time to wait for every single to test, though.

Darn it. That's not the intended behaviour. The duration script runs a batch convert in the background whenever you reach myvideonav. I get absolutely no lags when using it. Since it merely converts the actual library values, it's practically instantaneous.

Without the duration addon, while you wait for SH to pull the values, instead of an empty space, the back-up library minutes ought to appear. So you would get a small "conversion switch" when using SH, but never end up having no info, and just waiting for something to populate the space.

I've achieved this by making a duration variable with proper conditions. The lynchpin of most variants is the library duration. The only reason that might explain everything is that for some reason it takes your system a while to populate the library duration value, and that causes a chain reaction lag across the board... Are you getting any lags when using just the library duration?

Also, and this might be silly, but do you have the old script.duration still enabled? There might be some highly improbable conflict going on.

Alanon,

Thank you for your hard work. It is perfect.

(2017-01-17, 14:40)Alanon Wrote: [ -> ]Darn it. That's not the intended behaviour. The duration script runs a batch convert in the background whenever you reach myvideonav. I get absolutely no lags when using it. Since it merely converts the actual library values, it's practically instantaneous.

Without the duration addon, while you wait for SH to pull the values, instead of an empty space, the back-up library minutes ought to appear. So you would get a small "conversion switch" when using SH, but never end up having no info, and just waiting for something to populate the space.

I've achieved this by making a duration variable with proper conditions. The lynchpin of most variants is the library duration. The only reason that might explain everything is that for some reason it takes your system a while to populate the library duration value, and that causes a chain reaction lag across the board... Are you getting any lags when using just the library duration?

Also, and this might be silly, but do you have the old script.duration still enabled? There might be some highly improbable conflict going on.

script.duration is installed. But the new MOD version!
It is now showing the duration, finally. after I sorted the view by "duration". Happy as can be.
It does still blink for a second when it is recieving the duration online. before it is recieved, it shows nothing in the little space in the bottom right hand corner...

DOWNLOAD 1.8.1

1.8.1
1. New skin icon.
2. Begun updating the code to reflect soon-to-be deprecated string bools.
3. A bunch of small fixes to the code.
4. Some new flags.


Here's a quick & dirty update. I've edited some flags throughout the skin, and also made some fixes to the code.

I've also began converting the strings that will become deprecated when Leia arrives, with the strings that were introduced in Krypton. It's an extremely tedious task, but I find it's better to do it now than rush it later on. So please test the skin out, to make sure my replacing hundreds of fragments didn't funk anything up. It shouldn't have, but who knows.. After this batch there are literally hundreds more to change...

Also, I wanted to implement user ratings for music views, for those of you that import your ratings from your collections. Would that be something that interests anyone? You can find examples of all the flags I've found here. If someone knows of something better, give a shout...