[mythtv-users] Fully delete rec from cli

[Andrew Guenther]

On 8/28/06, f-myth-users at media.mit.edu <f-myth-users at media.mit.edu> wrote:
> The easiest way I've found to do deletions is to pretend I'm a web
> client.  In other words, I went to the Recorded Programs page in a
> browser and dumped the page source.  You'll find that there are
> non-Javascript links (for supporting browsers which have JS turned
> off) on the page.  In 0.18.1, they're of the form
>   http://host/mythweb/recorded_programs.php?delete=yes&file=filename
> where "host" and "filename" should be substituted as appropriate.
>
> I have automation that deletes programs, it just does something like
>   wget -O /dev/null -a logfile -q http://....
>
> Yeah, yeah, it'd be cleaner to send a message using the Myth protocol
> to the backend, or delete the file myself and then diddle with the
> database -and still- send a message so any frontends get their state
> updated, but the Mythweb approach was really, really straightforward,
> and it insulates me from the underlying details of the implementation
> ---no matter -what- Myth does, I can be pretty confident that Mythweb
> of the matching version will still be able to delete files.  And if
> the URL that Mythweb uses changes, that's a quick fix.  (And there's
> no standalone client to send arbitrary Myth-protocol messages, and I
> didn't feel like writing one.)
>
> Note:  For the first couple of months, files vanished instantly (this
> is on a JFS filesystem, and again remember that I'm using 0.18.1 so
> there's none of this incremental-delete stuff going on).  For some
> reason I've never figured out, things suddenly changed such that it now
> takes 5-6 seconds for the actual filename to vanish from the filesystem.
> Yes, the database is optimized & the FS is healthy, yadda yadda.  Since
> my automation does error-checking by ensuring that the file really
> -does- vanish before it moves onto the next (in part to guard against
> errors, and in part not to totally pound mythweb & mysql into the
> ground), I had to put a short loop in that checks once a second until
> the file actually disappears.  It typically takes 5-6s; the script
> would alarm if it took more than 30, but it hasn't.  (And I do mean
> "suddenly"; what -was- sub-second jumped discontinuously to 5+ seconds.
> It wasn't some gradual bit-rot sort of slowdown.  The machine's
> configuration hadn't been touched in weeks; in fact, it hadn't even
> been -booted- for several days before that.  Mythweb returns almost
> immediately (e.g., the wget terminates fast); it then takes 5-6s after
> -that- for the file to go away.  Mythweb is running on the MBE, and
> the files sit directly there; while there are NFS mounts on the
> machine, the actual video directory is local and not NFS-mounted.)
>
> P.S.  The existence of these delete links is why it's so vitally
> important to make sure that your Mythweb is protected from access
> by any untrusted host or browser (including -yourself- running a
> wget with the wrong URL and a recursive retrieval option).  Otherwise,
> even an innocent spider will delete all your recordings.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>


I love it. The full path I still had to go check through the source for:
wget -O /dev/null -a logfile -q \
http://192.168.1.3/mythweb/recorded_programs.php?delete=yes&file=%2Fmyth%2Ftv%2F1017_20060826070000_20060826073000.nuv

As of now, I can type the full http path into Firefox and have the
file delete. I'm trying the same patch both with wget and lynx -dump,
but no result. This is definitely a point in the direction I wanted.
Now I just have to figure out who is smarter, me or the box.

Thanks all for your time and knowledge.


Andrew