[Icecast] Fallback stream not preventing a disconnect

[Erwin Pannecoucke]

Dear Maarten,

Thanks for this clear explanation. The fallback is indeed a local file, so
you are probably absolutely right.

10-20s delay is, luckely, something I can live with ;-)


Thank you all!
Erwin

2017-08-29 10:36 GMT+02:00 Maarten Bezemer <mcbicecast at robuust.nl>:

> Hi Erwin,
>
> Not sure if this might be related. Not sure if you are connecting the
> fallback to another stream or to just a file. If it is a file, then you can
> get buffering issues because most clients have buffers they can fill with
> minutes of audio. If you fall back to a file that is pushed towards the
> client at once, it can push a few minutes of audio in just seconds.
>
> If you set up a locally pushed stream that takes into account the bitrate
> of the fallback file, falling back to that file would only give 1 second of
> data per second.
>
> As for the 10-20sec delays: this is normal, because players buffer data
> and usually only start playing if they have at least 10-15 seconds in
> buffer. Streaming audio was never intended to be real-time. If you want
> that, you need to use UDP data transport and fault-tolerant codecs such as
> used in phone systems.
>
> Best,
> Maarten
>
>
>
> On Tue, 29 Aug 2017, Erwin Pannecoucke wrote:
>
> Dear Philipp,
>>
>> I've compiled it from source on my raspberry pi, and replaced the binary
>> from the synaptic package manager with the compiled one. Everyting is
>> working fine now, it seems that there is indeed a "faulty" package in the
>> repository. I don't know who I should contact to get this fixed?
>>
>> Anyway, it works, but while using ogg as output stream from mopidy, I get
>> a
>> delay of 4 (!) minutes when changing tracks:, it takes me about 2 minutes
>> from the stream to stop (still playing track 1), then another 2 of silence
>> (probably buffering), and only than I hear my music again (song 2).
>> If I use mp3 as a stream output, the delay is 2x 10 seconds, thus more
>> feasable but still a bit long. Anything I can do about that?
>>
>>
>> Thanks for putting me in the right direction!
>>
>> Kind regards,
>> Erwin
>>
>> 2017-08-28 10:41 GMT+02:00 Philipp Schafft <lion at lion.leolix.org>:
>>
>> Good morning,
>>>
>>>
>>> On Mon, 2017-08-28 at 10:36 +0200, Erwin Pannecoucke wrote:
>>>
>>>> Dear Philipp,
>>>>
>>>> Thanks for this fast answer.
>>>>
>>>> I'm using "Icecast 2.3.3-kh7-20130425090916", installed on a Raspberry
>>>>
>>> Pi 3
>>>
>>>> using the cononical "sudo apt-get install".
>>>>
>>>> The output was copied from the log file in /var/log/icecast2/error.log.
>>>>
>>>
>>> Ok. That is a software from a different vendor (a fork).
>>>
>>> Have you tried with official Icecast2?
>>>
>>> You can also wait and see if any user of that software is on this ML
>>> that can help you.
>>>
>>> With best regards,
>>>
>>> 2017-08-28 10:06 GMT+02:00 Philipp Schafft <lion at lion.leolix.org>:
>>>>
>>>>> On Mon, 2017-08-28 at 09:39 +0200, Erwin Pannecoucke wrote:
>>>>>
>>>>>> I"m using a combination of mopidy, icecast2 and Home-Assistant on a
>>>>>> raspberry pi to stream Google music to a Chromecast Audio.
>>>>>>
>>>>>
>>>>> What exact software are you using. Your log file is not generated by
>>>>> official Icecast2.
>>>>>
>>>>>
>>>>> [2017-08-16  14:40:20] INFO mpeg/check_for_mp3 MPEG 1 Layer 3
>>>>>>
>>>>> detected
>>>
>>>> (44100, 2) on /mopidy.mp3
>>>>>>>
>>>>>>
>>>>> No official version of Icecast2 can generate this message.
>>>>>
>>>>
>>> --
>>> Philipp.
>>>  (Rah of PH2)
>>> _______________________________________________
>>> Icecast mailing list
>>> Icecast at xiph.org
>>> 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/20170830/9b89533e/attachment.htm>