[kyles]

hi XBMC,

how do I get this patch merged? I'd like to start working on the next thing. https://github.com/xbmc/xbmc/pull/22952

[Fuzzard]

Its been commented on that its believed its too niche. Unless theres some other extremely good reason you could give, it probably wont be.

From my view, i dont even understand what you're doing with it. i don't think you've explained the point of it well enough, but maybe thats just me.

[kyles]

Its been commented on that its believed its too niche. Unless theres some other extremely good reason you could give, it probably wont be.

From my view, i dont even understand what you're doing with it. i don't think you've explained the point of it well enough, but maybe thats just me.

HTTP streaming is what 99% (the percentage point may be off by one) of Kodi users utilize. As opposed to trying to convince a single mind that FileCache continues to not work properly for anyone, I've gone back to the simple webserver that works and is the main consumption path. However, the Directory listing for HTTP is very poorly implemented per this bug https://github.com/xbmc/xbmc/issues/21408 . So, to get a usable solution, I'm using the directory listing from smb (which is better, but still terrible even with stat off), and streaming actual media files via HTTP. Works 100% of the time, doesn't matter the system load, network utilization, if it's windy outside, it just consistently works and I forget I'm on Kodi and not a streaming platform (which, is high praise compared to what's been going on). The feature can also be utilized to enforce correctness, and plenty of other things.

It's 7 lines of code, I'll add tests if that's really a blocker, and the regression surface is 0. I really don't want to use Plex which is why I continue to try and get this working.

Next up is likely the JNI mess and the API not being followed since v1 (it clearly calls out isFinishing which isn't implemented, and Kodi seems to murder itself here for no good reason) which is also harming existing users. After that probably optimizing the smb stat calls so it doesn't take 7 minutes to load a simple 4000 item folder. Besides, maintaining a fork helps no one.

[Fuzzard]

Honestly, dont go spouting things you absolutely can not prove. That helps no one in a discussion.

To me, that sounds like such an insanely niche thing. Ive never heard of anyone ever doing such a thing. I understand you think this change is the greatest thing to ever happen, but once again, using one method, to then use a second method to list, to then strip and playback. thats wild.

You've obviously spent a great deal of time working out what is specific to your use case, and from what i saw in another PR (or was it an issue) other team members dont doubt there are improvements to be made on some filesystem backends, but i dont think you'll find a way to justify this change to anyone on the team at this point.

I personally use nfs (and have for years) without the drama you've said is the end of the world, and i know other team members have mentioned they use nfs as well in passing conversations. Horses for courses, and i dont want you to think im disregarding whatever issues you are having with your setup.

By all means PR whatever changes you think are good, but not everything is going to be accepted. I hope you do endeavour to improve whatever you want in whatever filesystem you choose to make such a crazy method outlined not needed by yourself.

[kyles]

Honestly, dont go spouting things you absolutely can not prove. That helps no one in a discussion.

To me, that sounds like such an insanely niche thing. Ive never heard of anyone ever doing such a thing. I understand you think this change is the greatest thing to ever happen, but once again, using one method, to then use a second method to list, to then strip and playback. thats wild.

You've obviously spent a great deal of time working out what is specific to your use case, and from what i saw in another PR (or was it an issue) other team members dont doubt there are improvements to be made on some filesystem backends, but i dont think you'll find a way to justify this change to anyone on the team at this point.

I personally use nfs (and have for years) without the drama you've said is the end of the world, and i know other team members have mentioned they use nfs as well in passing conversations. Horses for courses, and i dont want you to think im disregarding whatever issues you are having with your setup.

By all means PR whatever changes you think are good, but not everything is going to be accepted. I hope you do endeavour to improve whatever you want in whatever filesystem you choose to make such a crazy method outlined not needed by yourself.

I think the critical difference here is I don't have < 1ms to the source, I have 4-30ms depending on the peering between the locations and (literally) the time of day. So when I'm using any of these network protocols over what is essentially a MPLS circuit, I'm going to hit edge cases like a single stat taking 30ms as opposed to 0.3-0.7ms depending on the interrupt rate of the machines involved. These issues are still there, but they're going to be more invisible to people less than 100M from their source as opposed to running NFS between telcos.

Presently, there doesn't appear to be any other solution that's workable in Kodi for this scenario, simply due to the lack of pipelining and threadsafe filesystems.

So, yes, wild, but it resolves a large class of issues where people would normally be using that Plex or similar solution. From what I can tell, HTTP (streaming) was designed for a latency link, the others less so.