Playback aborts when a download is started, printing "server does not support seeking"

[Jurgen Schellaert]

Whenever heavy traffic starts on my network, Rhythmbox will abruptly stop playing audio streams. The traffic in question may be local data transfer or (mostly large) downloads.

The same happens to local audio streams managed by pulseaudio. A data transfer starts and the stream very much immediately cuts out.

Typically, rhythmbox will pops up a dialog saying "server does not support seeking". I can usually resume playback but during longer data transfers/downloads, it will frequently cut out again.

I have tried replacing the onboard audio chip with a discrete ASUS DX card. This does not make any difference.

What does work is manually restricting download speeds using a download manager. However,, not all network traffic is controlled by such a manager. Something trivial - say, installing a firefox or a gnome-shell plug-in - has been enough for an audio stream to die instantly.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: rhythmbox 3.4.4-1ubuntu2
ProcVersionSignature: Ubuntu 5.4.0-33.37-generic 5.4.34
Uname: Linux 5.4.0-33-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.2
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Sun May 31 05:06:56 2020
ExecutablePath: /usr/bin/rhythmbox
InstallationDate: Installed on 2020-04-05 (55 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200402)
SourcePackage: rhythmbox
UpgradeStatus: No upgrade log present (probably fresh install)

[crvi (crvi)]

What is your network speed ( mbps ) ? When you start your downloads, does other apps ( browser page loading / youtube in browser ) work fine or they are stalled too ?

You can give the following steps to get some insight into the issue:

1. Rhythmbox ( RB ) uses gstreamer backend for playing audio files. This step confirms if the problem is with gstreamer or RB. Run the following commands from the terminal.

$ sudo apt-get install gstreamer1.0-tools
$ gst-launch-1.0 playbin uri="http://stream-dc1.radioparadise.com/rp_192m.ogg"

This should play the audio stream. You can substitute your audio stream URI in the above command. Now start the downloads. If the playback is stuck / aborted etc, the same way as it happens in Rhythmbox, this is a gstreamer limitation and RB can do very little about it. Try opening a gstreamer bug at https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/new

2. If audio plays fine in above step, start rhythmbox in terminal as below

$ rhythmbox -d &> ~/rhythmbox.log

Start audio streams followed by downloads. Wait for the playback issues to show up. Quit Rhythmbox and attach rhythmbox.log in this bug report.

[Jurgen Schellaert (jurgen-schellaert-j)]

The URI you put up plays fine. Unfortunately, I ran into the same issue when I started a different stream.

There were a few short skips at first but the player came back. Then it suddenly gave up completely with the error message mentioned in my opening post.

I am including the log file. The issue appears to show up in lines 8492-8493. The lines further down show a recurring pattern so I assume that the player is stuck in a loop that prevents it from resuming.

[crvi (crvi)]

is the issue reproducible with 'gst-launch-1.0' command ?

[Jurgen Schellaert (jurgen-schellaert-j)]

I think this ticket can be closed, at least for now.

Since I replaced all my mp3 format streams with aac streams, I have not experienced as much as a stutter. Then again, for all I know, the actual reason may be a recent be a kernel update...

Anyway, thanks for your assistance!

[crvi (crvi)]

> the actual reason may be a recent be a kernel update...

after the kernel upgrade, do the mp3 streams work fine ?

[Jurgen Schellaert (jurgen-schellaert-j)]

Well... I just find that mp3 streams work just as fine. Most likely a kernel thing, then.