[mythtv-users] no write(2) method for mythfs.py?

Brian J. Murrell brian at interlinx.bc.ca
Wed Nov 23 18:17:06 UTC 2011

On 11-11-23 12:56 PM, Raymond Wagner wrote:

Heh.  I was just about to reply to my own posting with an "Ah ha!  :-(":

class Program( CMPRecord, DictData, RECSTATUS, AUDIO_PROPS, \
                         VIDEO_PROPS, SUBTITLE_TYPES ):
    """Represents a program with all detail returned by the backend."""
    def open(self, type='r'):
        """Program.open(type='r') -> file or FileTransfer object"""
        if type != 'r':
            raise MythFileError(MythError.FILE_FAILED_WRITE, self.filename,
                            'Program () objects cannot be opened for writing.')

> No, that's pretty much it.  There is a whole lot that would have to go 
> on behind the scenes to make such a thing work.  The recording would 
> have to be marked as in-use for writing.  The filesize would need to be 
> updated.  The seek table would have to be invalidated and flushed, 
> potentially along with any bookmarks and markup.

Yeah.  I'd consider those all optional.  I'm just looking to be able to
replace having to manually figure out the B/E's filename for a recording
whenever I want to do a:

$ cp $good_file $broken_myth_recording_file
$ mythcommflag --rebuild --file $broken_myth_recording_file

Although, it is interesting to do the mythcommflag --rebuild on close
after a write anyway, but being able to use the mythfs filename for
mythcommflag would be sufficient.

> The backend protocol 
> does not currently implement moving files, so would would have to be 
> implemented to write the new copy to a temporary file, delete it, and 
> shift the new one in place.  Alternatively, the original would have to 
> be buffered locally while the old one was deleted and written on top of.

So the backend can't just open the existing file for "truncate & write"
as simply as it can open one for read/tell/seek?
> Now some of this could be automated, hidden from the user.  Potentially 
> others could be tucked away into special text files the user could 
> access to modify metadata and seek/skip/cut tables.  To be honest, when 
> you need more access to the internals than a filename can provide, it 
> seems like it would be easier on both sides to just implement the 
> database and protocol access natively in whatever tool you're using to 
> fix those files.

Except that a file system interface such as mythfs gives me a really
easy way to hunt for the program I want to fix by title/subtitle com-
plete with tab completion, etc.  Otherwise I am manually referring
back to either mythweb or the output of a mysql select list for the
right subtitle and then the B/E file that that program is in, etc.

> That's not one I've seen before.

It seems on the first time a file is opened the line:

        LOG(LOG.FILE, 'open files', str(self._openFiles))

never gets hit so there is probably some exception being thrown in

        if path not in self._openFiles:

branch.  Once the file is known in _openFiles, the alternate branch:

            self._openFiles[path][0] += 1

is taken.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://www.mythtv.org/pipermail/mythtv-users/attachments/20111123/806aa021/attachment.bin 

More information about the mythtv-users mailing list