I have been pulling in YouTube feeds with this module and the Feed API module for quite some time and it has been working great. I happened to be migrating my files to another server today, and while backing up my sites directory, I noticed that there were thousands upon thousands of images created in the form of emvideo-youtube-lZ-s3DRZJKY_104.jpg for example just in the files directory. I had my Feed set to update often and update the content of the feed as well in my FeedAPI settings for that content type, but only had 37 videos total. I wouldn't have thought it would pull down a new image for the video each update, but that seems to be the case. So, I ended up with about a thousand images for each video that were the same image, but renamed. Either way, it doesn't seem like a great idea to put these thumbnailed emvideo- images in the root of the files directory.
There is a setting to "store remote thumbnails for this field" in the EMField field settings, which fixed the problem for me all together when I uncheck that setting. Perhaps it would be better to default that setting to unchecked. I could only imagine what this tandem of settings would do to an actual video site that sets up the same settings for Feed API. Ideally one would want to update their feed contents to the most updated version of the feed items, without causing massive file storage waste at the same time. I will be posting something in the Feed API issue queue also, as part of overall solution lies there as well. It's one of those issues... For now I think it would be best to set the store remote thumbnails locally to off by default.
Thanks,
Jason
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 894702-1.patch | 1.71 KB | gorbeia |
Comments
Comment #1
aaron commentedif you aren't using the embedded media thumbnail module, then that won't happen in the first place. not sure why it's creating multiple copies on update; i'll have to investigate whether that happens in all cases or just when used w/ feeds. you can also specify a folder in the configurations, so it's at least not in the root, fwiw.
Comment #2
aaron commentedComment #3
gorbeia commentedI can confirm the problem.
This happens because emthumb_emfield_field_extra function calls emthumb_fetch_remote_thumbnail function on every update. emthumb_fetch_remote_thumbnai calls file_create_filename and as there is already a file with that name it appends a number to the file name while the previous image never gets deleted.
Comment #4
gorbeia commentedWith attached patch the emthumb module replaces the thumbnail instead of creating another copy.