Hi, 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 Megabit/s 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, Thomas
Ok thanks a lot. 2012/9/27 R?cker Thomas <thomas.ruecker at tieto.com>:> Hi, > > 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 > Megabit/s > 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, > > Thomas > _______________________________________________ > Icecast-dev mailing list > Icecast-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast-dev
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>: >> Hi, >> >> 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 >> Megabit/s >> 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, >> >> Thomas >> _______________________________________________ >> Icecast-dev mailing list >> Icecast-dev at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast-dev