[mythtv] Special storage groups (was Re: an idea from ruby on rails)
Michael T. Dean
mtdean at thirdcontact.com
Tue Jan 29 08:26:53 UTC 2008
On 01/26/2008 03:30 AM, Chris Pinkham wrote:
> * On Fri Jan 25, 2008 at 02:00:08PM -0500, Michael T. Dean wrote:
>> 0.20-0.21 will still work). Heh. I actually mentioned the Backup
>> storage group way back in September--
>> http://www.gossamer-threads.com/lists/mythtv/users/288037#288037 --and
>> even then, I was way "late" on the patch. I really need to get this done.
> Chalk one up to my failing memory.... :)
Well, I didn't really mention it to you--so I wasn't accusing you of
forgetting. I was more surprised by how long I had been planning to
finish this one. Though, I wouldn't be surprised if I were to dig
through my IRC logs and find that the original idea of using a
specially-named storage group came from you a few months before that post.
>>> We can make a method
>>> in the Storage Groups class to list all groups available for recordings
>>> and eliminate some of these special groups.
>> Yeah. Wasn't sure whether they should be eliminated from the scheduled
>> recording editor's selections or left (if the user /wants/ recordings in
>> DB Backup or Thumbnails or ...). I was planning on asking you in IRC.
> I added a helper function for this tonight. Just add special group names
> in the "WHERE groupname NOT IN ('blah', 'blah'" SQL and they won't show
> up in the scheduled recording editor.
Yeah. I saw that. I wasn't expecting you to do that work. I'm
supposed to be helping here, not making more work for you. :)
Though, what do you think of something like the attached?. With this
patch, adding a new special group is as easy as adding a new QString to
StorageGroup::kSpecialGroups. Its primary purpose is to make the
StorageGroupListEditor stuff easier, but it also fits with your new
getRecordingsGroups() function. Currently, adding all the special
storage groups requires a lot of if/else if constructs to properly
translate the display string, but not the DB value and to create the
special "Create <special group> Group" buttons. By using a list of
special storage group names, we can automate the addition of new special
groups (and leave fewer opportunities for developers to forget
something/make a mistake in future changes). (Used a QStringList for
the contains() function.)
As written, the patch also removes the LiveTV group from the scheduled
recordings editor. I thought doing so would be a good thing, so I
included "LiveTV" in the kSpecialGroups list, but if you prefer, I could
leave the 'else if (group == "LiveTV")' code ("manual" handling of
LiveTV group) in place and just add the list code for the other special
groups (i.e. and remove "LiveTV" from kSpecialGroups).
The patch also assumes that the DB name for special groups will always
equal the untranslated display name of the storage group. Again, I
think that's an acceptable assumption to make (as we don't really have
any special groups that don't meet that assumption now, and future ones
could be written with the requirement in mind). Anyway, if you're not
opposed to this approach, I'll create a ticket with this patch. Oh, and
if you have any suggestions, please let me know and I'll incorporate
them (rather than making you rewrite my patch the way you want it).
Also, I thought it would be nice to provide a means for clients--like
MythWeb/Perl bindings/...--to find out what storage groups to display in
their scheduled recording editor screens/pages/whatever so they don't
need their own separately-maintained lists. We could do this either
with the storage group type in the DB you were talking about in the
"mythtv commit: r15604 by cpinkham" thread (
http://www.gossamer-threads.com/lists/mythtv/dev/312388#312388 ).
However, doing this assumes that the client will know what all the types
mean, etc. So, another approach may be to make
StorageGroup::getRecordingsGroups() available through the Myth protocol
(i.e. QUERY_RECORDINGS_GROUPS --we would want recordings to be plural,
as in the new function, right) or something. Thoughts?
>> without any new settings! :) I also planned to allow backup rotation,
>> but can't think of a way to do that without a setting(s) (MaxDBBackups
>> or MaxDBBackupStorage or MaxDBBackupAge or ...). Do you think that's
>> better handled externally, with settings, as a special configuration for
>> the special DB Backups storage group, or any other suggestions for it?
> I'd leave it external, not in the Storage Group area since the settings
> would apply whether the user created a special SG or not. I guess once
> we see what the MythVideo SG settings look like, then it may make sense
> to just put these on the DB Backups SG settings page. If the user didn't
> setup a specific backups SG, then the defaults are used.
Yeah. I guess I didn't really explain that too well. I meant a special
config page that's brought up when the user creates a "DB Backups"
storage group (using the special button in mythtv-setup) and that just
writes the info into the settings table (i.e. not part of the
storagegroup table).
Leaving it external sounds great, though. It also allows infinite user
configurability without any new settings. :) And, if
necessary/desired, we can always add new functionality later.
>> itself--is the easy part. Making the changes to the housekeeper (to
>> allow the job to run only if no recordings/LiveTV are in progress and if
>> no recordings are about to start; and to allow a "run anyway," i.e. for
>> mfdb; and ...) is a bit more complex (especially since I'd like to make
>> the housekeeper changes/support code usable for the jobqueue stuff,
>> too).
> It might be a good idea to also run a backup before any schema upgrade.
> This might not be possible if running mythfrontend, but should be with
> mythbackend and mythtv-setup (when run on a backend).
That's in the plan. That's the reason for the fallback to Default
storage group--so they'll even get a backup before installing the first
new version with support for backups. I hadn't thought of any reasons
why mythfrontend wouldn't be able to do the backup, but I guess I'll
find them as I work the issue. (I'm guessing it has to do with lack of
access to the storage directories on some configs. If so, I had just
planned to fallback to using something like ~/.mythtv/backup or /tmp or
something since not giving the user a backup could lead to problems.)
Mike
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mythtv-special_storage_groups.patch
Url: http://mythtv.org/pipermail/mythtv-dev/attachments/20080129/4af03376/attachment.diff
More information about the mythtv-dev
mailing list