Version: 1.3.1 (using KDE KDE 3.4.1)
Installed from: SuSE RPMs
Compiler: WhatEver Suse 9.3 Pro Used.
On SuSE 9.3 Pro. (Probley everything else 2)
Using either the offical amarok 1.2.2 build by suse or the amarok 1.3 beta 2 build by GURU. (Probley all other builds 2)
When adding music to the "collection" from a remote folder of music (via smb) which has been mounted by root "mount -t smbfs //computername/music /home/user/music".
Terminal spits out hundreds of
(tablib: could not open file /home/user/music/***.mp3)
user has read and execute access to the files.
no other applications have problems reading or executing files mounted like that. (including other media players playing those exact same mp3's)
Can you see if you're able to read the metadata for them in Konqueror? (right click on the file -> properties -> meta data) Which other media players are able to read the files?
Scott Wheeler wrote:
[bugs.kde.org quoted mail]
konqueror: no meta data tab or button or whatever, depending on however
konqueror was supposed to handle that
xmms: works, right clicking on files in the playlist and going view info
brings up the ID3 tags happily.
xine: (from memory) happy to play, donno about the tags tho.
mplayer: happy to play, donno about the tags tho.
amaroK: happy to play, but won't add files to the "collection". During
attempts, the terminal spits out taglib: can't open file
And you are able to read these files if you copy them to another partition?
Which kernel version? There were bugs in the smbfs code in all but the most recent Linux kernels, so you may be hitting them.
It would be interesting to test a non-KDE taglib app.
yeah, if i copy the files to locally, they are perfectly happy in every
uname -a spits out : Linux linux 220.127.116.11-21.7-default #1 Thu Jun 2
14:23:14 UTC 2005 i686 i686 i386 GNU/Linux
is that recent enough?
I've talked with Scott last night and we don't think it's the old smbfs bug.
However, given that it doesn't work in smb mounts only, we're at loss. We don't believe it's a taglib bug, though.
Can you run this:
strace -f -o /tmp/amarok amarokapp
then try to open one such file, then close amarok? Attach the produced file here, please (or mail it to one of us, if you don't want your information disclosed).
Created attachment 11918 [details]
looks like my last attempt to reply got interperated funny by something. well,
i'm doing this manually now, the file is compressed this time to save space.
"yeah, i had a read of the file /tmp/amarok when it gets to the part about the
mp3's, it says crap about permission denied, which seems illogical, cause, read
and execute permissions are fine... unless it's trying to write, which would be
completely inappropriate and concerning.
File is about 1.8MB
Ok, this is a file system bug. The interesting line is the one before "permission denied". When TagLib opens a file it first checks to see if the file is writable. If it is it opens it in read/write mode; if not it opens it in read only mode. The problem is that your file system is reporting that it's writable, then TagLib tries to open it in read read/write mode and gets permission denied. If the check to see if it is writable were correctly returning false, then it would open the file in read only mode.
*** Bug 102281 has been marked as a duplicate of this bug. ***
Have you reported this to the samba folk?
No, I haven't. Someone told me that it's fixed in the most recent version, but I haven't confirmed that.
meh, i'll test it, which distro would have the version of samba i should
Gentoo, circa March 23rd 2005? :-) I can test it too with Gentoo current.
Just for future reference:
Scott Wheeler wrote:
[bugs.kde.org quoted mail]
yeah, i reported the bug, it was temporary fixed by adding -r to the
command, someone said something about it being fixed in a new version of
something, so i was going to test it. dam i hate short-term memory.
*** Bug 117977 has been marked as a duplicate of this bug. ***
Created attachment 18028 [details]
patch to retry failed r/w fopen r/o
The cifs file system implementation could probably do something about the issue
of read-only exported shares mounted read-write. But then, the check for
writability is ultimately done on the server, but access(2) does not involve
The same problem might happen with nfs mounts. The RESTRICTIONS section of my
Linux access(2) man page contains this:
access() may not work correctly on NFS file systems with UID mapping enabled,
because UID mapping is done on the server and hidden from the client, which
So I suggest to implement something like the work-around in the attached patch.
*** Bug 98771 has been marked as a duplicate of this bug. ***
*** Bug 135243 has been marked as a duplicate of this bug. ***