Under certain circumstances, tumblerd will begin to consume 97-99% of the system's I/O bandwidth (according to iotop) indefinitely; this results in constant disk accesses until the process is killed. I most often see this when I delete a file that has an associated thumbnail, but there seem to be other times that it occurs as well. Unfortunately, I cannot reproduce the bug 100% of the time. I have seen this behavior with both 0.1.24 on Ubuntu 12.04 as well as 0.1.25, with packages I tried from the 12.10 repositories.
Some additional information: The bug can also occur with file types that do not get thumbnails. It only occurs when deleting files with Thunar; using 'rm' does not seem to cause it, even if the directory with the file is open in Thunar at the same time.
I have tumbler 0.1.25 in Fedora 18. I just upgraded yesterday (Fedora 17 used 0.1.23, I think) and when opening Thunar it would take some time both as the normal user or as root, abrt would report both Thunar and tumbler SIGSEGVing. I have an old PC (Athlon) and came here to open a bug report to make tumbler have a low priority by default. But I think commenting here may do as it seems it's related (if not pardon me and I open another bug report). With tumbler with nice=0 the way it is when it's running it almost freezes everything so it should use a low priority like nice=19, like the KDE background services do (nepomuk etc.).
I want to rectify that the issue I was having was most probably triggered by a bug in F18 that didn't blacklist nouveau while I was using the nvidia driver. This seems to be the reason that made thunar --daemon crash too. Now I fixed this in my system and thunar is behaving well and tumbler too working just fine as usual.
Rectifying again. nouveau had nothing to do with it. ;-) https://bugzilla.xfce.org/show_bug.cgi?id=9627
Thumbnailing video files always requires a lot of resources for a lot of formats, but there are a couple of things we're working on to improve this. - Will be a way to disable plugins or only let them work in some locations / file sizes. - We can lower the nice value (have to test this a bit, if 19 still gives a decent response). - There is a new cover-thumbnailer for video files, this plugin searches online for movie posters -> no io-traffic (apart from saving the 128x128 image). I'll check if the cache handling is working as it should be, but thumbnailing will always be 'heavy', that's also why it's outsourced to another process.
Just to clarify what I'm experiencing, my problem is not that tumbler uses the resources while generating thumbnails. What I'm seeing typically occurs when a file is deleted using Thunar; tumblerd then begins accessing the disk constantly, and does not stop until killed.
(In reply to comment #6) > Just to clarify what I'm experiencing, my problem is not that tumbler uses > the resources while generating thumbnails. What I'm seeing typically occurs > when a file is deleted using Thunar; tumblerd then begins accessing the disk > constantly, and does not stop until killed. I see the same issue here reproducibly by trashing files. Directly deleting them does not trigger the issue. However, even simple copy operations sometimes trigger it. Just a moment ago Tumbler spawned over 1000 threads and the load average increased dramatically. I barely managed to open a terminal and kill all tumblerd processes.
(In reply to comment #7) > (In reply to comment #6) > > Just to clarify what I'm experiencing, my problem is not that tumbler uses > > the resources while generating thumbnails. What I'm seeing typically occurs > > when a file is deleted using Thunar; tumblerd then begins accessing the disk > > constantly, and does not stop until killed. > > I see the same issue here reproducibly by trashing files. Directly deleting > them does not trigger the issue. > > However, even simple copy operations sometimes trigger it. Just a moment ago > Tumbler spawned over 1000 threads and the load average increased > dramatically. I barely managed to open a terminal and kill all tumblerd > processes. Correction: the large number of threads occur and stay due to Tumbler unable to generate thumbnails for some video files. (Maybe due to encoding with 10bit instead of 8bit? Not sure.)
Please fix this bug, tumblerd starts frequently, slowing the system.
same issue in 0.1.29. deleting one .jpg from desktop caused 2min of heavy disk activity.
strange thing about this is that this issue happens only when deleting into trash bin. when you delete with the shift key the hdd is silent as a grave.
I've noticed that this bug seems to have some relation to the size of the thumbnail cache. Deleting all the files in ~/.thumbnails causes the bug to disappear for a time; as thumbnails are regenerated, it seems to show up again. I have not been able to pin down the threshold; it seems to be in the thousands of thumbnails.
tumbler version 0.1.30 issue still present
I have the same trouble with tumbler 0.1.30-1 on Xubuntu 14.04 LTS. I don't have any video on my computer but tumblerd often starts to scan something on a disc.
by the way i have programmed my OpenRC to remove the thumbnails at every start. if you should fix this let me know i will remove my fix and test it. if the performance of xfce goes down i will switch to gnome->kde->xfce->lxde->kde->xfce->mate
ok mate sucks. i am using this as /etc/init.d/tumblerdel: #!/sbin/runscript start() { ebegin "Deleting tumbler thumbnails from /home/e3k/.thumbnails" rm -f /home/someuser/.thumbnails/normal/* rm -f /home/someuser/.thumbnails/large/* eend $? }
thank you Jannis. to who ever takes this bug please make sure you have an rotational data storing device (not SSD) installed and make tumbler do at least thousands of thumbnails.
All right guys, the bug is still here but I'm not pretty sure whether it's a bug, actually. So, deleting ANY file via Thunar causes tumblerd to pop up and consume disk READING queue heavily. I have not seen the source code yet, but according to I/O stats it starts to access each of previously generated thumbnail. Now the problem is: ~/.cache/thumbnails/large$ find . ! -name . | wc -l 7105 ~/.cache/thumbnails/normal$ find . ! -name . | wc -l 12122 Takes a lot of time, but eventually tumblerd completes its mission. Clearing the cache obviously helps to reduce the side effects of such a behaviour, still it's not a panacea. .
ad it starts to access each of previously generated thumbnail: yes that was my suspicion ad I'm not pretty sure whether it's a bug: if touching every generated thumbnail just because just one image was deleted is not a bug then it is at least ineffective way of programming. i am using xfce as the heaviest of the lightweight desktops for old pc's and such behaviour makes it unusable for this purpose.
> thumbnail just because just one image was deleted is not a bug then it is at > least ineffective way of programming. Probably the latter. What is getting things worse... How come that all thumbnails are spat into the SAME directory? What happens if I have hundreds of thousands of pictures? I think it's not a problem to do at least the simplest tricks with: 00/ 01/ .. zz/ > > i am using xfce as the heaviest of the lightweight desktops for old pc's and > such behaviour makes it unusable for this purpose. Me too. Moreover, I tend to use it everywhere. I'll try to figure the things out and fix them, then produce a patch (however I believe that developer and/or maintainer of the package is able to do this much more faster, since I've got no xfce development experience at all).
ad SAME directory: yes i had this thought today too. a copy of the real fs under .thumbnails would be probably more effective. but i think you have to count with multiple devices not just your hardrive. something like: ~/.thumnails/[UUID1]/large or small thumnails ~/.thumnails/[UUID2]/large or small thumnails ~/.thumnails/[UUID4]/large or small thumnails ~/.thumnails/[UUID8]/large or small thumnails
this issue is still present in 2016. could you please advice me on where to read the code? i did not find it in xfce4-session or xfce4-panel
The description of this bug matches a bug I've been experiencing, so I'm assuming it's the same issue. In my case, after sending a file to the recycle bin with thunar, my hard disk light goes on and stays on for a long time (tens of minutes). Checking what's going on with 'lsof', it seems that tumblerd is reading through the files in the ~/.thumbnails/normal directory in sequence. I haven't emptied the thumbnails folder since 2013, and there's 4.7G of thumbnails in the folder, which explains why tumblerd takes a long time to go through them all. I will probably empty the thumbnails folder. Anyway, this seems like a bug that needs fixing, since it's quite resource expensive to read through all the files in the thumbnails folder every time a file is deleted, and it could consume a lot of battery life on laptops or portable devices. -------- Details about my system: Debian 8 (stable) tumbler version: 0.1.30-1+b1 (according to 'apt-cache show tumbler') Steps to reproduce: 1. open thunar 2. right click a file in the home directory (as an example), click 'move to wastebasket' 3. observe these effects: * the hard disk light coming on and staying on * iotop reports that tumblerd is reading data * lsof reports that tumblerd is reading files from ~/.thumbnails/normal
Sorry, I forgot to add this information: in my tests, it seemed like the problem only happened when I used the 'send file to wastebasket' option in thunar. Using shift-delete didn't seem to cause it.
I made a thread on the XFCE forums here about this issue and was directed to this page as it seems to be a bug other people have had https://forum.xfce.org/viewtopic.php?pid=47423 I have the same issue, usually but not always when deleting files. Same as jlp says where it affects any file type, even files that aren't image/video files. Version 0.2.0, release 3.fc27 on Fedora 27
Created attachment 7638 Possible fix by handling correctly handling "0" value as since mtime for cleaning up thumbnails
Please try out the attached patch and report back.
Created attachment 7639 Possible fix by handling correctly handling "0" value as since mtime for cleaning up thumbnails
Created attachment 7640 Possible fix by handling correctly handling "0" value as since mtime for cleaning up thumbnails
Ali Abdallah referenced this bugreport in commit a6ebd22f789b3b49aa0eac2fad8a71e300eb13bf Handle 0 mtime threshold on Cleanup DBus method. https://git.xfce.org/xfce/tumbler/commit?id=a6ebd22f789b3b49aa0eac2fad8a71e300eb13bf
Ali Abdallah referenced this bugreport in commit e16646f2583333e4bcd49cbce95c3f7205f4cd8b Handle 0 mtime threshold on Cleanup DBus method. https://git.xfce.org/xfce/tumbler/commit?id=e16646f2583333e4bcd49cbce95c3f7205f4cd8b
This bug has been fixes in the old maintained 0.1.33 branch and the new 0.2.1 one as well.