When opening a folder which contains a lot of images / videos then tumblerd will use A LOT of CPU usage and the used RAM increase but won't decrease after time. It will use more and more RAM over time. Also, when downloading e.g. a video while having the download folder open in thunar will increase the RAM usage of tumblered up to 6GB within 15 minutes. The CPU is at very high usage at the same time as well. Thanks :)
I've just had the same issue (second part of it) on my Xubuntu 18.04 with Thunar 1.6.15 and tumbler 0.2.1 I was downloading three 450MB MP4 video files and I had a 'Downloads' folder opened. This caused tumblerd process to take 4,4GB of RAM and 28-40% CPU usage. I know that this is an old bug, unfortunately. Here are some other similar bug reports: 2012: https://bugzilla.xfce.org/show_bug.cgi?id=8377 2017: https://bugzilla.xfce.org/show_bug.cgi?id=13350 And there are many threads on various Linux forums about this issue.
I have more info about this issue, if someone tries to reproduce it. This issue wasn't occurring when I was downloading the same files with Firefox, because Firefox creates 0 bytes MP4 file and a PART file where the data is actually downloaded, so the tumblerd process wasn't working on anything (since the actual media file was empty and stayed that way until the download finished). So all was OK. But when I was using uGet program (which I normally use for larger files) the issue occurred almost instantly. That's probably because uGet creates MP4 file of the file's original size (let's say 500MB) and a second temporary ARIA2 file (about 130 bytes). So it constantly makes changes to the MP4 file filling it with other / new data.
This seems to be specific for some MP4 headers. Could you post a link of a MP4 that caused the problem for you so I can test on my system?
Sure, I was downloading (using uGet) MP4 files from this list: https://archive.org/download/diggnation So for example: https://archive.org/download/diggnation/diggnation--0083--2007-02-01--large.h264.mp4 https://archive.org/download/diggnation/diggnation--0097--2007-05-10--large.h264.mp4 https://archive.org/download/diggnation/diggnation--0159--2008-07-18maubrowncow--hd720p30.h264.mp4
@Spass Thanks! Actually gstreamer and ffmpeg thumbnailers have problems with sparse video files. It is not Tumbler's fault, but anyway probably I need to add some logic to detect sparse files and skip them, otherwise gst pipeline or ffmpeg backends cause high CPU and memory usage. Will keep you informed.
Created attachment 7941 Heuristic to try to skip sparse files Could you please try out this patch, best would be if you can delete (move temperately) your ~/.cache/thumbnails and regenerate thumbnails for your media, making sure tumbler does not skip valid videos/images+test video download
Sorry Ali, but this is my first ever attempt to try a patch and I failed. Not sure how can I do it properly. What I did was: git clone git://git.xfce.org/xfce/tumbler cd tumbler curl https://bugzilla.xfce.org/attachment.cgi?id=7941 | git apply ./autogen.sh make pkill -i tumbler pkill -i thunar tumblerd/tumblerd And the process is visible in the task manager, but when I start Thunar it gets killed and the "/usr/lib/x86_64-linux-gnu/tumbler-1/tumblerd" is opened instead.
Unless you have some strange setup, the procedure that you are describing is correct, and you should end up being using the compiled local one. Which version are you running? Be aware, that after some time of no activity, tumblerd will shut down to save memory. If you launch later Thunar it gets activated from /usr/lib/x86_64-linux-gnu/tumbler-1/tumblerd
My setup isn't strange, I think, but I'm probably doing something wrong. Tried again on my Xubuntu 18.04 and 18.10 in VM (both with tumbler 0.2.1), with the same result. When I run the last command tumblerd/tumblerd I get this (maybe it's related): (tumblerd:25090): tumbler-WARNING **: 12:54:28.701: Failed to load the cache plugin "tumbler-cache-plugin.so": /usr/local/lib/tumbler-1/plugins/cache/tumbler-cache-plugin.so: cannot open shared object file: No such file or directory Additionally, when I don't restart Thunar, the tumblerd (compiled) process isn't killed, but Thunar just doesn't use it. Checked it on some image files and no thumbnails were created at all. But when I close and open Thunar again, the tumblerd (compiled) process gets killed immediately and the new one (system one) is created. Sorry for not being helpful here, but I've tried.
Ok, try to compile with ./autogen.sh --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu/
That worked great. Now the process doesn't get killed and it works fine. Thumbnails are created (tested on some images and small MP4 file) and the CPU usage during downloading is very low (0-2%). So the patch is working fine on my end. Since uGet is creating a temporary file *.aria2 (and that extension is for fonts?) I get this error spilled in the terminal while downloading when I have Thunar opened on that folder: Could not load face 'file:///home/spass/Pobrane/diggnation--0159--2008-07-18maubrowncow--hd720p30.h264.mp4.aria2': Unable to read the font face file 'file:///home/spass/Pobrane/diggnation--0159--2008-07-18maubrowncow--hd720p30.h264.mp4.aria2' But that's not a problem with tumbler. Just a side note. Not sure why uGet chose that extension for a temporary file. Thanks for the patch and for helping me with testing it, really appreciate it.
Did you test until your download was completed?
Yes. When the download was completed, the MP4 file got a thumbnail (maybe I pressed F5 to force it, I don't remember). I changed the folder to something else and the tumblerd process ended after some inactivity time. Should I test more?
No that's okay for the moment. Thanks you for testing. I'll include the fix in the next release.
*** Bug 13350 has been marked as a duplicate of this bug. ***
*** Bug 10904 has been marked as a duplicate of this bug. ***
Ali Abdallah referenced this bugreport in commit 39e1e26a3907bd223f60554a14eb0f5ce93703ff Added stat check to try to skip sparse files. https://git.xfce.org/xfce/tumbler/commit?id=39e1e26a3907bd223f60554a14eb0f5ce93703ff
*** Bug 9954 has been marked as a duplicate of this bug. ***