197346 2009-06-21 10:40:01 +0000 kcm_filetypes does not store settings for audio/mp3 2010-03-02 15:19:47 +0000 1 1 2 Applications systemsettings kcm_filetypes unspecified Compiled Sources Linux RESOLVED FIXED NOR normal --- 1 mschiff faure andresbajotierra muziofg pino 0 oldest_to_newest 779249 0 mschiff 2009-06-21 10:40:01 +0000 Version: (using Devel) OS: Linux Installed from: Compiled sources I was trying to associate "JuK" with the audio/mp3 file type. Systemsettings -> Advanced -> File-Types (or similar, german locale here) Then type mp3 into the searchbox, then expand audio -> mp3 Now add "juk" to the applications, it will be added to the list. So far so good. But after clicking "apply", all changes will be lost and old settings are restored. If I call "keditfiletype audio/mp3" from the console and edit filetypes there it works as expected and the kcm module will show the new settings too. 781269 1 andresbajotierra 2009-06-24 18:32:53 +0000 Here using: Qt: 4.5.1 (qt-copy 971295) KDE: 4.2.92 (KDE 4.2.92 (KDE 4.3 >= 20090617)) kdelibs svn rev. 984425 / kdebase svn rev. 984427 on ArchLinux i686 - Kernel 2.6.29.4 I can reproduce the bug 781274 2 andresbajotierra 2009-06-24 18:41:20 +0000 Further tests: - "keditfiletype audio/mp3" works properly - "kcmshell4 filetypes" also shows this behaviour. Modifying the apps for "audio/mpeg" works properly, but not for "audio/mp3" Just note that "audio/mp3" is not a "real mimetype" but the extension for "audio/mpeg". (Also, when "audio/mpeg" is selected, the filename patterns show "mp3" and "mpga"; however if "audio/mp3" is selected, no filename patters are shown) @David: Could this be related then to this mixup of real mimetypes and extensions ? 781276 3 andresbajotierra 2009-06-24 18:44:21 +0000 Oh, I'm guessing something: When you have the complete dialog: if you edit the "audio/mp3" mimetype, if you add an application , then this is saved, but then the kcmshellApp will save the associated applications for "audio/mpeg" (as this is order by name ascending), and as "audio/mpeg" doesn't have this new added assoc application, it will delete it. And therefore, when the kcmmodule is updated after save, the "audio/mp3" "mime" will reflect the state of "audio/mpeg". That would explain the associated programs not being remembered in this weird case. 887813 4 mschiff 2009-12-27 22:30:58 +0000 This bug still exists in 4.3.85 :-( 893192 5 faure 2010-01-06 12:53:49 +0000 I don't even have a audio/mp3 mimetype. The mimetype for mp3 files is audio/mpeg. audio/mp3 is an alias for audio/mpeg Hmm. I'll have to look at what we do with aliases.... 924851 6 muziofg 2010-02-26 16:08:38 +0000 I have the same problem. But it is strange that, for example, mp3.xml is present in ~/.local/share/mime/audio/ (created by KDE for each first launch of a new user) and does not exist in /usr/share/mime/audio/ I use Kde 4.3.4 on a Debian sqeeze with shared-mime-info 0.70-1 version 926680 7 faure 2010-03-01 13:19:54 +0000 Then there is a packages file that defines audio/mp3 for you. KDE doesn't define it, it must come from somewhere else (wine, maybe, or some distro hack). Please search for "audio/mp3" in every directory returned by the command "kde4-config --path xdgdata-mime --locate packages/" and tell me what you find. E.g. grep mp3 ~/.local/share/mime/packages/* but also any other directory returned by the command above. 926695 8 mschiff 2010-03-01 14:34:20 +0000 Hi David, I am not Francesco, but I have that mp3.xml too, generated by gentoo's update-mime-database tool. mschiff@bart ~ $ kde4-config --path xdgdata-mime --locate packages/ /home/mschiff/.local/share/mime/packages/ mschiff@bart ~ $ grep mp3 ~/.local/share/mime/packages/* /home/mschiff/.local/share/mime/packages/application-x-nsv-vp3-mp3.xml: <mime-type type="application/x-nsv-vp3-mp3"> /home/mschiff/.local/share/mime/packages/audio-mp3.xml: <mime-type type="audio/mp3"> /home/mschiff/.local/share/mime/packages/audio-mp3.xml: <glob pattern="*.mp3"/> mschiff@bart ~ $ 926820 9 muziofg 2010-03-01 19:12:26 +0000 I have found the same result of Marc Schiffbauer, except of the record "<glob pattern="*.mp3"/> 927030 10 faure 2010-03-02 09:21:15 +0000 The problem comes from this file, then: /home/mschiff/.local/share/mime/packages/application-x-nsv-vp3-mp3.xml From its name, I would say that it was created by a webbrowser plugin (also called "netscape plugins"). Can you confirm that this file says "<!--MimeType generated by nspluginscan-->"? Ah! And in that case, I found the bug: pluginscan.cpp uses KMimeType::mimeType() without "ResolveAliases" so it thinks the mimetype doesn't exist, and defines it. Pino is right, we really have to change mimeType() so it resolves aliases by default. 927117 11 mschiff 2010-03-02 11:39:48 +0000 Hi David, bingo!: cat /home/mschiff/.local/share/mime/packages/application-x-nsv-vp3-mp3.xml <?xml version="1.0" encoding="UTF-8"?> <!--MimeType generated by nspluginscan--><mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info"> <mime-type type="application/x-nsv-vp3-mp3"> <comment>Nullsoft Streaming Video</comment> </mime-type> </mime-info> Great that you found the bug! Any chance to find a bugfix in 4.4.2 then? Marc 927191 12 faure 2010-03-02 15:19:47 +0000 SVN commit 1097954 by dfaure: As discussed with Pino: make alias resolution the default in KMimeType::mimeType. There is just no good reason not to, aliases can be used anywhere, especially with shared-mime-info replacing mimetypes with aliases over time (e.g. image/ico). This fixes at least two bugs: 1) a bug noticed by Pino: if you set the old name as filter in kfiledialog, when updating s-m-i it won't work anymore (because aliases are not resolved) 2) the bug that nspluginscan would define mimetypes because "unknown" when they are in fact aliases. BUG: 197346 Fixed for: 4.4.2 M +1 -1 services/kmimetype.h M +8 -4 tests/kmimetypetest.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1097954