Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2021-08-06T20:25:20Zhttps://gitlab.xiph.org/xiph/ezstream/-/issues/2274Mountpoint drops and comes back when switching songs via script2021-08-06T20:25:20ZcinderblockgamesMountpoint drops and comes back when switching songs via scriptI'm using
<filename>/ezstream/play-next.sh</filename>
<playlist_program>1</playlist_program>
to take control of the media that gets played, so I can add in stingers and whatever else. The issue, however, is that the mount poin...I'm using
<filename>/ezstream/play-next.sh</filename>
<playlist_program>1</playlist_program>
to take control of the media that gets played, so I can add in stingers and whatever else. The issue, however, is that the mount point drops when switching to the next file. Is there a way to keep this open so that clients don't get dropped and have to reconnect on every changeover?https://gitlab.xiph.org/xiph/rnnoise/-/issues/7using RNNoise in browser2021-08-09T07:44:17ZVishal dhullusing RNNoise in browserhi,i saw the browser implementation of RNNoise,i am curious to know how is this python model is being used in JS ? and where we are initializing it's weight in JS files ?
Thank youhi,i saw the browser implementation of RNNoise,i am curious to know how is this python model is being used in JS ? and where we are initializing it's weight in JS files ?
Thank youhttps://gitlab.xiph.org/xiph/daala/-/issues/1Issue with reading y4m2021-08-13T21:05:23ZJoshua Peter EbenezerIssue with reading y4my4m_input.c in daala/tools has an error in reading the headers of y4m files. Line 565 reads the header for 80 characters or until "\n" is reached:
/*Read until newline, or 80 cols, whichever happens first.*/
for(i=0;i<79;i++)
The pr...y4m_input.c in daala/tools has an error in reading the headers of y4m files. Line 565 reads the header for 80 characters or until "\n" is reached:
/*Read until newline, or 80 cols, whichever happens first.*/
for(i=0;i<79;i++)
The problem is that there is no reason why a y4m header should be less than 80 characters (afaik). I have a y4m file with a long header (more than 80 characters). A quick fix would be increasing this limit to 256.
char buffer[256];
int ret;
int i;
int xstride;
/*Read until newline, or 256 cols, whichever happens first.*/
for(i=0;i<255;i++){
ret=fread(buffer+i,1,1,_fin);
if(ret<1)return -1;
if(buffer[i]=='\n')break;
}
See https://github.com/Netflix/vmaf/issues/889 and https://github.com/Netflix/vmaf/pull/890.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2417After working days without problem Icecast 2.4.4 not trying to update relays ...2022-02-19T09:59:17ZdanielsoheilAfter working days without problem Icecast 2.4.4 not trying to update relays from master serverthis my icecast.xml config:
```
<icecast>
<location>Iran</location>
<admin>info@myts3.ir</admin>
<limits>
<clients>50000</clients>
<sources>1000</sources>
<queue-size>307200</queue-size>
<...this my icecast.xml config:
```
<icecast>
<location>Iran</location>
<admin>info@myts3.ir</admin>
<limits>
<clients>50000</clients>
<sources>1000</sources>
<queue-size>307200</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>600</header-timeout>
<source-timeout>600</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>196608</burst-size>
</limits>
<authentication>
<source-password>removed</source-password>
<relay-password>removed</relay-password>
<admin-user>admin</admin-user>
<admin-password>removed</admin-password>
</authentication>
<hostname>radio.myts3.ir</hostname>
<listen-socket>
<port>18000</port>
</listen-socket>
<http-headers>
<header name="Access-Control-Allow-Origin" value="*" />
</http-headers>
<master-server>192.168.100.53</master-server>
<master-server-port>8000</master-server-port>
<master-update-interval>30</master-update-interval>
<master-password>removed</master-password>
<relays-on-demand>0</relays-on-demand>
<fileserve>1</fileserve>
<paths>
<basedir>/usr/share/icecast</basedir>
<logdir>/var/log/icecast</logdir>
<webroot>/usr/share/icecast/web</webroot>
<adminroot>/usr/share/icecast/admin</adminroot>
<alias source="/" destination="/status-json.xsl"/>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<loglevel>4</loglevel>
<logsize>100000</logsize>
</logging>
<security>
<chroot>0</chroot>
</security>
</icecast>
```
i have logs too, its 66mB i can't send it here.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2418Linking fails with "multiple definition of `global_client_list'"2021-10-26T00:32:54ZThomas SchlienLinking fails with "multiple definition of `global_client_list'"Hi,
the linking, at least on Ubuntu 21.04 and Alpine Linux (docker latest), fails with:
```
CCLD icecast
/usr/bin/ld: icecast-logging.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_li...Hi,
the linking, at least on Ubuntu 21.04 and Alpine Linux (docker latest), fails with:
```
CCLD icecast
/usr/bin/ld: icecast-logging.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-sighandler.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-connection.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-global.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-util.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-slave.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-source.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-stats.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-client.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-xslt.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-fserve.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-admin.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_ogg.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_mp3.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_midi.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_flac.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_ebml.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_kate.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_skeleton.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_opus.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-event.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-event_exec.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-auth.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-auth_htpasswd.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-auth_anonymous.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-auth_static.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-auth_enforce_auth.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-auth_url.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-yp.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
/usr/bin/ld: icecast-format_vorbis.o:/home/schlien/devel/icecast-server/src/client.h:146: multiple definition of `global_client_list'; icecast-main.o:/home/schlien/devel/icecast-server/src/client.h:146: first defined here
collect2: error: ld returned 1 exit status
```
I used `./autogen.sh && ./configure && make -j5 install` to compile.
If I can provide any more information, please let me know.
Best regards,
Thomashttps://gitlab.xiph.org/xiph/xspf-website/-/issues/7Repository name2021-09-06T02:19:21ZMarvin ScholzRepository nameHi, why is this repo, contrary to what was discussed by email, not called xspf-website?
XSPF seems like a rather confusing name for it, given we already have a libxspf repo.Hi, why is this repo, contrary to what was discussed by email, not called xspf-website?
XSPF seems like a rather confusing name for it, given we already have a libxspf repo.https://gitlab.xiph.org/xiph/xspf-website/-/issues/8Define Design Goals2021-10-06T18:40:26ZThematizerDefine Design GoalsHi, this is Tess. I'm a UX Designer with a longstanding interest in music and open source. Thrilled to be part of this project. I put together some questions for my call yesterday with Lucas, but I will share them with the rest of the gr...Hi, this is Tess. I'm a UX Designer with a longstanding interest in music and open source. Thrilled to be part of this project. I put together some questions for my call yesterday with Lucas, but I will share them with the rest of the group:
- Do we want a new XSPF logo or only a new theme / skin for the site?
- Is there a desired time frame or other milestones to coordinate with? (new release, new functionality, etc)
- Any new content types or new / updated site pages?
- Will the overarching XIPH menu at the top stay as is?
- What is the CMS or framework used to generate the site?
- Who is your target end user? (ex. Developer, DJ)
- Can you share some sites whose designs you like?
- What is the most important goal for this redesign?
DESIGN ATTRIBUTES (pick up to three adjectives from this list)
- clean - modern - edgy - original - fresh - high-tech - warm - sleek - metallic - earth tones - monochromatic - funky - polished - industrial - futuristic - professional - friendly - readable - high-impact - crisp - accessible - fun - gritty - streamlined - eclectic - harmonious - corporate - artist-friendly - dramatic - photorealistic - primary colors - pastels - cool colors (blues/greens/grays) - responsive
I am assuming different people will pick different adjectives, and some people will object strenuously to some of the terms on this list. But that's part of the fun.
My process, if you're interested, is to take the feedback I get from these questions and turn them into two or more prompts. I present these to the core development team in a live screenshare (Jitsi or Zoom good) and get people's immediate, uncensored feedback. From there, we iterate...https://gitlab.xiph.org/xiph/icecast-server/-/issues/2419"listenurl" protocol does not match protocol used to request /status-json.xsl2023-09-01T17:53:06ZHenry van Megen"listenurl" protocol does not match protocol used to request /status-json.xslIt's probably because I'm doing something completely stupid, but when I request my /status-json.xsl over https, I see 'http' in the listenurl which I can't seem to change to https instead. This is causing me all kinds of issues with unse...It's probably because I'm doing something completely stupid, but when I request my /status-json.xsl over https, I see 'http' in the listenurl which I can't seem to change to https instead. This is causing me all kinds of issues with unsecure content, CORSS stuff and other nightmares when trying to build something that can actually read this feed.
Content of: https://domain.tld:8000/status-json.xsl (actual values replaced)
```
{
"icestats": {
"admin": "email@domain.tld",
"host": "domain.tld",
"location": "location",
"server_id": "Icecast 2.4.4",
"server_start": "Mon, 09 Aug 2021 17:00:00 +0200",
"server_start_iso8601": "2021-08-09T17:00:00+0200",
"source": {
"audio_bitrate": 192000,
"audio_channels": 2,
"audio_info": "ice-bitrate=192;ice-channels=2;ice-samplerate=44100",
"audio_samplerate": 44100,
"genre": "(NULL)",
"ice-bitrate": 192,
"ice-channels": 2,
"ice-samplerate": 44100,
"listener_peak": 1,
"listeners": 1,
"listenurl": "http://domain.tld:8000/stream.ogg",
"server_description": "Description",
"server_name": "Server name",
"server_type": "audio/ogg",
"server_url": "(NULL)",
"stream_start": "Mon, 09 Aug 2021 17:01:00 +0200",
"stream_start_iso8601": "2021-08-09T17:01:00+0200",
"subtype": "Vorbis",
"dummy": null
}
}
}
```
This is my configuration file `/etc/icecast2/icecast2.xml` : (actual values replaced)
```
<icecast>
<location>location</location>
<admin>email@domain.tld</admin>
<limits>
<clients>1000</clients>
<sources>5</sources>
<queue-size>262144</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>0</burst-on-connect>
<burst-size>4096</burst-size>
</limits>
<authentication>
<source-password>password</source-password>
<relay-password>password</relay-password>
<admin-user>user</admin-user>
<admin-password>password</admin-password>
</authentication>
<hostname>mydomain.tld</hostname>
<listen-socket>
<port>8000</port>
<ssl>1</ssl>
</listen-socket>
<listen-socket>
<port>8443</port>
<ssl>1</ssl>
</listen-socket>
<http-headers>
<header name="Access-Control-Allow-Origin" value="*" />
</http-headers>
<fileserve>1</fileserve>
<paths>
<basedir>/usr/share/icecast2</basedir>
<logdir>/var/log/icecast2</logdir>
<webroot>/usr/share/icecast2/web</webroot>
<adminroot>/usr/share/icecast2/admin</adminroot>
<pidfile>/usr/share/icecast2/icecast.pid</pidfile>
<alias source="/" destination="/"/>
<ssl-certificate>/usr/share/icecast2/letsencrypt-domain-tld-icecast.pem</ssl-certificate>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<playlistlog>playlist.log</playlistlog>
<loglevel>3</loglevel>
<logsize>100000</logsize>
<logarchive>1</logarchive>
</logging>
<security>
<chroot>1</chroot>
<changeowner>
<user>icecast2</user>
<group>icecast2</group>
</changeowner>
</security>
</icecast>
```
is there a way of fixing this by changing something in the configuration, or do I have to parse the json by some external script, fix the replace the protocol itself and then serve the changed version it to my webpage? I would love to just use the content of the json and have it be correct insteadhttps://gitlab.xiph.org/xiph/xspf-website/-/issues/13Final Call for Design Feedback2021-10-09T00:26:23ZThematizerFinal Call for Design FeedbackWe had a good meeting this morning with Rob and Lucas, despite a late start (my bad). We are hoping to make our first pass of design updates asap, so if you have feedback or requests, please take a look at the designs on https://github.c...We had a good meeting this morning with Rob and Lucas, despite a late start (my bad). We are hoping to make our first pass of design updates asap, so if you have feedback or requests, please take a look at the designs on https://github.com/tessgadwa/XSPF-Design-Sandbox and send my way!
We will be meeting again next week at the same time (8 AM PST) unless anybody would like to request a different time.
I also have an open source project with a possible budget attached. This would be integrating playlist features to accompany NFT's created by musicportland.org for their upcoming January Music Month. Please PM me if you're interested in learning more.https://gitlab.xiph.org/xiph/xspf-website/-/issues/14Clarification on acceptance of relative URIs2021-11-10T03:28:26ZPhilipp SchafftClarification on acceptance of relative URIs# Suggested change
The current specification permits for relative URIs in all cases. Based on the discussion on the 2021-09-24 meeting I suggest the following changes:
* Generators MUST create absolute URIs when the absolute form of the ...# Suggested change
The current specification permits for relative URIs in all cases. Based on the discussion on the 2021-09-24 meeting I suggest the following changes:
* Generators MUST create absolute URIs when the absolute form of the URI is known to the generator or can be evaluated by the generator.
* Parsers MUST support absolute URIs in all cases and MAY report or reject relative URIs but SHOULD be able to handle them for backward compatibility.
* The content of the `<location>`-tag is excluded from the above rules. Relative URIs are still considered valid.
* Generators SHOULD NOT generate relative URIs in <location> elements that point to a level in a directory structure higher than their own. Generators SHOULD NOT us the parent directory operator ".." in URIs used in `<location>`.¹
In addition the current clarifications on URIs should be kept in the specification as they are relevant at least when working with legacy data. A note might be added clarifying the reason for them to be still present. Such as: "While relative URIs are not valid they may be present in data generated under earlier revisions of this specification, therefore these rules apply when such data is encountered.".
# Required version updates
This change will not require a version or namespace update.
¹ Those are actually two rules as e.g. "a/../b" is not referring to a higher level but makes it more complex for parsers to check.https://gitlab.xiph.org/xiph/xspf-website/-/issues/15Updates to Content resovers: Well known prefix resolving2021-11-10T03:26:51ZPhilipp SchafftUpdates to Content resovers: Well known prefix resolving# Motivation
As discussed on the mailing list on windows machines "drive letters" can change while the "path part" of the filename is still valid. A suggestion was to allow content resolvers to work around this by allowing them to try ot...# Motivation
As discussed on the mailing list on windows machines "drive letters" can change while the "path part" of the filename is still valid. A suggestion was to allow content resolvers to work around this by allowing them to try other "drives".
# Suggested update
I suggest this more general update:
A content resolver is allowed to alter and try URIs from `<location>` tags in the following way if and only if none of the URIs provided by the `<location>` tags could be opened. Such modified URIs SHOULD be tried before trying to resolve content by other means than `<location>` tags.
Content resolvers MAY replace well known prefixes from URIs with valid local variants of them. This included physical mountpoints as well as logical mount points. However content resolvers SHOULD NOT replace prefixes with of one logical type with values of other logical types.
Valid examples:
* `C:\music\bla.ogg -> D:\music\bla.ogg` (physical mount/logical type "drive" is replaced)
* `/home/foo/bla.ogg -> /home/bar/bla.ogg` (logical mount/logical type "home directory" is replaced)
* `C:\Program Files/My Player/Collection/bla.ogg -> /home/foo/Music/bla.ogg` (logical mount/logical type "music collection" is replaced)
Questionable examples:
* `D:\bla.ogg -> /home/foo/Music/bla.ogg` (physical -> logical mount/logical type "drive" -> "music collection"; However valid if D:\ is also known as the root of a music collection)
# Required version updates
This change will not require a version or namespace update.https://gitlab.xiph.org/xiph/xspf-website/-/issues/16Identifier for "human-readable" elements2021-11-10T03:27:12ZPhilipp SchafftIdentifier for "human-readable" elements# Motivation
Currently content resolvers depend entirely on `<location>`-tag provided URIs and a set of "human-readable" elements. While both do an excellent job in their specific domain there is a gap between. URIs from `<location>` tag...# Motivation
Currently content resolvers depend entirely on `<location>`-tag provided URIs and a set of "human-readable" elements. While both do an excellent job in their specific domain there is a gap between. URIs from `<location>` tags provide a very hard link to data while the "human-readable" elements provide a very soft link. The hard links fail when e.g. the playlist is moved or shared. The soft links fail when data is ambiguous or hard to match (e.g. different languages or spellings are used).
# Suggested change
It is suggested to extend the specification by adding an OPTIONAL attribute "`identifier`" to the "human-readable" elements (see list below). This `identifier`-attribute holds a single URI that works the same way as `<identifier>`. The URI itself is considered a machine readable key, however it is not defined what the result is when actually fetching the given resource.
## Special and non-"human-readable" elements the change shall also apply to
* The `<date>`-tag as defined in 4.1.1.2.8: In case of the `<date>`-tag the `identifier`-attribute refers to a specific and exact event (timestamp). This is useful to denote a "at the same time" relation. While use cases are limited the attribute shall be formally allowed.
* The `<image>`-tag as defined in 4.1.1.2.7 and 4.1.1.2.14.1.1.1.7, the `<license>`-tag as defined in 4.1.1.2.9: In case of the `<image>`- or `<license>`-tag the meaning of the `identifier`-attribute is the same as the meaning of the `<identifier>`-tag would be if the image or license would be given as a `<track>`. This allows resolving of well known images/data e.g. without an internet connection. Well known/common images and licenses may be shipped e.g. by the operating system or a player. A player could provide the user with a gallery of default images and as long as the user uses the same player no network traffic is required for those. While when moved/shared the URI from the tag can be used to resolve the image in a different player. This provides a more efficient way than embedding using data:-URIs.
## Possible updates to elements with an `identifier`-attribute
It should be considered to allow but not recommend tags with an `identifier`-attribute to be empty. Even if this change is not accepted it should be considered to require parsers to allow this while forbid generators to generate such playlists. This may also require an namespace update.
## List of "human-readable" elements
* 4.1.1.2.1 title
* 4.1.1.2.2 creator
* 4.1.1.2.3 annotation
* 4.1.1.2.8 date
* 4.1.1.2.14.1.1.1.3 title
* 4.1.1.2.14.1.1.1.4 creator
* 4.1.1.2.14.1.1.1.5 annotation
* 4.1.1.2.14.1.1.1.8 album
# See also
* If a specific behaviour on fetch/specific result is expected <link> provides a way to link additional metadata from external sources.
# Required version updates
This change will not require namespace update. A version update should be considered.
Allowing previously non-empty tags to be empty requires a namespace update.https://gitlab.xiph.org/xiph/xspf-website/-/issues/17[Specs] Permit only UTC in `<date>`2021-10-05T18:24:55ZPhilipp Schafft[Specs] Permit only UTC in `<date>`# Motivation
Time zones are a mess. It is hard for computers and humans alike to work with them. Avoiding them seems to be the best option.
# Suggested change
The `<date>`-tag as defined by 4.1.1.2.8 shall no longer be allowed to use an...# Motivation
Time zones are a mess. It is hard for computers and humans alike to work with them. Avoiding them seems to be the best option.
# Suggested change
The `<date>`-tag as defined by 4.1.1.2.8 shall no longer be allowed to use any time zone other than UTC. Generators MUST generate timestamps in UTC. Parsers SHOULD accept time zones beside UTC. Parsers MAY report non-UTC time zones (independent on if they are supported or not).
This also allows comparing/sorting with purely alphanumeric comparing/sorting after normalisation of UTC to "Z"¹.
# Required version updates
This change will not require a version or namespace update.
¹ Quoted from the "XML schema dateTime" specification:
> The mapping so defined is one-to-one, except that '+00:00', '-00:00', and 'Z' all represent the same zero-length duration timezone, UTC; 'Z' is its canonical representation.https://gitlab.xiph.org/xiph/xspf-website/-/issues/18Clarification on order of content resolving and <location>-tags2021-11-10T03:27:52ZPhilipp SchafftClarification on order of content resolving and <location>-tags# Motivation
Currently there is no step-by-step list of actions a renderer should do to locate a playable copy of the referenced track. Such a list would help implementing renderers as well as keeping their behaviour more aligned.
# Sug...# Motivation
Currently there is no step-by-step list of actions a renderer should do to locate a playable copy of the referenced track. Such a list would help implementing renderers as well as keeping their behaviour more aligned.
# Suggested change
This should be changed and clarified.
Important:
* Such a list should keep in mind `<location>`-, `<link>`-, `<meta>`-, `<extension>`-tags, and "human-readable" elements.
* Keep the difference between transport qualities in mind (e.g. prefer local files over remote files).
* Clarify if finding a fetchable but unrenderable resource is a error condition that should stop rendering the current track. (e.g. if a `<location>`-tag links a FLAC but the player does not support FLAC if it should stop or try other `<location>`-tags to see if it finds a file in a format it supports.)
## Example list
* Try without accessing the network:
* All `<location>`-tags
* Ask your neighbour
* All resources found by fuzzy matching
* Retry with accessing the network.
* Fail
# Required version updates
This change will not require a version or namespace update.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2420Cannot connect to icecast-radio on external sources (winamp), browser-based c...2021-10-31T13:29:41Zsuper sleepyCannot connect to icecast-radio on external sources (winamp), browser-based connection works fineI'm at my wits' end, here. I've tried listening from a different proxy, assuming that there's something wrong with my connection - anyway.
The source audio is [here](https://play.squid-radio.net/clouds). I get an access denied notifica...I'm at my wits' end, here. I've tried listening from a different proxy, assuming that there's something wrong with my connection - anyway.
The source audio is [here](https://play.squid-radio.net/clouds). I get an access denied notification - at best! - from winamp, or at worst it just rapidly tries to connect and fails without displaying any messages. Listening through the browser is a pretty strain on my memory, I want to see if this is an icecast issue, or if there's *any* ideas you might on what could be causing this. Any advice, and I do mean any advice, would be appreciated!https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2332Patch for macOS >= 11.x2021-10-26T13:06:10ZMichka PopoffPatch for macOS >= 11.xHi
Here is a patch we are using in Homebrew (the package manager for macOS and Linux) to build libshout.
The current build is broken and causes the library to be linked with a flat
namespace, which might cause issues when dynamically lo...Hi
Here is a patch we are using in Homebrew (the package manager for macOS and Linux) to build libshout.
The current build is broken and causes the library to be linked with a flat
namespace, which might cause issues when dynamically loading the library with
dlopen under some modes:
```
diff -u libshout-2.4.5-old/configure libshout-2.4.5/configure
--- libshout-2.4.5-old/configure 2021-10-21 12:28:29.000000000 +0200
+++ libshout-2.4.5/configure 2021-10-21 12:31:31.000000000 +0200
@@ -7582,17 +7582,12 @@
_lt_dar_allow_undefined='${wl}-undefined ${wl}suppress' ;;
darwin1.*)
_lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
- darwin*) # darwin 5.x on
- # if running on 10.5 or later, the deployment target defaults
- # to the OS version, if on x86, and 10.4, the deployment
- # target defaults to 10.4. Don't you love it?
- case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
- 10.0,*86*-darwin8*|10.0,*-darwin[91]*)
- _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
- 10.[012]*)
- _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
- 10.*)
- _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
+ darwin*)
+ case ${MACOSX_DEPLOYMENT_TARGET},$host in
+ 10.[[012]],*|,*powerpc*)
+ _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
+ *)
+ _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
esac
;;
esac
```
This is a patch for the configure file, but it should be applied to the the libtool.m4 file. I am not an expert on how you have setup the m4 folder in your project, so I'll let you handle the addition of that patch.
For reference:
https://github.com/Homebrew/homebrew-core/pull/87694Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/libao/-/issues/2322dynamic linking: initialize fails/crashes2021-10-22T19:06:35Zminttydynamic linking: initialize fails/crashesI'm trying to link libao dynamically, using dlopen.
It fails (i.e. crashes) on ao_initialize, however, while all other functions work as I can verify by a split up configuration, linking ao_initialize statically and all others dynamically.I'm trying to link libao dynamically, using dlopen.
It fails (i.e. crashes) on ao_initialize, however, while all other functions work as I can verify by a split up configuration, linking ao_initialize statically and all others dynamically.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2421admin/includes/confirm.xsl missing -> Confirmation in admin webGUI cannot be ...2021-10-26T10:06:39ZThomas Schlienadmin/includes/confirm.xsl missing -> Confirmation in admin webGUI cannot be doneHi.
When installing with `./autogen.sh && ./configure && make -j5 install` the file admin/includes/confirm.xsl is missing and therefore, if a confirmation is needed in the admin webGUI, it cannot be done.
I fixed this by adding `includ...Hi.
When installing with `./autogen.sh && ./configure && make -j5 install` the file admin/includes/confirm.xsl is missing and therefore, if a confirmation is needed in the admin webGUI, it cannot be done.
I fixed this by adding `includes/confirm.xsl` in the `nobase_dist_admin_DATA` part of https://gitlab.xiph.org/xiph/icecast-server/-/blob/master/admin/Makefile.am.
Is there a proper way to do merge requests for this project? If I try to clone the repo in this Gitlab I only get the error that I do not have the rights to do that.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2422Programmatically set the fallback-override value2021-10-31T22:11:44Zisaac-codeProgrammatically set the fallback-override valueAs advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fall...As advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fallback, but immediately the mountpoint is back, I cannot programmatically switch back to the mountpoint
Switching back to the former mountpoint is only possible when the fallback-override value is set to 1, but I cannot achieve that because there is no way to programmatically achieve that, which is weird.
P.S. I want users to create mountpoints via an exposed endpoint, so I don't create it manually inside the icecase.xml filehttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2423Allow setting the charset globally, not only on per-mount basis2021-11-15T18:41:48ZVadim UshakovAllow setting the charset globally, not only on per-mount basisHi! In my setup, I use a script that manages the sources dynamically, creating, starting and stopping mount points by user request. The icecast config is static, and all the sources share the same login/password. So no need to declare mo...Hi! In my setup, I use a script that manages the sources dynamically, creating, starting and stopping mount points by user request. The icecast config is static, and all the sources share the same login/password. So no need to declare mount points in icecast.xml in that case.
Unfortunately, IceCast uses the charset ISO8859-1 by default, and the only way to override it is declare mount point for each single source and specify `<charset>UTF-8</charset>` for each. This is extremely inconvenient.
I tried the following simple patch and seems to work. It allows to set the charset at the upper level so it takes effect for every mount point that doesn't explicitly override the value. If no charset is set at all, the default ISO8859-1 is used as the last resort.
Could you please merge it?
[global-charset.diff](/uploads/a1b7d890b0ea73d1d12fdf19b7b58209/global-charset.diff)