Version: (using KDE KDE 3.3.92) Installed from: Compiled From Sources From a mounted Cifs network drive(Samba) with Std. Mount options amarok fails to : make a collection show time remaining of mp3 playing show khz of mp3 playing amarok version is CVS from 7.2.2005 with kde 3.4beta2 and all new taglib and everything else.
Christian, this is a mysterious effect indeed. But whatever it is, it can hardly be an amaroK bug. See, to amaroK all mounted directories are the same. There is no way an application could/should have any special handling for mounted network folders. After all that's the whole point of transparency.
yup, will close this bug for now. feel free to open with further information! without there is nothing we could do. so far, the only thing we can tell is: works fine everywhere we tried it. regards, muesli
Please check Amarok with a Cifs share. If you dont have one please forward this Bugreport to someone who has a Cifs network drive. Say to him he should build a Collection of the Network drive. Since it is probably a Taglib Problem please forward this Bug to the Taglib People.
Make sure you have a *very* recent Linux kernel, because it had a bug in its CIFS code. If you still can reproduce using 2.6.11 or better, reopen.
i confirm that the bug is there in 2.6.10 2.6.11 and now i am running 2.6.1-mm1. I also check i i can play and seek files with xmms that are on the network drive-and with xmms there is no problem. With amarok i cant seek in the files and much metainformation is displayed wrong.
XMMS wouldn't be affected because it isn't a KDE application. Please try listing the directory in Konqueror and opening the file with another KDE program -- for instance, playing it with kaboodle.
listing with konqueror and kaboodle in 3.4 works and playing and seeking work perfectly , but not in amarok. should i test more ?
You simply must tell us which audio-engine you are using.
engine is gstreamer with alsasink
The bug report with information on the kernel bug is Bug #92347 (http://bugs.kde.org/show_bug.cgi?id=92347). See if there's anything there that can help you solve your problem with CIFS-mounted shares.
*** Bug 98767 has been marked as a duplicate of this bug. ***
Is this still valid?
close
Amarok 1.4.3 (KDE 3.5.2, Kubuntu Package 4:3.5.2-0ubuntu18 dapper) Linux (i686) release 2.6.15-27-686 When some smb share is mounted to lacal filesystem via smbfs, there is no seeking in files from mounted share in Amarok. In mplayer and kaffeine seeking is ok. Also, amarok doesn't see any tags in mp3 files from this mounted share, and again, kaffeine and mplayer shows tags ok. Tags also missing in file properties dialog from konqueror. Amarok and Kaffeine uses xine engine. And also tags and seeking fails with KMplayer with both mplayer and xine engine
I can confirm this problem, but the reason is not clear to me. However, it seems to be a problem at quite a low level: - taglib checks if the file is writable, this is done by verifying if the return value of 'access("filename",W_OK)' is 0 - the permissions on the file as listed by ls and the return value of this access call indicate that the file is writable - however, actually opening the file for reading with 'fopen("filename", "rb+") fails (and touch(1)ing non-existing files in a writable directory on this cifs share fails as well) In my case, the server was samba 3.0.22 as found in ubuntu edgy. The client kernel was 2.6.17-1.2187_FC5 on fedora 5 using the -tcifs on the mount command line. The smb share had the option 'writable = no' in the smb.conf file. The problem could probably worked around in taglib by trying to open a file again for reading only if opening for both reading & writing failed.
The problem is not specific to the cifs implementation, but also happens when using -tsmb. But it can be worked around, by mounting the non-writable filesystem read-only (-oro mount option). However, ls -l still shows the files to be writable, but the access test used in taglib works correctly then.
*** This bug has been marked as a duplicate of 10945 ***
It seems that it should have been marked a duplicate of http://bugs.kde.org/show_bug.cgi?id=109451
Yes, mounting with read-only solved this problem for me, tanks a lot!
yup, wrong dupe
*** This bug has been marked as a duplicate of 109451 ***