[mythtv-users] Fully delete rec from cli
andguent at gmail.com
Fri Sep 1 02:53:15 UTC 2006
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
> off) on the page. In 0.18.1, they're of the form
> 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
I love it. The full path I still had to go check through the source for:
wget -O /dev/null -a logfile -q \
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.
More information about the mythtv-users