From bogus@does.not.exist.com Mon Aug 17 22:47:44 2026 From: bogus@does.not.exist.com () Date: Mon, 17 Aug 2026 22:47:44 -0000 Subject: No subject Message-ID: --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request at xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered. From bogus@does.not.exist.com Mon Aug 17 22:47:44 2026 From: bogus@does.not.exist.com () Date: Mon, 17 Aug 2026 22:47:44 -0000 Subject: No subject Message-ID: one of the possible streams will be chosen, either by round-robin, some other deterministic method, or by geographic or netographic proximity. The question for implementation here is whether to implement this at the directory server level or somewhere else. In one scenario (this is similar to how the Shoutcast directory operates), the relay streams report to the directory server directly and the directory is responsible for authenticating and grouping this information. In a different scenario, the original server (or whatever owns the directory entry) is responsible for reporting on it's relays. The latter scenario makes more sense, in my opinion, and supports other types of media entries better. Putting the responsibility on the owner of the entry for tracking its mirrors seems correct. Note that a 'professional' stream might handle this case in a different way, by having relays hidden behind a multi-host dns entry, in the same way that webservers are often load balanced. In this situation, the stream would appear as Type 1. Type 3: Single stream with multiple bitrates -------------------------------------------- A broadcaster may offer a stream at a variety of bitrates for technolgies that don't support transparency in this regard. Typical broadcasters may offer both a high and low bitrate version of their content. In icecast terminology, we call the the group a stream and each bitrate an instance of the stream. This terminology is reflected in configuration files for ices. It is important to group these instances under a common entry, since they logically represent one stream. Like a mirror/relay, this is just an alternative version of the same data, not new data. This should be handled in much the same was as mirrors. As much as possible the users should be given streams automatically, and in all cases this should appear to the users as alternatives for one stream, and not appear as multiple distinct streams. In the case where someone mirrors this type of broadcast, they may only mirror parts. A mirror is an alternative location for an instance of a stream. A stream is broken up into it's instances (alternative formats and bitrates for examples), and these instances may have mirrors. This also speaks for the owner responsibility model for tracking mirrors. It would be fairly easy to have the original server track this information, but tracking it on the directory would involve some searching and grouping. The owner of the stream can know more about the connectivity of a mirror much easier than the directory can. Type 4: Multiple streams ------------------------ Many broadcasters will want to offer multiple distinct streams to the public. This should be handled differently than many streams of types 1, 2 or 3. It is sometimes useful to know what other streams a particular broadcaster offers. If one really enjoys a particular stream, one might likely enjoy another from the same broadcaster. These should be in a logical group, even if such a grouping is never offered to a user. It is also likely that these streams will be maintained in the directory as a group, and not as a number of single stream entries. All the groups apply from the previous three cases. You might have multiple streams, each with multiple formats and bitrates, and each of those with alternative locations. Type 5: Directories of streams ------------------------------ This case is likely to be rare, but two directory systems might become part of a third system. In this case, one might want to preserve which directory each set of streams came from. This type is also likely to maintained in a much different way. The directory itself will probably maintain directory level entries. Current state ------------- The current directories only support Type 1 and Type 2 entries. Considering common Type 3 and Type 4 are, this is a serious deficiency, and must be addressed in the new directory system being proposed. All types of entries must be gracefully handled, and only type 5 can be left to some manual or custom handling. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request at xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered. From bogus@does.not.exist.com Mon Aug 17 22:47:44 2026 From: bogus@does.not.exist.com () Date: Mon, 17 Aug 2026 22:47:44 -0000 Subject: No subject Message-ID: ---[start]----- 64 1 2 ---[end]----- ices ldd output: ---[start]----- libpthread.so.0 => /lib/libpthread.so.0 (0x40023000) libshout.so.1 => /usr/local/lib/libshout.so.1 (0x40039000) libmp3lame.so.0 => /usr/local/lib/libmp3lame.so.0 (0x4003d000) libnsl.so.1 => /lib/libnsl.so.1 (0x400e7000) libdl.so.2 => /lib/libdl.so.2 (0x400fe000) libm.so.6 => /lib/libm.so.6 (0x40101000) libc.so.6 => /lib/libc.so.6 (0x40121000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40247000) libxml.so.1 => /usr/lib/libxml.so.1 (0x40274000) libz.so.1 => /usr/lib/libz.so.1 (0x402d0000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) ---[end]----- ices 0.1.0 reencoded my mp3s without any problem (as verified by mpg123, freeamp, xmms, and by ear). My mp3s are encoded with the following command: /usr/local/src/lame3.86/lame -S -V 1 -b 128 -h -m j \ --tt "title" --ta "artist" --tl "album" \ --ty "year" --tn tracknum song.wav song.mp3 If there's any info I'm leaving out here, let me know. I'm stuck using ices 0.1.0 at the moment, which core dumps every 10 or 15 songs. Thanks, -- Steve Chadsey Now playing: Feel the Same (Riot - "Fire Down Under") --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request at xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered. From bogus@does.not.exist.com Mon Aug 17 22:47:44 2026 From: bogus@does.not.exist.com () Date: Mon, 17 Aug 2026 22:47:44 -0000 Subject: No subject Message-ID:

--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request at xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered. From bogus@does.not.exist.com Mon Aug 17 22:47:44 2026 From: bogus@does.not.exist.com () Date: Mon, 17 Aug 2026 22:47:44 -0000 Subject: No subject Message-ID: of the time its 120 kbytes but every 3-4 time its 120 or 116 kbytes. The config file is attached. As you can see I am starting two icecast streams, one 128 kbits and one 64. It also leaks with just one stream. Thanks, Kristjan

-----Original Message----- From: owner-icecast at xiph.org [mailto:owner-icecast at xiph.org]On Behalf Of Akos Maroy Sent: 8. april 2002 14:34 To: icecast at xiph.org Subject: Re: [icecast] Darkice memory leak

Kristjan, > After babysitting liveice for few months I decided to move to Darkice. First > I tried installing Darkice on Redhat7.1 but soon gave up after endless > broken dependencies. Upgraded to Redhat7.2 and the rpms were accepted right > away. I installed: > > lame-3.91-1.i686.rpm > libogg-1.0rc3-1.i386.rpm > libvorbis-1.0rc3-1.i386.rpm > darkice-0.9-1.i386.rpm > > Darkice runs but it eats up memory like hell. I tried compiling from src > and its still leaking. I still want to spend more time on getting Darkice > to work because believe its more stable than liveice. Can anyone help? Hmm. Very strange. I've been using darkice 24 hours a day for over 1.5 years now. Though it only runs 4 hours each time, but I would see a memory leak in such a timespan as well. What is the rate is leaks memory? Can you send me your config file?

Akos

--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request at xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered. --=---------HYPETOMBOXCREATEDBOUNDARY2588 Content-Type: application/octet-stream; name="darkice.cfg" Content-Transfer-Encoding: base64 Content-Description: darkice.cfg Content-Disposition: attachment; filename="darkice.cfg" IyBzYW1wbGUgRGFya0ljZSBjb25maWd1cmF0aW9uIGZpbGUsIGVkaXQgZm9yIHlvdXIgbmVlZHMg YmVmb3JlIHVzaW5nCiMgc2VlIHRoZSBkYXJraWNlLmNmZyBtYW4gcGFnZSBmb3IgZGV0YWlscwoK IyB0aGlzIHNlY3Rpb24gZGVzY3JpYmVzIGdlbmVyYWwgYXNwZWN0cyBvZiB0aGUgbGl2ZSBzdHJl YW1pbmcgc2Vzc2lvbgpbZ2VuZXJhbF0KZHVyYXRpb24gICAgICAgID0gMCAgICAgICAgIyBkdXJh dGlvbiBvZiBlbmNvZGluZywgaW4gc2Vjb25kcy4gMCBtZWFucyBmb3JldmVyCmJ1ZmZlclNlY3Mg ICAgICA9IDUgICAgICAgICAjIHNpemUgb2YgaW50ZXJuYWwgc2xpcCBidWZmZXIsIGluIHNlY29u ZHMKCiMgdGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgYXVkaW8gaW5wdXQgdGhhdCB3aWxsIGJl IHN0cmVhbWVkCltpbnB1dF0KZGV2aWNlICAgICAgICAgID0gL2Rldi9kc3AwICAjIE9TUyBEU1Ag c291bmRjYXJkIGRldmljZSBmb3IgdGhlIGF1ZGlvIGlucHV0CnNhbXBsZVJhdGUgICAgICA9IDQ0 MTAwICAgICAjIHNhbXBsZSByYXRlIGluIEh6LiB0cnkgMTEwMjUsIDIyMDUwIG9yIDQ0MTAwCmJp dHNQZXJTYW1wbGUgICA9IDE2ICAgICAgICAjIGJpdHMgcGVyIHNhbXBsZS4gdHJ5IDE2CmNoYW5u ZWwgICAgICAgICA9IDIgICAgICAgICAjIGNoYW5uZWxzLiAxID0gbW9ubywgMiA9IHN0ZXJlbwoK IyB0aGlzIHNlY3Rpb24gZGVzY3JpYmVzIGEgc3RyZWFtaW5nIGNvbm5lY3Rpb24gdG8gYW4gSWNl Q2FzdCBzZXJ2ZXIKIyB0aGVyZSBtYXkgYmUgdXAgdG8gOCBvZiB0aGVzZSBzZWN0aW9ucywgbmFt ZWQgW2ljZWNhc3QtMF0gLi4uIFtpY2VjYXN0LTddCiMgdGhlc2UgY2FuIGJlIG1peGVkIHdpdGgg W2ljZWNhc3QyLXhdIGFuZCBbc2hvdXRjYXN0LXhdIHNlY3Rpb25zCltpY2VjYXN0LTBdCmJpdHJh dGUgICAgICAgICA9IDEyOCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgYml0cmF0 ZSBvZiB0aGUgbXAzIHN0cmVhbSBzZW50IHRvIHRoZSBzZXJ2ZXIKc2VydmVyICAgICAgICAgID0g YnVydG9uLm1ham9uZXouaXMgICAgICAgICAgICAgICAgICAjIGhvc3QgbmFtZSBvZiB0aGUgc2Vy dmVyCnBvcnQgICAgICAgICAgICA9IDgwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IyBwb3J0IG9mIHRoZSBJY2VDYXN0IHNlcnZlciwgdXN1YWxseSA4MDAwCnBhc3N3b3JkICAgICAg ICA9IHNuam9icmV0dGkgICAgICAgICAgICAgICAgICAgICAgICAgIyBzb3VyY2UgcGFzc3dvcmQg dG8gdGhlIEljZUNhc3Qgc2VydmVyCm1vdW50UG9pbnQgICAgICA9IGljeV8wICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIyBtb3VudCBwb2ludCBvZiB0aGlzIHN0cmVhbSBvbiB0aGUgSWNl Q2FzdCBzZXJ2ZXIKbmFtZSAgICAgICAgICAgID0gbXV6aWsuaXMgRk04OC41ICAgICAgICAgICAg ICAgICAgICAjIG5hbWUgb2YgdGhlIHN0cmVhbQpkZXNjcmlwdGlvbiAgICAgPSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICMgZGVzY3JpcHRpb24gb2YgdGhlIHN0cmVhbQp1cmwg ICAgICAgICAgICAgPSBodHRwOi8vd3d3Lm11emlrLmlzICAgICAgICAgICAgICAgICMgVVJMIHJl bGF0ZWQgdG8gdGhlIHN0cmVhbQpnZW5yZSAgICAgICAgICAgPSB2YXJpb3VzICAgICAgICAgICAg ICAgICAgICAgICAgICAgICMgZ2VucmUgb2YgdGhlIHN0cmVhbQpwdWJsaWMgICAgICAgICAgPSBu byAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgYWR2ZXJ0aXNlIHRoaXMgc3RyZWFt PwoKW2ljZWNhc3QtMV0KYml0cmF0ZSAgICAgICAgID0gNjQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAjIGJpdHJhdGUgb2YgdGhlIG1wMyBzdHJlYW0gc2VudCB0byB0aGUgc2VydmVy CnNlcnZlciAgICAgICAgICA9IGJ1cnRvbi5tYWpvbmV6LmlzICAgICAgICAgICAgICAgICAgIyBo b3N0IG5hbWUgb2YgdGhlIHNlcnZlcgpwb3J0ICAgICAgICAgICAgPSA4MDAwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICMgcG9ydCBvZiB0aGUgSWNlQ2FzdCBzZXJ2ZXIsIHVzdWFsbHkg ODAwMApwYXNzd29yZCAgICAgICAgPSBzbmpvYnJldHRpICAgICAgICAgICAgICAgICAgICAgICAg ICMgc291cmNlIHBhc3N3b3JkIHRvIHRoZSBJY2VDYXN0IHNlcnZlcgptb3VudFBvaW50ICAgICAg PSBpY3lfMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgbW91bnQgcG9pbnQgb2YgdGhp cyBzdHJlYW0gb24gdGhlIEljZUNhc3Qgc2VydmVyCm5hbWUgICAgICAgICAgICA9IG11emlrLmlz IEZNODguNSAgICAgICAgICAgICAgICAgICAgIyBuYW1lIG9mIHRoZSBzdHJlYW0KZGVzY3JpcHRp b24gICAgID0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGRlc2NyaXB0aW9u IG9mIHRoZSBzdHJlYW0KdXJsICAgICAgICAgICAgID0gaHR0cDovL3d3dy5tdXppay5pcyAgICAg ICAgICAgICAgICAjIFVSTCByZWxhdGVkIHRvIHRoZSBzdHJlYW0KZ2VucmUgICAgICAgICAgID0g dmFyaW91cyAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGdlbnJlIG9mIHRoZSBzdHJlYW0K cHVibGljICAgICAgICAgID0gbm8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGFk dmVydGlzZSB0aGlzIHN0cmVhbT8KCg==

--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request at xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered. --=---------HYPETOMBOXCREATEDBOUNDARY2588-- From bogus@does.not.exist.com Mon Aug 17 22:47:44 2026 From: bogus@does.not.exist.com () Date: Mon, 17 Aug 2026 22:47:44 -0000 Subject: No subject Message-ID:

--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request at xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered. From bogus@does.not.exist.com Mon Aug 17 22:47:44 2026 From: bogus@does.not.exist.com () Date: Mon, 17 Aug 2026 22:47:44 -0000 Subject: No subject Message-ID:

--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request at xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered. From bogus@does.not.exist.com Mon Aug 17 22:47:44 2026 From: bogus@does.not.exist.com () Date: Mon, 17 Aug 2026 22:47:44 -0000 Subject: No subject Message-ID:

--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request at xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered. From bogus@does.not.exist.com Mon Aug 17 22:47:44 2026 From: bogus@does.not.exist.com () Date: Mon, 17 Aug 2026 22:47:44 -0000 Subject: No subject Message-ID:

--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request at xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.