Clementine: Files on samba share run out of buffer

[Schabernack]

I have all my music stored on an external usb drive connected to my router. It is mounted as a samba share automatically when logging in.

Since the update from 1.2 to 1.2.3 playback is constantly interrupted to rebuffer the song. Playback continues normally after. It is not related to a slow network since I can watch movies or play songs with audacious without any issues.

I have experimented with buffer sizes but even large 8000ms buffers don't change the situation. For comparison, in audacious I have a 500ms buffer.

Pulse is used as soundoutput. I am using Lubuntu 14.04.

[TheUbuntuGuy]

Have you tried this with the latest dev build?

My guess is that this is caused by a bug in gstreamer 0.1, which was fixed in gstreamer 1.0. This is the same bug which causes #4061. The latest builds now use gst 1.0 so they shouldn't have the same bandwidth bug.

[Schabernack]

any chance the change is released as a new minor version any time soon so I can just apt-get upgrade instead of dealing with dev builds?

[TheUbuntuGuy]

You can just download the .deb from http://builds.clementine-player.org/ and install it with dpkg. It will install as an upgrade for the version in the repository. You can use apt to downgrade after.

[Schabernack]

thanks a lot for your help. I installed the latest dev build but buffering still occurs.

I tried the steps described here: https://github.com/clementine-player/Clementine/issues/3653 but this didnt solve the problems.

i did however notice that the audio output - output device is not saved. i tried to change it to pulse but after closing the settings it is back to automatic selection.

playback also stops after each track and you have to manually tell clementine to play the next song. I understand that its a dev version, unstable and this stuff can be expected but this makes isse makes it impossible to use the dev version as a replacement

[rcmn]

I'm having the same issue here. Clementine 1.2.3 on lubuntu 14.03 and 14.10.
So after further testing here what I'm seeing. Changing buffering size(time) will make the buffer run out quicker stop and buffer again or longer if increasing , rather than keep buffering while playing. It's a strange behavior.(ex for a 10mb file I need to extend to at least 10 000ms or more). I also experience some strange issue where the track go silent randomly .this happen on both system from 2 different smb share (respectively ubuntu server and Raspian) on wired connections.
I stream video from these shares and music to other players with no issues at all.

[dniku]

I'm experiencing the same problem on Gentoo with Clementine 1.2.3 and two versions of GStreamer installed (0.10.36-r2 and 1.4.5, Clementine uses the 0.10 branch). Funny thing is that it only occurs while playing MP3 and never while playing much bigger FLAC or M4A (with ALAC inside).

UPD: in my case VLC also makes pauses in playback of MP3 files.

[bananabob]

Getting this problem with Linux Mint 17.2, and the PPA version of Clementine (1.2.3). I seem to have Gstreamer .10 and Gstreamer 1.0 installed. This is a clean fresh install of Mint 17.2 with only the PPA of Clementine added to try and fix the issue. The problem only seems to occur with MP3 files flacs work well.

[sentinelt]

I have also encountered this problem and tried to analyze it.

Although the mp3 file I play over a Samba share is only 7MB in size, after clicking Play Clementine is generating 4-5MB/s network traffic (SMB packets) quickly saturating my wifi link. What is also weird is that even if I stop the playback the traffic still stays for a 2-3 minutes.

[dniku]

Just ditch Samba and use sshfs.

[nigels-com]

I'm using Clementine 1.3.1 on Windows 7 (64-bit) and seeing some buffering problems over wifi, especially for FLAC-compressed music files. Poking around in the UI, I can adjust the audio buffering to a certain time. From a robustness point of view, it would be nice if Clementine pre-buffered (compressed) from the playlist upto some disk space limit to mitigate wifi fluctuation.

[ferrouswheel]

I posted this as a reply to #3653 on the original issue tracker but apparently it was eaten by the migration to github. Since I just ran into this frustrating bug again I thought I'd post my fix on this issue:

For anyone else pulling their hair out over this this issue: turns out that a recent kernel change re: cifs could be to blame.

If you check the mount.cifs man page, there is a option "cache=loose". This was the default before kernel 3.7. Afterwards it changed to "cache=strict".

Switching back to cache=loose fixed the issue for me.

[bananabob]

I found that switching to NFS has solved the issue for me.

[cemelmaci]

please see here
answer from @ferrouswheel

> I posted this as a reply to #3653 on the original issue tracker but apparently it was eaten by the migration to github. Since I just ran into this frustrating bug again I thought I'd post my fix on this issue:For anyone else pulling their hair out over this this issue: turns out that a recent kernel change re: cifs could be to blame.If you check the mount.cifs man page, there is a option "cache=loose". This was the default before kernel 3.7. Afterwards it changed to "cache=strict".Switching back to cache=loose fixed the issue for me.