Bug 2887 - problems accessing files > 2 GB with mediaplayers
Summary: problems accessing files > 2 GB with mediaplayers
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Client Tools (show other bugs)
Version: 3.0.14a
Hardware: x86 Linux
: P3 minor
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-18 11:09 UTC by r. brinkhuis (550 5.1.1 User unknown in local recipient table)
Modified: 2005-08-24 10:20 UTC (History)
0 users

See Also:


Attachments
screendump filesize error (136.91 KB, image/png)
2005-07-18 11:12 UTC, r. brinkhuis (550 5.1.1 User unknown in local recipient table)
no flags Details
different_data_is_red_back (65.86 KB, image/png)
2005-07-20 11:10 UTC, r. brinkhuis (550 5.1.1 User unknown in local recipient table)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description r. brinkhuis (550 5.1.1 User unknown in local recipient table) 2005-07-18 11:09:12 UTC
I'm not sure this problem is samba related. It might be KDE or smb-kioslave 
related. This problem is also posted at KDE.   
Server is running mandrake 10.1, smbd 3.0.11. The server is exporting a share 
called hda containing a 6.3 GB file. 
Client 1 is running mandrake 10.2, kde 3.3.2, smb4k 0.5.1., smbd 3.0.13. 
When using smb4k for mounting the server, the filesize is reported as 6.3 GB 
(6.776.653.980 bytes). This is OK. When accessing the same share on the server 
using smb://user@server1/hda, the filesize is 2.3 GB (2.481.686.684 bytes). 
This is not OK. 
Client 2 is running mandrake 10.1, kde 3.2.3, smb4k 0.4.0, smbd 3.0.13. 
When using smb4k for mounting the server, the filesize is reported as 6.3 GB 
(6.776.653.980 bytes). This is OK. When accessing the same share on the server 
using smb://user@server1/hda, the filesize is 16.777.216.0 TB 
(18.446.744.071.896.270.848 bytes) This is not OK.
Comment 1 r. brinkhuis (550 5.1.1 User unknown in local recipient table) 2005-07-18 11:12:07 UTC
Created attachment 1315 [details]
screendump filesize error
Comment 2 r. brinkhuis (550 5.1.1 User unknown in local recipient table) 2005-07-19 02:48:47 UTC
I did some additional tests: 
Client is running mandrake 10.2, kde 3.3.2, smb 3.0.13. 
I made a share on the client, and mounted this share on the client itself 
using smb4k. 
In this share is an avi-file of 6.3 GB. I think it is not an old-type AVI-file 
because, as far as I understood, these have a filesize limit of 2 GB. It is an 
OpenDML AVI-file. The file is generated using kmenc15, which runs on top of 
the latetst plf-mencoder. 
An avi-file should have an index inside itself, because an index makes it 
possible to rapidly go forward and backward throuhg the file. 
The videoplayers I use are xine (latest plf) and vlc 0.8.2. 
When accessing the avi-file with vlc, and the avi-file is located on an ext3 
filesystem, vlc is able to "see" the duration of the file and is able to go 
fast forward and backward through the file. This does not generate cpuload, so 
it is apparently an easy thing to do for vlc. 
When accessing the same avi-file with vlc, and the avi-file is accessed by a 
mounted smb filesystem, vlc is not able to "see" the duration of the file and 
is not able to go fast forward and backward through the file. 
When accessing the same avi-file with xine, and the avi-file is accessed by a 
mounted smb filesystem, xine reports to me that it is restoring the index when 
going fast forward and backward through the file. This is very cpu-intensive 
and slow. 
When accessing the avi-file with xine, and the avi-file is located on an ext3 
filesystem, xine is able to go fast forward and backward through the file. 
As far as I understood, the index information is "somewhere" in de file, and 
because of compatible reasons with the old AVI-file spec's, it is located 
after the first 2 GB of data. 
Apparently seeking through a file when mounted using smb is not possible or is 
different compared with seeking through a the same file on a plain ext3 
filesystem. 
I upgraded samba from 3.0.13 t 3.0.14a but this does not change the behaviour. 
I think it is not player-related because xine and vlc do not share much code 
for reading files or decoding avi's (as far as I know). 
Using WXP gives a different result. A drive-letter is used on WXP to mounted 
the share on the Mandrake-PC. VLC 0.8.2 on WXP is able to show the duration of 
the avi-file and is able to go fast forward and backward. 
I went back to the mandrake-PC and did another mount of the same share. The 
first mount was done through smb4k. The second mount was done typing mount -t 
smbfs //mdktest/share /mnt/test -o=user. 
The result did not differ from the results using smb4k. Vlc cannot report the 
duration of the avi-file. Xine still reports "restoring index" when going fast 
forward or backward. 
On the share is also another AVI with a filesize of 1.9 GB. Most likely this 
is an old-style AVI. VLC and Xine do not have any problem playing this file. 
These results suggest that the problem is not related to the server-part of 
samba but to the linux-client-part of samba and is related to the filesize. 
Being able to use the index inside an avi is important because of the ability 
of using the fast forward and backward buttons on the videoplayer.  
Comment 3 Björn Jacke 2005-07-20 09:36:48 UTC
libsmbclient was fixed for large file support in 3.0.14, if possible alway test
against the most recent version before reporting a bug. I just checked this with
konqueror and libsmbclient of samba 3.0.14a. I see no problem with large files,
even 5TB large files are reported correctly.
Comment 4 r. brinkhuis (550 5.1.1 User unknown in local recipient table) 2005-07-20 11:10:58 UTC
Created attachment 1324 [details]
different_data_is_red_back
Comment 5 r. brinkhuis (550 5.1.1 User unknown in local recipient table) 2005-07-20 11:12:50 UTC
There are two problems; one of them is the filesize shown. Most likely the     
incorrect filesize show is related to the smb-kioslave of kde, and is not     
related to samba. Let's forget that problem in this bugzilla; it's a problem     
for kde-bugzilla.     
The other problem is, I think, samba-client related. The problem is that   
mediaplayers cannot, for some reason, seek in files larger then 2 GB, when   
those files are located on a mount using -t smbfs.   
   
The filesize reported with ls -l is always correct.   
   
The test-PC is as follows: 1 PC, mandrake 10.2, smbd --version 3.0.14a,     
smbclient --version 3.0.14a.     
On an ext3-partition an avi-file is located. This ext3-partition is made   
sharable through samba, and mounted on the same PC. So the same file can be   
accessed directly or accessed through a samba share <--> samba-mount.     
When playing the avi-file on the samba-share-mount, vlc is not able to show 
the total duration of the avi-file, and is not able to go fast forward or 
backward in the avi-file. Xine complaints about "restoring the index" when 
going fast forward or backward. 
When playing the avi-file from a local ext3-partition, everything is OK. VLC 
can show the total time and both players can go fast forward and backward. 
When mounting the sambashare using a WXP-PC, win-vlc can show the total 
duration of the avi-file and is able to go fast forward and backward. 
Apperently the problem is related to the samba-client and not the 
samba-server, because the combination of samba-server and WXP works OK. 
 
Second test. See attached screendump called different_data_is_red_back.png. 
Using the command od, the same avi-file is accessed. When getting 100 bytes of 
data while going through the samba-share, different data is reported back. 
 
Comment 6 Björn Jacke 2005-07-20 17:47:56 UTC
the original problem was fixed in 3.0.14, please don't reopen to report a
different problem.

The thing you mention here is something which is smbfs related and smbfs is not
part of Samba. Your media player wants to mmap the file which is not supported
by smbfs.
Comment 7 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:20:31 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.