[prae5]

fair enough, hadn't really thought about rewind/fastforward, kind of breaks thought process don't have the issue myself I was just intrigued regarding how the buffering worked. Didint realise you'd need to have to copy the entire file before starting to watch it, figured it could just be copied and simultaneously opened for reading.

That is only one of many reasons. Fundamentally, if your network cannot reliably transfer data for you to watch the content - chances are it isn't going to be able to supply a big buffer fast enough to keep it full.

[davilla]

Well written post, horrible and useless responses. A better buffer system would be appreciated but I haven't looked into what the community is doing about it. Do you have any links to threads?

Useless because the XBMC devs have already considered such a thing and have discarded it has completely useless at solving a crappy wifi issue.

[TugboatBill]

You want a big buffer? Get a 1TB USB hard drive.

[AnalogKid]

so waiting 10-15 mins before a movie starts is acceptable?

That sir, is a very misleading comment and I suspect you know it!

There is no reason why any buffer need be 100% full before allowing the current contents to be read...

A buffer will never solve a bad network, but it WILL 'buffer' inconsistent throughput and provide a 'constant' level of throughput which is ideal for streaming style applications.

So, a buffer loads a few meg and caches the data locally, then begins playback, IF the network can afford it, it tries to grab more data than it needs (whilst it can) in order to ensure a regular stream of data for the playback. The buffer increases to MAX_BUFFER size, but may descrease down to 0 if there's no bandwidth (when it hits 0, you get stuttered playback, or the video just stops).

This is how most web client streaming works, and CD burners etc... this 'waiting for 15 mins' until the buffer reaches MAX_BUFFER size is a red herring!

You scoundrel, rapscallion and general rogue!

[AnalogKid]

Useless because the XBMC devs have already considered such a thing and have discarded it has completely useless at solving a crappy wifi issue.

Just because it was developed then discounted, doesn't make it invalid, or indeed suggest it never worked.

Perhaps it wasn't as smart as it could have been, and my understanding was that it was developed early on for XBox.

Getting someone to code it is another matter, and if nobody can be bothered, that's fair enough, but it still doesn't make the suggestion and revisiting of a decision a bad one.

XBMC's great, but there's still some 'whacky' design decisions lingering around!

[AnalogKid]

That is only one of many reasons. Fundamentally, if your network cannot reliably transfer data for you to watch the content - chances are it isn't going to be able to supply a big buffer fast enough to keep it full.

This is partly true, but the purpose of a buffer is never, has never been, and could never be to increase bandwidth. The purpose is to 'buffer' fluctuations in throughput in order to maintain a constant bandwidth.
WiFi networks are notorious for fluctuations in bandwidth, whilst having an overall decent bandwidth. For video streaming, it's the fluctuations that screw up playback, hence the buffering requirement.

Totally agree that a slow network's a slow network and there is no hope for that, but a 5 second dip in bandwidth should not be the cause of movie playback stuttering or even stopping.

It's untrue to say 'chances are it won't be able to keep the buffer full'. It doesn't have to. It only has to keep it from being empty. If the 'average' bandwidth of the network is sufficient, then the buffer will act as a 'dip' filter. The peaks in bandwidth act as a buffer filler.

The most prevalent issue with wireless networks as a transport for media isn't the bandwidth! it's the fluctuations.

[davilla]

Here you do, see http://forum.xbmc.org/showthread.php?tid=51728 for what to diddle. Now quit your bitch'en and start coding patches welcome.

[The_Dogg]

Chances are that if your wifi connection is not good enough to play the file correctly without a bigger buffer, having one would need a few minutes in order to have enough data received to have a good playback. that is why you will need to wait 10 mins before starting the movie.

You would end up with a message saying buffering every few mins.

as someone put it already I agree that a bad network setup/equipement cannot be fixed by an application.

[AnalogKid]

Chances are that if your wifi connection is not good enough to play the file correctly without a bigger buffer, having one would need a few minutes in order to have enough data received to have a good playback. that is why you will need to wait 10 mins before starting the movie.

You would end up with a message saying buffering every few mins.

as someone put it already I agree that a bad network setup/equipement cannot be fixed by an application.

Please try to read, it helps.

[AnalogKid]

Useless because the XBMC devs have already considered such a thing and have discarded it has completely useless at solving a crappy wifi issue.

It isn't just a wifi issue, it's a general optimisation for all networks and improves bandwidth utilisation across any transport.
Just because some devs decide 'nah, don't like it' doesn't make it a logical decision.

If devs can't be bothered, it's their choice what they want to code or not, but making the assumption a buffer does not solve some bandwidth fluctuation issues is like saying "wheels don't rotate".

People keep making the false assumption that a buffer is trying to fix poor wifi speed, it's not.

[Freddo]

A local buffer could also allow for faster seeking on network sources, and allow more advanced timeshifting/recording functionality for live sources (this is basically how sky+ works, by constantly buffering the transport stream)

I still hate wifi with a passion though.

[davilla]

It isn't just a wifi issue, it's a general optimisation for all networks and improves bandwidth utilisation across any transport.
Just because some devs decide 'nah, don't like it' doesn't make it a logical decision.

If devs can't be bothered, it's their choice what they want to code or not, but making the assumption a buffer does not solve some bandwidth fluctuation issues is like saying "wheels don't rotate".

People keep making the false assumption that a buffer is trying to fix poor wifi speed, it's not.

Start coding then Then we will see if you come to the same conclusion or not.

[tanglin]

Instead of kludging a larger buffer, a possible solution would be to enable the ability to locally cache a title, show or series.

This has great benefits for someone like me, I could keep all my titles on my home network share, but when I travel, my laptop's XBMC could be loaded with a cacheful of stuff I want to watch on the road.

I'd like to be able to just select a load of titles, have them background upload (overnight maybe) and when I've watched them, just delete/uncache them.

Extending this to a local cache on a wireless system would probably be trivial, and solve the problem the OP has/had. It may not be feasible for him to have a hardwired 1Gb network like many of us have the luxury of!

[teixeiras]

Half of wireless network works with high and lows.
When its high it can full cache in few seconds and stay at "idle" waiting to be used. But at lows can take several seconds to full it.

Higher cache can help to recharch full cache during higher signals and compensate the lows.

It should really be an user option, since everyone has different network settings.

I hops u understand what I mean

[umpa]

XBMC used to have a setting for setting a cache file size. This would be handy for me at the moment after a firmware update has rendered my ShareSpace NAS all but about useless for streaming video, I have applied their fix patch, but its still no good. I could live with a few minutes buffering, FYI I am on a Cat5e Gigabit network, with a prosafe gigabit switch.