Note that UNIX POCRay-3.6/3.6.1 is flawed in that it does not return non-zero exit codes in failure. You need this patch for POVRay before using RendView with POVRay-3.6/3.6.1.
It is currently unknown if newer versions of POVRay work as expected or not!

Unfortunately, there are bugs in RendView.
I say that because it is very unlikely that a piece of software with that size (>1Mb source code) has no bug. In fact, I find bugs frequently when confronting RendView with special situations.
But, do not understand me wrong: I have been rendering hundreds of frames in network, killed clients while operating, doing stop and cont etc. without a single problem, so this is not a piece of buggy junk.
However, RendView contains several highly non-trivial event-driven state machines which are somewhat prone to illegal states and race conditions. (Remember: "Threads are for people who don't like state machines.")
What makes things complicated is the fact that errors can happen just about everywhere and they all want to get dealt with gracefully. Needless to say that I simply cannot test them all.

Bugs include (in order of decreasing severity):

• Segmentation fault / SIGSEGV. This is the most critical one.
  Tracking down and fixing such a bug is of highest priority.
  
• Failed assertions. Also severe; it means that a bug was caught in one of the many bug traps placed all over the source code. They look like that:
    rendview: dif_ldr.cpp:1234: int foo(): Assertion `bar' failed.
  The message above describes a bug in RendView.
  Please submit a full bug report.
Sometimes, these failures are just due to too strict assertions but they are all bugs which need to get properly fixed by me.
• Memory leaks: RendView uses more and more RAM (very unlileky) or fails to clean up all allocated memory in which case, it will tell you so: If the last line of RendView output is not something like
    rendview: Alloc: 0 bytes in 0 chunks; Peak: 16040 by,211 chks; (253/0/253)
but rather
    rendview: *** Alloc: 12 bytes in 1 chunks; Peak: 16040 by,211 chks; (253/0/252) ***
  rendview: YOU PROBABLY FOUND A MEMORY LEAK IN rendview.
  rendview: PLEASE FIND OUT HOW TO REPRODUCE IT AND REPORT THIS BUG TO THE AUTHOR
then you found a mem leak.
• Misbehaviour. RendView does not what it should do: Hangs during operation, takes too long breaks, spins idly around (busy-looping), ...
  (Watch out for "OOPS: TaskManager scheduler strangely busy.")
• Minor issues. Missing warnings, typos in output, ...

...then do not say "Ah, it crashed two times, it's just a piece of junk", flame the author and rm -rf it.
Instead, remember that writing such a program is not easy, very time-consuming and that I do it in my free time. Therefore, report the bug so that it can be fixed.

Say you have found a bug in a recent version of RendView.
First, figure out how to reproduce it. Fixing a bug which cannot be reproduced if very hard if not impossible.
For bug reporting, please send a complete bug report (platform, version, comand line args and RENDVIEWARGS/ LDRCLIENTARGS/ LDRSERVERARGS environment variables as well as the output (best with -verbose=+all) together with description on how to reproduce it directly to the author.
Provide everything which is needed to reproduce the bug.

This is a list of missing features and known bugs. I know of no severe bugs so these are all non-critical bugs or missing features:

• Some protection against frames getting stuck in todo list (LDR)
  The issue is the following: Say, you want to render 100 frames using POVRay and then filter them using the filter "foobar" using LDR (i.e. in a LAN). In this case you must make sure that both the renderer and the filter are available on at least one client. (You can have 10 clients for rendering and one for rendering and filtering with foobar.) However, if no client can filter using foobar, after some time, a couple of tasks will be in the todo queue and prevent any more tasks from getting executed. The bug is subtle because of LDR re-connect, etc.
  Workaround: Take care not to provoke such a situation.
• Additional files with %d spec
  Allow frame number spec (%d) for additional files as well.
• Non-flat directory structure for LDR
  Only if people (or me) really need it in the future. (email me in this case.)
• rdir/fdir and frame pattern for LDR client
  Allow user to specify frame patterns (file name patterns) and different render/filter directories when using LDR. Currently, only the local task source (plain RendView, LDR server) allows that.
  Workaround: Who needs that anyway?
• Delay output file deletion
  Do not delete output files before actually re-rendering/filtering them. (Currently they are deleted by the task source when creating the task. Effect: in case you interrupt RendView, some more files than necessary were deleted.) Will be fixed soon. Currently no plan to fix that because deleting dest files just before assigning frames to clients will only save few frames as most of them are queued on the client side -- and deleting them just before upload would introduce unneeded bug prone complexity (see -L-transfer and shared directory, failed frames, resume operation,...)
• Additional render/filter file
  Allow a file to be both, additional render and filter at the same time.
• Per-frame statistics / log file
  For batch operation in a render farm, it may be interesting to get a log file which has an entry for every frame processed. Currently, you can use the verbose output and store it in a file.
• Config file support
  Support for a config file which tells RendView about everything it has to do. The config file could be treated like the known Makefile (i.e. RendView reads it in automatically, just set a special option in RENDVIEWARGS env var).
• Information network port
  ...which you can telnet to and get info about done frames and terminate RendView. (Actually, not telnet but using challenge-response auth and proprietary protocol.) [currently being implemented]
• Saving Output
  Ability to dump output of render and filter programs to one file per frame. The file could be deleted when the job terminates successfully.
  Also, ability to do the same for the filter and have it read files instead of stdin/out.
  Workaround: Use shell script as renderer/filter. Please note the about shell scripts in the docu.
• stdin, stdout
  Support for filters which do not take input from stdin and write output to stdout.
  Workaround: Use shell script as filter. Please note the about shell scripts in the docu.