Troubleshooting
A number of problems have been observed when using xmms-syncup. Where applicable, workarounds follow. If you find a problem (or better, solve it!), please file a report with the project developers so this page may be updated.
xmms-syncup complains that it can't contact the server / client plays something completely wrong
Make sure that xmmsd is installed and enabled in the server's XMMS. Since xmmsd speaks HTTP, you can verify this through a web-browser on the client (e.g http://xmmsserver:8335/). Firewall settings on the server may also be to blame; make sure that xmmsd's port (typically 8335) is open to the client(s).
Clients don't play what the server is playing
This is usually because the paths in the server's playlist are not valid on the client. Check the "View File Info" option in XMMS and ensure that the path to the selected track is correct on the client.
Client and server play the same track, but client skips around sometimes/frequently/constantly
Short version: XMMS isn't really designed to do what xmms-syncup does, so it takes some guess-and-checking to make its underlying strategy work well. Try different audio formats and output plugins until something works for you.
Long version: to keep the audio playback synchronized between machines, xmms-syncup attempts to perform file seeking to re-sync the client to the server whenever the playback cursors become excessively different (more than about 20ms is noticable). This seeking is sometimes perceivable as an audible hiccup in the client's playback. Though these gaps are inherent to the nature of resynchronization, minimizing temporal descrepancy between the client and server playback also minimizes the frequency of required corrections.
A number of factors may lead to asynchrony in the players.
- System clocks
XMMS seeks to whole seconds only, so system clocks that are skewed by more than a small fraction of a second confuse xmms-syncup. Use NTP and life will be better, honest. It's not necessary that your machines track UTC accurately, only that they share a common idea of what time it is. Having all clients use the server's time is probably the best idea.
- Input plugins
xmms-syncup has been tested with the mpg123 (for MP3) and FAAD input plugins (for MP4/AAC). Both work well with xmms-syncup, but only with non-variable rate encoded (VBR) tracks. Seeking within these input plugins is done by computing a file seek offset based on the average bitrate of a file. This computation is correct for CBR files, but only occasionally correct for VBRs. Thus, the corrective seeking done by xmms-syncup is frequently erroneous. To date, the best workaround we have discovered for this problem is transcoding VBR tracks to CBR (or you could try to fix the seek logic in the xxms input plugins).
- Output plugins
xmms-syncup has been tested primarily with the ALSA and OSS output plugins. artsd has also been tried, but its internal buffering has caused significant problems for xmms-syncup thus far. ALSA and OSS both work, though OSS appears to provide reliably less resolution for reading the server playback cursor. But on some hardware, ALSA has been observed to lose up to 2ms per second even where OSS does not. Best results for the developers have been acquired by testing available combinations to see which leads to the least corrective skipping. By enabling the DEBUG option in the plugin source, it is possible to track the degree of deviation between client and server to get a quantitative idea of what works best.
The client isn't tracking the server's playlist
To minimize server load and bandwidth consumption, xmms-syncup only updates the client playlist if it detects that
- The number of tracks on the playlists is different or
- The filename for the currently playing track is different
In practice, these conditions should cover all sane use cases. If the problem persists, try manually emptying the client's playlist, or report a bug.