LanManFS problems

I have noticed a few problems while using LanManFS on my PI 3:

- While playing MP3 of FLAC files, attempts to for example open a file or folder from a LanManFS filer window gives a “LanManFS in use” error and LanManFS stops working. I guess that it is related do the fact that the MP3/FLAC files are read in the background from callbacks.

- At some time in the past I transferred on an USB disk files and folders containing hardspaces using a PC and Samba. Now this disk is connected to my router. The PC sees these files and folder normally but with LanManFS they are displayed as "Â ".

- When I try to open a file or folder located in a folder whose name includes a “/” (or should I say a “.” on the PC side) I get a “file not found” error.

Also, seems like the very useful fixes Colin made for the not-displayed files & folder in the Omni Puzzle topic have not made it in the CVS yet.

I found another way to get “LanManFS in use” errors, playing DVD VOB files with !KinoAmp in full screen mode (no multitasking, so no other applications are involved). After playing between 5 to 15 mins KinoAmp suddenly freezes for good. Sometimes I can’t do nothing and have to reboot, sometimes I can kill KinoAmp and return to the desktop but trying to open a file or folder from a LanManFS filer window gives a “LanManFS in use” error.

A great fix is in CVS waiting for release, is there anything that needs “kicking”?
(too many files bug)

All the ROM downloads look like they’re up to date to me. The changes went into CVS on the 14th, and the ROMs are dated the 15th.

A great fix is in CVS waiting for release, is there anything that needs “kicking”?
(too many files bug)

That should be in the ROM built and on the download page now. Probably doesn’t address the issue of opening files like this though. Similar lockups can be generated doing operations on files inside an archive (zip or Spark) across the network.

Some interesting point, this time I got a post mortem in my KinoAmp log:

Internal error: abort on data transfer at &FC17CC78

Postmortem requested
Arg3: 0×00020000 131072 → [0xe1a00004 0xebfffb12 0xea000022 0xe3100008]
Arg2: 0×001357f4 1267700 → [0×96db4689 0xd48cd038 0xaa3291db 0xd2a23951]
Arg1: 0×00063404 406532 → [0×4d6e614c 0×3a3a6e61 0×65746e49 0×2e6f736e]
163e8 in function ka_input_read
Arg1: 0×000653ac 414636 → [0×00063404 0×00065380 0×001757fc 0×80000112]
17a20 in function ka_stream_process
Arg1: 0×0004de80 319104 → [0xf7f00000 0×001aa2a8 0×00231a80 0×00246480]
21d50 in function decode
Arg1: 0×0004de80 319104 → [0xf7f00000 0×001aa2a8 0×00231a80 0×00246480]
21fe4 in function null_event
Arg2: 0×00049f00 302848 → [0×00049f20 0×00049f2a 0×00049f40 0×00049f9a]
Arg1: 0×00000004 4
226d0 in function main
Arg2: 0×0002211c 139548 → [0xe1a0c00d 0xe92ddbf3 0xe24cb004 0xe24dce43]
Arg1: 0×000499a4 301476 → [0×6f6e694b 0×6e694b3a 0×662d206f 0×6f6e694b]
fc17458c in shared library function
367b0 in anonymous function

• unrecoverable error in run time system: free failed, (heap overwritten)

*where FC17CC78
Address &FC17CC78 is at offset &0000C6D4 in module ‘SharedCLibrary’

ka_input_read just calls SWI OS_GBPB to read some data from the input file. The pointer of the buffer is Arg2 and its length Arg3 (clearly in application space).
Seeing that so far it happened only to LanManFS I suspect that LanManFS itselfs corrupts its own memory during the read operation (writing past the limit of an internal buffer?).

One curious behaviour I have noticed while copying large files from LanManFS is that the mouse pointer tends to jump by about 100 pixels up and slightly to the left every 4 or 5 seconds.

One curious behaviour I have noticed while copying large files from LanManFS is that the mouse pointer tends to jump by about 100 pixels up and slightly to the left every 4 or 5 seconds.

It seems that this behaviour is not specific to LanManFS, the mouse also moves by itself from time to time when I use ShareFS. I wonder if this slightly annoying behaviour is specific to the PI3?

I don’t know whether this is the same slightly annoying behaviour or a different one: on my Pi B2 very occasionally the pointer drifts slowly left (or more rarely, slowly upwards, or more rarely still, both at once). Move the mouse itself a fraction and the pointer drift usually stops. It’s rare enough and slow enough to be more an interesting quirk than an annoyance.

I thought at first it was the actual mouse moving due to imperceptible vibrations of the desk, or mechanical elasticity of the mouse cable or something, but deliberately letting it continue shows it’s not: the pointer can drift from the right hand side of a 4K screen to the left hand side, given time (several minutes!), which would definitely be a visible movement if it was physical movement of the mouse!

I don’t think it’s the mouse itself generating nonsense: I’ve used the same mouse on the Mac, without seeing the effect. But that might be just that I didn’t have the patience to use it for long enough.

I have one model of PS/2 mouse when connected to a RiscPC via PS2MouseMine it about once every two to four hours will jump up and left by about 200 pixels in both axis. Other mice on the same PS2MM/RPC do not have the same effect. Andre: have you tried a different model of mouse?

The mouse I’m using is a native USB mouse.

When I get a round tuit, I intend to convert one of my Marconi Trackerballs to USB. I love Trackerballs. It’s the one thing I really miss from RiscPC days.

The mouse I’m using is a native USB mouse.

I had realised that, but wondered if some sort of incompatibility with a USB mouse might have similar symptoms to the PS/2 mouse problem I’ve experienced.