[mythtv-users] Help needed for scripted recordings

[Jonatan Lindblad]

Den 2020-03-30 kl. 23:52, skrev Klaas de Waal:> On Mon, 30 Mar 2020 at 21:56, Bill Meek <keemllib at gmail.com <mailto:keemllib at gmail.com>> wrote:
> 
>     On 3/30/20 2:15 PM, Klaas de Waal wrote:
>     > As I understand it mythfrontend communicates with mythbackend with the
>     > so-called mythprotocol, while the ServicesAPI is implemented as a HTTP
>     > webserver on the same mythbackend. This suggests that the frontend, via the
>     > mythprotocol, does something different than the ServicesAPI.
>     > This definitely needs some thinking, it might even be necessary to
>     > understand what the code is actually doing.... which is usually not need to
>     > fix crashes. Just find the null pointer....
> 
>     The DeleteRecording endpoint: https://code.mythtv.org/cgit/mythtv/tree/mythtv/programs/mythbackend/services/dvr.cpp#n315
> 
>     may end up here: https://code.mythtv.org/cgit/mythtv/tree/mythtv/programs/mythbackend/mainserver.cpp#n1321
> 
>     But there's another place in mainserver that handles the DELETE_RECORDING message. The other one's:
>     https://code.mythtv.org/cgit/mythtv/tree/mythtv/programs/mythbackend/mainserver.cpp#n635
> 
>     Looks like mythprotocol to me.
> 
> Thanks for the pointers!
> From both places really soon the common code is called. I do not think the code itself is at fault.
> 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.
> 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.
> 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.
>  
> 
>     Good news that it happens from the combined FE.
> 
>     When I tried the test, the 1st use of Dvr/DeleteRecording always worked and
>     the next <n> always failed because the recording was successfully deleted.
> 
> 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.....
> 
> Thanks,
> Klaas.

If it is that reproducible then I think running it under valgrind would show where the problem is, unless that affects the timing too much of course.

Cheers
Jonatan