[AaronCompNetSys]

I noticed that the cache GUI was taken out, which doesn't make sense to me, and that only DVDplayer is available now instead of Mplayer as a secondary option.

This now means that all my x264 1080p content is at a fixed 2MB buffer, which is not enough. I previously used 16 to 30MB with no issues. Yes, its over a wireless link, so 2MBps is the line speed, but most if not all x264 allows plenty of variability to build the buffer up.

I tried changing the CacheMemBuffer that DVDplayer uses, that didn't work.
I tried changing cachevideo/lan to 16384, nothing either. I have 9.04.1, and I know it worked before on this machine with an older version of XBMC.

Am I missing something or was this done on purpose?

I just wiped my profile with the update, so I think I may have been carrying over settings from an old version. I'm grabbing an old version now to try.....

[AaronCompNetSys]

I just tried 8x version, and I still cant break out of this 2MB buffer, I have to be missing something. I remember before having to sit for 20 seconds while it filled part of the 20MB buffer after a skip, which is what I want.

[prae5]

I might be mistaken, but i seem to recall that that cache value did nothing at all as it wasn't linked to anything, hence the reason it was removed.

iirc it did on the xbox, again i might be mistaken but i don't recall mplayer ever being an option on anything but the xbox.

[topfs2]

I might be mistaken, but i seem to recall that that cache value did nothing at all as it wasn't linked to anything, hence the reason it was removed.

iirc it did on the xbox, again i might be mistaken but i don't recall mplayer ever being an option on anything but the xbox.

Correct, any benefits seen from altering them was placebo

[AaronCompNetSys]

Well, I do use the original xbox alot for SD and HR-HD, and my memory does suck pretty bad
So what about a resolution anyway? Shouldn't this work? I'm still in need of a solution, and VLC isn't one of then. Can someone try it out on a Mac 9x build and see if I'm just doing something wrong?

[AaronCompNetSys]

Bump? I can't imagine that 2MB is enough for all XBMC users, I can't be the only one.

[AaronCompNetSys]

Hello? Anyone? I've tried every way I can figure to bump the cache to something useful. Can someone who is more knowledgeable than me take a look and bump the Trac ticket if this is really broken?
Or just tell me how stupid I am and how to correct my problem?

[elupus]

Why would you ever need more?

If you need more your network isn't fast enough. Then you should download the movie and play it locally instead.

[AaronCompNetSys]

Myself as well as many users are going to cheap NAS solutions. I'm not going to abandon my (yes, it is slightly slow) NAS because of a cache setting. VLC works fine with a 20MB cache, but their program sucks
My reason for bandwidth limitations is my problem, I'll deal with it separately.

To elaborate on why it makes sense and really does work in practice to have a large cache over a unreliable connection: (I'm sure you know this already, but I'll post for a reader who might not)
x264 (and h.264) bitrates vary wildly in accordance to content. The opening credits may use 0.5Mbps while an explosion will use 10Mbps. I rarely see 1080p content hit the 2MBps barier consistently, but it does and usually for short periods. Those instances are easily taken care of by a larger buffer. No a larger buffer will not fix Michael Bay's newest movie: "Explosions, Constantly!" which contains 3MBps compressed content for the entirety of the film, but that isn't the goal here.

Example used for streaming content over a unreliable but capable network: streaming your neighbor's content wirelessly house to house No, I don't do that but I might.

[elupus]

Well bitrate things are a different problem.. We should be caching based on time not buffer size, then the buffer will grow when bitrate increases.

Been on my todolist for ages. At some point it'll get done

[AaronCompNetSys]

Great idea, thank you. Let me know if I can be of any help at all.

[SniperCharlie]

I recently updated to the newest SVN for XBOX - and the LAN loading time for audio is ridiculously slow. 10+ seconds most times. Checked all my samba settings and access from other machines is fine.

Since the cache options are gone - I manually edited guisettings.xml to lower my music cache with no improvement - if what was said above was true these settings are now ignored?

On a side note - video loads about the same rate, but seems to function a little better.

Perhaps my Xbox NIC is dying and its just really slow but the wireless bridge I have the xbox hooked up to functions with great throughput to any device connected including the Xbox 360 for live gaming - so LAN traffic shouldn't be an issue.

However, streaming movies tends to fail out often and now loading a flac, or even an MP3 can take quite a while.

It's not a great addition to a media center when changing songs takes an extra 10 seconds. What happened to the first releases of XBMC that worked great on Xbox? Now most scripts, plugins, and streaming programs don't function properly. I understand most of those scripts are out of date - but is it time to update to buy a mini-mac just to have the best media interface available?

Any help needed on this issue I can try and provide - scripting/programming skills somewhat limited but I can at the very least provide a few test environments.

[Seft]

To elaborate on why it makes sense and really does work in practice to have a large cache over a unreliable connection: (I'm sure you know this already, but I'll post for a reader who might not)
x264 (and h.264) bitrates vary wildly in accordance to content. The opening credits may use 0.5Mbps while an explosion will use 10Mbps. I rarely see 1080p content hit the 2MBps barier consistently, but it does and usually for short periods. Those instances are easily taken care of by a larger buffer. No a larger buffer will not fix Michael Bay's newest movie: "Explosions, Constantly!" which contains 3MBps compressed content for the entirety of the film, but that isn't the goal here.

It makes sense over an entirely solid connection. I get 2-3MBps on my Homeplug network, which is fine most of the time for 720P video. However, I occasionally have to rebuffer because of a bitrate spike in a particularly busy/grainy scene. Given that there's almost certainly some spare bandwidth for the 99% of the movie that works just fine, it would seem to be sensible to put it to use and buffer ahead.

[AaronCompNetSys]

I've given up on XBMC and switched to Plex for now. Network buffer just plain works. 1080p h264 over a 3.5MBps connection gets manhandled into submission with a 20 second buffer. I watched as an intense scene chewed into the buffer while Plex just took it in its stride, starting at 99% and crunching down to 5% at the lowest before recovering. Example scenes: lightening in Astroboy's birth and Wall-E escape pod scenes.

On a separate note, the loopback filter actually works as advertised in Plex too (h264 "speed boost").

Sorry XBMC, I'll be back some day.

Seft, take a look, you won't be disappointed in the cache. The loss of Confluence might be though

[woutje76]

I must say I think AaronCompNetSys is having a valid point here.
I also do use a NAS connected via Airport Ethernet and a GB switch.

Throughput and ping times are minimal but not adequate enough to compensate for the sudden vast increase in megabit/sec seen in blu-ray rips.
In a few frames time the bit-rate can increase from 15-20 to 40-45. A 2 megabyte cache would rapidly result in a buffer underrun and result in either:
- the GUI element informing you that buffer is being replenished
- the screen showing small stripes and stuttering

Both of which occur in my scenario.

Is there a valid ground for re-introducing this setting for people using a NAS as a source for playing files on the AppleTV?