[mythtv-users] Two questions/comments on the consequences of human-readable filenames

[Yeechang Lee]

For months, I've been using contrib/mythrename.pl to automatically
rename MythTV's inscrutable default recording filenames to
human-readable form
(<URL:http://www.gossamer-threads.com/lists/mythtv/users/239834#239834>).
Responding to Kirby Bakken's question on how to rebuild recordings'
seektables reminded me of two issues with doing so I wanted to ask
about:

* Rebuilding seektables the way I describe at
  <URL:http://www.gossamer-threads.com/lists/mythtv/users/183846#183846>
  only works with recordings with default-style filenames, like
  "1160_20070131202900.mpg." The --infile xyz.nuv flag tells
  mythtranscode to do its best to figure out the channel and starttime
  of the recording *from the filename itself*; non default-format
  filenames prevent mythtranscode from doing so (and which it
  complains about). This is all well and good, except that
  mythtranscode *still proceeds anyway*, confusing the user. In other
  words, the resulting mythtranscode run is utterly useless because
  the utility doesn't know what seektable to update in the first
  place. The only way around this is 1) first rename the recording
  back to the default format or 2) instead of using the
  more-convenient --infile, manually specify the data mythtranscode
  needs with -c and -s.

  I suggest that mythtranscode either a) abort immediately if it is
  unable to match the recording with the relevant database entries,
  instead of proceeding and misleading the user, or preferably b) use
  the filename from --infile (which, of course, is also already in the
  database) to identify the proper database entries. Reading this over
  I guess I really should file a SVN ticket, since although b) is
  arguably a feature request, a) is clearly a bug.

* I run the crontab job I discuss in the first message I link to above
  at 23 minutes after each hour. I understand that mythfrontend caches
  recording filenames. This causes situations in which sometimes,
  after the rename job is run, mythfrontend doesn't yet know about the
  new filenames of the most recent recording(s) and can't find
  them. Simply exiting the list of recordings and reentering fixes
  this, but I wonder if there's a way to avoid needing to do so? From
  this naive non-coder's perspective, I can come up with two
  possibilities;

  1) Have mythfrontend not cache filenames. I presume they're cached
     for a reason and that not doing so would slow things down.
  2) Have mythfrontend be automatically able to rescan the list of
     recordings. Perhaps a 'kill -HUP xyzpid' or something like that?

-- 
Yeechang Lee <ylee at pobox.com> | +1 650 776 7763 | San Francisco CA US