On Sat, 19 May 2018 09:39:50 +0100, RobH  declaimed the
following:


>
>Presently the NASname = os.path.join("/mnt/CCTV/PiZero" , fname)
>
>After running the script and a picture shows up on the monitor, it does
>not get saved to the /CCTV/PiZero directory, nor on my NAS box.

 "/CCTV/PiZero" is not the same directory as "/mnt/CCTV/PiZero"

 With the script as I provided it, the first place the video file should
appear is that "shared memory" RAM; it should then be copied (the shutil
line) to "/mnt/CCTV/PiZero"

 It will only appear on the NAS box if you've managed a successful
"mount ..." command.

 Put a # in front of the  os.unlink()  line; that will keep it
from deleting the RAM copy.

 ~15 seconds after you see a preview, execute (at the console prompt --
you may want to open a second console connection so the script can run in
one console while you explore using the second):  ls /run/shm
{Hmmm, Debian Stretch in a virtual instance is using  /dev/shm rather
than  /run/shm -- I shouldn't spend the time but I'm going to dig out
my RPi to check.

wulfraed@stretch:~$ df
Filesystem      1K-blocks      Used  Available Use% Mounted on
udev              1015088         0    1015088   0% /dev
tmpfs              205264     11224     194040   6% /run
/dev/sda1        31210380  13389136   16212796  46% /
tmpfs             1026320         0    1026320   0% /dev/shm
tmpfs                5120         4       5116   1% /run/lock
tmpfs             1026320         0    1026320   0% /sys/fs/cgroup
VB_Shared      1952096584 457233388 1494863196  24% /media/sf_VB_Shared
tmpfs              205264         4     205260   1% /run/user/111
tmpfs              205264        20     205244   1% /run/user/1000
wulfraed@stretch:~$ uname -a
Linux stretch 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19)
x86_64 GNU/Linux

pi@raspberrypi:~$ df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/root       13064524 6465240   5912592  53% /
devtmpfs          468088       0    468088   0% /dev
tmpfs             472696       0    472696   0% /dev/shm
tmpfs             472696   12244    460452   3% /run
tmpfs               5120       4      5116   1% /run/lock
tmpfs             472696       0    472696   0% /sys/fs/cgroup
/dev/mmcblk0p6     66528   22137     44392  34% /boot
tmpfs              94536       0     94536   0% /run/user/1000
/dev/mmcblk0p5     30701     398     28010   2% /media/pi/SETTINGS
pi@raspberrypi:~$ uname -a
Linux raspberrypi 4.14.34-v7+ #1110 SMP Mon Apr 16 15:18:51 BST 2018 armv7l
GNU/Linux
pi@raspberrypi:~$

debian@beaglebone:~$ df
Filesystem     1K-blocks    Used Available Use% Mounted on
udev              219512       0    219512   0% /dev
tmpfs              49576    5164     44412  11% /run
/dev/mmcblk1p1   3704040 2893736    602432  83% /
tmpfs             247876       0    247876   0% /dev/shm
tmpfs               5120       4      5116   1% /run/lock
tmpfs             247876       0    247876   0% /sys/fs/cgroup
tmpfs              49572       4     49568   1% /run/user/1000
debian@beaglebone:~$ uname -a
Linux beaglebone 4.9.78-ti-r94 #1 SMP PREEMPT Fri Jan 26 21:26:24 UTC 2018
armv7l GNU/Linux
debian@beaglebone:~$


 Okay -- Debian Stretch 64-bit in VirtualBox (on Windows), RPi-3
"Raspbian", and Beaglebone Black Debian are ALL using /dev/shm

root@ElusiveUnicorn:~# df
Filesystem      1K-blocks       Used  Available Use% Mounted on
rootfs         1952096584  458150456 1493946128  24% /
root           1952096584  458150456 1493946128  24% /root
home           1952096584  458150456 1493946128  24% /home
data           1952096584  458150456 1493946128  24% /data
cache          1952096584  458150456 1493946128  24% /cache
mnt            1952096584  458150456 1493946128  24% /mnt
none           1952096584  458150456 1493946128  24% /dev
none           1952096584  458150456 1493946128  24% /run
none           1952096584  458150456 1493946128  24% /run/lock
none           1952096584  458150456 1493946128  24% /run/shm
none           1952096584  458150456 1493946128  24% /run/user
C:             1952096584  458150456 1493946128  24% /mnt/c
D:             2930134012  993977732 1936156280  34% /mnt/d
E:             3906983932  252169040 3654814892   7% /mnt/e
Z:             5860519932 3360494188 2500025744  58% /mnt/z
root@ElusiveUnicorn:~# uname -a
Linux ElusiveUnicorn 4.4.0-17134-Microsoft #48-Microsoft Fri Apr 27
18:06:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
root@ElusiveUnicorn:~#

... but the "Ubuntu BASH shell on Windows" is using /run/shm (and not in
RAM either). I'm sure someone else on the thread suggested /run/shm; google
searches imply that /run/shm is the new standard name, but it appears
Debian hasn't changed from /dev/shm yet.

 On your RPi, execute: df  and look for either /run/shm or
/dev/shm

 If you find it is  /dev/shm change the line in the script from

    RAMname = os.path.join("/run/shm", fname)

to

    RAMname = os.path.join("/dev/shm", fname)

I'm surprised the script didn't dump a traceback on a non-exist ant path if
this is the case... Maybe the camera library is catching the error and just
silently not doing the capture.




--
 Wulfraed                 Dennis Lee Bieber         AF6VN
 wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

--- SoupGate-Win32 v1.05