OK thanks, I'll try MEMCACHE.

This is the build I'm attempting:

export BUILD_ROOT=$PWD/build
export PATH=/usr/local/python2.5/bin:$BUILD_ROOT/bin:$PATH
export SYSTEM_ID=linux-2.2-libc6-gcc32-i586

HELIX_DATESTAMP="-D 20070913"
HELIX_BRANCH="helix_restricted"
HELIX_PROFILE="helix-client-audio-all-fixpt"
HELIX_BUILD_COMMAND="build.py"

$HELIX_BUILD_COMMAND -m $HELIX_BRANCH -P $HELIX_PROFILE -trelease 
-tsymbols $HELIX_DATESTAMP filesystem_http


There's normally a few checkout and rebuild iterations before arriving 
at a working version due to missed HELIX_FEATURES, bad combinations of 
HEALIX_FEATURES etc. Do you have a known profile that is known to work 
with that feature ? This would be much appreciated as we're under a bit 
of time pressure to get this working. If you could edit the above build 
info with your recommended one that would be helpful.

eg should I be using branch
hxclient_3_1_0_atlas_restricted

John



Milko Boic wrote:

>
> If using Atlas httpfsys, give HELIX_FEATURE_HTTP_MEMCACHE a try (also 
> configurable via preferences).
> See the description of the feature below:
>
> Also, if you could send us the call-stack of the seg-fault, we could 
> help further with HELIX_FEATURE_HTTPFSYS_MEM_GROWTH_LIMIT feature.
>
> Thanks,
> Milko
>
> Modified by: milko at real.com
> Date: 08:22:07
> Project: Atlas
>
> Synopsis: MemCache support for HTTP
>
> Overview:
> The change supplies mem-cache functionality to
> HTTP file system.
>
> Mem-cache is memory resident MRU driven cache
> that automatically trims during download.
> The cache is useful to maintain an appropriate
> possibly non-contiguous pool of data that is
> in use and provide limited, localized random
> access around most recently used blocks thus
> eliminating need for re-acquisition of the data
> from the server.
>
> HTTP file system already supported MRU driven
> disk based cache (aka ChunkyRes) which stored
> the entire download on the disk. For clients
> utilizing Super-buffer (RecordControl) this
> represented double storage of data. Use
> of disk also introduced performance issues on
> systems displaying video on primary thread due
> to the synchronous disk I/O. For those reason
> use of mem-cache is much preferred.
>
> Already existing HELIX_FEATURE_HTTPFSYS_MEM_GROWTH_LIMIT
> feature was overly simplistic to be a general solution
> as it turnes the ChunkyRes into a linear cache which
> does not work for formats requiring mulitple read
> pointers into the file.
> HELIX_FEATURE_HTTPFSYS_MEM_GROWTH_LIMIT also suffers from
> possibility of having data trapped beyond the range of
> data being read casing the buffer to fill and being unable to
> purge.
>
> HELIX_FEATURE_HTTPFSYS_MEM_GROWTH_LIMIT can still be used
> when new HTTP mem-cache is enabled. Mem-cache fixes the issue
> of trapped data as it is purges data in non-liear fassion
> when buffer is filled.
>
> The new mem-cache feature can be enabled at compile time to
> be used by default via HELIX_FEATURE_HTTP_MEMCACHE.
> It can be also enabled/disabled at run-time (regardless of
> compile-time setting) via HTTPMemCacheSize preference:
> HTTPMemCacheSize = 0
> (mem-cache is disabled, disk cache is used unless
> configured differently)
> HTTPMemCacheSize = <size of cache in bytes>
> <mem-cache is enabled of the indicated size, disk
>
> Mem-cache default size is 4MB and 0.5MB for MIN_HEAP builds.
> Trimming of mem-cache occurs in 25% of total size incerements
> when cache is full and any of the read pointers have less
> than their equal share of 25% of total cache size of contiguous
> data ahead of them.
>
> This changes also changes the deafult ChunkyRes settings:
> MIN_HEAP build:
> Memory resident data 256KB -> 256KB (no change)
> Page size 32kb -> 32kb (no change)
> Regular build:
> Memory resident data 256KB -> 4MB
> Page size 32KB -> 64KB
>
>
> Modified files:
> /common/fileio/chunkres.cpp,
> common/fileio/pub/chunkres.h
> /filesystem/http/httpfsys.cpp
> /filesystem/http/httpfsys.h,
>
> Image Size and Heap Use impact (Client -Only):
> Small increase.
>
> Platforms and Profiles Affected:
> All
>
> Distribution Libraries Affected:
> none
>
> Distribution library impact and planned action:
> n/a
>
> Platforms and Profiles Build Verified:
> system id: macos-gcc4-xcode22,
> target: LitePlayer
> profile: helix-client-playerx
> branch: playerx
> Options: nodll
>
>
> Platforms and Profiles Functionality verified:
> OS-X
>
> Branches:
> HEAD, hxclient_3_1_0_atlas
>
>
> At 08:11 AM 9/14/2007, John Stirling wrote:
>
>> It appears we never had this working. We'd set the helix fetures, but 
>> it was a cayenne build which doesn't appear to have any of those 
>> features in the code.
>>
>> When we checkout and build filesystem_http on atlas and copy that 
>> into a cayenne build it works fine (with MEM_GROWTH not defined). As 
>> soon as we define it, then it either segfaults (on arm-linux - don't 
>> know where yet) or or just sits there 'opening file'.
>>
>> Do you have a known working profile that contains these features ? 
>> Are there any others essential to making it work ?
>>
>> John
>>
>>
>>
>> John Stirling wrote:
>>
>>> We're seeing a problem when we try to play a large mp3 podcast via 
>>> http (file length is known).
>>>
>>> We've already got these features defined (as suggested by greg) 
>>> which fixed playback of fixed length mp3 files via http (smaller 
>>> files than the podcast we're trying to play).
>>>
>>> project.AddDefines('HELIX_FEATURE_HTTPFSYS_MEM_GROWTH_LIMIT')
>>> project.AddDefines("CHUNK_RES_MEM_FLOOR=128000")
>>> project.AddDefines("CHUNK_RES_MEM_CEILING=256000")
>>>
>>> When playing the file a PNX_* file is created in /tmp which grows 
>>> until we run out of memory.
>>>
>>> We'll check what's getting reported by
>>> HXBOOL CHTTPFileObject::IsLiveStream(const char* pMimeType)
>>>
>>> In the meantime do you have any suggestions ?
>>>
>>> John
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Helix-client-dev mailing list
>>> Helix-client-dev at helixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>
>>
>>
>>
>> _______________________________________________
>> Helix-client-dev mailing list
>> Helix-client-dev at helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>
>
>