
andguent at gmail
Aug 31, 2006, 7:53 PM
Post #6 of 6
(1820 views)
Permalink
|
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 _______________________________________________ mythtv-users mailing list mythtv-users[at]mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
|