@DJ, I have checked and this update solves the issue with pi camera. I have not tested it deeply (I will do it tomorrow), but it seems stable and with a good performance.

Thanks.

OK, I think I spoke too soon. When I thought I tested the new version yesterday, I was in fact still on the old one (2019.12.20): for a strange reason, when I remove the old version and extract the new one, if I don't close and reopen the terminal window where i launch ARC, it launches the old one...

Anyway, the new release don't solve the picamera issue: still no video stream. It also adds a new issue: when it launches for the fist time (after removing old "EZ-BuilderPi" and "EZ-Builder" folder), it opens without any error. But on the second launch, I have the following error:

Version: 2020.01.04.00

System.Net.WebException: The operation has timed out. at System.Net.HttpWebRequest.RunWithTimeoutWorker[T] (System.Threading.Tasks.Task1[TResult] workerTask, System.Int32 timeout, System.Action abort, System.Func1[TResult] aborted, System.Threading.CancellationTokenSource cts) [0x00118] in :0 at System.Net.HttpWebRequest.GetResponse () [0x00019] in :0 at EZ_Builder.Common.LatestUpdateVersion () [0x00035] in :0 at EZ_Builder.FormMain.ngsWg70XFR (System.Object , System.EventArgs ) [0x0031a] in :0 at System.Windows.Forms.Form.OnLoad (System.EventArgs e) [0x00022] in <0e1823914d7643eeaf1207febb083a4a>:0 at System.Windows.Forms.Form.OnLoadInternal (System.EventArgs e) [0x00029] in <0e1823914d7643eeaf1207febb083a4a>:0

I need to remove the "EZ-Builder" folder for ARC to launch again without error, but I have to do it every time...

I created a new build - try it. It's Pi 2020.01.05.00

@DJ, with this version, ARC freezes each time I try to connect to the picamera (whatever the server, EZBpi or Blueberry). Here is the content of the terminal of ARC when it happens:

double free or corruption (out)
Stacktrace:

  at  <0xffffffff>
  at (wrapper managed-to-native) System.Drawing.GDIPlus.GdipBitmapUnlockBits (intptr,System.Drawing.Imaging.BitmapData) <0x0003b>
  at System.Drawing.Bitmap.UnlockBits (System.Drawing.Imaging.BitmapData) [0x00000] in <0b937e1c0ddd4bf8a08584be511c9f4d>:0
  at (wrapper remoting-invoke-with-check) System.Drawing.Bitmap.UnlockBits (System.Drawing.Imaging.BitmapData) [0x00032] in <0b937e1c0ddd4bf8a08584be511c9f4d>:0
  at EZ_B.Camera.jloHrtvksW () [0x003ca] in <2fea5116ea814526830bcc071cb3f9ca>:0
  at System.Threading.ThreadHelper.ThreadStart_Context (object) [0x00017] in :0
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x0008d] in :0
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in :0
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object) [0x00031] in :0
  at System.Threading.ThreadHelper.ThreadStart () [0x0000b] in :0
  at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) [0x0004d] in :0
/proc/self/maps:
00010000-003d7000 r-xp 00000000 b3:02 53839      /usr/bin/mono-sgen
003e6000-003ea000 r--p 003c6000 b3:02 53839      /usr/bin/mono-sgen
003ea000-003ee000 rw-p 003ca000 b3:02 53839      /usr/bin/mono-sgen
003ee000-00474000 rw-p 00000000 00:00 0 
00c67000-056da000 rw-p 00000000 00:00 0          [heap]
a8fa2000-a9189000 rwxp 00000000 00:00 0 
a9300000-a9381000 rw-p 00000000 00:00 0 
a9381000-a9400000 ---p 00000000 00:00 0 
a942f000-a9800000 rw-p 00000000 00:00 0 
a9800000-a98ff000 rw-p 00000000 00:00 0 
a98ff000-a9900000 ---p 00000000 00:00 0 
a9900000-a9923000 rw-p 00000000 00:00 0 
a9923000-a9a00000 ---p 00000000 00:00 0 
a9a00000-a9aff000 rw-p 00000000 00:00 0 
a9aff000-a9b00000 ---p 00000000 00:00 0 
a9b00000-a9bff000 rw-p 00000000 00:00 0 
a9bff000-a9c00000 ---p 00000000 00:00 0 
a9c00000-a9cff000 rw-p 00000000 00:00 0 
a9cff000-a9d00000 ---p 00000000 00:00 0 
a9d00000-a9dff000 rw-p 00000000 00:00 0 
a9dff000-a9e00000 ---p 00000000 00:00 0 
a9e00000-a9eff000 rw-p 00000000 00:00 0 
a9eff000-a9f00000 ---p 00000000 00:00 0 
a9f00000-a9fff000 rw-p 00000000 00:00 0 
a9fff000-aa000000 ---p 00000000 00:00 0 
Memory around native instruction pointer (0xb6d6df24):
0xb6d6df14  00 20 a0 e3 08 30 a0 e3 af 70 a0 e3 00 00 00 ef  . ...0...p......
0xb6d6df24  04 21 9d e5 00 30 94 e5 0c 00 a0 e1 03 00 52 e1  .!...0........R.
0xb6d6df34  08 00 00 1a 43 df 8d e2 f0 80 bd e8 24 30 9f e5  ....C.......$0..
0xb6d6df44  00 20 60 e2 e8 ae ff eb 03 30 9f e7 00 c0 e0 e3  . `......0......

Native stacktrace:

Yeah... that's what i figured. The way mono handles the GDI and its memory pointer is not like Windows. The camera engine will have to be written to accommodate the issues with mono...