<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 30 Mar 2020 at 21:56, Bill Meek <<a href="mailto:keemllib@gmail.com">keemllib@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/30/20 2:15 PM, Klaas de Waal wrote:<br>
> As I understand it mythfrontend communicates with mythbackend with the<br>
> so-called mythprotocol, while the ServicesAPI is implemented as a HTTP<br>
> webserver on the same mythbackend. This suggests that the frontend, via the<br>
> mythprotocol, does something different than the ServicesAPI.<br>
> This definitely needs some thinking, it might even be necessary to<br>
> understand what the code is actually doing.... which is usually not need to<br>
> fix crashes. Just find the null pointer....<br>
<br>
The DeleteRecording endpoint: <a href="https://code.mythtv.org/cgit/mythtv/tree/mythtv/programs/mythbackend/services/dvr.cpp#n315" rel="noreferrer" target="_blank">https://code.mythtv.org/cgit/mythtv/tree/mythtv/programs/mythbackend/services/dvr.cpp#n315</a><br>
<br>
may end up here: <a href="https://code.mythtv.org/cgit/mythtv/tree/mythtv/programs/mythbackend/mainserver.cpp#n1321" rel="noreferrer" target="_blank">https://code.mythtv.org/cgit/mythtv/tree/mythtv/programs/mythbackend/mainserver.cpp#n1321</a><br>
<br>
But there's another place in mainserver that handles the DELETE_RECORDING message. The other one's:<br>
<a href="https://code.mythtv.org/cgit/mythtv/tree/mythtv/programs/mythbackend/mainserver.cpp#n635" rel="noreferrer" target="_blank">https://code.mythtv.org/cgit/mythtv/tree/mythtv/programs/mythbackend/mainserver.cpp#n635</a><br>
<br>
Looks like mythprotocol to me.<br>
<br></blockquote><div>Thanks for the pointers!</div><div>From both places really soon the common code is called. I do not think the code itself is at fault.</div><div>I have not yet checked it but I guess that the MythProtocol and the MythSocket processing is done in different threads and that this does infuence the timing.</div><div>If I  add a 100ms delay at a critical place, or exit out of the loop once the recording is found (the patch in the ticket), then that does fix the crashing problem. Which is a strong indication of a locking/threading problem so that is the next spot to look.</div><div>I guess that if I hack the MythSocket so that the delete event sent back and processed via the MythProtocol (and on the thread of the MythProtocol) then it will crash.</div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Good news that it happens from the combined FE.<br>
<br>
When I tried the test, the 1st use of Dvr/DeleteRecording always worked and<br>
the next <n> always failed because the recording was successfully deleted.<br><br></blockquote><div>Yes this is how it works. I use a "vcr.py" command that makes only one recording which is then deleted This command is inside a bash "while [ 1 ] ; do_command; done" loop to run forever. And this three times for three channels, of one multiplex received by one tuner. This then runs forever. If I delete recordings-in-progress with the GUI then within a few tries the backend crashes.....</div><div><br></div><div>Thanks,</div><div>Klaas.</div><div> </div><div><br></div><div><br></div></div></div>