Bug 197346 - kcm_filetypes does not store settings for audio/mp3
Summary: kcm_filetypes does not store settings for audio/mp3
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_filetypes (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-21 10:40 UTC by Marc Schiffbauer
Modified: 2010-03-02 15:19 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Schiffbauer 2009-06-21 10:40:01 UTC
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.
Comment 1 Dario Andres 2009-06-24 18:32:53 UTC
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
Comment 2 Dario Andres 2009-06-24 18:41:20 UTC
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 ?
Comment 3 Dario Andres 2009-06-24 18:44:21 UTC
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.
Comment 4 Marc Schiffbauer 2009-12-27 22:30:58 UTC
This bug still exists in 4.3.85 :-(
Comment 5 David Faure 2010-01-06 12:53:49 UTC
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....
Comment 6 Francesco 2010-02-26 16:08:38 UTC
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
Comment 7 David Faure 2010-03-01 13:19:54 UTC
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.
Comment 8 Marc Schiffbauer 2010-03-01 14:34:20 UTC
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 ~ $
Comment 9 Francesco 2010-03-01 19:12:26 UTC
I have found the same result of Marc Schiffbauer, except of the record "<glob
pattern="*.mp3"/>
Comment 10 David Faure 2010-03-02 09:21:15 UTC
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.
Comment 11 Marc Schiffbauer 2010-03-02 11:39:48 UTC
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
Comment 12 David Faure 2010-03-02 15:19:47 UTC
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