Foobar2000:Preferences:Networking: Difference between revisions
mNo edit summary |
m (→Enable dynamic track titles: Updated with "code" template.) |
||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{fb2k prefs | {{fb2k prefs|Preferences-Networking.png|Networking}} | ||
Settings on this page affect how foobar2000 processes HTTP and HTTP-like ([[SHOUTcast]] protocol) streams. | |||
Settings on this page affect how foobar2000 processes | |||
==Buffer size== | |||
Buffer size is how much data to read from the stream before starting playback. Even if a server is pumping out a stream continuously and at a constant rate, normal network lag between the server and your computer can cause the rate at which data reaches you to vary. Sometimes you will get too much data, sometimes not enough. A buffer can help insulate the player from these variations, thus preventing interruptions in playback. Too small of a buffer increases the risk of lost data and choppy sound. | Buffer size is how much data to read from the stream before starting playback. Even if a server is pumping out a stream continuously and at a constant rate, normal network lag between the server and your computer can cause the rate at which data reaches you to vary. Sometimes you will get too much data, sometimes not enough. A buffer can help insulate the player from these variations, thus preventing interruptions in playback. Too small of a buffer increases the risk of lost data and choppy sound. | ||
| Line 15: | Line 8: | ||
The default setting of 256 KB should be more than enough for average network conditions. If you get choppy sound from a stream, increasing the buffer size can help. However it won't make up for a disparity between the stream's bitrate and your network connection's bandwidth. | The default setting of 256 KB should be more than enough for average network conditions. If you get choppy sound from a stream, increasing the buffer size can help. However it won't make up for a disparity between the stream's bitrate and your network connection's bandwidth. | ||
==Use proxy server== | |||
If checked, you can enter a hostname, port, and optional username & password to use as a proxy. Use this if you don't have direct access to the streaming server itself, but you do have access to another HTTP server on a host which is configured to allow proxying and which does have direct access to the streaming server. | If checked, you can enter a hostname, port, and optional username & password to use as a proxy. Use this if you don't have direct access to the streaming server itself, but you do have access to another HTTP server on a host which is configured to allow proxying and which does have direct access to the streaming server. | ||
| Line 21: | Line 14: | ||
This is for standard HTTP proxying, not SOCKS or HTTP CONNECT-based proxying. | This is for standard HTTP proxying, not SOCKS or HTTP CONNECT-based proxying. | ||
==Enable dynamic track titles== | |||
If checked, in its initial connection to a SHOUTcast server, foobar2000 will send an | If checked, in its initial connection to a SHOUTcast server, foobar2000 will send an {{code|Icy-Metadata: 1}} to inform the server it wants to receive [[metadata]] (song artist & title, normally) multiplexed in the stream, and it will parse that metadata as it comes in and use it to dynamically update {{code|%artist%}} and {{code|%title%}} playlist fields. | ||
If unchecked, the %title% will contain the stream/station name or URL only; no metadata will be requested or parsed. | If unchecked, the {{code|%title%}} will contain the stream/station name or URL only; no metadata will be requested or parsed. | ||
HTTP proxy servers sometimes eat headers, so the | HTTP proxy servers sometimes eat headers, so the {{code|Icy-Metadata: 1}} might not get through to the server, resulting in no metadata being sent in the stream. Or, the server's acknowledgement of the request might not get through to the player, resulting in glitchy audio when the metadata is interpreted as garbage in the stream. | ||
Latest revision as of 16:24, 18 October 2018
|
foobar2000 Preferences |
|---|---|
Deprecated pages Pages marked * are added via third-party components. | |
Settings on this page affect how foobar2000 processes HTTP and HTTP-like (SHOUTcast protocol) streams.
Buffer size
Buffer size is how much data to read from the stream before starting playback. Even if a server is pumping out a stream continuously and at a constant rate, normal network lag between the server and your computer can cause the rate at which data reaches you to vary. Sometimes you will get too much data, sometimes not enough. A buffer can help insulate the player from these variations, thus preventing interruptions in playback. Too small of a buffer increases the risk of lost data and choppy sound.
The default setting of 256 KB should be more than enough for average network conditions. If you get choppy sound from a stream, increasing the buffer size can help. However it won't make up for a disparity between the stream's bitrate and your network connection's bandwidth.
Use proxy server
If checked, you can enter a hostname, port, and optional username & password to use as a proxy. Use this if you don't have direct access to the streaming server itself, but you do have access to another HTTP server on a host which is configured to allow proxying and which does have direct access to the streaming server.
This is for standard HTTP proxying, not SOCKS or HTTP CONNECT-based proxying.
Enable dynamic track titles
If checked, in its initial connection to a SHOUTcast server, foobar2000 will send an Icy-Metadata: 1 to inform the server it wants to receive metadata (song artist & title, normally) multiplexed in the stream, and it will parse that metadata as it comes in and use it to dynamically update %artist% and %title% playlist fields.
If unchecked, the %title% will contain the stream/station name or URL only; no metadata will be requested or parsed.
HTTP proxy servers sometimes eat headers, so the Icy-Metadata: 1 might not get through to the server, resulting in no metadata being sent in the stream. Or, the server's acknowledgement of the request might not get through to the player, resulting in glitchy audio when the metadata is interpreted as garbage in the stream.