[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] += 1
-------------- next part --------------
A non-text attachment was scrubbed...
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