fallback with aac streams doesn't work

[Smana]

Hello,

I'm currently facing an issue with the "fallback-override" enabled for aac streams. The expected behaviour (which works fine with mp3 streams) is to move back to the master server when the latter is back. But that doesn't work when the codec is aac.

Mount configuration example

    <mount>
        <mount-name>/4989/SkaTest.mp3</mount-name>
        <fallback-mount>/4989/SkaTest.mp3-fb</fallback-mount>
        <fallback-override>1</fallback-override>
        <burst-size>64000</burst-size>
        <queue-size>128000</queue-size>
    </mount>

    <mount>
        <mount-name>/4989/SkaTest.mp3-fb</mount-name>
        <burst-size>64000</burst-size>
        <queue-size>128000</queue-size>
    </mount>

    <relay>
        <local-mount>/4989/SkaTest.mp3</local-mount>
        <on-demand>1</on-demand>
        <relay-shoutcast-metadata>1</relay-shoutcast-metadata>

        <master>
            <server>10.117.0.2</server>
            <port>9010</port>
            <mount>/</mount>
        </master>
    </relay>
    <relay>
        <local-mount>/4989/SkaTest.mp3-fb</local-mount>
        <on-demand>1</on-demand>
        <relay-shoutcast-metadata>1</relay-shoutcast-metadata>

        <master>
            <server>10.117.0.6</server>
            <port>9010</port>
            <mount>/</mount>
        </master>
    </relay>

os : debian wheezy icecast-kh version : 2.4.0-kh1

Tell me if you need more input. Regards, Smana

[karlheyes]

Can you get the level 4 messages of this occurring, best to use a single listener on the stream. There's no reason for aac to acc switch overs to not work

karl.

[MaPePeR]

I also have this problem with 2.4.0-kh3 with AAC+ and a relay to another relay-fallback. This worked fine in an earlier icecast-kh version i used before. (2.3.3-kh8)

Using VLC to determine the Codec Infromation both streams show exactly the same encoding: MPEG AAC Audio (mp4a), stereo, 44100Hz, SBR

But the Icecast status page only shows a "bitrate" for one of the streams. So i suspect it has something to do with the encoding being a little bit different, despite being the same in VLC?

[karlheyes]

ok, but can you get me the level 4 log of the switch over? The trigger for the switch over is not dependent on the precise codec settings, only if they are significantly different.

karl.

[MaPePeR]

2 Relays: / and /fallback. /fallback being the fallback of /.

The source of / will be shutdown, the listeners will be moved to /fallback, but when / reappears the listeners won't be moved back to /.

error.log with loglevel=4

What happens in the log:

approx 12:07 i shutdown the source of / 
approx 12:09 I restart the source of /
approx 12:10 / reappears on the status page

I hope this helps to resolve the issue.

[karlheyes]

hmm, just tried a similar set up here and they moved back as expected. Does this always occur for you or only occasioanlly?

I can see certain things like no fileserving, no auth, no limits being triggered. The initial fallback did not occur because the relay was not on long enough, but the clients reconnected and joined the fallback stream. I see the setting of the override but no followup messages. Can you show me the blocks you have for both streams, I just need to see what tags are set.

karl.

[MaPePeR]

I did never see the listeners being moved back.

The <relays-on-demand> should be ignored because its not a valid tag anymore, but that should not cause that problem.... i hope

The relevant parts of the config:

<icecast>
<!-- ... -->
    <mount>
        <mount-name>/fallback</mount-name>
        <max-listeners>64</max-listeners>
        <public>0</public>
    </mount>
    <mount>
        <!-- another mountpoint that is mostly offline and not related -->
    </mount>
    <mount>
        <mount-name>/</mount-name>
        <stream-name>{{/ stream-name}}</stream-name>
        <stream-description>{{/ stream-description}}</stream-description>
        <genre>{{/ genre}}</genre>
        <fallback-mount>/fallback</fallback-mount>
        <fallback-override>1</fallback-override>
        <source-timeout>20</source-timeout>
        <client-timeout>40</client-timeout>
    </mount> 
    <relay>
        <server>{{relayhost}}</server>
        <port>{{relayhost port}}</port>
        <mount>/{{relayhost mountpoint}}</mount>
        <local-mount>/</local-mount>
        <relays-on-demand>0</relays-on-demand>
        <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
    </relay>

    <relay>
        <server>{{fallbackrelayhost}}</server>
        <port>{{fallbackrelayhost port}}</port>
        <mount>/{{fallbackrelayhost mountpoint}}</mount>
        <local-mount>/fallback</local-mount>
        <relays-on-demand>1</relays-on-demand>
        <relay-shoutcast-metadata>0</relay-shoutcast-metadata>
    </relay>
</icecast>

(I did only add the unrelated mountpoint to the config when i updated from 2.3.3-kh8 to 2.4.0-kh3 and it worked in 2.3.3-kh8 - the unrelated mountpoint didn't work in the old version, which was my reason to update)

[karlheyes]

The fact that certain messages were missing indicated something was being bypassed, it looks like when a mountpoint of / was used, then the override was not applying as intended. This was because of the expansion routine failing, eg a fallback-mount of say /fallback-${mount} could be used on a of /stream*.mp3 and it would work (eg /fallback-stream128.mp3) but tripped over the mountpoint of just /

The fix was trivial and now pushed to master.

karl.

[MaPePeR]

Thank you very much!

Is there an ETA on when you will publish the next version, so i can try it?

Sadly i was not very successful compiling it myself.

[karlheyes]

If there are no further issues raised then I could do it at the weekend. There's been a few fixes since kh3 and no big changes elsewhere.

karl.