Michael T. Dean wrote:
<snip... >
_Proposal_:
<snip... >
IMHO, we should create a script that either a) accepts info as
command-line arguments and/or b) prompts the user for info. (Whether
it accepts command-line args or not, it needs the ability to prompt
the user for info--otherwise, we're forcing the user to deal with
things like maximum command-line length and shell-based
quoting/escaping issues.) It would be possible to allow the user to
easily provide information by asking for channel id--even listing the
available channel ID's, channel numbers, and channel names and
allowing the user to select an option or type their own). Then, the
script should ask for the start date/start time (allowing the user to
provide a complete start time or simply the date). Then, if the user
provided a chanid/date that exists within the data in oldrecorded,
display a list of shows from that date for the user to select or allow
the user to specify a different time. If the user selected a show,
verify the info and then insert it into the db (and update the
recstatus in oldrecorded). If not, then continue prompting for the
additional required information.
Comments? Suggestions?
Sorry for taking so long to reply to you. My hard drive filled up on
Wednesday and I have been trying to manage the data on it since then:
It seems to me that using File::Find::Rule instead of glob to search for
files would solve most of the problems you have mentioned. We could hard
code a list of extensions to look for, or the user could provide a list
of extensions in an ASCII file. File::Find::Rule can be told to filter
out directory names and files below a certain size and will look in any
sub-directories. I haven't thought of files existing on other machines.
Don't know how to solve that one yet.
The user would still need to be prompted for the channel-id, and start-,
end-date information.
When dealing with massive amounts of files, I don't want to have to type
the name of each I want to process at a command line prompt. Cutting the
info down to a [Y/n] prompt or no prompt at all is ideal, but since the
new naming scheme leaves certain critical information out of the file
name, I don't see how to eliminate the prompt all together.
It might be possible to derive the start and end dates by looking at the
creation and last modified dates for the file, but those are just
guesses since these dates would not be accurate if the file was
transcoded (for instance). But, even if we can derive the start and end
dates from the file times, we would still have to prompt the user for
the channel-id.
It might also be possible to allow an option for the user to pass the
name of an ASCII file to the script. The file would contain a list of
the file names and associates channel-ids and start-, end-dates.
Creating the list of files would be fairly straight forward for the
average user using 'ls' and an editor, but then entering the channel-ids
and dates could get really cumbersome because the script would have to
allow for some variance in personal style.
I'm not sure what you intend to accomplish by re-writing the entire
script, the basis of what needs to be done is contained in the current
script and the user/machine interfaces need to be tweaked to make the
script perform properly and easier to use. Could you tell me why you
think a total re-write is necessary? Also comment on my proposals above
and let's see if we can't work out a more usable interface.
Carl.
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
