Karmic Alpha 4 playback stops when playing media stored on samba share

[Ian Mackenzie]

Kubuntu Karmic Alpha 4 - updated packages as at 28/9 August 2009

Kaffeine, when playing a file (eg, MP4 TED Talk) from a samba share on a networked PC, stops playback, losing it's place in the file. The same file, copied to the local PC, plays perfectly, with no interruptions or problems.

This seems to happen on many types of media, MP4, .flv, avi etc.

Kaffeine is launched for this by opening up the shared directory in Dolphin, and clicking on the file, if that's any use.

[Tommy Brander (demom)]

I have the same problem. Both Kaffeine and Dragon Player stops playback on all tested files after some time.

This seems to be network-related, or at least to dhclient in some way, since after I increased DHCP lease time from fifteen to thirty minutes it played twice as much as before - whopping 34 minutes - before stopping playback.

I'm not loosing network connectivity, it's only playback that's not working.

Even Totem and MPlayer seems affected, but they stop much earlier.

I'm unable to get debug information, if someone tells me how I will gladly attach it.

[Ian Mackenzie (gldcompsol)]

I made another attempt at reporting a related bug: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/425526

- Having looked at Tommy's comment, I tried killing the networkmanager process, and playback problems have gone - a 720p .mkv file (2.2GB for ~50 minutes) which would only play about 5 minutes at a time is now playing perfectly.

- I am using a static IP for my network card and a manually set up /etc/resolv.conf pointing to OpenDNS for nameserving.

I hope that this helps assist someone more familiar with KDE/Kubuntu networking to identify the problem or at least give us a pointer as to how we can get the information necessary for that person to do so.

I'm running Kubuntu Karmic Alpha 5 updated at at September 15th 2009.

[Tommy Brander (demom)]

I've disabled NetworkManager daemon and runs dhclient manually to see if that helps the issue.

If it does, the problem is with NetworkManager, else it is with DHCP.

[Tommy Brander (demom)]

The problem lies not with NetworkManager itself, but with DHCP client. Somehow it disrupts the player some time (circa 4 minutes - buffer?) after a lease has been renewed.

Totem with GStreamer halts after some 10-20 seconds, the same does MPlayer and Xine-UI player with default settings. Kaffeine and Dragon player plays until DHCP lease is renewed.

Interesting to note is that VLC is able to play the entire clip, although with some hickups. It does output some error rows: [0x1b39de8] access_smb access error: read failed (Ogiltigt argument) (Ogiltigt argument is swedish for Invalid argument).

[Ian Mackenzie (gldcompsol)]

This problem still seems to be there in Kubuntu Karmic Alpha 6 - although the mean time before playback glitch on my system is now closer to 20 minutes than 5.

I installed a fresh copy of Kubuntu Karmic Alpha 6, installed libxine1-all-plugins, and tried to play the 720p .mkv file from a network share.

It played fine for ~20 minutes, then kaffeine stopped playing.

I then set up a static IP in /etc/network/interfaces and pointed /etc/resolv.conf at OpenDNS, and ran:
sudo ifdown eth0
sudo ifup eth0
sudo service network-manager stop

from a command prompt. Unfortunately the glitch is still there, but timing seems less predictable now.

Is there a way for me so see whether DHCP3 is still running and stop it if it is?

Thanks,

Ian Mackenzie

[Ian Mackenzie (gldcompsol)]

There was an up date to Kubuntu Karmic i386 on of about 25th September 2009 that seemed to fix this.

For me, anyway.

Tommy, are you still having this problem or can this bug be closed?

Ian Mackenzie

[Chuck Short (zulcss)]

Hi Jonathan,

Are you using dhcp and are you connecting to a NAS device?

Regards
chuck

[Jonathan Thomas (echidnaman)]

I'm just bug triaging. I don't have this bug.

[lembregtse (eric-lembregts)]

I'm still experiencing this problem on an up-to-date Karmic 9.10 64bit beta laptop.
I have a 9.04 64bit server running samba and MPlayer/GStreamer watching the file.

It randomnly stops while playing.

[Ian Mackenzie (gldcompsol)]

A change in the last week seems to have resurrected this bug - I'm running up to date Kubuntu 9.10 i386 Beta
Watching media stored on a Kubuntu i386 9.04 Samba share.
It seems to stop for me after playing for about 5 minutes and Kaffeine loses its place in the media, so continuing playback requires manually dragging the slider to the approximate place in the file.

All PCs use static IP and manual DNS (set in /etc/network/interfaces and /etc/resolv.conf)

Ian Mackenzie

[Ian Mackenzie (gldcompsol)]

I've just copied a large group of files (8.9GB worth) from the server to my media PC, and after about 5 minutes of copying, there was a glitch that with autoskip enabled, left one file incomplete and the next not copied.

What in the Kubuntu samba client software stack or networking stack would cause this? (And how could I get a log that could provide a clue for debugging purposes?)

What I did:

pointed Dolphin to smb://10.1.1.2/(samba share)/(subdirectory)

selected all files in the directory

Right-click | Copy

alt-tab to instance of Dolphin pointing at <home folder>/Video projects

Right-Click | Paste

Expected result: all files copied successfully

Actual result: two files not copied due o glitch in the middle of copy process

Kubuntu Karmic i386 up to date as at 11pm 22 October 2009 (NZ Daylight Saving Time - GMT + 13)

Ian Mackenzie

[Chuck Short (zulcss)]

@Ian,

You said you were using opendns correct?

Can you try uncommenting the following line:

name resolve order = lmhosts host wins bcast

Also can you attach your /var/log/samba/log.smbd

Regards
chuck

[Ian Mackenzie (gldcompsol)]

Hi Chuck,

The log (from the server PC) referring to samba access from my Karmic test PC "ian-bedroom" is attached -
I just uncommented the name resolve order line (in smb.conf) and restarted samba, and the /var/log/samba/log.smbd file reads as follows:

[2009/10/23 09:23:39, 0] smbd/server.c:main(1260)
  smbd version 3.3.2 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2009

I also repeated the copy ~9GB of files to the test PC after restarting samba, so the difference in before/after the change is visible. On the client PC, the glitch affected file 21 rather than files 13 and 14 - so it appears that the glitches are becoming less frequent.

Playing a media file glitched after 10 rather than 5 minutes just now - another 3-4 doublings of the time to glitch and it will seem solved ;-)

I hope this helps,

Ian Mackenzie

[Chuck Short (zulcss)]

" getpeername failed. Error was Transport endpoint is not connected"

Try putting this in the [general] section of the your /etc/samba/smb.conf:

smb ports = 139

Regards
chuck

[Ian Mackenzie (gldcompsol)]

Hi Chuck,

I put that in the [global] section - my smb.conf does not have a [general] section.

I still seem to be having the glitch:

[2009/10/27 21:41:02, 1] smbd/service.c:make_connection_snum(1115)
  ian-bedroom (10.1.1.17) connect to service TV initially as user nobody (uid=65534, gid=65534) (pid 28705)
[2009/10/27 21:46:43, 1] smbd/service.c:close_cnum(1327)
  ian-bedroom (10.1.1.17) closed connection to service TV
[2009/10/27 21:47:20, 0] lib/util_sock.c:read_socket_with_timeout(939)
[2009/10/27 21:47:20, 0] lib/util_sock.c:get_peer_addr_internal(1676)
  getpeername failed. Error was Transport endpoint is not connected
  read_socket_with_timeout: client 0.0.0.0 read error = Connection reset by peer.
[2009/10/27 21:47:20, 1] smbd/service.c:close_cnum(1327)
  ian-bedroom (10.1.1.17) closed connection to service TV
[2009/10/27 21:47:20, 0] lib/util_sock.c:read_socket_with_timeout(939)
[2009/10/27 21:47:20, 0] lib/util_sock.c:get_peer_addr_internal(1676)
  getpeername failed. Error was Transport endpoint is not connected
  read_socket_with_timeout: client 0.0.0.0 read error = Connection reset by peer.
[2009/10/27 21:47:20, 1] smbd/service.c:close_cnum(1327)
  ian-bedroom (10.1.1.17) closed connection to service TV
[2009/10/27 21:47:20, 0] lib/util_sock.c:read_socket_with_timeout(939)
[2009/10/27 21:47:20, 0] lib/util_sock.c:get_peer_addr_internal(1676)
  getpeername failed. Error was Transport endpoint is not connected
  read_socket_with_timeout: client 0.0.0.0 read error = Connection reset by peer.
[2009/10/27 21:47:20, 1] smbd/service.c:close_cnum(1327)
  ian-bedroom (10.1.1.17) closed connection to service Docos
[2009/10/27 21:47:20, 0] lib/util_sock.c:read_socket_with_timeout(939)
[2009/10/27 21:47:20, 0] lib/util_sock.c:get_peer_addr_internal(1676)
  getpeername failed. Error was Transport endpoint is not connected
  read_socket_with_timeout: client 0.0.0.0 read error = Connection reset by peer.
[2009/10/27 21:47:20, 1] smbd/service.c:close_cnum(1327)
  ian-bedroom (10.1.1.17) closed connection to service Docos
[2009/10/27 21:47:20, 0] lib/util_sock.c:read_socket_with_timeout(939)
[2009/10/27 21:47:20, 0] lib/util_sock.c:get_peer_addr_internal(1676)
  getpeername failed. Error was Transport endpoint is not connected
  read_socket_with_timeout: client 0.0.0.0 read error = Connection reset by peer.
[2009/10/27 21:47:20, 1] smbd/service.c:close_cnum(1327)
  ian-bedroom (10.1.1.17) closed connection to service TV

[2009/10/27 21:57:23, 1] smbd/service.c:make_connection_snum(1115)
  ian-bedroom (10.1.1.17) connect to service TV initially as user nobody (uid=65534, gid=65534) (pid 28989)
[2009/10/27 21:57:24, 1] smbd/service.c:make_connection_snum(1115)
  ian-bedroom (10.1.1.17) connect to service TV initially as user nobody (uid=65534, gid=65534) (pid 28990)
[2009/10/27 22:01:00, 1] smbd/service.c:close_cnum(1327)
  ian-bedroom (10.1.1.17) closed connection to service TV
[2009/10/27 22:03:17, 1] smbd/service.c:close_cnum(1327)
  ian-bedroom (10.1.1.17) closed connection to service TV
[2009/10/27 22:04:16, 1] smbd/service.c:make_connection_snum(1115)
  ian-bedroom (10.1.1.17) connect to service TV initially as user n...

[Ian Mackenzie (gldcompsol)]

Just an update - this bug is still present in the released version of Kubuntu 9.10 i386 (booted off a USB stick to make sure that user settings are not affecting behavior). In my system, playback stops very close to 5 minutes from starting.

Booting off a USB version of Ubuntu 9.10 i386 works fine and plays media indefinitely with no problem.

Media server upgraded to Kubuntu 9.10 i386 today with no change in behavior.

In case it is relevant, directories are shared from the server with no password, read only, guest ok - I'm not sure whether this is any help.

Any advice on how to come up with more useful logs or other information for debugging purposed would be greatly appreciated.

Ian Mackenzie.

[Suhas Gupta (suhasgupta)]

I was facing this bug as well. mplayer would get stop playback at exactly 5 minutes which is the same as the default value for keepalive interval used by smbd on my karmic installation. As a workaround, if I add "keepalive = 0" in /etc/samba/smb.conf on the server, mplayer does not disconnect any more. If I understand it correctly, the smb servers sends netbios keepalive packets after every 5 minutes and the client should respond, so maybe the bug is that the client is not responding correctly? On setting keepalive to 0, the server does not attempt to send any keepalive packets. This worked for me. Hope it helps!

[Ian Mackenzie (gldcompsol)]

Suhas Gupta's workaround has stopped this bug from affecting me. I doubt that it is a permanent solution for Kubuntu's smbclient configuration, however.

Thank you Suhas!

Chuck, if you have a client-side alteration you would like tested on a system where the bug can be turned on at will, I am happy to help.

Ian Mackenzie

[Chuck Short (zulcss)]

Ian,

Just for my info, what os for the share you are connecting to?

Regards
chuck

[Thierry Carrez (ttx)]

I used to have this issue, but I haven't been able to reproduce it so far on Lucid. Any chance you could try and confirm that this is now fixed ?

[Tommy Brander (demom)]

I dont have this problem anymore.

[Tommy Brander (demom)]

forgot to mention that i run Lucid

[Chuck Short (zulcss)]

Closing based on feedback recieved