Cant add new images

Question

Cant add new images

Closed this issue 7 years ago · 10 comments

Hi
Raspberry Pi 3 running Jessie
Using the imagewall example

All is running fine but I'm getting the following error when adding a new image into the directory:

`
[image.c] [0x1be43c0/imagewall/3.jpg] looks like 1920x1080 RGB jpg
[image.c] [0x1bdbb60/imagewall/1.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bdc2e8/imagewall/2.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bda9f8/imagewall/3.jpg] looks like 1920x1080 RGB jpg
[image.c] [0x1bdd558/imagewall/1.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bdd668/imagewall/2.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bdb5e0/imagewall/3.jpg] looks like 1920x1080 RGB jpg
[image.c] [0x1bcf780/imagewall/1.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1be33e0/imagewall/2.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bcf890/imagewall/3.jpg] looks like 1920x1080 RGB jpg
[image.c] [0x1be3e18/imagewall/1.jpg] looks like 1200x900 RGB jpg

uptime 50s, cpu 9s+1s, rss 7932kb, 20 objs, 72'C
mem fps width height cpu flags name (alias)

215kb 21.8 1920 1080 1.2% R-S- '- imagewall (-)

[image.c] [0x1bdb2d0/imagewall/2.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bdbdf0/imagewall/3.jpg] looks like 1920x1080 RGB jpg
[image.c] [0x1be3110/imagewall/1.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bdc888/imagewall/2.jpg] looks like 1200x900 RGB jpg
[imagewall] update +4.jpg.filepart (write closed)
[imagewall] update -4.jpg.filepart (deleted)
[image.c] [0x1be4270/imagewall/3.jpg] looks like 1920x1080 RGB jpg
[image.c] [0x1bdc3f8/imagewall/1.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1be37e0/imagewall/2.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bdaff8/imagewall/3.jpg] looks like 1920x1080 RGB jpg
[image.c] [0x1bdbf00/imagewall/1.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bdd408/imagewall/2.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1be43c0/imagewall/3.jpg] looks like 1920x1080 RGB jpg
[image.c] [0x1bdcfe0/imagewall/1.jpg] looks like 1200x900 RGB jpg

uptime 60s, cpu 11s+2s, rss 7932kb, 20 objs, 72'C
mem fps width height cpu flags name (alias)

222kb 21.8 1920 1080 1.4% R-S- '- imagewall (-)

[image.c] [0x1bdc2e8/imagewall/2.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bdd558/imagewall/3.jpg] looks like 1920x1080 RGB jpg
[image.c] [0x1bda9f8/imagewall/1.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bdd0f0/imagewall/2.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bdb5e0/imagewall/3.jpg] looks like 1920x1080 RGB jpg
[image.c] [0x1bcf780/imagewall/1.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1be33e0/imagewall/2.jpg] looks like 1200x900 RGB jpg
[image.c] [0x1bcf890/imagewall/3.jpg] looks like 1920x1080 RGB jpg
[main.c] terminating (escape pressed)...
[main.c] That's all. Have a nice day
`

If i stop and then restart the script 4.jpg is then displayed correctly.

Any tips on adding images without having to stop and restart the script..?

Answer 1 · 2017-08-24T17:44:42.000Z

Can you put a line pp(files) before line 24? This function (and therefore the pp call) should happen regularly once the columns need a new image. You should see the 4.jpg here. Also I'd highly recommend to use smaller images (400x300 max), so they close to the resolution that is use to display them. A higher resolution might result in a sluggish result.

Answer 2 · 2017-08-24T21:23:17.000Z

Thank you for your speedy response.

I've tried what you suggested above but i'm afraid still the same problem:

local pictures = util.generator(function() local files = {} for name, _ in pairs(CONTENTS) do if name:match(".*jpg") or name:match(".*png") then pp(files) files[#files+1] = name end end return alphanumsort(files) -- sort files by filename end)

Terminal output:

`[image.c] [0xedb9f8/imagewall/2.jpg] looks like 300x400 RGB jpg
[image.c] [0xee3838/imagewall/3.jpg] looks like 400x300 RGB jpg
[imagewall] {}
[imagewall] { "3.jpg" }
[imagewall] { "3.jpg", "2.jpg" }
[image.c] [0xee3568/imagewall/1.jpg] looks like 300x400 RGB jpg
[image.c] [0xecf780/imagewall/2.jpg] looks like 300x400 RGB jpg
[imagewall] update +4.jpg.filepart (write closed)
[imagewall] update -4.jpg.filepart (deleted)
[image.c] [0xeda9e0/imagewall/3.jpg] looks like 400x300 RGB jpg
[imagewall] {}
[imagewall] { "3.jpg" }
[imagewall] { "3.jpg", "2.jpg" }
[image.c] [0xedbfa0/imagewall/1.jpg] looks like 300x400 RGB jpg
[image.c] [0xedbcc8/imagewall/2.jpg] looks like 300x400 RGB jpg
[image.c] [0xedb168/imagewall/3.jpg] looks like 400x300 RGB jpg
[imagewall] {}
[imagewall] { "3.jpg" }
[imagewall] { "3.jpg", "2.jpg" }
[image.c] [0xee3988/imagewall/1.jpg] looks like 300x400 RGB jpg
[image.c] [0xee2cb8/imagewall/2.jpg] looks like 300x400 RGB jpg
[image.c] [0xee3e18/imagewall/3.jpg] looks like 400x300 RGB jpg
[imagewall] {}
[imagewall] { "3.jpg" }
[imagewall] { "3.jpg", "2.jpg" }
[image.c] [0xedc410/imagewall/1.jpg] looks like 300x400 RGB jpg

uptime 30s, cpu 2s+0s, rss 15020kb, 20 objs, 67'C
mem fps width height cpu flags name (alias)

266kb 60.0 1920 1080 2.9% R-S- '- imagewall (-)

`

It wont load and display 4.jpg unless the script is stopped and restarted.

Answer 3 · 2017-08-25T06:22:54.000Z

[imagewall] update +4.jpg.filepart (write closed)
[imagewall] update -4.jpg.filepart (deleted)

It's odd that this is the only log output related to the 4.jpg file. And those don't touch 4.jpg at all. Instead it's 4.jpg.filepart. What kind of program are you using to put 4.jpg into the imagewall directory. There should be a message like

[imagewall] update +4.jpg (moved in symlink/file)

as it looks like your program is doing the following steps:

copy 4.jpg as 4.jpg.filepart to imagewall directory.
Once done, rename 4.jpg.filepart to 4.jpg.

For some reason info-beamer doesn't seem to pick up the last step. What filesystem is the imagewall directory on? Can you paste the complete output of running info-beamer with the INFOBEAMER_LOG_LEVEL=3 environment variable set?

Answer 4 · 2017-08-25T09:04:24.000Z

Im new (ish) to Raspberry and Linux.

I was looking for something I could use to display a slideshow of Photos that would easily allow images to be added and removed on the fly. Eventually this will be done via local webserver running on the RPI and a http form to upload and manage the images.

At the moment, on my PC, im just using WinSCP to simply drag the images across to the main imagewall folder on the Raspberry to see if it would do what I needed. I will experiment more over the weekend to see if other methods of getting the images in the folder resolve the problem and then report back.

Answer 5 · 2017-08-29T13:22:51.000Z

Resolved:
Its WinSCP and the way it moves and renames files.
Moving or renaming images with a terminal window works fine as does http/php uploads.
Thank you for your prompt replies.

Answer 6 · 2017-08-29T16:47:43.000Z

That still sounds like a bug in info-beamer. If the 4.jpg file is in the node directory and info-beamer didn't detect this, something is wrong. I'll look into that. Might take a couple of weeks though.

Answer 7 · 2017-08-29T16:55:27.000Z

yep.. something doesn't seem quite right.

after the initial messages:

[imagewall] update +4.jpg.filepart (write closed)
[imagewall] update -4.jpg.filepart (deleted)

Info-Beamer will continue to ignore the file unless it is restarted.. then all is fine.

Answer 8 · 2017-08-29T17:05:33.000Z

I'm probably missing some inotify event. As of now I'm watching IN_CLOSE_WRITE|IN_CREATE|IN_DELETE|IN_MOVE. Looking at the manpage again, I'm not sure how winscp managed to work around those. I'll look into that.

Answer 9 · 2017-09-20T09:51:39.000Z

I'm managed to find out what happens and how to work around this issue. I don't have a proper fix at the moment:

The reason is that WinSCP by default uses the following pattern to upload files: It first uploads the file to
'target.filepart' then issues the following commands:

rm -f target; ln target.filepart target; rm target.filepart

It is basically a move, except done with hardlinks. info-beamers file detection runs into a race condition: It receives a IN_CREATE inotify event for 'target'. Since raw IN_CREATE events shouldn't directly result in a content_update event (as the file was just created and is most likely not yet filled with the full content), it then stat's the file to see its link count.

If the IN_CREATE event is handled before the rm command is done, the link count would be 2 which would correctly indicate that this IN_CREATE results from a hardlink "copy" and the file is most likely usable. So a content_update event is delivered to Lua. Unfortunately the stat usually happens after the rm already removed the 'target.filepart' file. As a result, the link count of 'target' is 1 and info-beamer won't send an content_update event. The result is that the newly copied file is missed by info-beamer.

I'm not sure how to solve this. The inotify API doesn't seem to provide the tools required to correctly detect this case. Of course I'm open for suggestions.

Meanwhile you can work around this issue by not using the above pattern and reconfiguring WinSCP like this:

Options > Preference > Transfer/Endurance 

  Enable transfer resume/transfer to temporary filename
  (x) Disable

Answer 10 · 2017-09-25T15:19:23.000Z

The work around you suggest works for me, so thank you for your assistance.

uptime 50s, cpu 9s+1s, rss 7932kb, 20 objs, 72'C mem fps width height cpu flags name (alias)