[alex_a]

Hey guys,

I wanted to check with the team what is the status of PR2607 ...

The feature (and proposed implementation) have been around in one form or another for a year now, if we go back to PR1388 & PR831. Most of the feedback on the PR is positive (except one or two "I don't like it" comments, which do not provide any real critique as to what in particular isn't liked). It had been successfully tested by many people in Rbej OpenElec builds (http://openelec.tv/forum/124-raspberry-p...s-openelec). Yet, it hasn't made it into the mainline XBMC, and based on the current June list, there's no plans to include it.

When implemented, it'd benefit a very large segment of people who stream from NAS or home server SMB share over wireless ... if you search forums for people trying to resolve buffering problems, you'd find quite a few. Yet, the PR seems to be dead at the moment, with the last comment being over two months old. Is there any chance this could be revived? I know it'd help me, and based on what I've found in my attempts to resolve this problem, it'd help A LOT of people.

Thank you for all the work you do!
- A.

[DJ_Izumi]

Backing this, I think it's something that'd be a practical solution to a lot of 'SMB Streaming' threads that are never resolved.

[alcoheca]

It's not being ignored, the OP has some work to do.

[alex_a]

It's not being ignored, the OP has some work to do.

Do you mean the contrived scenario of rapidly switching between different subtitle tracks? Does anyone seriously think that regressing in this area is worse then continue on with broken LAN streaming?

[alcoheca]

I normally wouldn't respond to narky comments from people but it's late so maybe that's why we're all narky

They have to rebase, split and rename the commits and address the issue with broken external subs; doing this all in the course of a few days or so in order to get and keep the attention required for someone to accept it.

It's not that much to ask is it?

[alex_a]

I normally wouldn't respond to narky comments from people but it's late so maybe that's why we're all narky

They have to rebase, split and rename the commits and address the issue with broken external subs; doing this all in the course of a few days or so in order to get and keep the attention required for someone to accept it.

It's not that much to ask is it?

Sorry if this sounded as snark, I was really wondering if the problem seen was too critical to hold this up.

I did miss the splitting requests, and I guess after two months another rebase was needed. I did skip over the portion that modifies how memory caching works, and submitted a PR2843, which only allows using existing cache mechanism to be applied to all streams.

Thanks again!

[alcoheca]

great thanks for doing that

[Faldaani]

Also, having XBMC crash due to running out of memory when streaming from .rar files (15mb each) on a 512mb raspberry pi, with the percentage set to 45%.
Haven't looked into it any further yet, but it'd be nice if we didn't break rar support..

EDIT: As for the subtitle thing being contrived, sure.. but it probably points to a bigger issue somewhere?

[Ned Scott]

Also, having XBMC crash due to running out of memory when streaming from .rar files (15mb each) on a 512mb raspberry pi, with the percentage set to 45%.
Haven't looked into it any further yet, but it'd be nice if we didn't break rar support..

EDIT: As for the subtitle thing being contrived, sure.. but it probably points to a bigger issue somewhere?

...and this has nothing to do with what we're talking about...?

[Kib]

mod edit: fixed some pull request links in several posts.

Update: A modified pull request of the ones discussed here was made in PR2843 and some progress has been made.

Interested parties are as always welcome to read the current state there, but be advised not to post to github PRs unless you have code to share.
This because every post there is spammed by email to every participant.

All other discussion of this PR should be done here,

[Faldaani]

Also, having XBMC crash due to running out of memory when streaming from .rar files (15mb each) on a 512mb raspberry pi, with the percentage set to 45%.
Haven't looked into it any further yet, but it'd be nice if we didn't break rar support..

EDIT: As for the subtitle thing being contrived, sure.. but it probably points to a bigger issue somewhere?

...and this has nothing to do with what we're talking about...?

Yeah, it does. Because without this PR it doesn't crash.
Thus something is borked, probably allocation or lack of cleanup (or delayed cleanup) of the allocated (now very large) cache.

[ZERO <ibis>]

Would not this issue only occur on either A) slow network or B) drive to slow to stream from

Seems to me these are pretty simple things to resolve.

[alex_a]

Would not this issue only occur on either A) slow network or B) drive to slow to stream from

Seems to me these are pretty simple things to resolve.

That depends. Running ethernet may not be an option, and even the best wireless connection isn't fast enough when more than one person are actively streaming content (and not necessarily, local/XBMC content).

---

Also, having XBMC crash due to running out of memory when streaming from .rar files (15mb each) on a 512mb raspberry pi, with the percentage set to 45%.
Haven't looked into it any further yet, but it'd be nice if we didn't break rar support..

EDIT: As for the subtitle thing being contrived, sure.. but it probably points to a bigger issue somewhere?

...and this has nothing to do with what we're talking about...?

Yeah, it does. Because without this PR it doesn't crash.
Thus something is borked, probably allocation or lack of cleanup (or delayed cleanup) of the allocated (now very large) cache.

I agree there's some issue related to cleanup. I have been chasing it, as I definitely see buffer underruns towards the end of the movie (at a point, where the EOF occurs, but a large buffer is still outstanding).

Still, the patch is an improvement upon current situation -- by default, it changes nothing, yet gives some of us a setting turning a poor viewing experience into a tolerable one. Hopefully, I'll find the problem before the next official release -- I've had a very limited amount of time to work on it in the last week or so; hope to get more next week.

But, just as an illustration, I've been playing with logging buffer stats, and on some BD rips I've seen it go from 70MB to 0 in no time -- and usually, bitrate surges, rather than slow connection were at play.

[Ned Scott]

Also, having XBMC crash due to running out of memory when streaming from .rar files (15mb each) on a 512mb raspberry pi, with the percentage set to 45%.
Haven't looked into it any further yet, but it'd be nice if we didn't break rar support..

EDIT: As for the subtitle thing being contrived, sure.. but it probably points to a bigger issue somewhere?

...and this has nothing to do with what we're talking about...?

Yeah, it does. Because without this PR it doesn't crash.
Thus something is borked, probably allocation or lack of cleanup (or delayed cleanup) of the allocated (now very large) cache.

Ah, I see now. Sorry, I misunderstood.

Though, I thought XBMC un-rar'ed parts in the temp folder and played from there, but maybe that's only when XBMC is forced to unrar the whole file at once (when compression).

[DJ_Izumi]

Would not this issue only occur on either A) slow network or B) drive to slow to stream from

Seems to me these are pretty simple things to resolve.

No, there's some 'fast' wireless network hardware that gives issues. I have an 802.11ac network with an AC client and several N clients. More than sufficient throughput, but ONLY by using the most recent beta driver for the router, which allows a streaming optimized 'Xbox Mode' for the wireless networks can it even stream over SMB without cutting out every 10-60mins. (Which is about just frequent enough to turn one's viewing experience into a desire to throw computers out of windows)/ XBMC is extremely finicky about even a single packet not getting delivered the moment it demands it. This requirement of 'Xbox Mode' prevents me from using DDWRT on my $200 router. (Replicated this and it's solution on multiple XBMC machines and both Linux and Windows) It's not always about how 'fast' the network is but how immediate it gives a packet in response to XBMC.

There's actually a LOT of threads on this forum with unexplained SMB/buffering issues on wireless that would likely see this solution.