Version: 2.4.0 (using KDE 4.5.5) OS: Linux Amarok flooding Knotify while playing. But all notifications is off in Amarok (OSD & Knotify). Reproducible: Always Steps to Reproduce: play music from mp3 collection Actual Results: flood Knotify with two results: 1) kio error: unknown protocol amarok-sqltrackuid:// 2) notify about copy file from amarok-sqltrackuid://some-hash-32-hex to /tmp/kde-user/plasma-desktopAANNNN.tmp performance of desktop/plasma is degraded ..
Reassigning. This is not a problem of the KNotify backend. It is KIO related. I wonder why it says "amarok-sqluidtrack is an unknown protocol" in the first place.
I mean .. primary it is Amarok bug. In version 2.3 not has this bug. Question is: why Amarok propagate to desktop notify about some ugly non-important transfer ? Yes, transfered via kio, but who defined "this is propagate to notification" ? But temporary unknown protocol for kio - good to be solved. For clarify: i have collection in internal db from older version Amarok, then only updated to Amarok 2.4. And "show moodbar" is On.
Next clarify: bug is not related to scripts, all is off. Amarok generate cca 16.000 EMPTY files in cca 2-3 hours of playing. Why? Creating these files not in all time.
New test: start playing, in time of 3 songs (cca 10 minutes) all is ok. Then flooding started. While next 3 songs played (time cca 9 minutes), has been created new cca 2.000 empty files in /tmp/kde-user .. and Knotify is flooding, desktop is near of unusable. After stop playing flooding is stopped allways. In collection setting i have off both "write statistic to file" and "watch folders for changes". What doing amarok-sqltrackuid and why is copied to tmp ? Is it neccessary ?
Even more - when closing amarok during this flood - kwin crashes...
I've got the same problem here: Running Amarok 2.4 (under KDE 4.5.5) - Amarok starts sending stuff via knotify which completely kills the desktop interactivity. I hope this gets solved soon, as Amarok is not usable in this state to me.
I can't reproduce this here at all, using Amarok 2.4-git, KDE 4.6 RC2 on Kubuntu 10.10
I can also confirm this on KDE 4.5.5, Amarok 2.4.0 (opensuse 11.3). I've disabled my notifications, and I found the following in my .xsession-errors: "plasma-desktop(29353)/ Mpris::artwork: "Could not start process Unable to create io-slave: klauncher said: Unknown protocol 'amarok-sqltrackuid'." In conjunction with the fact that album artwork is not showing in the "Now Playing" plasmoid, I got rid of all instances of the plasmoid, and plasma is responsive again. Looks like something is jacked in the MPRIS D-BUS interface between Amarok 2.4.0 and KDE 4.5 and that's causing these errors. Why is the marked as "works for me"??
Folks, this is likely a problem with KIO that is apparently solved in the upcoming KDE 4.6, to be released later this month. As I said, I can't reproduce this here at all
I hope there'll be KDE upgrade packages to 4.6 done soon for Mandriva. I'll check if the problem vanishes after the update...
I have the same problem running Amarok 2.4 on KDE 4.5.5 (Arch Linux x86_64). I've been doing some testing and find out that the problem is when you have any plasmoid that uses the "Now Playing" DataEngine. I think this is a problem between the new amarok and the mpris protocol (with amarok 2.3.2 this works just fine).
I've been doing some more testing and find that when I send the message "GetMetadata" to "org.mpris.amarok" the arturl in the metadata returned by amarok 2.4.0 is a string like "amarok-sqltrackuid://13228983f087cf69d0062918cd86a41a" instead of the string "file:///home/mauro/.kde4/share/apps/amarok/albumcovers/cache/1@c57937f7a7fd632b84a5263d906a56a6" returned by amarok 2.3.2. And I think that when the now playing plasmoid tries to open the url it gets the "Unknown protocol 'amarok-sqltrackuid'" and show that annoying notification.
Can anyone confirm that this happens only with the tracks that have an id3 embedded cover?
(In reply to comment #13) > Can anyone confirm that this happens only with the tracks that have an id3 > embedded cover? I tested this and with a not embedded cover and downloading the album cover with "get cover" option from amarok (Write Back Cover option deactivate) it works. The parameter 'arturl' is "file:///home/mauro/.kde4/share/apps/amarok/albumcovers/large/50f6250e343b77dbdce32f9cbfcb7b17".
(In reply to comment #13) > Can anyone confirm that this happens only with the tracks that have an id3 > embedded cover? Now i tested cca 5 albums without embedded cover and 5 albums with embedded cover .. different sources. YES, empty files are copy to tmp only with tracks with embedded cover.
I tried to look into it, and this is what I think: I believe the developer who rewrite the collectionscanner simply forgot that the mpris specification implies to provide the path to an actual image file for the arturl in metadata. In Amarok in general, embedded covers are retrieved directly through the track file, and identified with the amarok-sqltrackuid protocol. That means that the cover images are never cached on disk. But cover images have to be cached, otherwise there is no way for an external application to get a cover, since the amarok-sqltrackuid protocol is known only inside Amarok. So for a file with an embedded cover, when the arlurl is requested, instead of giving a location like file://blabla, Amarok gives amarok-sqltrackuid://someotherblabla. The now playing plasmoid (and, according to Mauro, any plasmoid using the data engine) doesn't handle it so well and causes the KNotify flood. So Amarok is not directly responsible for Plasma going crazy, but the MPRIS support in 2.4 is broken. That's what this bug is really about. Of course I might be wrong about the details, but I'm pretty confident this is basically what is happening. Myriam, could you please remove the WORKSFORME tag? If you need a file containing an embedded cover to reproduce I can provide one.
Changing status as asked in comment #16
OK, when i remove PlayWolf widget from desktop then all is OK. Fine, problem is only when is used widget "now playing" type and track have embedded cover.
Actually the problem happens with any plasmoid that uses the nowplaying DataEngine and is connected to "mpris.amarok.org". This is because the nowplaying DataEngine automatically generate a QPixmap from the album cover url and then is when the problem starts.
Comment #12 is the issue, I'll ask the corresponding dev about this. We should not give amarok-sqluidtrack URLs to the outside at all.
Anthony, it's a little stupid that mpris needs an url to an actual file. Of the many different collections we have in Amarok not many can reliable provide URLs to images. The SqlCollection is one that has a disk cover cache only for scaled images. The full scale images are sometimes embedded inside the tracks. I will try to have a look a the mpris specification.
Anthony, it's a little stupid that mpris needs an url to an actual file. Of the many different collections we have in Amarok not many can reliable provide URLs to images. The SqlCollection is one that has a disk cover cache only for scaled images. The full scale images are sometimes embedded inside the tracks. I've just read the Mpris specification and it says "if there is an image associated with the track, a URL for it may be provided using the "mpris:artUrl" key" However it does NOT say that an URL to a local file should be given. It also does not specify a prefered size of the image. For now, I think Amarok is following the specification. It does however make sense to change the whole behaviour. 1. extend the CoverCache class to provide a disk cache for images with a sensible size 2. remove the imageUrl function from Meta::Album as it is not working for most collections as they usually can provide a QImage but seldom a file for it. 3. update the Mpris specification to be more specific about the meta data provided. E.g. not linking to XMMS page for definition of meta data. Please indicate if you like this solution.
A little detail first, the mpris spec here is the v1 (for arturl: http://xmms2.org/wiki/MPRIS_Metadata#.22arturl.22), but it doesn't change much in this case. So it says "(string) An URI to an image associated with the work". > However it does NOT say that an URL to a local file should be given. > It also does not specify a prefered size of the image. > > For now, I think Amarok is following the specification. If it's not an URL to a local file, then what could it be? That's a honest question, I just don't see what are the other possibilities. In any case, I think giving amarok-sqluidtrack as a URL breaks the specification, since there is no way for a third party application to understand what it means. > It does however make sense to change the whole behaviour. > 1. extend the CoverCache class to provide a disk cache for images with a > sensible size What is considered as a sensible size? > 2. remove the imageUrl function from Meta::Album as it is not working for most > collections as they usually can provide a QImage but seldom a file for it. I guess you meant imageLocation(). But how can one retrieve the cover then? That's really what I don't understand in your reasoning. > 3. update the Mpris specification to be more specific about the meta data > provided. E.g. not linking to XMMS page for definition of meta data. What would you like to see being more specific? Maybe a preferred size? (I'm asking this but I have no link with the "MPRIS team" whatsoever) The XMMS page was just where the spec v1 was hosted at first.
(In reply to comment #23) .. > If it's not an URL to a local file, then what could it be? That's a honest > question, I just don't see what are the other possibilities. > In any case, I think giving amarok-sqluidtrack as a URL breaks the > specification, since there is no way for a third party application to > understand what it means. URL linking a picture on Amazon or LastFM I agree that an internal url does not make much sense. > > It does however make sense to change the whole behaviour. > > 1. extend the CoverCache class to provide a disk cache for images with a > > sensible size > What is considered as a sensible size? Good point. Many users store high-res images and that's what you get for a link. Forcing you to parse a 1600x1600 picture is probably not the most sensible way. > > 2. remove the imageUrl function from Meta::Album as it is not working for most > > collections as they usually can provide a QImage but seldom a file for it. > I guess you meant imageLocation(). But how can one retrieve the cover then? > That's really what I don't understand in your reasoning. The normal way to retrieve an image should be the Album::image function. imageLocation does only work with collections that have an actual image file somewhere. Most collections don't. Also imageLocation is only really used for mpris but needs to be implemented for every collection. That's why I say: make a function that takes the QImage and store it on the filesystem. That could be the mpris module or the CoverCache (with the additional benefit that we could use the stored cover cache image also internally) > > 3. update the Mpris specification to be more specific about the meta data > > provided. E.g. not linking to XMMS page for definition of meta data. > What would you like to see being more specific? Maybe a preferred size? (I'm > asking this but I have no link with the "MPRIS team" whatsoever) > The XMMS page was just where the spec v1 was hosted at first. the definition for "location" is more sensible. You can actually imply that non-local files are allowed. In the light of this: Why don't we allow non-local files for album covers. And an additional comment: Why does Knotify not sanitize the data?
The bug still exist in kde 4.6.0 with amarok 2.4.0. Amarok and KNotify generates almost 30'000 plasma-desktop*tmp file in a day on my pc.... Count file: gentoo kde-pycoder # ls -la | wc -l 29621 List dir: -rw------- 1 pycoder pycoder 0 6. Feb 11:58 plasma-desktopZya490.tmp -rw------- 1 pycoder pycoder 0 6. Feb 12:20 plasma-desktopZYa490.tmp -rw------- 1 pycoder pycoder 0 6. Feb 09:21 plasma-desktopzya529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 09:32 plasma-desktopzYa529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 09:21 plasma-desktopZya529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 09:33 plasma-desktopZYa529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 13:31 plasma-desktopzyb109.tmp -rw------- 1 pycoder pycoder 0 6. Feb 13:31 plasma-desktopZyb109.tmp -rw------- 1 pycoder pycoder 0 6. Feb 09:44 plasma-desktopzyb529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 09:55 plasma-desktopzYb529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 09:44 plasma-desktopZyb529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 09:55 plasma-desktopZYb529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 10:07 plasma-desktopzyc529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 10:18 plasma-desktopzYc529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 10:07 plasma-desktopZyc529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 10:18 plasma-desktopZYc529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 14:18 plasma-desktopzz4322.tmp -rw------- 1 pycoder pycoder 0 6. Feb 14:18 plasma-desktopZz4322.tmp -rw------- 1 pycoder pycoder 0 6. Feb 12:44 plasma-desktopzz5109.tmp -rw------- 1 pycoder pycoder 0 6. Feb 12:40 plasma-desktopzZ5109.tmp -rw------- 1 pycoder pycoder 0 6. Feb 12:56 plasma-desktopZz5109.tmp -rw------- 1 pycoder pycoder 0 6. Feb 12:50 plasma-desktopZZ5109.tmp -rw------- 1 pycoder pycoder 0 6. Feb 11:16 plasma-desktopzz5490.tmp -rw------- 1 pycoder pycoder 0 6. Feb 11:37 plasma-desktopzZ5490.tmp -rw------- 1 pycoder pycoder 0 6. Feb 11:16 plasma-desktopZz5490.tmp -rw------- 1 pycoder pycoder 0 6. Feb 11:38 plasma-desktopZZ5490.tmp -rw------- 1 pycoder pycoder 0 6. Feb 08:55 plasma-desktopzz5529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 08:52 plasma-desktopzZ5529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 09:00 plasma-desktopZz5529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 08:52 plasma-desktopZZ5529.tmp -rw------- 1 pycoder pycoder 0 6. Feb 15:02 plasma-desktopzz7388.tmp -rw------- 1 pycoder pycoder 0 6. Feb 15:02 plasma-desktopZz7388.tmp -rw------- 1 pycoder pycoder 0 6. Feb 13:09 plasma-desktopzza109.tmp -rw------- 1 pycoder pycoder 0 6. Feb 13:20 plasma-desktopzZa109.tmp -rw------- 1 pycoder pycoder 0 6. Feb 13:09 plasma-desktopZza109.tmp -rw------- 1 pycoder pycoder 0 6. Feb 13:21 plasma-desktopZZa109.tmp -rw------- 1 pycoder pycoder 0 6. Feb 11:59 plasma-desktopzza490.tmp Please fix the bug :/
(In reply to comment #24) > .. > URL linking a picture on Amazon or LastFM That would be suboptimal IMHO (needs an internet connection), but that seems acceptable in theory. I did a small test and the dataengine pops up a notification when it downloads the file for the first time (then it's cached, apparently). From a user point of view that's a little bit annoying, nothing compared to what is reported in this report though. > I agree that an internal url does not make much sense. > > > > It does however make sense to change the whole behaviour. > > > 1. extend the CoverCache class to provide a disk cache for images with a > > > sensible size > > What is considered as a sensible size? > > Good point. Many users store high-res images and that's what you get for a > link. Forcing you to parse a 1600x1600 picture is probably not the most > sensible way. While I understand this might be a nice improvement, I don't quite see how this has something to do with this bug...? Or you were just talking about general improvements? > > > > 2. remove the imageUrl function from Meta::Album as it is not working for most > > > collections as they usually can provide a QImage but seldom a file for it. > > I guess you meant imageLocation(). But how can one retrieve the cover then? > > That's really what I don't understand in your reasoning. > > The normal way to retrieve an image should be the Album::image function. > imageLocation does only work with collections that have an actual image file > somewhere. Most collections don't. > Also imageLocation is only really used for mpris but needs to be implemented > for every collection. > > That's why I say: make a function that takes the QImage and store it on the > filesystem. > That could be the mpris module or the CoverCache (with the additional benefit > that we could use the stored cover cache image also internally) That means that every cover available in Amarok would have a cache, right? That would definitely be my prefered solution. > > > > 3. update the Mpris specification to be more specific about the meta data > > > provided. E.g. not linking to XMMS page for definition of meta data. > > What would you like to see being more specific? Maybe a preferred size? (I'm > > asking this but I have no link with the "MPRIS team" whatsoever) > > The XMMS page was just where the spec v1 was hosted at first. > > the definition for "location" is more sensible. You can actually imply that > non-local files are allowed. > In the light of this: Why don't we allow non-local files for album covers. I think they are allowed, but, as I said at the beginning, I think it's better to download and cache an image once for all. But that's just my opinion. > And an additional comment: Why does Knotify not sanitize the data? I guess the dataengine doesn't perform checks because it trusts the providers, there is a specification after all.
another way of transferring images through uri is the data uri...
Additionally, I have mp3's where I have the cover art in the directory (as folder.jpg) as well as embedded. Amarok seems to prioritize the embedded coverart giving me the amarok-sqltrackuid:// problem.
I can confirm this issue on openSUSE 11.3/x86_64 with KDE 4.5.5. https://bugs.kde.org/show_bug.cgi?id=267271 Moreover, killing (or exiting amarok) results in a plasma crash.
Confirm, Amarok 2.4 KDE 4.6, Gentoo. Starts after playing a while. Tracks have embedded Covers. Removing the "media player widget" from desktop fixes it.
I can confirm this using veromix in 4.6.2 on openSUSE.
Still present in Ubuntu Natty (kernel 2.6.38-8, amarok 2.4.0, KDE Development Platform: 4.6.2) ... T_T !!!
I think it is still present in 2.4.1 The system starts going slow and plasma crashes. it gives some messages in the notification area, I think its something like amarok-slquid or something like that.
I can confirm this error is still present using KDE 4.6.3, openSUSE 11.3, amarok 2.4 from standard openSUSE and openSUSE Playground. When I remove the media plasmoid, it stops showing the copy dialog notification.
I can confirm a variant of this issue in openSUSE 11.4 for x86_64, KDE 4.6.3 and amarok 2.4.1 (`rpm -q amarok` = amarok-2.4.1-12.1.x86_64). I paused amarok for about 30 min, and when I came back to the PC, there were dozens of dummy notifications with no text whatsoever. Killing amarok also took the panel down ...
Git commit e28bec53d9944fde58849ee576b06a43f561f66f by Ralf Engels. Committed on 01/07/2011 at 17:03. Pushed by rengels into branch 'master'. Give already scaled images to mpris. BUG:263642 M +4 -1 src/core/meta/Meta.h M +9 -2 src/core/meta/support/MetaUtility.cpp http://commits.kde.org/amarok/e28bec53d9944fde58849ee576b06a43f561f66f