Yeah, this is because the kernel has to allocate extra memory to keep track of all its extra memory! The 'data size' reported by big_mem players differs greatly from that of stock due to this.

Basically the player application makes an assumption of the kernel's size when calculating the cache size. Mark and I have had a few discussions on how to deal with this such that ReserveCache wouldn't be needed purely to deal with an increased kernel size (thus allowing more/bigger hijack features), but unfortunately the player's calculation borks on 16MB players if hijack misreports the memory size to achieve this. (Mark tried this in a series of kernels around v400)

For the moment the issue is simmering on the back burner and ReserveCache is the recommended way of dealing with increased kernel size. If the player application gets modified to allow hijack to deal with this more gracefully, or if Mark or I think of another way to do it then that requirement could go away.

180 sounds like a lot though. My quick guesstimate suggests that ReserveCache=6 should be enough to cover the additional 324k of data space. Can you verify this? (If it isn't then try 8,10...)
_________________________
Mk2a 60GB Blue. Serial 030102962 sig.mp3: File Format not Valid.