Vorbis still glitching on metadata update?

[Andreas Bergstrøm]

Greetings,

I am trying to track down a bug with intermittant glitching in our  
Vorbis streams.

I am running Icecast 2.3.2 on Ubuntu 9.04.

Several Vorbis clients seem to glitch on some (not all) metadata  
updates. As we update metadata 3 to 4 times a minute, this is  
something we are trying to fix, VLC gives the following output on  
metadata update:

main warning: the mixer got a packet in the past (22371)
main warning: the mixer got a packet in the past (1038)
main warning: mixer start isn't output start (398)
ogg debug: end of a group of logical streams
ogg debug: found vorbis header
ogg debug: will reuse old stream to avoid glitch
ogg debug: beginning of a group of logical streams
main error: ES_OUT_RESET_PCR called
main warning: received buffer in the future
main debug: Buffering 0%
main debug: Buffering 0%
main debug: Buffering 19%
main debug: Buffering 40%
main debug: Buffering 63%
main debug: End of audio preroll
main debug: Buffering 84%
main debug: Stream buffering done (1274 ms in 144 ms)
main debug: Decoder buffering done in 0 ms

For testing you can compare:

http://radio.hiof.no/nrk-jazz-128 (MP3 stream, no glitching)
http://radio.hiof.no/nrk-jazz-128.ogg (Vorbis stream, glitches)

Metadata is updated via the web admin interface from a script.

Has anyone else encountered this or know a way to fix this issue?

Regards,

--
Andreas Bergstrøm
Østfold University College
Dept. of Computer Sciences
Tel: [phone]
http://media.hiof.no/





_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast

[Petr Pisar]

On Tue, Oct 27, 2009 at 10:09:22AM +0100, Andreas Bergstrøm wrote:
>
> Several Vorbis clients seem to glitch on some (not all) metadata  
> updates. As we update metadata 3 to 4 times a minute, this is  
> something we are trying to fix, VLC gives the following output on  
> metadata update:
>
[…]
> http://radio.hiof.no/nrk-jazz-128.ogg (Vorbis stream, glitches)
>
MPlayer plays very well, moc (music on console) too (but it reports `Stream
error' on each meatadata update).

Reference implementation ogg123 produces glitches. It says ALSA underrun and
rebufferes the stream.

All players tested with 128 kB buffer.

BTW, I your IPv6 streams do not work because:

$ ping6 -n radio.ipv6.hiof.no
PING radio.ipv6.hiof.no(2001:700:a00:ff33:216:3eff:fe75:c27d) 56 data bytes
From 2001:700:0:1003::2 icmp_seq=1 Destination unreachable: Address unreachable

-- Petr


_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast

[Andreas Bergstrøm]

On 27. okt. 2009, at 11:14, Petr Pisar wrote:
 > MPlayer plays very well, moc (music on console) too (but it reports  
`Stream
> error' on each meatadata update).

OK, thank you.

> Reference implementation ogg123 produces glitches. It says ALSA  
> underrun and
> rebufferes the stream.

So could be clientside, could be serverside, time to dig deeper, I  
guess.

> All players tested with 128 kB buffer.
>
> BTW, I your IPv6 streams do not work because:
>
> $ ping6 -n radio.ipv6.hiof.no
> PING radio.ipv6.hiof.no(2001:700:a00:ff33:216:3eff:fe75:c27d) 56  
> data bytes
> From 2001:700:0:1003::2 icmp_seq=1 Destination unreachable: Address  
> unreachable


Ah thanks, found a configuration error, it _should_ work now.

Regards,

--
Andreas Bergstrøm
Østfold University College
Dept. of Computer Sciences
Tel: [phone]
http://media.hiof.no/





_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast

[Thomas B. Ruecker-2]

Hi,

Andreas Bergstrøm schrieb:
> Metadata is updated via the web admin interface from a script.
>  

sorry for stating the obvious:
Injecting the metadata directly within the source client is not an
option for you?


Maybe Karl can say something about the metadata update?

Cheers

Thomas
_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast

[Karl Heyes]

On 27/10/09 09:09, Andreas Bergstrøm wrote:

> Greetings,
>
> I am trying to track down a bug with intermittant glitching in our
> Vorbis streams.
>
> I am running Icecast 2.3.2 on Ubuntu 9.04.
>
> Several Vorbis clients seem to glitch on some (not all) metadata
> updates. As we update metadata 3 to 4 times a minute, this is
> something we are trying to fix, VLC gives the following output on
> metadata update:

> For testing you can compare:
>
> http://radio.hiof.no/nrk-jazz-128 (MP3 stream, no glitching)
> http://radio.hiof.no/nrk-jazz-128.ogg (Vorbis stream, glitches)

inserts for ogg are different to mp3. It is generally better to get the
source client to do that as it will be in sync with the content.

> Metadata is updated via the web admin interface from a script.
>
> Has anyone else encountered this or know a way to fix this issue?
>

from here, ogg123 is ok (although a 128k buffer, not sure what the
prebuffer % is, seems to be low, try increasing those).  mplayer is fine
but vlc keeps resetting itself in a major way on a new logical stream.
The format of the stream looks ok, I don't see any specific issue with
it. There is one other thing I can check but I'll have to get back to
you on that.

karl.

_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast

[Petr Pisar]

On Tue, Oct 27, 2009 at 04:40:02PM +0000, Karl Heyes wrote:
> On 27/10/09 09:09, Andreas Bergstrøm wrote:

> > http://radio.hiof.no/nrk-jazz-128.ogg (Vorbis stream, glitches)
>
> from here, ogg123 is ok (although a 128k buffer, not sure what the
> prebuffer % is, seems to be low, try increasing those).

I check it out with bigger buffer (size 512 kB, prebuffer 80 %) again
and it sounds perfectly now. Maybe mplayer has better TCP tunning than
ogg123 because the buffer fill stays around 37--40 % but ogg123 shows
decreasing fill periodically with 128kB buffer.

-- Petr


_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast

[Eric Kolotyluk-2]

Sorry for what seems like a real newbie question, but who actually sets
the mount point? Is it the client/source, the icecast.xml file, or both?

I find the IceCast configuration documentation quite confusing as it
does not really explain mount points very well. If someone would take
the time to explain things to me I would volunteer to improve the
documentation.

Case in point. I've been using IceCast for years, but never really
understood what I was doing. Recently I installed IceCast 2.3.1 on my
new computer. I have not configured anything - everything is the default
out of the box experience. As far as I can tell the default icecast.xml
file does not actually have any mount points defined, they are all
commented out. Am I correct?

I'm using the ODDCAST DSP with Winamp. As far as I can tell IceCast
locked on to the first mount point I configured in ODDCAST, which
happened to be example-complex.ogg, and now I cannot seem to change it.
Is this how IceCast works, it takes whatever the client/source sends it
and then automatically creates a mount point?

My problem now is my ODDCAST DSP seems to be locked into
example-complex.ogg as its 'destination' and won't release it even when
I change the mount point in the DSP Config settings. I would like to
change the mount point to something else, but I cannot figure out how.
Has the mount point "example-complex.ogg" been locked into my Winamp
configuration somewhere, or is something in the IceCast configuration
that is forcing this mount point?

I have uninstalled the ODDCAST DSP and reinstalled it, and the DPS still
thinks it's configured to "example-complex.ogg" even though it has not
connected to IceCast yet. I suspect there is some magic winamp/oddcast
config file somewhere, but I am unable to find it (as Windows search
mechanism is hopelessly lame).

Cheers, Eric
_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast

[Eric Dantan Rzewnicki-2]

On Tue, Oct 27, 2009 at 02:49:18PM -0700, Eric Kolotyluk wrote:
> Sorry for what seems like a real newbie question, but who actually sets
> the mount point? Is it the client/source, the icecast.xml file, or both?

As I understand it, a source client has to specify a mount point when it
connects.

If that mount point was already specified in the icecast server config,
then the associated mount options will be applied.

If the client specified mount point was not previously known to icecast,
then a new mount point with the name given by the source client is
created.

-Eric Rz.
_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast

[Karl Heyes]

On 27/10/09 23:48, Eric Dantan Rzewnicki wrote:

> On Tue, Oct 27, 2009 at 02:49:18PM -0700, Eric Kolotyluk wrote:
>> Sorry for what seems like a real newbie question, but who actually sets
>> the mount point? Is it the client/source, the icecast.xml file, or both?
>
> As I understand it, a source client has to specify a mount point when it
> connects.
>
> If that mount point was already specified in the icecast server config,
> then the associated mount options will be applied.
>
> If the client specified mount point was not previously known to icecast,
> then a new mount point with the name given by the source client is
> created.

Dynamic allocation of mountpoint names is not done.

When using a native icecast source client (edcast can be configured for
that) then a mountpoint is supplied by the source client and icecast
uses that to lookup the authentication details and any other mount
settings.

When using a shoutcast style source client, then it does not send a
mountpoint so icecast assumes one based upon the incoming port (actually
2 sequential ports). 2.3.1 only allowed one of these clients to connect
at any one time (and used the global shoutcast-mount setting and 2
listen-socket sections), but 2.3.2 allows for several as long as they
are on different ports (shoutcast-mount in the listen-socket). eg

<listen-socket>
     <port>8000</port>
     <shoutcast-mount>/myfirststream</shoutcast-mount>
</listen-socket>

<listen-socket>
     <port>9000</port>
     <shoutcast-mount>/mysecondstream</shoutcast-mount>
</listen-socket>

The mount tags we ship are commented out in the examples
<!-- ignored --> they are just there to help in showing you want can be
done.  There does not need to be a <mount> section but if it's there
then those settings (if present) are applied, a typical one used is
<max-listeners>

karl.

_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast

[abitar.com]

This is what i found out in use with the icecast servers.

Mounts Can be made by each  of the following:

1> The icecast.xml file define a mount with a username/password for
this mount. Since most our broadcaster using edcast to broadcast the
username is set to source.

2> The use of the global  source password can create a dynamic mount.

  But, the best way is to define it in the icecast.xml file by the
mount. By using the method 2 to create a new mount that is not
defined, will cause relaying not to happen.

We current create a mount, and assign a password to the mount for each
of out broadcasters.  We also, defined mounts without passwords for in
house streams using the source password.

I cant say much for shoutcast mounts we don't use them.

basicly, the source password can be used when ther mount has not been
assigned a password in the icecast.xml file.

So I guess the answer to your questions is, the icecast/xml is the
preferred method of setting the mount and password :)



david

On Tue, Oct 27, 2009 at 5:49 PM, Eric Kolotyluk <eric@...> wrote:

> Sorry for what seems like a real newbie question, but who actually sets
> the mount point? Is it the client/source, the icecast.xml file, or both?
>
> I find the IceCast configuration documentation quite confusing as it
> does not really explain mount points very well. If someone would take
> the time to explain things to me I would volunteer to improve the
> documentation.
>
> Case in point. I've been using IceCast for years, but never really
> understood what I was doing. Recently I installed IceCast 2.3.1 on my
> new computer. I have not configured anything - everything is the default
> out of the box experience. As far as I can tell the default icecast.xml
> file does not actually have any mount points defined, they are all
> commented out. Am I correct?
>
> I'm using the ODDCAST DSP with Winamp. As far as I can tell IceCast
> locked on to the first mount point I configured in ODDCAST, which
> happened to be example-complex.ogg, and now I cannot seem to change it.
> Is this how IceCast works, it takes whatever the client/source sends it
> and then automatically creates a mount point?
>
> My problem now is my ODDCAST DSP seems to be locked into
> example-complex.ogg as its 'destination' and won't release it even when
> I change the mount point in the DSP Config settings. I would like to
> change the mount point to something else, but I cannot figure out how.
> Has the mount point "example-complex.ogg" been locked into my Winamp
> configuration somewhere, or is something in the IceCast configuration
> that is forcing this mount point?
>
> I have uninstalled the ODDCAST DSP and reinstalled it, and the DPS still
> thinks it's configured to "example-complex.ogg" even though it has not
> connected to IceCast yet. I suspect there is some magic winamp/oddcast
> config file somewhere, but I am unable to find it (as Windows search
> mechanism is hopelessly lame).
>
> Cheers, Eric
> _______________________________________________
> Icecast mailing list
> Icecast@...
> http://lists.xiph.org/mailman/listinfo/icecast
>

_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast

[Eric Kolotyluk-2]

OK, I solved my problem. I was using ODDCAST v2. I switched to edcast
(ODDCAST v3) and was able to set the mountpoint to something different.
I can change it in the edcast configuration and it automatically changes
the mount-point in IceCast. Wha-Hoo!

There is some incredibly valuable information in this thread that should
be in the IceCast documentation on the "Icecast 2 - Basic Setup" page.

It would also be nice if there were an official Icecast wiki somewhere
so that people could document things as they figure them out.

Thanks everyone for the tips.

Cheers, Eric

On 10/27/2009 6:18 PM, David Saunders wrote:

> This is what i found out in use with the icecast servers.
>
> Mounts Can be made by each  of the following:
>
> 1>  The icecast.xml file define a mount with a username/password for
> this mount. Since most our broadcaster using edcast to broadcast the
> username is set to source.
>
> 2>  The use of the global  source password can create a dynamic mount.
>
>    But, the best way is to define it in the icecast.xml file by the
> mount. By using the method 2 to create a new mount that is not
> defined, will cause relaying not to happen.
>
> We current create a mount, and assign a password to the mount for each
> of out broadcasters.  We also, defined mounts without passwords for in
> house streams using the source password.
>
> I cant say much for shoutcast mounts we don't use them.
>
> basicly, the source password can be used when ther mount has not been
> assigned a password in the icecast.xml file.
>
> So I guess the answer to your questions is, the icecast/xml is the
> preferred method of setting the mount and password :)
>
>
>
> david
>
> On Tue, Oct 27, 2009 at 5:49 PM, Eric Kolotyluk<eric@...>  wrote:
>    
>> Sorry for what seems like a real newbie question, but who actually sets
>> the mount point? Is it the client/source, the icecast.xml file, or both?
>>
>> I find the IceCast configuration documentation quite confusing as it
>> does not really explain mount points very well. If someone would take
>> the time to explain things to me I would volunteer to improve the
>> documentation.
>>
>> Case in point. I've been using IceCast for years, but never really
>> understood what I was doing. Recently I installed IceCast 2.3.1 on my
>> new computer. I have not configured anything - everything is the default
>> out of the box experience. As far as I can tell the default icecast.xml
>> file does not actually have any mount points defined, they are all
>> commented out. Am I correct?
>>
>> I'm using the ODDCAST DSP with Winamp. As far as I can tell IceCast
>> locked on to the first mount point I configured in ODDCAST, which
>> happened to be example-complex.ogg, and now I cannot seem to change it.
>> Is this how IceCast works, it takes whatever the client/source sends it
>> and then automatically creates a mount point?
>>
>> My problem now is my ODDCAST DSP seems to be locked into
>> example-complex.ogg as its 'destination' and won't release it even when
>> I change the mount point in the DSP Config settings. I would like to
>> change the mount point to something else, but I cannot figure out how.
>> Has the mount point "example-complex.ogg" been locked into my Winamp
>> configuration somewhere, or is something in the IceCast configuration
>> that is forcing this mount point?
>>
>> I have uninstalled the ODDCAST DSP and reinstalled it, and the DPS still
>> thinks it's configured to "example-complex.ogg" even though it has not
>> connected to IceCast yet. I suspect there is some magic winamp/oddcast
>> config file somewhere, but I am unable to find it (as Windows search
>> mechanism is hopelessly lame).
>>
>> Cheers, Eric
>> _______________________________________________
>> Icecast mailing list
>> Icecast@...
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
>>      
> _______________________________________________
> Icecast mailing list
> Icecast@...
> http://lists.xiph.org/mailman/listinfo/icecast
>    

_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast

[Andreas Bergstrøm]

On 27. okt. 2009, at 17:40, Karl Heyes wrote:

> inserts for ogg are different to mp3. It is generally better to get  
> the
> source client to do that as it will be in sync with the content.
>

I see, thank you. I guess the challenge will be finding a system which  
allows insertion of metadata on the encoding side.

>> Metadata is updated via the web admin interface from a script.
>>
>> Has anyone else encountered this or know a way to fix this issue?
>>
>
> from here, ogg123 is ok (although a 128k buffer, not sure what the
> prebuffer % is, seems to be low, try increasing those).

I can look into increasing the burst-on-connect value.

>  mplayer is fine
> but vlc keeps resetting itself in a major way on a new logical stream.
> The format of the stream looks ok, I don't see any specific issue with
> it. There is one other thing I can check but I'll have to get back to
> you on that.

OK, I will await that then while looking into inserting metadata at  
encoding time.

Regards,

--
Andreas Bergstrøm
http://blog.andreasb.net



_______________________________________________
Icecast mailing list
Icecast@...
http://lists.xiph.org/mailman/listinfo/icecast