Ok, you have been very clear. If I have any other questions I will contact again. Thanks a lot. Best Renato 2012/9/25 R?cker Thomas <thomas.ruecker at tieto.com>:> On 25/09/12 18:41, renato fringuello wrote: >> For example, this station: http://radio.dyne.org:8000/ondarossa.mp3 >> has got a xspf file? >> I obtain a message: Could not parse XSLT file when i try to open it > Ah, you are talking about the /individual/ servers, not about > http://dir.xiph.org - that explains it! > > So let's deconstruct this: > This is the status page: http://radio.dyne.org:8000/ > It has a link to http://radio.dyne.org:8000/blackout.mp3.xspf > If you click that link it will show "Could not parse XSLT file". > This is a problem of /this/ particular server. > > I think in Icecast 2.3.x there was a problem that the make-file would > not install the xspf.xsl file properly and thus some distributions > carried 'broken' packages. > Sadly nothing you can do about that on your side. Most up to date > servers should provide that though. (the administrator can disable it > though, together with the web interface). > > >> For the stations that I can't found in yp.xml >> (e.g. http://212.162.68.230/1.mp3 >> http://212.162.68.230/2.mp3 >> http://212.162.68.230/3.mp3 >> http://stream15.top-ix.org/ondequadre ) >> it means they aren't on an official database ? because I can hear >> them! so they exist! > > While those stations do exist they did not chose to be listed on > dir.xiph.org. > It is up to the server administrator and the stream themselves to enable > directory listing. Not everyone does that. > c.f. http://www.icecast.org/docs/icecast-2.3.3/icecast2_config_file.html#yp > http://www.icecast.org/docs/icecast-2.3.3/icecast2_config_file.html#mount > > >> The project to enrich the APIs is a long term plan? Because I think >> this is a very good project and it needs APIs!! > > Yes it's a long term plan. First I'd like to understand the needs of > application developers. > Likely it's going to be quite simple though so that we can cope with the > load of many clients on the server side. > > >> Thanks again for your disponibility and sorry for my english! > > No problem, we're here to help. > > Cheers > > Thomas > _______________________________________________ > Icecast-dev mailing list > Icecast-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast-dev
Hi! I'm here again, I hope I am not too boring! 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? Thanks 2012/9/26 renato fringuello <rfringuello at gmail.com>:> Ok, you have been very clear. > If I have any other questions I will contact again. > > Thanks a lot. > Best > Renato > > 2012/9/25 R?cker Thomas <thomas.ruecker at tieto.com>: >> On 25/09/12 18:41, renato fringuello wrote: >>> For example, this station: http://radio.dyne.org:8000/ondarossa.mp3 >>> has got a xspf file? >>> I obtain a message: Could not parse XSLT file when i try to open it >> Ah, you are talking about the /individual/ servers, not about >> http://dir.xiph.org - that explains it! >> >> So let's deconstruct this: >> This is the status page: http://radio.dyne.org:8000/ >> It has a link to http://radio.dyne.org:8000/blackout.mp3.xspf >> If you click that link it will show "Could not parse XSLT file". >> This is a problem of /this/ particular server. >> >> I think in Icecast 2.3.x there was a problem that the make-file would >> not install the xspf.xsl file properly and thus some distributions >> carried 'broken' packages. >> Sadly nothing you can do about that on your side. Most up to date >> servers should provide that though. (the administrator can disable it >> though, together with the web interface). >> >> >>> For the stations that I can't found in yp.xml >>> (e.g. http://212.162.68.230/1.mp3 >>> http://212.162.68.230/2.mp3 >>> http://212.162.68.230/3.mp3 >>> http://stream15.top-ix.org/ondequadre ) >>> it means they aren't on an official database ? because I can hear >>> them! so they exist! >> >> While those stations do exist they did not chose to be listed on >> dir.xiph.org. >> It is up to the server administrator and the stream themselves to enable >> directory listing. Not everyone does that. >> c.f. http://www.icecast.org/docs/icecast-2.3.3/icecast2_config_file.html#yp >> http://www.icecast.org/docs/icecast-2.3.3/icecast2_config_file.html#mount >> >> >>> The project to enrich the APIs is a long term plan? Because I think >>> this is a very good project and it needs APIs!! >> >> Yes it's a long term plan. First I'd like to understand the needs of >> application developers. >> Likely it's going to be quite simple though so that we can cope with the >> load of many clients on the server side. >> >> >>> Thanks again for your disponibility and sorry for my english! >> >> No problem, we're here to help. >> >> Cheers >> >> Thomas >> _______________________________________________ >> Icecast-dev mailing list >> Icecast-dev at xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast-dev
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