Project

General

Profile

Bug #358

Problem with playing MP3 files over SMB/CIFS shares

Added by Mr. Zdeeck over 11 years ago. Updated over 11 years ago.

Status:
Rejected
Priority:
Minor
Assignee:
-
Category:
-
Target version:
-
Start date:
October 08, 2013
Due date:
% Done:

0%

Estimated time:
Affects version:

Description

Hello,

there've been several bugreports concerning this, but I'm posting this one because of the attachment and other (maybe useful) observations of the issue:

1) when trying to play MP3 file from the CIFS/SMB share, audacious (test versions 3.2.5 and 3.4.2) locks for 1-2 minnutes when reporting "buffering"
2) during this time it is transferring avg 40KB/s (my max. network thruput is around 2MBs)
3) after couple of minutes it finally starts to play the file
4) when trying to seek in the MP3, same situation happens

When tracing the CIFS connections with Wireshark (see attachment) it's clearly visible that audacious is seeking through the MP3 by single byte (!!) and with the WiFi latency overhead the resulting speed is not a surprise.

I've tried several CIFS/SMB speedups, but unfortunatelly for some reason even CacheFS (cfs mount option for network filesystems caching) doesn't help. My SMB/CIFS options:

//server/music /music cifs rw,guest,sec=lanman,nounix,noperm,uid=nobody,gid=nogroup,file_mode=0666,dir_mode=0777,rsize=130048,nobrl,fsc 0 0

Other software (VLC) works perfectly fine, also when trying caching (cp'ing the files) everything looks fine.

I've seen the patch included in bug #351 but it doesn't seem final - I've swtiched off mpg123 plugin and tried to play MP3 file with ffmpeg plugin and the same behavior followed.

--Z

smb_packets.txt (39.3 KB) smb_packets.txt Mr. Zdeeck, October 08, 2013 22:47
samba-log-jlindgren.txt (63.7 KB) samba-log-jlindgren.txt John Lindgren, November 24, 2013 03:41

History

#1 Updated by John Lindgren over 11 years ago

Please attach or link to the MP3 file you are testing with.

#2 Updated by John Lindgren over 11 years ago

  • Category deleted (core)
  • Affects version deleted (3.4.2)

Also there is no version 3.4.2 yet ...

#3 Updated by Mr. Zdeeck over 11 years ago

The MP3 file is here:

http://zdeeck.borg.cz/01-Korana.mp3

Yeah, the version is 3.4.1, sorry for the misinfo ;-)

#4 Updated by Mr. Zdeeck over 11 years ago

Hello,

I´ve got another update:

I've got my shares on Synology NAS 212j with FW version 4.3, which is a pretty nice piece of hardware and software. Nevertheless when I switch off the "Enable SMB2 and large MTU" in the NAS GUI, the starting time of the song above is like 3 seconds (which is still more than expected), but definitely much better than 1 minute.

Hope this helps a little,

--Z

#5 Updated by John Lindgren over 11 years ago

Mr. Zdeeck wrote:

I've got my shares on Synology NAS 212j with FW version 4.3, which is a pretty nice piece of hardware and software. Nevertheless when I switch off the "Enable SMB2 and large MTU" in the NAS GUI, the starting time of the song above is like 3 seconds (which is still more than expected), but definitely much better than 1 minute.

Now that's interesting. I wonder if there is a problem in the SMB driver on one side or the other. I haven't had time to recreate the scenario here yet, but as far as I know the one-byte reads are not normal for Audacious. Usually it reads one MP3 frame at a time (somewhere around half a KB, depending on the bitrate).

#6 Updated by Mr. Zdeeck over 11 years ago

Well I've experienced similar problems with MPlayer. Copying the file in Midnight commander works as a charm, playing with MPlayer from the share sometimes fail (I've tried only some videos though). On the other hand VLC works without problems. Is there any way how can I help with debugging this? When I run audacious with -V flag, it starts messing with the file (the VFS layer), but when the actual reading takes place, nothing is written in the log... My guess is that there is some correlation between seeks (which is a common player behavior unlike simple copy usecase) and the SMB2-MTU.

#7 Updated by John Lindgren over 11 years ago

Do you notice any difference in the Wireshark logs with and without SMB2 enabled?

#8 Updated by Mr. Zdeeck over 11 years ago

Hello,

sorry for the late reply, but after further investigation I think I've finally found the real cause. It is definitely ID3V2 picture tag. I've made several test files:

http://zdeeck.borg.cz/audacious/

1-fulltag.mp3 (all the tags)
2-id3v1.mp3 (only ID3V1)
3-id3v2.mp3 (only ID3V2 with picture)
4-notag.mp3 (no ID3V1 and ID3V2)
5-id3v2-nopic.mp3 (ID3V2 without picture)
6-id3v2-autofix.mp3 (ID3V2 with picture but tags autocorrected with EasyTAG)

files 1,3 and 6 causes the behavior described above. I've also noticed that the delay is dependent on the picture size (in files above the picture is pretty big - 600x600px 365.8kB, so the delay is more than noticeable).

I hope we finally nailed it ;-)

--Z

#9 Updated by John Lindgren over 11 years ago

I'm completely and utterly unable to reproduce this. I have Windows XP running in VirtualBox (192.168.1.95), which is sharing the C:\Samba folder which contains only 01-Korana.mp3 (your original version). I mount the share on an Arch Linux box (192.168.1.93) with the following command:

$ sudo mount -t cifs -o guest //192.168.1.95/Samba /opt

I also have Audacious set to use FileWriter output for benchmarking purposes. Now I run Audacious like so:

$ audacious /opt/01-Korana.mp3

From the attached Wireshark log, you can see that most of the requests are 60 KB and the smallest is 4 KB. The entire file is read and decoded (including displaying the album art image) in under 5 seconds. Hence I have to assume something is wrong in your network setup.

#10 Updated by John Lindgren over 11 years ago

  • Status changed from New to Rejected

I'm closing this and #351 since both are unreproducible here and hence probably network configuration problems.

Also available in: Atom PDF