[emveepee]

Users have been reporting issues when folders of recordings have been deleted and I was able to duplicate it when I have lots of recordings and found the crash was on one lock not being set in Kodi.  Deletes are async so it is a bit hard for me to trace.  I do see in pvr-nextpvr after each delete there is a PVR->TriggerRecordingUpdate().  Is this necessary?  Perhaps Kodi is already taking care of removing recording file items and that code is just introducing extra overhead and chances for collision.

Thanks.

Martin

[djp952]

For what it's worth I don't call the trigger on delete, Kodi takes care of it. No reported issues with deleting folders. I just delete from the back end and report success/fail.

I try to call the triggers as infrequently as possible, and ultimately stopped calling the EPG one entirely due to similar problems. That was on Krypton, though

[emveepee]

Thanks Michael,

That probably is the problem.  For now I will test to see what happens.

Martin

[emveepee]

So I tested DeleteRecordings without doing the trigger afterward and it did remove the recording from the file list.  Going by your statement I tried to do the same thing on DeleteTimer and it definitely requires me to update the trigger. There are many GUI issues (timer is still in the list, the red circle stays on the items, "Currently Recording" box stays open).  Other triggers require a uid from the backend so they can't be removed. 

That made me think of another test and I tried to delete a folder containing an an in progress recording. That did not work well. It has the same screen issues as deleting an in progress recording partly because the timer is deleted but there is no second call to delete the recording.  That is probably a good thing, but all indications were that the file is still recording so that case needs a trigger too.

Worth a shot though

Martin

[djp952]

So I tested DeleteRecordings without doing the trigger afterward and it did remove the recording from the file list.  Going by your statement I tried to do the same thing on DeleteTimer and it definitely requires me to update the trigger. There are many GUI issues (timer is still in the list, the red circle stays on the items, "Currently Recording" box stays open).  Other triggers require a uid from the backend so they can't be removed. 

That made me think of another test and I tried to delete a folder containing an an in progress recording. That did not work well. It has the same screen issues as deleting an in progress recording partly because the timer is deleted but there is no second call to delete the recording.  That is probably a good thing, but all indications were that the file is still recording so that case needs a trigger too.

Worth a shot though

Martin

Never tried deleting a folder with an in-progress recording, I'll check that out later - thank you!  Better to know what the behavior will be before a user runs into it.  'preciated!

I do trigger timer changes in response to PVR API requests, but I never put much thought into that since my backend is a bit weird to work with, changing a timer/timer rule can have an entire cascade of consequences that Kodi would have no way to know about

Glad I'm keeping up the good work with feeding you useless information … my plan is working perfectly! mwahaha.  (kidding of course)

[emveepee]

I thought I had a partial solution to this by returning PVR_ERROR_RECORDING_RUNNING  but that is for timers and just gives a generic error to the user telling them to look in the logs.

Martin