Saw things had changed with OzWeather, so popped in here and was very pleasantly surprised.
Awesome work on the patch stuff (far less mucking around).
Works perfectly here, on PC and Shields (tested so far, stock Esuary, 19.1).
Thanks mate.
EDIT - Add Sony Android TV (x8000) to the list of working ok as well.
That's good to hear. (I got a bit more motivated once I found out <edit> quite a few folks </edit> - are using it...)
(2021-06-22, 08:27)bossanova808 Wrote: [ -> ]That's good to hear. (I got a bit more motivated once I found out <edit> quite a few folks </edit> - are using it...)
OK a glitch in the patcher.
OSMC just updated and overwrote the xml files but th patcher didn't overwrite them whaen I ran it presumably because the .original files still existed and I couldn't patch the skin.
I then restored from the patcher and then I could patch it..
No, if .originals are already there (which they won't be if your skin is updated anyway, but even if they are) - it assumes they are good and carries on patching. I've tested that plenty of times.
Perhaps next time OSMC updates, reboot and then try? Otherwise need a debug log when it fails...
(2021-06-24, 06:58)bossanova808 Wrote: [ -> ]No, if .originals are already there (which they won't be if your skin is updated anyway, but even if they are) - it assumes they are good and carries on patching. I've tested that plenty of times.
Perhaps next time OSMC updates, reboot and then try? Otherwise need a debug log when it fails...
It definitely didn't patch which I verified by checking the actual file.
Sure, but I am no magician...gonna need full debug log if it something that repeats...
Brilliant work, bossanova808!
Just an observation (HA! Pun!), since you've added the option to configure colours via xml modification (e.g. [COLOR _colour_text_dim_] replaced by ADDON.getSetting('colour_text_dim'), you can no longer be a masochist and simply copy the appropriate skin files from the zipped patcher into your Kodi install. You'll end up with no visible text from MyWeather.xml!
In other words, you now MUST install & run the skin patcher to use the skin files, because only the patcher stores those configured colour setting fields, then uses python to replace the text anchor tags in the .xml.
This is not a problem that needs "fixing", since you clearly tell people to "USE THE PATCHER", but you might want to make note of it on the wiki.
I suppose, for people who insist on doing it manually regardless, they'll need to manually search/replace the placeholders themselves before manually relocating the skin files. Yeah, UGH to that, but there'll always be one who'll want to try.
@
WhatZit That is a good point, yeah. I'll update the Wiki about that. I really can't imagine why anyone would want to do it manually, now the patcher exists, but they could do it once, auto, then grab the patched patch files and save those, I guess. I suppose someone will, indeed, come up with a reason, but I'm not going to maintain a bunch of patched patches as well.
Becoming a bit of a tongue twister too!
(2021-06-24, 08:51)bossanova808 Wrote: [ -> ]Sure, but I am no magician...gonna need full debug log if it something that repeats...
Well it did it again with another OSMC update.
I think it is leaving the .original files in place and overwriting the skin xml files in the skin so when I try to patch it doesn't copy over the patched files unless I remove the patch and then add it back again.
This is a rare event so I'm not going to be catching it with a debug log.
"I think it is leaving the .original files in place and overwriting the skin xml files in the skin so when I try to patch it doesn't copy over the patched files unless I remove the patch and then add it back again."
I don't know what this means really.
This is exactly what it should do - it won't nuke the .original files (which it needs in case of restore - if it copied over these each time it would be copying patched files to the .original files, which we don't want) - but even if those exist already, it will still copy over the main files (whether they are patched or not, it does not care or even know....unless you've changed permissions on those files or something, somehow, and it can't copy over them for some reason).
I really can't help without a debug log, sorry, and I've tested this process on a bunch of platforms many times now, and it all works ok....there are no other reports currently....so I don't really know what you expect me to do with this unless you can provide some useful debugging info - sorry! If it happens after each OSMC update it should be easy enough to grab that log surely? Or doesn't OSMC give you some warning when it updates? Just leave debug logging turned on all the time, and grab it immediately after the next update/attempted patch cycle.
As you know I am happy to help but I have to have some clue as to what is happening. Feel free to poke around the very simple code and have a look at what it does, there might be a flaw I am not seeing of course....
(2021-07-14, 00:56)bossanova808 Wrote: [ -> ]"I think it is leaving the .original files in place and overwriting the skin xml files in the skin so when I try to patch it doesn't copy over the patched files unless I remove the patch and then add it back again."
I don't know what this means really.
This is exactly what it should do - it won't nuke the .original files (which it needs in case of restore - if it copied over these each time it would be copying patched files to the .original files, which we don't want) - but even if those exist already, it will still copy over the main files (whether they are patched or not, it does not care or even know....unless you've changed permissions on those files or something, somehow, and it can't copy over them for some reason).
I really can't help without a debug log, sorry, and I've tested this process on a bunch of platforms many times now, and it all works ok....there are no other reports currently....so I don't really know what you expect me to do with this unless you can provide some useful debugging info - sorry! If it happens after each OSMC update it should be easy enough to grab that log surely? Or doesn't OSMC give you some warning when it updates? Just leave debug logging turned on all the time, and grab it immediately after the next update/attempted patch cycle.
As you know I am happy to help but I have to have some clue as to what is happening. Feel free to poke around the very simple code and have a look at what it does, there might be a flaw I am not seeing of course....
I think you are expecting that when a skin is overwritten, it overwrites all the skin files and that is what it used to do (I think) but it is leaving the .original files in place. so then the patcher sees those and doesn't 'see' that the .original files are the same unpatched files as the new xml files and so it doesn't 'do' anything when I try and patch the files again as the .original file exists.
It definitely isn't copying over the new files... I have verified this by examining the files it 'patches'. The only way to make it work is to do a restore and then patch again.
I will check out the code.
You are right, it does assume that. And that certainly did happen (i.e. the whole skin folder was replaced) - at some point when I explicitly tested it. I wonder if that is a general change, or an osmc thing? I tested it a good while back, though, and can't say for sure I have tested that with matrix or not ( or later matrix versions at least).
I'd presume it's a general Kodi change (wonder what the reasoning was, though?) - but if the .originals are not removed on skin updates, it all becomes a bit trickier, because then how do I know whether or not it is grabbing the actual skin original files?
(2021-07-14, 01:55)bossanova808 Wrote: [ -> ]You are right, it does assume that. And that certainly did happen (i.e. the whole skin folder was replaced) - at some point when I explicitly tested it. I wonder if that is a general change, or an osmc thing? I tested it a good while back, though, and can't say for sure I have tested that with matrix or not ( or later matrix versions at least).
I'd presume it's a general Kodi change (wonder what the reasoning was, though?) - but if the .originals are not removed on skin updates, it all becomes a bit trickier, because then how do I know whether or not it is grabbing the actual skin original files?
Well you could check if the skin file contains your mod lines (OzWeather section) and if not then assume they are the new oriiginals and overwrite the backups? Or even write the originals to the patcher folder and not store them in the skin folder. I guess the thing is those xml files *could* change in a skin update so you'd want to back them up if the xml file isn't your patched one.
I'm not going to go parsing skin files in a hurry, that's for sure, and it
really shouldn't be necessary. And it's not really about where they are stored either, ultimately. Already there or not, the patcher should copy the patched skin files if it can. It only stops if the backups
don't exist and it can't make them. And then tells you that.
I.e. even if new backups are
not being made because the backup files already exist (and you're talking about this error happening when OSMC itself updates, right, not skin updates as such yeah? - I will confirm the expected flow there with the Kodi devs anyway...)...you can see here:
https://github.com/bossanova808/reposito...er.py#L105
...that the backup bit is then just skipped...and it proceeds on to copying the skin files anyway (it only stops if the backups
don't exist, and it can't make backups...as it should). It should still therefore copy the skin files
if that is possible.
To be honest, you should only need to do an update IF the skin itself
has actually changed/been updated. Just because OSMC has been updated doesn't mean Estuary has. And even if it does do this (update the skin 'outside of band' and not using the Kodi process - maybe they patch in some OSMC specific stuff??) - then as long as the file permissions are ok at the end of that, the patcher should
still work anyway.
All of which brings us full circle to the need for a debug log...because that will log the actual error that occurs when the copy is attempted -
https://github.com/bossanova808/reposito...er.py#L158