Mailing List Archive: MythTV: Dev

delete_recording & the rerecord option

Index | Next | Previous | View Threaded

gnassas at mac

Apr 16, 2012, 8:24 PM

Post #1 of 4 (267 views)
Permalink

delete_recording & the rerecord option

Hi, I'm putting together the trivial patch to allow rerecording when deleting a recording using the http services api.

Problem is there are two handlers for DELETE_RECORDING: one in MainServer::ProcessRequestWork which recognizes the rerecord option, and one in MainServer::customEvent which does not. The services api calls customEvent which rejects the "FORGET" keyword.

So, what's going on here? More important is how to fix it. I can correct the customEvent piece but I suspect the better choice is to remove it and have the logic fall through to the other function assuming that's how it works.

Wise counsel requested.

- George
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

cpinkham at bc2va

Apr 16, 2012, 8:46 PM

Post #2 of 4 (249 views)
Permalink

Re: delete_recording & the rerecord option [In reply to]

* On Mon Apr 16, 2012 at 11:24:21PM -0400, George Nassas wrote:
> Problem is there are two handlers for DELETE_RECORDING: one in
> MainServer::ProcessRequestWork which recognizes the rerecord option,
> and one in MainServer::customEvent which does not. The services api
> calls customEvent which rejects the "FORGET" keyword.

One of these is for handling requests from frontends (the
ProcessRequestWork version) and one is for handling delete requests
from other threads within mythbackend like the services API.

> So, what's going on here? More important is how to fix it. I can correct
> the customEvent piece but I suspect the better choice is to remove it
> and have the logic fall through to the other function assuming that's
> how it works.

ProcessRequestWork is only for handling requests received over a socket.
I think that you can replicate the logic from the DELETE_RECORDING
handling inside ProcessRequestWork so that you check for optional
arguments in the customEvent handling code and then you can have the
services API send the optional FORGET argument and pass true as the
last argument to HandleDeleteRecording.

Also good would be to call HandleDeleteRecording() instead of
DoHandleDeleteRecording() inside the customEvent handler so that you
can simplify that code and let HandleDeleteRecording() do the
RecordingInfo lookup for you. If you do that, modify
HandleDeleteRecording() so that it handles a NULL PlaybackSock pointer
being passed in.

> Wise counsel requested.

Hope it was supplied. :) Thanks for taking a look at making a patch.

--
Chris
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gnassas at mac

Apr 17, 2012, 5:03 AM

Post #3 of 4 (239 views)
Permalink

Re: delete_recording & the rerecord option [In reply to]

On 2012-04-16, at 11:46 PM, Chris Pinkham wrote:

> Thanks for taking a look at making a patch.

No probs!

My other observation is I wonder if the http version should always do a FORCE_DELETE_RECORDING. My guess is if you call ordinary DELETE_RECORDING and there's no file it will fail (I'll try that to see) but since you're calling a delete API it's a good hint you want that entry removed from the DB whether there's a file or not. Since the http delete only returns true or false it's hard to know why you get a false when you do. Maybe someone else got there before you. Anyway I'll test the behaviour and upgrade it to FORCE_ if necessary.

- George

mtdean at thirdcontact

Apr 17, 2012, 7:18 PM

Post #4 of 4 (236 views)
Permalink

Re: delete_recording & the rerecord option [In reply to]

On 04/17/2012 08:03 AM, George Nassas wrote:
> On 2012-04-16, at 11:46 PM, Chris Pinkham wrote:
>
>> Thanks for taking a look at making a patch.
>
> No probs!
>
> My other observation is I wonder if the http version should always do
> a FORCE_DELETE_RECORDING. My guess is if you call ordinary
> DELETE_RECORDING and there's no file it will fail (I'll try that to
> see) but since you're calling a delete API it's a good hint you want
> that entry removed from the DB whether there's a file or not. Since
> the http delete only returns true or false it's hard to know why you
> get a false when you do. Maybe someone else got there before you.
> Anyway I'll test the behaviour and upgrade it to FORCE_ if necessary.

I'd prefer that it continue to default to no-force so that users don't
accidentally create hundreds of gigabytes of orphans when they start
deleting shows via some external client only to find out later that one
or more file systems didn't properly mount (or a slave backend wasn't
running or ...).

If you get an error, you can check for the file and if it doesn't exist
and you /really/ want to delete the metadata, you can force the delete
(or the client can provide a force delete argument explicitly if they
don't want the safety). If that means another argument to the API call
(like the forget argument), then you could add that, too.

Either that, or if necessary, you can change the API so you get
more/better information on failures?

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads