[mythtv-users] mythtv dropping mysql???

[Michael T. Dean]

On 10/19/2014 11:24 AM, Peter Bennett (cats22) wrote:
> I vote to keep the external mysql database. There is a lot that I do
> with the database and I have not yet shot myself in the foot or reported
> as bugs things that I caused. This is the principle behind open source,
> let the users do their thing with the caveat that they may mess things
> up.

They can.

>   Those people who use mythtv as an appliance and do not touch the
> database can continue to do that even with an external database.

Actually, those who do directly edit their database can do so with an 
embedded DB.

> There was a bug back in version 0.24 or 0.25 where the backend would
> exceed the limit of database connections if a large number of files
> expired at the same time. Then recordings were stuck in limbo. That
> happened to me and the fix from the mailing list was to reset the
> deletepending flag on the recording table. If I could not run SQL what
> would the fix have been?

The fix would have been properly implemented in MythTV code so that you 
(and all the other MythTV users) don't have to do that specific 
extremely dangerous query (that can break all sorts of things if the 
entire process isn't performed properly).  As it is, I haven't put the 
fix in place because the small likelihood of the particular race 
condition triggering coupled with the available workaroud allow me to be 
lazy and tell people to use a SQL hack instead of doing the right thing.

> I often do database selects to find things, for example recently I
> needed to find if any recording rules did not have user job 1 selected.

OK.  And you're saying it makes far more sense to dig into the internal 
database data--and learn to interpret the internal data 
formats/codes--than to use the Services API or the backend web server or 
a script written with the Python bindings?  Because the internal data 
format and meanings change over time and the Services API, the backend 
web server, and Python bindings are updated for those changes, it seems 
better to me to let them interpret the data rather than writing the 
interpretation into the SQL (and having to update your "script" for the 
changes rather than having it pick up the changes automatically when it 
pulls a page of XML/HTML produced by the updated server or when it runs 
against updated Python bindings).

> In common with many people I use a database script to add channels. I
> have many scripts that access the database daily, for example I look at
> all of my recording devices and test them during startup so that I know
> if somebody has pulled out a cable. Rather than hard code them in my
> script I read them off the database.

Again, instead of using the services API or backend web server or Python 
bindings to get information on your devices/inputs...

Mike