Please stop to implement SSH source video
#16
Dropping old releases is more about they having ancient libraries, which becomes a support burden with ifdefs (some libraries doesn't even have proper versioning defines so its even more annoying). When SFTP releases a new library and noone wants to bump our integration code. We would remove that feature too. Its apples and oranges your comparing. In general these types of features are fine to support if the libraries change nothing, the problem arise when the API changes between libraries and we use the platforms libraries. Thats when we are dropping old releases, when we don't want to carry ancient code just for a platform 4 people uses. Obviously we could keep old releases and disable features, but people nag about that so we opt to drop releases altogether. There is no winning.

The SSH implementation was initially done by me as I wanted a simple way to connect to my computer, it works for that and anything else either supply a patch or shut up. I have no interest in doing more than what I need on it.
And it has previously supported key files afaik, I'm guessing that it was either dropped because of a bug or the user here has a weird setup.

And there is _nothing_ stopping him from using ordinary fuse ssh mount while our vfs is in place, and if he for some reason care that its there (even without being a problem). He can compile kodi without it.
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#17
As far as I know, we're not actually dropping support for anything from my example. It was just an example of a position that other people on the team had. In that particular case the issue was about hardware video decoding not being supported for newer GPUs, but people with that newer hardware are unlikely to be using an older LTS version of Ubuntu in the first place, so there's not much point in dropping support when everything else works. At least, that was the impression I had from that discussion/example.

Like I said, I don't share the view that it is better to drop something that isn't 100% supported, but those kinds of views are not without merit.

That being said, I'm sure there are other reasons to also not agree with this proposal, but I don't think he was trying to be as negative as it sounded to us, due to the language barrier.
Reply
#18
(2014-10-27, 11:18)Ned Scott Wrote: Like I said, I don't share the view that it is better to drop something that isn't 100% supported, but those kinds of views are not without merit.

We rarely drop something which is actively maintained. Old releases aren't, thus dropping. Or when its a maintenence hell. And if the user doesn't want to upgrade the OS, maybe he shouldn't expect that all apps should upgrade. If he want the latest and greatest, use the latest and greatest. If the old works, then use the old. The old release of kodi doesn't magically become useless becouse there is a new one.

And the response to the original thread is still, patch or stop whine.
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#19
I think we're on the same page here. I'm not talking about old releases that aren't supported/maintained. Helix still supports 12.04 LTS.
Reply
#20
Which is a hassle since it, as an example, has an old libyajl which we need to maintain really weird ifdefery for.
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#21
(2014-10-27, 13:52)topfs2 Wrote: Which is a hassle since it, as an example, has an old libyajl which we need to maintain really weird ifdefery for.

I think I understand that now, but my example is referring to the idea that we should drop 12.04 because new GPUs are not being supported. Not because of development hassle. This was because some Team members were concerned about users viewing XBMC/Kodi as broken because it didn't work with GPUs manufactured after a certain date.

Something like libyajl would be a different situation, even though it involves the same Ubuntu 12.04.

I guess my example was not wisely chosen, since there were multiple discussions about 12.04. My bad.
Reply
#22
Hello,

topfs2, nice to meet you, sorry if my post look rude, really nothing about you as you imagine.
You have resume the trouble better as me.

sshfs with libfuse work perfectlly. OsX and GNU/Linux if it have a option to use libfuse sshfs and replace the actual support that will be amazing.

If the XBMC support is not change , it will be unrealistic due to all libssl openssh updates during they last mounths.
Actually after the last Debian Jessie update, that finish .... XBMC/libssh can't work anymore with the actual openssh server ... now the only way i know is sshfs.

Regards
Reply
#23
You CAN already use fuse on OS level. Just mount it on linux/OSX and use the resulting folder in kodi.
Reply

Logout Mark Read Team Forum Stats Members Help
Please stop to implement SSH source video0