Kodi Community Forum

Full Version: Bin URLs are self-deprecating
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
I created an issue on GitHub, but I'm not sure if they are looked at since issues are auto-marked "Invalid"

Does anyone know who is responsible for http://mirrors.kodi.tv?
Just tell us the issue here in the forums.
This? 7942 (GH issue)

I'm honestly not sure why we do that either. If the desire is to clean up the clutter, we should stop throwing betas and RCs in the same folder as releases. However, there might be other reasons for this. Maybe the "old" folder is scanned less for mirrors or something, to help out with mirror traffic?
On a side note, why is the isses menu point even activated on github? I'm guessing it wasn't possible before, but now you can set it to deactivated in the repo settings.
(2015-09-01, 16:34)Razze Wrote: [ -> ]On a side note, why is the isses menu point even activated on github? I'm guessing it wasn't possible before, but now you can set it to deactivated in the repo settings.
Because the github website is so stupid that you need to enable it get the labels we use for the PRs
(2015-09-01, 16:40)Martijn Wrote: [ -> ]
(2015-09-01, 16:34)Razze Wrote: [ -> ]On a side note, why is the isses menu point even activated on github? I'm guessing it wasn't possible before, but now you can set it to deactivated in the repo settings.
Because the github website is so stupid that you need to enable it get the labels we use for the PRs

Hrm, that made me curious. Is that still valid? Are you talking about other labels?
Just did a quick test https://github.com/Razzeee/script.module.trakt/pull/3

But yeah, it's scary stuff to change this on a big repo like the kodi one.
Yes, those as well as milestones.
Perhaps they "fixed" it by now. I added the request years ago and it was on their to do list
Milestones also seem okay
(2015-09-01, 10:43)Ned Scott Wrote: [ -> ]This? 7942 (GH issue)

Yup, that's the issue as linked in my initial post.

Quote:I'm honestly not sure why we do that either. If the desire is to clean up the clutter, we should stop throwing betas and RCs in the same folder as releases.

The desire is less about clutter and more about unchanging bin URLs. The easiest solution is simply to copy release files into the "old" folder. But that means the filename "old" is no longer correct, so maybe change "old" to "archive" or "all".

Optimally, betas and RCs could also have a permanent home. For those interested the "nuget" package I maintain is https://chocolatey.org/packages/kodi

Quote:However, there might be other reasons for this. Maybe the "old" folder is scanned less for mirrors or something, to help out with mirror traffic?

Is there a better location to post this question? or someone whom I should ping?
Our server guys will see this thread and respond when they have a moment :)
Not to sound unfriendly, but I'm not sure why we should need to change the way we have always managed our mirrors because you aren't able to script your way about a file being in possibly two different locations.
Why not simply do a head request and check if the file exists if you don't want to update it manually ?
Manual updating is what we do ourselves for our download page.

The reasons why we do not keep all old RC and beta releases is simply because of size considerations for our mirrors.
We only provide older stables and want to make it clear for users browsing our mirrors which is the current stable. (Everything else gets moved to old.)
This is actually a fairly recent change, within the last year I think. Normally, all releases have been in the same folder and were not moved into an "old" folder. I understand the logic, but I doubt that using an old folder is actually doing anything at all. Users who don't understand that a higher version number is the latest release are not going to care what folder the release is in.
well, we could also go the other way arround have have a "current" folder and/or symlink that always points to the latest release. Not that I actually care.
It is fine as is. We want users to use the current version, so it should be obvious which one that is.
Its is trivial to look into the old dir if what you are looking for is not there from a scripting POV.
(2015-09-04, 13:07)da-anda Wrote: [ -> ]well, we could also go the other way arround have have a "current" folder and/or symlink that always points to the latest release. Not that I actually care.

I don't have strong feelings about it, either, but a "current" symlink would be awesome. We used to do this years and years ago for Apple TV 1 installs (running OS X) when it downloaded the OS X build from the mirrors. It could really come in handy for a few situations, including OP's situation, and the occasional Android or iOS use case, where some users have to type in (or cut-and-paste) URLs for installation.
Pages: 1 2