PrivatEye PgUP does PgDn

PrivatEye uses PgUp and PgDn keys to scroll backwards and forwards through a directory of photos, and AFAIK it is the only way to do this.
Unfortunately on my RPi3, PrivatEye interprets a PgUp keypress as a PgDn keypress, with the result that there is no way back.
This happens regardless of the version of PrivatEye and of the keyboard used. It happens when no other user apps are running.
Using KeyTest (1990 Kell Gatherer) shows that the keys are generating different values:
PgUP 415 (&19F) PgDn 414 (&19E)

The PgUp and PgDn keys work correctly in other applications, eg NetSurf, StrongED.

Can anybody throw any light on this connundrum?

PrivatEye interprets a PgUp keypress as a PgDn keypress

Further investigation shows that this happens when the directory of photos is on a USB pen drive. If the photos are on the SD card system disc PrivateEye behaves correctly.
The USB device is 16 GB FAT32 formatted.

Further investigation shows that this happens when the directory of photos is on a USB pen drive.

So it would appear to be connected with the order in which the (a particular) filing system reads the files. BTW, which FS is in use on the pen drive?

I have recently devised a program to prune my back-up files to leave the three most recent, named in reverse date notation.

However, I was obliged to bubblesort the filenames to ensure a true ASCII filename order to avoid difficulties such as this!

I also remember having to experiment with Fat32fs to find a “last” dummy filename which I could use to visually ensure that a back-up had completed successfully.

For this I used initially <underscore>z<underscore> until I realised that my “first” file, which was <hardspace>!Info<hardspace>, contrived to appear first in the SDFS filer window, but was, in fact, the last to be copied over by my back-up program to my Fat32fs-formatted hard drive(s)!

Hence, armed with this experience, the ASCII bubblesort in my “pruning” program!

This looks to be a similar “trap”.

However, I was obliged to bubblesort the filenames to ensure a true ASCII filename order to avoid difficulties such as this!

I think it is more fundamental than sort order. PgDn shows the photos in name order from low to high. So does PgUp.
Suppose I have four files: pic01, pic02, pic03, pic04.
Double-click on pic01, pic01 shows. Then press PgDn, pic02 shows. Then press PgUp and pic03 shows, not pic01 as expected.
Maybe there is something in the FAT32 interface that just presents the next file following any request?

Sounds a bit like the old problem of poorly written software misusing the value of R4 in the os_gbpb call.

https://www.riscosopen.org/forum/forums/11/topics/2995?page=2&posts_per_page=25#posts-37761

Sounds a bit like the old problem of poorly written software misusing the value of R4 in the os_gbpb call.

OK – like soup it gets thicker the more you cook it!

Ignore my observations!

….misusing the value of R4 in the os_gbpb call.
https://www.riscosopen.org/forum/forums/11/topics/2995?page=2&posts_per_page=25#posts-37761

Thanks for the link – it explains the scrolling behaviour, but I am not sure what is responsible for the misuse. Is that PrivatEye or the Filer?

I thought the answer might be to using Filecore instead of FAT32.
It fixes the scrolling problem but the performance hit is unacceptable. The FAT32 is 2 to 4 times faster depending on file size.

Thanks for the link – it explains the scrolling behaviour, but I am not sure what is responsible for the misuse. Is that PrivatEye or the Filer?

I would guess PrivateEye: it will be the thing that’s scanning for the “next” and “previous” files when you press Page Up and Page Down.

I would guess PrivateEye: it will be the thing that’s scanning for the “next” and “previous” files when you press Page Up and Page Down.

Well, that’s probably just additional weight after:

Sounds a bit like the old problem of poorly written software misusing the value of R4 in the os_gbpb call.

Stated by the author of FAT32FS, which will be feeding the info requested to PrivateEye.

The source of FAT32FS is available to check what it does, how about PrivateEye?

I thought the answer might be to using Filecore instead of FAT32. It fixes the scrolling problem but the performance hit is unacceptable. The FAT32 is 2 to 4 times faster depending on file size.

But does it make the keys work properly? Or is that what you meant by “the scrolling problem”.

I recall having had similar problems reading JPEGs from a ’phone via USB – unpredictable order, but with SwiftJPEG rather than PrivateEye.

ISTR that when reading files from a directory, if the sequence is important, the program should always sort them. Unsorted they may be in the expected order … but another time, or another FS, they may not. The strange direction of the keys may be just that the files have not been sorted.

ISTR that when reading files from a directory, if the sequence is important, the program should always sort them.

Ah, yes; I’d forgotten about your ArmSort module when I wrote my pruning program referred to above (third post in thread). I did my sorting the “hard” way in BASIC!

Fast enough for this simple application, though!

The source of FAT32FS is available to check what it does, how about PrivateEye?

It certainly is…

Having had a quick look, the definition for static void step() in display.c contains a fairly “classic” abuse of OS HeebieJeebie’s context pointer. In fact, I like the comment

      /* if we're moving backwards then skip back by *two* entries. */
      /* note the assumption that the context values returned by OS_GBPB are
       * indices */

which suggests that it was known that it might not always work… :-)

ETA: I’m fairly sure that we could submit a patch to Dave to fix the problem — it is Open Source code, after all. I don’t think it would actually be too difficult whilst retaining the current approach, but I won’t get chance to think about it until at least next week. If anyone else fancies trying it, with my current thinking you would need to scan through the whole folder with OS_GBPB and compare filenames as you go…

PS. I don’t think that step forward can be guaranteed to work correctly with the current code, either.

The strange direction of the keys may be just that the files have not been sorted.

In this particular case that the sort order is not relevant.

Test A: Make a new directory on a FAT32 formatted drive and put two jpegs in it. Name or rename the jpegs 1 and 2.
Drag and drop jpeg 1 on the PrivatEye icon on the iconbar. The image will appear in a window on the desktop.
Now press PgDn and the second image will appear in the window. Press PgDn again and nothing happens because PrivatEye has reached the end of the list of files.
Press PgUp. Nothing happens because there is a bug and PrivatEye is interpreting a PgUp request as if it were a PgDn request.

Test B: Drag and drop jpeg 2 onto the iconbar. Now PgDn and PgUp do nothing.

Test C: Drag and drop jpeg 1 onto the iconbar. Press PgUp. The next picture appears. Ie PgUp has been interpreted as PgDn. Now pressing either PgUp or PgDn will do nothing as PrivatEye is at the end of the list.

Incidentally SwiftJpeg will scroll back and forth but it is not directly comparable as it uses arrow keys instead of PgUp and PgDn, and it keeps a list of files in memory unlike PrivatEye which asks the filing system for each next or previous request.

with my current thinking you would need to scan through the whole folder with OS_GBPB and compare filenames as you go…

Would it not be simpler to enumerate all the files in a directory into a block of memory, sort the list, then step through the sorted list in memory for previous/next?

Would it not be simpler to enumerate all the files in a directory into a block of memory, sort the list, then step through the sorted list in memory for previous/next?

Yes, but that would require enough memory to hold all of the filenames, which currently isn’t needed. Given that you don’t know how many filenames need to be included, and that OS_GBPB can’t tell you how much memory you require before the names start arriving, it seems to have some issues when we’re talking about “previous image/next image” functionality.

As a user, I’d not expect to run out of memory just by pressing PageUp or PageDown… :-)

As Steve Fryatt points out the PrivateEye source is available and clearly shows that the bug is expected but when I got around to looking (as Steve was posting it seems) I found the source on GitHub. Without the talent to fix all I can do is look in curiosity

Incidentally SwiftJpeg will scroll back and forth but it is not directly comparable as it uses arrow keys instead of PgUp and PgDn, and it keeps a list of files in memory unlike PrivatEye which asks the filing system for each next or previous request.

I believe the key mapping is alterable “!PrivateEye.Resources.Keys” but the relevant difference is the list of files in memory vs. requests for next or previous file where the file system response may not match the expected response.
Obviously SwiftJPEG is pulling the list and holding an index (it may or may not sort the list in the memory array) so it always has a defined “next” or “previous”

but the relevant difference is the list of files in memory vs. requests for next or previous file where the file system response may not match the expected response.

The “list of files” strategy employed by SwiftJpeg has two problems:
memory allocation as mentioned above by Steve; and the fact that if you delete a file from the filer SwiftJpeg does not do a refresh and (gracefully) falls over. PrivatEye handles this situation well.

Yes, but that would require enough memory to hold all of the filenames,

That’s why I said “enumerate”. As in whizz through OS_HeeBeeGeeBee to work out how much memory is needed, then again to actually read in the names.

It isn’t foolproof, because:

and the fact that if you delete a file from the filer SwiftJpeg does not do a refresh and (gracefully) falls over.

It shouldn’t fall over, it should pop up some sort of message that the file cannot be loaded. One could, I suppose, sit on an Event or somesuch to see if anything has changed.

But to be honest, I wouldn’t bother. XP’s image previewer suffers from the exact same problem. It takes a snapshot of available image files and that’s what it’ll try and show – regardless of whether or not files have been added or deleted while the viewer is open.

The real problem here is that one cannot be assured of any specific behaviour from GBPB other than it’ll return whatever the underlying filesystem considers to be the next file in the directory…

As a user, I’d not expect to run out of memory just by pressing PageUp or PageDown… :-)

Certainly. And since my machine is (just about!) capable of running Otter, there’s really seriously no excuse to run out of memory just attempting to cache a list of files, even if there’s 2,983 of them (adding up to around 483MB). Well, that’s my current Manga cache directory (eeek!) and the filer displays them all (nicely sorted in various ways) without melting down.
https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Desktop/Filer/s/CacheDir?rev=4.4;content-type=text%2Fplain

FWIW, it’s amusing that the code still thinks “6” characters is the length of an average filename. Does this still hold true with long name support? [link]

and the fact that if you delete a file from the filer SwiftJpeg does not do a refresh and (gracefully) falls over.

It shouldn’t fall over, it should pop up some sort of message that the file cannot be loaded.

To be fair. It doesn’t really fall over. It puts up a message then closes its viewer window; with the result that you have to find where in the directory you had got to, and start again.

I’ve put a plausible looking fix into this test build: http://www.davespace.co.uk/software/privateeye301.zip. Please give it a try.

Did anyone try it?

Did anyone try it?

On a Fat32 drive I did reproduce the issue with PrivateEye 3.00, PageUp and PageDown initially work but get stuck at one end of the directory. 3.01 looks good to me.

OK, thanks, I can make 3.01 an official release.

PrivateEye V3.01 gets rid of the PageUp/PageDn issue of reading a flash stick where PageUp reads the next image in the list instead of the previous. Another real bugbear where a displayed image when deleted appears to freeze the program has been cured. I’ve not seen anything announced on c.s.a. but I may have missed it.

Excellent work David.