Hide
added a comment -
Hi !
Thanks for the report, I will try to reproduce.
I see that you are setting vorbis' quality to -0.2, I assume you are using the aoTuV implementation of libvorbis.. ?
This is the second report of reconnection problems (although it does not look like the first report we've had on the mailing-list). I tried to reproduce using the same script (modulo details like quality setting) and at first I got this problem just after kicking the source:
{{{
2010/06/12 10:59:24 [foo(dot)ogg:2] Cry socket error: timeout, network failure, server shutdown? Restarting the output in 3 seconds.
2010/06/12 10:59:24 [foo(dot)ogg:3] Closing connection...
2010/06/12 10:59:28 [threads:1] Thread "wallclock_main" aborts with exception Vorbis.Invalid_channels!
Thread 4 killed on uncaught exception Vorbis.Invalid_channels
Raised at file "vorbis.ml", line 121, characters 4-39
Called from file "ogg_muxer.ml", line 429, characters 13-30
Called from file "hashtbl.ml", line 145, characters 8-13
Called from file "hashtbl.ml", line 148, characters 4-19
Called from file "ogg_muxer.ml", line 441, characters 4-76
Called from file "ogg_muxer.ml", line 456, characters 2-15
Called from file "encoder/ogg_encoder.ml", line 187, characters 16-23
Called from file "outputs/icecast2.ml", line 374, characters 18-57
Called from file "outputs/output.ml", line 317, characters 35-47
Called from file "outputs/output.ml", line 226, characters 6-27
Called from file "list.ml", line 69, characters 12-15
Called from file "clock.ml", line 132, characters 6-43
Called from file "clock.ml", line 318, characters 10-24
Called from file "clock.ml", line 321, characters 8-15
Called from file "tools/tutils.ml", line 141, characters 15-18
Re-raised at file "tools/tutils.ml", line 164, characters 21-22
Called from file "thread.ml", line 38, characters 8-14
2010/06/12 10:59:28 [main:3] Shutdown started!
}}}
Just so you know, it's fixed after updating ocaml-vorbis. After that, mp3 or ogg, no problem: it reconnected, and I could hear me tapping on the mic.
I used OSS, but we should keep in mind that things are hardware dependent here: please try with another input if possible, and please try by wrapping your input in {{{mksafe(buffer(clock(sync=false,live)))}}} see if it changes anything (it avoids that icecast reconnection causes some latency in the input... just in case a too long latency could create a freeze or silence).
Ok, I ran a few more tests and thought I would pass this info along:
- The problem persists with Vorbis regardless of whether I use q-2, q-1 or q0
- MP3 reconnects ok
- aacplusenc external encoder also reconnects ok
I am using aotuv Vorbis and OSS on FreeBSD 7.1. It seems to me that this is a problem on the encoding side rather than the audio input side given that the other formats continue to stream and reconnect seamlessly. Is that correct?
Any ideas?
FYI, I just tried running this same SVN liquidsoap with libvorbis-1.2.3 and the problem still persists. So it does not seem to be specific to the aotuv implementation.
I would be happy to run any other tests or provide any further information that could help here.
I just tried using input.http and encountered the same issue of Icecast connecting but not sending any data. This would seem to rule out the problem being OSS related, would it not? Is this problem occurring on Linux as well or just FreeBSD?
Would it be possible to bump this bug up in the priority list before 1.0 beta? 0.9.2 has a few bugs that prevent me from running it, and I would really love to move away from Ices/Darkice to liquidsoap. SVN is oh so close to working for me, but I need to make sure that streams can reconnect seamlessly. I can provide shell access if a FreeBSD box is needed and/or supply any testing.
Hey, thank you for all the extra tests. Looks like there is a real problem there, and we need to run more tests to try to bump into it. If the bug is vorbis specific, Romain would be the best to solve it, but he's on holidays. Nevertheless I'll give it a try this week-end -- and if I can't reproduce I'll pick up on your offer to access your BSD box, it's a great idea.
Hey, I've tested your exact script and reproduced the issue with everything on localhost, restarting icecast to trigger reconnection. I could spot the problem pretty quickly since there's one unusual thing in your script: icy_metadata="true". Of couse, you couldn't know it was unusual... too bad I didn't look into it earlier. In any case, there problem seems to disappear if you remove that line.
I might look into what's exactly going wrong into the code, but a good question is also: why do you want icy metadata? It's designed for MP3 streams, I don't think it's a standard thing with ogg streams, though some clients might support it (liquidsoap, maybe). Is it related to the CPU-burst-on-metadata issue with vorbis encoding?
Slightly more details that may be useful to Romain at some point.
When the situation arises, I checked that liquidsoap keeps sending data using {{{Cry.send}}} following the same pattern as before. And {{{Cry.send}}} simply does a {{{write}}} in the socket, raising an error if it's incomplete or fails in any way. Hence, we are sending data to icecast. This data may be broken, though, or there may be something else that isn't right, I don't know and the icecast log doesn't say.
Also, the problem arises for a first connection too: start the script with icecast down, then start icecast, and you get the same seemingly working connection but no data goes through to the listener.
Ahh! Thanks, removing the icy_metadata seems to have fixed that. I had copied that line straight from the aacplusenc sample without considering how it would affect Vorbis.
Hey guys,
Indeed, icy_metadata="true" for ogg connections is bad. What it does is a parallel GET request to the streaming server to push the informations of the new track.
It is not supposed to work with ogg because metadata in ogg are handled in the beginning of the tracks. Also, it might mess with icecast because icecast does a mangling of ogg tracks.
Hence, I agree to consider that there was no bug here, unless we have more informations.
For the shake of completeness, sending icy metadata along with ogg data will work with harbor but you will have to new tracks very closed.
I think I also remember experiencing a similar situation with icecast when implementing the vorbis encoder. As far as I remember, I was surprised to see icecast accepting icy metadata and starting a new track. However, this might need to completely remove all metadata/track from the ogg data.
This can be tried with liq by dropping metadata from your stream just before passing it to icecast and using {{{icy.update_metadata}}} with a {{{on_metadata}}} placed before droping them..
I will see if I have 5 min to test this :)
Indeed, this works:
{{{
def f(m) =
m = [("artist", m["artist"]), ("title",m["title"]), ("album",m["album"])]
icy.update_metadata(mount="bla",m)
end
s = on_metadata(f,s)
s = clear_metadata(s)
output.icecast(%vorbis, icy_metadata="false",mount="bla", s)
}}}
Nice :-)
Show
added a comment - Hi !
Thanks for the report, I will try to reproduce.
I see that you are setting vorbis' quality to -0.2, I assume you are using the aoTuV implementation of libvorbis.. ?
This is the second report of reconnection problems (although it does not look like the first report we've had on the mailing-list). I tried to reproduce using the same script (modulo details like quality setting) and at first I got this problem just after kicking the source:
{{{
2010/06/12 10:59:24 [foo(dot)ogg:2] Cry socket error: timeout, network failure, server shutdown? Restarting the output in 3 seconds.
2010/06/12 10:59:24 [foo(dot)ogg:3] Closing connection...
2010/06/12 10:59:28 [threads:1] Thread "wallclock_main" aborts with exception Vorbis.Invalid_channels!
Thread 4 killed on uncaught exception Vorbis.Invalid_channels
Raised at file "vorbis.ml", line 121, characters 4-39
Called from file "ogg_muxer.ml", line 429, characters 13-30
Called from file "hashtbl.ml", line 145, characters 8-13
Called from file "hashtbl.ml", line 148, characters 4-19
Called from file "ogg_muxer.ml", line 441, characters 4-76
Called from file "ogg_muxer.ml", line 456, characters 2-15
Called from file "encoder/ogg_encoder.ml", line 187, characters 16-23
Called from file "outputs/icecast2.ml", line 374, characters 18-57
Called from file "outputs/output.ml", line 317, characters 35-47
Called from file "outputs/output.ml", line 226, characters 6-27
Called from file "list.ml", line 69, characters 12-15
Called from file "clock.ml", line 132, characters 6-43
Called from file "clock.ml", line 318, characters 10-24
Called from file "clock.ml", line 321, characters 8-15
Called from file "tools/tutils.ml", line 141, characters 15-18
Re-raised at file "tools/tutils.ml", line 164, characters 21-22
Called from file "thread.ml", line 38, characters 8-14
2010/06/12 10:59:28 [main:3] Shutdown started!
}}}
Just so you know, it's fixed after updating ocaml-vorbis. After that, mp3 or ogg, no problem: it reconnected, and I could hear me tapping on the mic.
I used OSS, but we should keep in mind that things are hardware dependent here: please try with another input if possible, and please try by wrapping your input in {{{mksafe(buffer(clock(sync=false,live)))}}} see if it changes anything (it avoids that icecast reconnection causes some latency in the input... just in case a too long latency could create a freeze or silence).
Ok, I ran a few more tests and thought I would pass this info along:
- The problem persists with Vorbis regardless of whether I use q-2, q-1 or q0
- MP3 reconnects ok
- aacplusenc external encoder also reconnects ok
I am using aotuv Vorbis and OSS on FreeBSD 7.1. It seems to me that this is a problem on the encoding side rather than the audio input side given that the other formats continue to stream and reconnect seamlessly. Is that correct?
Any ideas?
FYI, I just tried running this same SVN liquidsoap with libvorbis-1.2.3 and the problem still persists. So it does not seem to be specific to the aotuv implementation.
I would be happy to run any other tests or provide any further information that could help here.
I just tried using input.http and encountered the same issue of Icecast connecting but not sending any data. This would seem to rule out the problem being OSS related, would it not? Is this problem occurring on Linux as well or just FreeBSD?
Would it be possible to bump this bug up in the priority list before 1.0 beta? 0.9.2 has a few bugs that prevent me from running it, and I would really love to move away from Ices/Darkice to liquidsoap. SVN is oh so close to working for me, but I need to make sure that streams can reconnect seamlessly. I can provide shell access if a FreeBSD box is needed and/or supply any testing.
Hey, thank you for all the extra tests. Looks like there is a real problem there, and we need to run more tests to try to bump into it. If the bug is vorbis specific, Romain would be the best to solve it, but he's on holidays. Nevertheless I'll give it a try this week-end -- and if I can't reproduce I'll pick up on your offer to access your BSD box, it's a great idea.
Hey, I've tested your exact script and reproduced the issue with everything on localhost, restarting icecast to trigger reconnection. I could spot the problem pretty quickly since there's one unusual thing in your script: icy_metadata="true". Of couse, you couldn't know it was unusual... too bad I didn't look into it earlier. In any case, there problem seems to disappear if you remove that line.
I might look into what's exactly going wrong into the code, but a good question is also: why do you want icy metadata? It's designed for MP3 streams, I don't think it's a standard thing with ogg streams, though some clients might support it (liquidsoap, maybe). Is it related to the CPU-burst-on-metadata issue with vorbis encoding?
Slightly more details that may be useful to Romain at some point.
When the situation arises, I checked that liquidsoap keeps sending data using {{{Cry.send}}} following the same pattern as before. And {{{Cry.send}}} simply does a {{{write}}} in the socket, raising an error if it's incomplete or fails in any way. Hence, we are sending data to icecast. This data may be broken, though, or there may be something else that isn't right, I don't know and the icecast log doesn't say.
Also, the problem arises for a first connection too: start the script with icecast down, then start icecast, and you get the same seemingly working connection but no data goes through to the listener.
Ahh! Thanks, removing the icy_metadata seems to have fixed that. I had copied that line straight from the aacplusenc sample without considering how it would affect Vorbis.
Hey guys,
Indeed, icy_metadata="true" for ogg connections is bad. What it does is a parallel GET request to the streaming server to push the informations of the new track.
It is not supposed to work with ogg because metadata in ogg are handled in the beginning of the tracks. Also, it might mess with icecast because icecast does a mangling of ogg tracks.
Hence, I agree to consider that there was no bug here, unless we have more informations.
For the shake of completeness, sending icy metadata along with ogg data will work with harbor but you will have to new tracks very closed.
I think I also remember experiencing a similar situation with icecast when implementing the vorbis encoder. As far as I remember, I was surprised to see icecast accepting icy metadata and starting a new track. However, this might need to completely remove all metadata/track from the ogg data.
This can be tried with liq by dropping metadata from your stream just before passing it to icecast and using {{{icy.update_metadata}}} with a {{{on_metadata}}} placed before droping them..
I will see if I have 5 min to test this :)
Indeed, this works:
{{{
def f(m) =
m = [("artist", m["artist"]), ("title",m["title"]), ("album",m["album"])]
icy.update_metadata(mount="bla",m)
end
s = on_metadata(f,s)
s = clear_metadata(s)
output.icecast(%vorbis, icy_metadata="false",mount="bla", s)
}}}
Nice :-)
Bug
Closed
Thanks for the report, I will try to reproduce.
I see that you are setting vorbis' quality to -0.2, I assume you are using the aoTuV implementation of libvorbis.. ?
This is the second report of reconnection problems (although it does not look like the first report we've had on the mailing-list). I tried to reproduce using the same script (modulo details like quality setting) and at first I got this problem just after kicking the source:
{{{
2010/06/12 10:59:24 [foo(dot)ogg:2] Cry socket error: timeout, network failure, server shutdown? Restarting the output in 3 seconds.
2010/06/12 10:59:24 [foo(dot)ogg:3] Closing connection...
2010/06/12 10:59:28 [threads:1] Thread "wallclock_main" aborts with exception Vorbis.Invalid_channels!
Thread 4 killed on uncaught exception Vorbis.Invalid_channels
Raised at file "vorbis.ml", line 121, characters 4-39
Called from file "ogg_muxer.ml", line 429, characters 13-30
Called from file "hashtbl.ml", line 145, characters 8-13
Called from file "hashtbl.ml", line 148, characters 4-19
Called from file "ogg_muxer.ml", line 441, characters 4-76
Called from file "ogg_muxer.ml", line 456, characters 2-15
Called from file "encoder/ogg_encoder.ml", line 187, characters 16-23
Called from file "outputs/icecast2.ml", line 374, characters 18-57
Called from file "outputs/output.ml", line 317, characters 35-47
Called from file "outputs/output.ml", line 226, characters 6-27
Called from file "list.ml", line 69, characters 12-15
Called from file "clock.ml", line 132, characters 6-43
Called from file "clock.ml", line 318, characters 10-24
Called from file "clock.ml", line 321, characters 8-15
Called from file "tools/tutils.ml", line 141, characters 15-18
Re-raised at file "tools/tutils.ml", line 164, characters 21-22
Called from file "thread.ml", line 38, characters 8-14
2010/06/12 10:59:28 [main:3] Shutdown started!
}}}
Just so you know, it's fixed after updating ocaml-vorbis. After that, mp3 or ogg, no problem: it reconnected, and I could hear me tapping on the mic.
I used OSS, but we should keep in mind that things are hardware dependent here: please try with another input if possible, and please try by wrapping your input in {{{mksafe(buffer(clock(sync=false,live)))}}} see if it changes anything (it avoids that icecast reconnection causes some latency in the input... just in case a too long latency could create a freeze or silence).
Ok, I ran a few more tests and thought I would pass this info along:
- The problem persists with Vorbis regardless of whether I use q-2, q-1 or q0
- MP3 reconnects ok
- aacplusenc external encoder also reconnects ok
I am using aotuv Vorbis and OSS on FreeBSD 7.1. It seems to me that this is a problem on the encoding side rather than the audio input side given that the other formats continue to stream and reconnect seamlessly. Is that correct?
Any ideas?
FYI, I just tried running this same SVN liquidsoap with libvorbis-1.2.3 and the problem still persists. So it does not seem to be specific to the aotuv implementation.
I would be happy to run any other tests or provide any further information that could help here.
I just tried using input.http and encountered the same issue of Icecast connecting but not sending any data. This would seem to rule out the problem being OSS related, would it not? Is this problem occurring on Linux as well or just FreeBSD?
Would it be possible to bump this bug up in the priority list before 1.0 beta? 0.9.2 has a few bugs that prevent me from running it, and I would really love to move away from Ices/Darkice to liquidsoap. SVN is oh so close to working for me, but I need to make sure that streams can reconnect seamlessly. I can provide shell access if a FreeBSD box is needed and/or supply any testing.
Hey, thank you for all the extra tests. Looks like there is a real problem there, and we need to run more tests to try to bump into it. If the bug is vorbis specific, Romain would be the best to solve it, but he's on holidays. Nevertheless I'll give it a try this week-end -- and if I can't reproduce I'll pick up on your offer to access your BSD box, it's a great idea.
Hey, I've tested your exact script and reproduced the issue with everything on localhost, restarting icecast to trigger reconnection. I could spot the problem pretty quickly since there's one unusual thing in your script: icy_metadata="true". Of couse, you couldn't know it was unusual... too bad I didn't look into it earlier. In any case, there problem seems to disappear if you remove that line.
I might look into what's exactly going wrong into the code, but a good question is also: why do you want icy metadata? It's designed for MP3 streams, I don't think it's a standard thing with ogg streams, though some clients might support it (liquidsoap, maybe). Is it related to the CPU-burst-on-metadata issue with vorbis encoding?
Slightly more details that may be useful to Romain at some point.
When the situation arises, I checked that liquidsoap keeps sending data using {{{Cry.send}}} following the same pattern as before. And {{{Cry.send}}} simply does a {{{write}}} in the socket, raising an error if it's incomplete or fails in any way. Hence, we are sending data to icecast. This data may be broken, though, or there may be something else that isn't right, I don't know and the icecast log doesn't say.
Also, the problem arises for a first connection too: start the script with icecast down, then start icecast, and you get the same seemingly working connection but no data goes through to the listener.
Ahh! Thanks, removing the icy_metadata seems to have fixed that. I had copied that line straight from the aacplusenc sample without considering how it would affect Vorbis.
Hey guys,
Indeed, icy_metadata="true" for ogg connections is bad. What it does is a parallel GET request to the streaming server to push the informations of the new track.
It is not supposed to work with ogg because metadata in ogg are handled in the beginning of the tracks. Also, it might mess with icecast because icecast does a mangling of ogg tracks.
Hence, I agree to consider that there was no bug here, unless we have more informations.
For the shake of completeness, sending icy metadata along with ogg data will work with harbor but you will have to new tracks very closed.
I think I also remember experiencing a similar situation with icecast when implementing the vorbis encoder. As far as I remember, I was surprised to see icecast accepting icy metadata and starting a new track. However, this might need to completely remove all metadata/track from the ogg data.
This can be tried with liq by dropping metadata from your stream just before passing it to icecast and using {{{icy.update_metadata}}} with a {{{on_metadata}}} placed before droping them..
I will see if I have 5 min to test this :)
Indeed, this works:
{{{
def f(m) =
m = [("artist", m["artist"]), ("title",m["title"]), ("album",m["album"])]
icy.update_metadata(mount="bla",m)
end
s = on_metadata(f,s)
s = clear_metadata(s)
output.icecast(%vorbis, icy_metadata="false",mount="bla", s)
}}}
Nice :-)