[mythtv-users] Rerecord large groups of recordings in digital

[Michael T. Dean]

On 08/21/2013 10:15 AM, Joseph Fry wrote:
>>>> The beauty is, that everything you do in the menu can be accomplished
>>>> by editing the database.  I don't know what exactly "allow this
>>>> episode to rerecord" does... but there is no doubt in my mind that you
>>>> could reproduce this in scale with a few lines of SQL.
>>> This would be a good approach for me. I am a programmer (actually these
>>> days I program in Qt) but sql update queries will be pretty easy for me
>>> provided I find the right place to update..
>>
>> Just make sure before you start poking raw data in the database you read all
>> of the MythTV source code and understand all of the data constraints and
>> requirements, as they aren't expressed in the database.
>>> Yesterday I tried deleting all of the 200+ items in oldrecorded for a
>>> particular show expecting it forget the old. That did not help. I had to
>>> still force recording via the upcoming recordings screen of mythweb.
> Did you trigger a scheduler run afterward?
>
>> See, if you don't understand the data and how it's used by the application,
>> you can't just edit data to get what you want.  Instead, you may end up the
>> data and a) get no noticeable effect, b) get the desired effect and an
>> undesired effect, c) not get the desired effect and get an undesired effect,
>> or even d) break the application (due to breaking assumptions it makes about
>> the data).
> Of course tinkering in the database directly is risky.  Doesn't mean
> that it should not be done under any circumstances.  Because there is
> some real world applicability, and because the poster is a capable
> programmer, don't you think it would be more constructive to tell him
> what he needs to know rather than to warn him away from doing it.

No.  Do you know how many times people have posted SQL hacks or other 
hacks or some piece of information to this list, then some user finds it 
4 versions in the future and does the same and breaks things.

I'm tired of helping people fix database that they break themselves 
because they don't know what they're doing, so I'm not going

Besides, who says I will be able to think of all the things that need to 
change.  Of course, I /could/ go in and read all the code that I can 
think of that's related to what he's trying to do, but then again, so 
could a "capable programmer" like the OP.  That's why I told him to read 
the code to figure out

> I realize he could spend time reading through all the applicable code
> to determine the way to properly make the scheduler ignore all
> previous recordings of a given show... but that is not a very
> efficient use of anyone's time.  Not when a quick explanation from an
> experienced developer would achieve the same thing in minutes.
>
>> This is /exactly/ why we have a user interface for MythTV.  It allows people
>> to use MythTV without spending months (years--I'm still learning all the
>> data requirements for MythTV and I do a /ton/ of work related to those data
>> requirements) learning the data.
> And the limitations of the user interface is exactly why the community
> has developed hundreds of scripts to achieve things that the
> interface, often wisely, leaves out.

And my request for a patch that adds the capability the user 
wants--ability to set "Allow re-record" on a playlist of recordings all 
at once was intended to *fix* the limitations of the UI.

It's people doing and posting terrible hacks, instead of doing the work 
(and, in this case, not that much work) to do it right that's the reason 
our UI is limited.

Help us help you.  Please.

>    To develop a single purpose
> script, he need not know all of the ins and outs of the database...
> just the portions relevant to what he is working on.

And no one benefits.  This is completely against the idea of F/LOSS.

>> Note that just because one speaks SQL doesn't mean they know the MythTV data
>> constraints.
> I agree with you Mike, manipulating the database is risky, and
> requires some understanding about the structure and constraints of the
> database.  I just don't agree that before you touch the database you
> need to understand every detail about it; especially when others have
> that knowledge and can share the relevant bits.

A little knowledge is a very dangerous thing--especially when posted to 
a publicly-archived list where anyone could see it, and act on it (even 
in /very/ different circumstances), when frantically trying to fix 
something they don't understand only to make things even worse than 
before they found that post.

Mike