rfringuello at gmail.com
Fri Sep 28 01:54:17 PDT 2012
Hi again! I was thinking to get informations from the xspf file only
if it has been modified.
The problem is, when I try to obtain the date of the alteration (with
CURL), I obtain dates like 1970-01-01 00:59:59 and they never change.
How can I handle that problem?
2012/9/27 renato fringuello <rfringuello at gmail.com>:
> Ok thanks a lot.
> 2012/9/27 Rücker Thomas <thomas.ruecker at tieto.com>:
>> On 27/09/12 12:45, renato fringuello wrote:
>>> I took some radios from yp.xml 2 days ago, but today someone (like
>>> http://streaming207.radionomy.com/AngeFM) answers to me :
>>> "The file you requested could not be found"
>>> what's the problem?
>>> They doesn't exist anymore? They are off now and they could be on later?
>> Yes, yp.xml is a snapshot of the streams that exist at the given time.
>> You should refresh your cached copy every now and then to be up to date.
>> As said previously don't do this too often. I'd guess if your cached
>> copy is older than e.g. 60min and the user does something that requires
>> the list, it should be safe to download a fresh copy.
>> GENERAL WARNING (nothing personal):
>> As said before I'd like to avoid situations where we get some popular
>> software where each client will download the list every 5 minutes.
>> To give everyone reading this list an idea what this could mean:
>> - 500 copies active at a given time
>> - Polling every 5min
>> - XML size (compressed): 500 kByte / uncompressed: 5 MByte
>> - resulting bandwidth usage (compressed): 7 Megabit/s; uncompressed: 70
>> For just /one/ misbehaving software.
>> For comparison the current average bandwidth of the /whole/ dir.xiph.org
>> server is 7Megabit/s (most of it due to uncompressed downloads)
>> Now consider a well behaved software:
>> - 100000 copies active at a given time, install base in the millions.
>> - Updates only when it really needs the list (e.g. the user opens the
>> 'Internet streams' dialogue)
>> - When it needs the list it doesn't update more often than every e.g. 60min
>> - Uses RFC2616 compliant compression
>> 30 requests per hour, 400kbit/s effective bandwidth usage.
>> (Those numbers are actually educated guesses based on real usage
>> statistics of dir.xiph.org)
>> Thanks for listening,
>> Icecast-dev mailing list
>> Icecast-dev at xiph.org
More information about the Icecast-dev