[mythtv] Special storage groups (was Re: an idea from ruby on rails)

[Michael T. Dean]

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