Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2009-02-22T15:26:13Zhttps://gitlab.xiph.org/xiph/oggdsf/-/issues/1449can not seek over http spx streams2009-02-22T15:26:13ZGitlab Botcan not seek over http spx streamsI have some spx files served over http. WMP can not seek when playing, and the slider seems to be disbled; there is no such problem to download the file and play locally. I am using oggcodecs_0.80.15039.exe, the unstable version; the sta...I have some spx files served over http. WMP can not seek when playing, and the slider seems to be disbled; there is no such problem to download the file and play locally. I am using oggcodecs_0.80.15039.exe, the unstable version; the stable version hangs WMP whenever I open a spx file.Cristian AdamCristian Adamhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2103Clarify default setting of logarchive2018-03-06T12:49:38ZMicheil SmithClarify default setting of logarchiveCurrently no default setting is in place for logarchive in the configuration, it's just by chance that the default is that it's off, due to how the internals of log.c work.Currently no default setting is in place for logarchive in the configuration, it's just by chance that the default is that it's off, due to how the internals of log.c work.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/oggdsf/-/issues/1412Theora postprocessing decoder2009-02-22T15:25:49ZGitlab BotTheora postprocessing decoderIt would be a good feature to add Theora video postprocessing decoder.
It would be a good feature to add Theora video postprocessing decoder.
Cristian AdamCristian Adamhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2056On-demand relay mount vanishes shortly right after last player disconnects2023-02-27T11:40:50ZMarvin ScholzOn-demand relay mount vanishes shortly right after last player disconnectsIf a on demand relay is configured, and the last listener disconnects, it vanishes from the stats for a short period of time.
This is because in `source.c` the `source_shutdown()` function deletes the source stats:
```
stats_event(so...If a on demand relay is configured, and the last listener disconnects, it vanishes from the stats for a short period of time.
This is because in `source.c` the `source_shutdown()` function deletes the source stats:
```
stats_event(source->mount, NULL, NULL);
```
There would be different approaches to fix this:
1. Do not fix it at all
2. If it is a on-demand mount, only remove the data that will probably change
3. Remove all data and trigger immediate refresh of mount data (inefficient?)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2101Verify if on-connect (events) are still impossible on windows2018-03-06T12:49:38ZThomas B. RückerVerify if on-connect (events) are still impossible on windowsWe migrated to mingw32, I suspect it might now be either trivial or easy to fork a script (.bat). We migrated to mingw32, I suspect it might now be either trivial or easy to fork a script (.bat). Icecast 2.6Stephan JauernickStephan Jauernickhttps://gitlab.xiph.org/xiph/libao/-/issues/1830shell-fm doesn't open /dev/snd/timer2011-08-22T17:28:00ZGitlab Botshell-fm doesn't open /dev/snd/timerI have a problem using [shell-fm](http://nex.scrapping.cc/shell-fm/) and libao (it uses libao for playback).
If the file/dev/snd/timer is not opened by any process, shell-fm starts playing music without opening it. However if it's alrea...I have a problem using [shell-fm](http://nex.scrapping.cc/shell-fm/) and libao (it uses libao for playback).
If the file/dev/snd/timer is not opened by any process, shell-fm starts playing music without opening it. However if it's already opened by another process, it opens it.
The problem is that when shell-fm starts playing sounds without opening /dev/snd/timer, any other process can't play sounds.
I can't reproduce this behavior using libao 1.0.
As default driver I'm using alsa.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2055Changing relay on-demand settings messes things up2018-03-06T12:49:38ZMarvin ScholzChanging relay on-demand settings messes things upIf a relay is configure in Icecast like the following:
```
<relay>
<server>stream.server.de</server>
<port>8000</port>
<mount>/24.mp3</mount>
<local-mount>/diff.mp3</local-mount>
<relay-shoutcast...If a relay is configure in Icecast like the following:
```
<relay>
<server>stream.server.de</server>
<port>8000</port>
<mount>/24.mp3</mount>
<local-mount>/diff.mp3</local-mount>
<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
<on-demand>1</on-demand>
</relay>
```
and the `on-demand` value is changed to 0 and config re-read with SIGHUP, it will still show as on-demand in the stats and the whole relay mount will disappear and reappear quite randomly.
When initially 0 and changed to 1 it seems to have no effect at all.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/libao/-/issues/1815ALSA driver always uses native byte order2011-06-25T11:44:20ZMaarten ter HuurneALSA driver always uses native byte orderIn ao_alsa.c, the alsa_get_sample_bitformat() function will return constants like SND_PCM_FORMAT_S16, which specify the native byte order for ALSA. However, in ao_plugin_open() there is a comment "alsa's endinness will be the same as the...In ao_alsa.c, the alsa_get_sample_bitformat() function will return constants like SND_PCM_FORMAT_S16, which specify the native byte order for ALSA. However, in ao_plugin_open() there is a comment "alsa's endinness will be the same as the application's" and there the device byte order is made equal to the client byte order.
One possible solution would be to make alsa_get_sample_bitformat() respect its "bigendian" argument and return SND_PCM_FORMAT_S16_LE or SND_PCM_FORMAT_S16_BE depending on that. This would yield the best performance if the hardware can support both byte orders. I don't know whether libalsa will convert the byte order or return an error if the byte order requested is not available though.
Another possible solution would be to set the device byte order to the native byte order. This might lead to unnecessary byte swapping, but it is a two-line fix (line 528 and 530).
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2100Document icecast access log format in docs2018-03-06T12:49:38ZThomas B. RückerDocument icecast access log format in docswe should explain it, especially the last field that adds on top of Apache "combined" type output and signifies connection duration in seconds.
Also mentioning that we do NOT log the amount of data sent by a source client due to adherin...we should explain it, especially the last field that adds on top of Apache "combined" type output and signifies connection duration in seconds.
Also mentioning that we do NOT log the amount of data sent by a source client due to adhering to convention "bytes _sent_".Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/opus/-/issues/2330Make decoder state completely relocatable by avoiding inline pointer to mode2020-08-06T12:42:35ZDan RavivMake decoder state completely relocatable by avoiding inline pointer to modeCurrently, Opus Decoder state can be freely moved in memory in the same process, but it can't e.g. be copied as bytes to be sent across the network and set as a state for another decoder. But it *almost* can! The only thing preventing th...Currently, Opus Decoder state can be freely moved in memory in the same process, but it can't e.g. be copied as bytes to be sent across the network and set as a state for another decoder. But it *almost* can! The only thing preventing this use case is the `mode` pointer at the start of `CELTDecoder`. A clean decoder state on one machine has identical bytes to those of a clean state on another machine with the same architecture, except for possibly the bytes of the `mode` pointer - even when the mode itself is the same.
I'm not sure how to fix this in a way compatible with any custom mode, but it would be nice to be able to do this for the default mode, at least.https://gitlab.xiph.org/xiph/libao/-/issues/1809libao: add version info to ao/ao.h2012-05-15T14:15:25ZNicklibao: add version info to ao/ao.hAs new features are added to libao, version information in the ao.h header would be helpful so code that uses libao can detect the version and use the new features.
For example, the ao_sample_format has a new field called matrix in 1.x....As new features are added to libao, version information in the ao.h header would be helpful so code that uses libao can detect the version and use the new features.
For example, the ao_sample_format has a new field called matrix in 1.x.x that is not int version 0.8.8 (the version currently in the Ubuntu repositories 10.04, 11.04).
I'm releasing code that will work with 0.8.8 but it would be nice to be able to include code for 1.1.0 when it becomes available in the Ubuntu repositories.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/opus/-/issues/2331Enable NEON optimizations for Windows ARM642020-08-09T04:09:13ZMarcus AsteborgEnable NEON optimizations for Windows ARM64Windows on ARM64 uses another header then the general neon one.
AC:
- Enable Neon for Windows ARM in CMake
- Fix includes
- Verify on ARM64 deviceWindows on ARM64 uses another header then the general neon one.
AC:
- Enable Neon for Windows ARM in CMake
- Fix includes
- Verify on ARM64 devicehttps://gitlab.xiph.org/xiph/libao/-/issues/1806Amend ALSA options2011-05-28T08:58:04ZKaroly NegyesiAmend ALSA optionsIt took me quite some time to figure out how to configure my alsa configuration. I would recommend adding a mapping from aplay -L because it's everything but trivial to map especially the default.
It says:
The alsa driver normally choo...It took me quite some time to figure out how to configure my alsa configuration. I would recommend adding a mapping from aplay -L because it's everything but trivial to map especially the default.
It says:
The alsa driver normally chooses one of "surround71", "surround51", "surround40", "front", or "default" automatically depending on number of output channels.
I would change to:
You can see the available devices by running aplay -L. Use the name before the colon, for example "surround71", "surround51", "surround40", "front", or "default". The alsa driver normally chooses one of these in the order above automatically depending on the number of output channels.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2094YP protocol documentation / revision2018-03-06T12:49:38ZThomas B. RückerYP protocol documentation / revisionWe should document the currently used YP protocol, old docs might be available but are outdated.
As we'll have to introduce a few changes we should rethink some protocol aspects while we document it.
Collaborative wiki page is at https...We should document the currently used YP protocol, old docs might be available but are outdated.
As we'll have to introduce a few changes we should rethink some protocol aspects while we document it.
Collaborative wiki page is at https://wiki.xiph.org/Icecast/YP-protocol-v2Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2092Write specification of Icecast specific HTTP protocol features2018-06-07T20:52:20ZThomas B. RückerWrite specification of Icecast specific HTTP protocol featuresUse HTTP 1.0 and 1.1 specs as base, document differences and quirks.
Give guidance what a source client SHOULD, MUST, MUST NOT do, etc.
Explain source and listener HTTP headers, authentication quirks.Use HTTP 1.0 and 1.1 specs as base, document differences and quirks.
Give guidance what a source client SHOULD, MUST, MUST NOT do, etc.
Explain source and listener HTTP headers, authentication quirks.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/opus/-/issues/2333cmake - Add Doxygen doc generation to CMakebuild2020-08-09T04:24:52ZMarcus Asteborgcmake - Add Doxygen doc generation to CMakebuildhttps://vicrucann.github.io/tutorials/quick-cmake-doxygen/https://vicrucann.github.io/tutorials/quick-cmake-doxygen/https://gitlab.xiph.org/xiph/icecast-server/-/issues/2004calls to abort() should be removed and checks for memory allocation failture ...2018-10-18T08:03:57ZPhilipp Schafftcalls to abort() should be removed and checks for memory allocation failture to be addedicecast calls abort() 3 times. All 3 times are related to memory allocation. It is used to avoid the need to handle errors on memory allocation. In many other places memory allocation is not checked to be successful.
* all calls to abor...icecast calls abort() 3 times. All 3 times are related to memory allocation. It is used to avoid the need to handle errors on memory allocation. In many other places memory allocation is not checked to be successful.
* all calls to abort() should be removed.
* all calls to malloc(), calloc() and realloc() should be checked handling errors correctly.
* There should be a policy on what happens on memory allocation failure (icecast dropping clients/resources OR dieing?)
* icecast should (at high/all cost) try to inform the user about this problem.
* memory failure can have many reasons. Not just the system being out of memory.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2091Fix up ogg serial numbers for incoming streams in Icecast2018-03-06T12:49:38ZThomas B. RückerFix up ogg serial numbers for incoming streams in IcecastWe should do this server side, there are too many broken things out there.
Ices has some code for this if we need a reference.We should do this server side, there are too many broken things out there.
Ices has some code for this if we need a reference.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/opus/-/issues/2334cmake - Build all tests and programs for Opus in CMake build2020-08-09T04:24:33ZMarcus Asteborgcmake - Build all tests and programs for Opus in CMake buildAC:
- Add minor unittest for dll and static build
- Add missing programs for dll and static buildAC:
- Add minor unittest for dll and static build
- Add missing programs for dll and static buildhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2003refbuf should be replaced2018-10-18T08:03:57ZPhilipp Schafftrefbuf should be replacedrefbuf is a type of objected used to store binary data. As the name suggest it has an internal reference counter that allows it to be freed automatically when no longer in use.
the old refbuf objects aren't well designed and allow direc...refbuf is a type of objected used to store binary data. As the name suggest it has an internal reference counter that allows it to be freed automatically when no longer in use.
the old refbuf objects aren't well designed and allow direct access to internal data structures. This became abused.
The new object type MUST:
* be well designed,
* not allow access to internal data structures,
* have a well designed API to access the object's content in a secure way.Icecast 2.6Philipp SchafftPhilipp Schafft