[Icecast] IceS segmentation fault

[Kit]

Thank you for this and for XML advice (I’ve cleaned it up and same issue remains). 
How do I obtain a stacktrace?

Thanks,

Kit


> On 16 May 2020, at 16:49, Marvin Scholz <epirat07 at gmail.com> wrote:
> 
> Please obtain a stacktrace as the log seems not very
> helpful in this case to figure out what went wrong.
> 
> On 16 May 2020, at 16:52, Kit wrote:
> 
> I get a segmentation fault when starting the IceS encoder on a Linux-based QNAP NAS.
> 
> I'm trying to set up IceS to stream an ALSA input to Icecast. Icecast works well and confirms when I stream using other things to it. However IceS hits a segmentation fault immediately after starting the encoder.
> The IceS log is:
> 
> [~] # sudo ices /etc/ices.xml
> [2020-05-11  19:24:34] INFO ices-core/main IceS 2.0.2 started...
> [2020-05-11  19:24:34] INFO input-alsa/alsa_open_module Opened audio device hw:0,0
> [2020-05-11  19:24:34] INFO input-alsa/alsa_open_module using 2 channel(s), 48000 Hz, buffer 341 ms 
> [2020-05-11  19:24:34] INFO input-alsa/alsa_open_module Starting metadata update thread
> [2020-05-11  19:24:34] INFO signals/signal_usr1_handler Metadata update requested
> [2020-05-11  19:24:34] INFO encode/encode_initialise Encoder initialising with bitrate management: 2 channels, 48000 Hz, minimum bitrate 256000, nominal 320000, maximum 320000
> Segmentation fault
> The IceS config file looks like this:
> 
> <?xml version="1.0"?>
> <ices>
> 
> <background>0</background>
> <logpath>/share/4a Downloads temporary</logpath>
> <logfile>ices.log</logfile>
> <logsize>10000</logsize>
> <loglevel>4</loglevel>
> <consolelog>1</consolelog>
> <!-- <pidfile>/share/4a Downloads temporary/ices.pid</pidfile> -->
> 
> <stream>
>         <metadata>
>                 <name>Roon</name>
>                 <genre>Avant-garde</genre>
>                 <description>Roon Icecast stream</description>
>         </metadata>
> 
>         <input>
>         <module>alsa</module>
>                 <param name="rate">48000</param>
>                 <param name="channels">2</param>
>                 <param name="device">hw:0</param>
>                 <param name="periods">2</param>
>                 <param name="buffer-time">1000</param>
>                 <!-- <param name="metadata">1</param>
>                 <param name="metadatafilename">/home/ices/metadata</param> -->
>         </input>
> 
>         <instance>
>                 <hostname>localhost</hostname>
>                 <port>8000</port>
>                 <password>mirror</password>
>                 <mount>/test.ogg</mount>
>                 <encode>
>                         <quality>10</quality>-->
>                         <nominal-bitrate>320000</nominal-bitrate>
>                         <maximum-bitrate>320000</maximum-bitrate>
>                         <minimum-bitrate>256000</minimum-bitrate>-->
>                         <managed>1</managed>
>                         <samplerate>48000</samplerate>
>                         <channels>2</channels>
>                         <flush-samples>48000</flush-samples>
>                 </encode>
>         </instance>
> </stream>
> 
> </ices>
> I've changed nearly every parameter in it to see if I can get round it, but all I am able to achieve is causing a crash sooner than the segfault. I've also got no more logging than this - level 4 is max anyway - so I can only assume the fault is in the encoder. libvorbis and libogg are both installed. I don't know of any way to use an external encoder or I'd be using that... can anyone help with what might be causing this segfault?
> 
> Thanks!
> 
> 
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast <http://lists.xiph.org/mailman/listinfo/icecast>_______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200518/065162b3/attachment.htm>