mtdean at thirdcontact
Apr 17, 2012, 7:18 PM
Post #4 of 4
On 04/17/2012 08:03 AM, George Nassas wrote:
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.
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?
mythtv-dev mailing list
mythtv-dev [at] mythtv