[kittmaster]

Are you trying to install on Leia? Because your xbmc.gui version is too low for Matrix/Nexus (5.15)
https://github.com/kittmaster/Kittmaster...don.xml#L4

Your repo looks setup correctly. It is functioning correctly according to your addons.xml (which is valid as far as I can see)

The reason there are no skins displayed is because your repo doesn't contain any skins which can be installed on Nexus (xbmc.gui 5.15)

If you want a skin to be installed on Matrix/Nexus then you need to bump the version here from 5.14 to 5.15

Code:


<import addon="xbmc.gui" version="5.14.0"/>


No, not Leia, or ever Leia, I used Leia when I first found Kodi for like maybe 6 weeks (worked fine for me then) and then Matrix popped and from there, that has been my reference.

In all the wave of changes, your latest point made all the difference, I went all the way back to "my" beginning using Matrix as the OS and Mr.V's last known cloned repo files as I wasn't sure if I screwed something in all the bug hunting I was doing using Nexus and then the Omega experiment (well for me anyway). I must of at some point found that I had to move .14 to .15 to use the skin on Matrix very early on and "forgot" that it clearly affects what was being done here. Noted to self.

Moving it to .15 I can now see "Look/Feel" > Skin > Madnox. ....... <opens champagne bottle and passes around>

While I realize it may be trivial once the method is known this was an interesting learning experience as it was a real project that "requires" Github to APP/Program mechanism. So as a personal milestone... it ends in TADA.

I still have a few things I'll want to add like the support plugins to ensure they always are available etc. and use proper artwork to represent the skin and enhance all the descriptions and probably reset all the values to 1.0.01 type of thing as the starting baseline including wiping all the errors off Github and starting from a ground zero value so that others don't replicate if it is ever looked at randomly.

Thanks again to everyone for holding my hand per say and getting me across the goal line... now I can start doing what I actually came here to do... work on a skin I use exclusively across 7 different device/platforms and intend to keep alive and kicking.

Until the next inquiry: Mark as solved.

Greetz,
Chris

[kittmaster]

I updated the thread to "broken"... well kinda based on about what I'm about to ask.

I am trying to figure how to split the repo into 3 builds, Matrix, Nexus, Omega.

Prior to this change, my skin.madnox lives in the root like this:



When I run generator, everything builds and has so successfully for several iterations.... happy so far.

Now, because I want to split the repository by build, my understanding is that I need to create 3 sub folders named accordingly (Matrix, Nexus, Omega) and put and entire copy of skin.madnox in each and those serve as each build as they are modded or not so depending on build an etc etc... 

Then I'd adjust my repo <dir> to reflect those folders by version like:

Code:



        <dir minversion="19.0.0" maxversion="19.9.9">
            <info compressed="false">https://raw.githubusercontent.com/kittmaster/KittmasterRepo/master/repo/zips/matrix/addons.xml</info>
            <checksum>https://raw.githubusercontent.com/kittmaster/KittmasterRepo/master/repo/zips/matrix/addons.xml.md5</checksum>
            <datadir zip="true">https://raw.githubusercontent.com/kittmaster/KittmasterRepo/master/repo/matrix/zips/</datadir>
        </dir>
        <dir minversion="20.0.0" maxversion="20.9.9">
            <info compressed="false">https://raw.githubusercontent.com/kittmaster/KittmasterRepo/master/repo/zips/nexus/addons.xml</info>
            <checksum>https://raw.githubusercontent.com/kittmaster/KittmasterRepo/master/repo/zips/nexus/addons.xml.md5</checksum>
            <datadir zip="true">https://raw.githubusercontent.com/kittmaster/KittmasterRepo/master/repo/nexus/zips/</datadir>
        </dir>
        <dir minversion="21.0.0" maxversion="21.9.9">
            <info compressed="false">https://raw.githubusercontent.com/kittmaster/KittmasterRepo/master/repo/zips/omega/addons.xml</info>
            <checksum>https://raw.githubusercontent.com/kittmaster/KittmasterRepo/master/repo/zips/omega/addons.xml.md5</checksum>
            <datadir zip="true">https://raw.githubusercontent.com/kittmaster/KittmasterRepo/master/repo/omega/zips/</datadir>
        </dir>



That all seems to make perfect sense to me... if all that is still 100% right to this point... is it?

If so, then the new issue that has popped up is that my script doesn't seem to like the new added 3 subfolders and will not compile  the 3 new folders by build and then subfolder their outputs.

Clearly this is a problem based on how my script is coded:

Code:


https://github.com/kittmaster/Kittmaster...nerator.py


So I'm reaching out to see if anyone could give me some guidance so I don't torch all the progress I've had thus far and if how far off this script I'm using and if their are simple corrections that someone could point out that I could modify to make this work.

When I run the script as is, this is the current results:



You can see it does build the top level folders, it just does not go further down into the 3 new folders by build. I'm not sure how this is done otherwise, so if I'm out in left field, drag me back home.

So again, it's not really "broken" but for where I need to get to, it is. Can anyone give me an idea how to handle this so I don't create mountains of work to fix this?

Thanks,
Chris

[jurialmunkey]

Your version folders are in the wrong location. Should be in basedir alongside repo, not within.

"repo" is your generic repo without a min/max version. Other versions like "omega" or "matrix" are siblings of "repo", not children.

[kittmaster]

So following your advice... I moved (as a test) to a different folder so nothing to worry about to try....this is the end result.... is this the expected result ?

If so....why?

Shouldn't they all have to be in the same master zip folder ?

[jurialmunkey]

Yes that is expected.

Each version of the repo needs its own set of zips because the zips for each version should be different versions of the addons -- e.g. the nexus folder will contain 21.00.05~nexus version of your skin, whereas the matrix folder will contain the 21.00.05~matrix version of your skin; so whilst each folder might contain a 21.00.05.zip in its zips folder, these should be for different Kodi versions.

[kittmaster]

So to be clear, I'm "there" I just need to use GitHub desktop to upload it exactly as it is now presented and fix my repo with the proper <dir> paths at this point (which the above ones are wrong).

Is there a way to "mark" each skin set so that lets say if I'm testing on Matrix or whatever, and using the portable version, and it downloads the Matrix version of the skin from the repo that a "signature" for the Matrix version of the skin without affecting the users experience but that can be tracked correctly to ensure it is point to the right repo/build outside of the addon.xml GUI version?

I think this would be my "last" info hurdle and I can carry on. 

Thanks for the validation and feedback of the method, saving me a lot of trial and error grief.

Chris

[jurialmunkey]

Yeah you can use a tilde ~ character in the addon ID to add a name on end of version number
e.g.
1.2.3~omega
1.2.3~nexus

e.g. compare nexus vs. omega versions of my skin addon.xml in my repo:
https://github.com/jurialmunkey/reposito...don.xml#L1
https://github.com/jurialmunkey/reposito...don.xml#L1


Also take note that a version with a tilde is **lower** than a version without
-- e.g. 1.2.3 > 1.2.3~omega > 1.2.3~nexus > 1.2.2 > 1.2.2~omega > 1.2.2~nexus
https://kodi.wiki/view/Addon.xml#How_versioning_works

[kittmaster]

I saw the versioning page, that makes sense when I read it.

The other logic issue on this I don't have my finger on... in the structure, the plugin I'm using still get jettisoned into "main" zip folder. 

Do scripts and plugins follow this same format assuming they are build specific? Like Madnox needs Embuary for say Matrix but that goes away for say Omega (stupid example, but for sake of absolutes on this split type), would I follow the same mindset here where I'd have say 1 copy that lives in the root (moved like the other folders) and therefore it would not show up in the "main" zip folder like it is now with the <dir> tags in repo?

I think that is the logical flow for it, just want to make sure I'm getting it because once I move to this split type, I plan to include all of the skins required scripts in my repo just to ensure I always have a deliverable even it somehow disappears from the main repo etc. Even if it is stated that it never would, the point is I'll always have a local copy regardless of the rest of the world type thing.

ty.

[kittmaster]

I see the difference and expectation of the addon.xml, nothing more than the GUI bump from .15 to .17 for the Omega requirement.

That I understood, I'm just trying to get my head around the other aspects outlined in previous post.

Thank you for the clear concise example!

I will push all my updates to the new folders and give it a shot uploading the new format.

I will have a full .rar snapshot archive of each so I can quickly revert if something goes wrong, which it probably won't.

[jurialmunkey]

The other logic issue on this I don't have my finger on... in the structure, the plugin I'm using still get jettisoned into "main" zip folder. 

That's because you put it in the "repo" folder. Just think of this as another "version" like "omega" or "nexus" -- the difference being it gets used as a generic folder with no specified version. For example see my addons.xml which lists "repo" with min/max
https://github.com/jurialmunkey/reposito...xml#L5-L29

Do scripts and plugins follow this same format assuming they are build specific?

Yes. See above. If you need different versions of an addon per Kodi version then use specific version folders. If there is only a single version of the plugin and it works on all versions of Kodi as long as its minimum dependencies are met, then use the generic folder instead.

Like Madnox needs Embuary for say Matrix but that goes away for say Omega (stupid example, but for sake of absolutes on this split type), would I follow the same mindset here where I'd have say 1 copy that lives in the root (moved like the other folders) and therefore it would not show up in the "main" zip folder like it is now with the <dir> tags in repo?

I think that is the logical flow for it, just want to make sure I'm getting it because once I move to this split type, I plan to include all of the skins required scripts in my repo just to ensure I always have a deliverable even it somehow disappears from the main repo etc. Even if it is stated that it never would, the point is I'll always have a local copy regardless of the rest of the world type thing.

You shouldn't be packaging up other people's add-ons. These should be installed from the original repo source, not your repo.

If you are worried about an addon being deleted, simply go onto the github page for the addon and press the fork button to create your own copy. There's no need to be including it in your Kodi repo *unless* the original gets deleted.

A repo which attempts to install its own copies of addons made by other people is generally considered a red flag indicating an untrustworthy source.

At best it indicates a repo which will create dependency hell causing users to miss important updates from the official channels and end up with outdated versions of the add-on because the version tracking for that addon switched to following your repo and you haven't kept up with updates. At worst, these types of repos with lots of addons not made by repo author suggest malicious intent.

The only time a repo should contain addons also on the official repo is if the repo is a beta channel for the author (e.g. I package newer "beta/alpha" versions of my own addons in my repo).

[kittmaster]

Just a fast reply because it may be late in your day:

The whole supply my own is because one item in particular: Colorpicker.py is STILL wrong when it downloads without modification.

It is extremely annoying to expect a user test driving a new skin to have to mod any file just to use it because one of the dependencies are out of date or not updated......and like 3 years outdated.

That was the thought on why to deliver it myself.

[jurialmunkey]

If you're making your own version of an addon that diverges then simply give it a new addonid and name and package that instead. That avoids any dependency issues because it is clear that you require a modified version in your dependencies and both versions can be installed alongside so you aren't modifying the behaviour of the addon for those skins which require the original.

As a simple example specifically related to me. The skin Arctic Zephyr Reloaded is not made by me, but it is a mod of my original skin Arctic Zephyr. To avoid conflicts, beatmasters renamed his with the addonid skin.arctic.zephyr.mod
https://github.com/beatmasterRS/skin.arc...don.xml#L2

This way both my original skin and the mod version can be installed side-by-side without conflict because they have separate addon IDs. It is also clear to users that they are installing a different skin because it has a different name.

[mikeSiLVO]

Just a fast reply because it may be late in your day:

The whole supply my own is because one item in particular: Colorpicker.py is STILL wrong when it downloads without modification.

It is extremely annoying to expect a user test driving a new skin to have to mod any file just to use it because one of the dependencies are out of date or not updated......and like 3 years outdated.

That was the thought on why to deliver it myself.

If you are talking about changing xbmc.translatePath to xbmcvfs.translatePath for script.skin.helper.colorpicker then, I believe, it is already updated in its repo

[kittmaster]

Just a fast reply because it may be late in your day:

The whole supply my own is because one item in particular: Colorpicker.py is STILL wrong when it downloads without modification.

It is extremely annoying to expect a user test driving a new skin to have to mod any file just to use it because one of the dependencies are out of date or not updated......and like 3 years outdated.

That was the thought on why to deliver it myself.

If you are talking about changing xbmc.translatePath to xbmcvfs.translatePath for script.skin.helper.colorpicker then, I believe, it is already updated in its repo

Yes, exactly that, I just installed a new copy of nexus and I had to make the change.... yet it shows updated there... I'll have to try it again, maybe it was old install... but I'll try it again.

Thanks!

[jurialmunkey]

Just a fast reply because it may be late in your day:

The whole supply my own is because one item in particular: Colorpicker.py is STILL wrong when it downloads without modification.

It is extremely annoying to expect a user test driving a new skin to have to mod any file just to use it because one of the dependencies are out of date or not updated......and like 3 years outdated.

That was the thought on why to deliver it myself.

If you are talking about changing xbmc.translatePath to xbmcvfs.translatePath for script.skin.helper.colorpicker then, I believe, it is already updated in its repo

Yes, exactly that, I just installed a new copy of nexus and I had to make the change.... yet it shows updated there... I'll have to try it again, maybe it was old install... but I'll try it again.

Thanks!

Probably need to enable the setting to allow updating official addons from unknown sources.