sbower at cisco
Mar 20, 2006, 7:19 AM
Post #1 of 1
(489 views)
Permalink
|
|
PreviewGenerator and .png file permissions
|
|
Howdy folks,
I use just the preview thumbnails, not video, in my Recordings screen.
Ever since changeset #7886 in November, preview .png generation hasn't
been limited to just the backend that recorded a program. This means
that other processes (mythbackend, mythfrontend), potentially running on
other hosts or as other UIDs, will attempt to update the .png file.
The initial .png seems to be created with a mode of 0644 (if your umask
is the default), so if the other processes have access to the storage
directory but aren't running as the same UID, they'll fail to update the
file. If it's a frontend in the Recordings page doing this, it'll go
into a loop continually trying to update it until you move to a
different recording.
Right now there's a bug that prevents the update from being attempted
(and therefore looping) on remote machines in many cases, but I'll talk
about that in a separate thread... :-)
I suppose there are a few possible approaches to the permissions issue:
- set the mode of the .png to 0666 whenever it's written
- if updating the .png fails, create a .png.new file (which will work if
the directory is writable), and if that succeeds move it over the
original .png file
- if those fail, it's likely that we're not running as part of the
backend that "owns" the recording (but we can check that too), so talk
to it and ask it to update the preview
One sticky bit is the local_only parameter to PreviewGenerator, which is
supposed to be set whenever it's invoked by any backend: if it's being
called by a remote backend (like after a jobqueue commflagging, which is
one situation that brought the issue to my attention), is it then okay
to talk to the "owning" backend to have it generate the preview?
I can attempt to create a patch to implement the above steps (and will
open a trac ticket when I do).
Any other thoughts or better ideas?
Thanks,
Steve.
--
Steve Bower - IT/EHS Unix Administrator - sbower [at] cisco
The ideas presented herein aren't necessarily the ideas presented herein.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
|
