On Thu, May 05, 2005 at 12:38:32AM -0400, Chris Pinkham wrote:
> > Just to clarify and avoid ambiguity, I've attached a new patch
> > attached without any of the unrelated cruft; no changes otherwise.
>
> Couple questions/comments based on my initial observations after
> applying the patch.
>
> 1) The "UPDATE table1, table2, tabl3 SET table1.column" syntax is
> not valid for MySQL v3.x, so this will need to be changed to
> something like the following and put after the performActualUpdate()
> call.
>
> ----------------------------------------
> QString thequery;
> int recordid;
> MSqlQuery query(MSqlQuery::InitCon());
>
> thequery = QString("SELECT r.recordid "
> "FROM record r, recordingprofiles p, codecparams c "
> "WHERE c.name = 'autotranscode' "
> "AND c.value = 1 "
> "AND c.profile = p.id "
> "AND r.profile = p.name; ");
> query.prepare(thequery);
>
> if (query.exec() && query.isActive() && query.size() > 0)
> {
> MSqlQuery query2(MSqlQuery::InitCon());
> while (query.next())
> {
> recordid = query.value(0).toInt();
>
> thequery = QString("UPDATE record SET autotranscode = 1 "
> "WHERE recordid = %1;").arg(recordid);
> query2.prepare(thequery);
> query2.exec();
> }
> }
> }
> ----------------------------------------*Grumble*. OK. I'll work on this. I can shuffle around the SQL as described above, but I don't think I'll be able to test it, as I only have a single FE/BE system with whatever the debian default MySQL is (presumably some 4.x version). > The logic of the above update seems to be flawed anyway. I set my > recordings to record using the "Default" profile, and have > autotranscode off except for my air2pc recording profile. The > update changed all my recordings to autotranscode = 1. This isn't > what I want, I only want recordings to transcode when they record on > my air2pc card, not when they record on my M179 cards. I think this is correct. The intent of the SQL is to migrate all recording schedules associated with an autotranscoding recording profile to have the per-recording-schedule "autotranscode" flag set to 1. The recording profiles continue to keep their present "autotranscode" flag. There are two "autotranscode" flags floating around that eventually get ANDed together. Scheduled recordings can have autotranscode=1. This means that the recording *may* be autotranscoded. The "Default" recording profiles associated with your devices should have autotranscode set to 1 or 0, depending on whether you want the profile associated with that device to allow autotranscode. So in your case, you would configure the Air2PC "Default" recording profile to enable auto-transcode, and you would configure the M179 "Default" recording profile to *not* enable auto-transcode. This recording-profile-autotranscode means that any recordings associated with this profile (on this device) *may* be autotranscoded. The recording profile is looked up by name at the time the recording is actually done, so it finds the one associated with the recording device, so it should get the correct device-based "autotranscode", which is then finally ANDed with the "autotranscode" value associated with the recording schedule, to finally decide whether or not to kick off mythtranscode. It is this ANDing that should allow you to transcode only HD content, and not transcode analog content (that was already compressed at recording time). That is the intent, anyway. Given my above explanation, do you still see a problem? Can you verify in your database (and/or UI) that the "Default" recording profiles associated with your M179 and Air2PC have auto-transcode configured appropriately? > 2) Would it make better sense to just have 1 column rather than > the 2 you created. The value would indiate one of the following: > > * Do not transcode > * Transcode using Autodetect > * Transcode using 'Low Quality' > * Transcode using 'Medium Quality' > * Transcode using 'High Quality' > > I think it would be nice if this could be wrapped into one setting > on the scheduled recording editor page. You might not be able to > keep the recording profile ID in the column, but I think that having > the 4 different profiles is enough, the same as it is with normal > recording profiles for bttv and ivtv cards. I actually started out doing it the way you suggested above, but it means that it you schedule something to *not* autotranscode, then you will be unable to transcode it later (since the setting says "do not transcode"). By separating the boolean "autotranscode" from the actual transcoder to use when transcoding is actually performed, one can configure a transcoder to eventually use, without committing to immediate auto-transcoding. Collapsing the "autotranscode" column with the "transcoder" column will make this impossible. Also, later on, I would like for the "Watch Recordings" popup to allow a just-in-time selection of transcoder to use when choosing "Start Transcoding"; currently the user has to remember what profile was selected for the scheduled recording. Does this make sense? Given the above explanation, do you still want me to merge the "autotranscode" and "transcoder" columns? If you agree with everything I say above, then the only thing I think I need to deal with is the MySQL 3.x stuff. Otherwise, let me know where you think I am wrong. Thanks, --Rob
signature.asc
Description: Digital signature
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
