да, далеко не все самозаписываются, но часто вызываемые туда можно смело добавлять.
к тому же я еще использую старый добрый урезанный Litestep, в котором остался только модуль хоткеев.
Чё вы к терминам придираетесь?
nginx из «портов» не подходит — собираем руками.
eccelerator’a нету — тоже собираем руками.
всё остальное ставится из портов.
полезная статься для новичков.
таки да, всё работает.
но:
1. на странице статистики icecast висят всё fallback-маунты. ну хрен бы с ними
2. когда поднимается первый поток из списка, icecast всё равно продолжает вещать как ни в чем не бывало с текущего.
3. начинается что-то ненормально если лежат три потока и работает только четвертый. и пытаешся подключиться к icecast по адресу первого потока.
отваливается не канал, периодически отваливаются источники — не очень у kissfm с трансляцией.
собственно ради этого я и задался вопросом, как сделать себе максимально прозрачную стабильную ретрансляцию.
fallback-mount
This optional value specifies a mountpoint that clients are automatically moved to if the source shuts down or is not streaming at the time a listener connects. Only one can be listed in each mount and should refer to another mountpoint on the same server that is streaming in the same streaming format.
If clients cannot fallback to another mountpoint, due to a missing fallback-mount or it states a mountpoint that is just not available, then those clients will be disconnected. If clients are falling back to a mountpoint and the fallback-mount is not actively streaming but defines a fallback-mount itself then those clients may be moved there instead. This multi-level fallback allows clients to cascade several mountpoints.
A fallback mount can also state a file that is located in webroot. This is useful for playing a pre-recorded file in the case of a stream going down. It will repeat until either the listener disconnects or a stream comes back available and takes the listeners back. As per usual, the file format should match the stream format, failing to do so may cause problems with playback.
Note that the fallback file is not timed so be careful if you intend to relay this. They are fine on slave streams but don't use them on master streams, if you do then the relay will consume stream data at a faster rate and the listeners on the relay would eventually get kicked off.
к тому же я еще использую старый добрый урезанный Litestep, в котором остался только модуль хоткеев.
Так чтоб ему подсунуть файл проекта, а он выдал готовый exe или ошибку.
nginx из «портов» не подходит — собираем руками.
eccelerator’a нету — тоже собираем руками.
всё остальное ставится из портов.
полезная статься для новичков.
винамп «переспрашивает» раньше чем появляется поток (я так думаю)
но:
1. на странице статистики icecast висят всё fallback-маунты. ну хрен бы с ними
2. когда поднимается первый поток из списка, icecast всё равно продолжает вещать как ни в чем не бывало с текущего.
3. начинается что-то ненормально если лежат три потока и работает только четвертый. и пытаешся подключиться к icecast по адресу первого потока.
А сервер вообще в Киеве стоит в датацентре. Оно не на столько критично чтоб туда fm-тюнер тулить.
собственно ради этого я и задался вопросом, как сделать себе максимально прозрачную стабильную ретрансляцию.
This optional value specifies a mountpoint that clients are automatically moved to if the source shuts down or is not streaming at the time a listener connects. Only one can be listed in each mount and should refer to another mountpoint on the same server that is streaming in the same streaming format.
If clients cannot fallback to another mountpoint, due to a missing fallback-mount or it states a mountpoint that is just not available, then those clients will be disconnected. If clients are falling back to a mountpoint and the fallback-mount is not actively streaming but defines a fallback-mount itself then those clients may be moved there instead. This multi-level fallback allows clients to cascade several mountpoints.
A fallback mount can also state a file that is located in webroot. This is useful for playing a pre-recorded file in the case of a stream going down. It will repeat until either the listener disconnects or a stream comes back available and takes the listeners back. As per usual, the file format should match the stream format, failing to do so may cause problems with playback.
Note that the fallback file is not timed so be careful if you intend to relay this. They are fine on slave streams but don't use them on master streams, if you do then the relay will consume stream data at a faster rate and the listeners on the relay would eventually get kicked off.
Но в случае с fallback-mount получается 4 разных mount points. Да и люди пишут что для relay оно не очень.