Thread: Reading Myth Tuner status from the database

Hi,

I'm trying to determine whether Myth is recording on the tuners so that I can schedule backups, work on it's configuration, reboot the server, etc. without affecting any current recordings.

Rather than looking at the Frontend Status and / or MythWeb, I was hoping that I could determine what Myth is doing from the database, but I can't find any info.

I've found the database schema (Database Schema - MythTV), but this only seems to give the jobqueue (ie looking for adverts), rather than the tuner status.

And I've seen other similar posts (http://www.mythtvtalk.com/forum/gene...recording.html), but they go off towards grep'ing webpages and hardware solutions...

Surely the tuner recording / not recording status is logged somewhere (or maybe not?!) so that Myth itself can determine whether it can record - so I want to be able to get at this same info.

Any ideas?

If it *is* in the database, I'll be nice and update the database wiki

TIA

I remembered reading a wiki entry where a guy used leds lights that illuminated if a tuner was in use. He wrote a python script that queries the database on tuner status. The link to the wiki entry is below.

Using System LEDs for Recording Status - MythTV

Thanks for the pointer

I'd googled around and found various parts of the original email thread about using LEDs, but I didn't find the juicy bits - where he got the data on the tuner status.

It looks like he's grep'ing MythWeb ... IMHO getting data second hand always breaks - if I can determine where MythWeb get's it's status from, then that would be much more robust.

As I'm fairly new to Linux / Ubuntu / MythTV, this is definitely proving harder than expected!

Maybe there's some mileage in fuser (didn't know it existed)...

I was hoping to query the database, find a table called "here's what your tuners are doing" and I'd be done by lunchtime!

Anyway, thanks, I'll see what fuser can do, otherwise, the search continues...

Just posting an update (for myself as much as anyone else!)...

fuser doesn't look like a go-er... there's no difference in command output between a running tuner and an idle tuner (as far as I can tell)

In case someone else can give me a better pointer, the command I used was:

Code:

find /dev/dvb/adapter0/* | xargs sudo fuser -mv 2> ~/Documents/fuser-adapter0

Comparing the output of 2 tuners while one was recording and the other was idle gave absolutely no difference.

Ok, so whatever process that connects to the tuner to record the output is always connected.


Next.

I tried to look at MythWeb to see where it gets it's data from - apparently MythWeb's status page is just a direct pass-through of the backend status page (ie localhost:6544) - so Kevin Dorff's parser could work on that (one less level of abstraction to go through)

Reading around though, MythWeb's having a major re-write (as of 0.22), so I'm sticking to my plan to look under the hood, rather than grep a webpage that could change (break) after each upgrade...

more to follow...

I have spent some time looking through the mythconverg database and I have never seen anything that would indicate the status of the capture devices. I am not saying it's not in there somewhere, but it is certainly not obvious.

Originally Posted by fromans4

I have spent some time looking through the mythconverg database...

I don't suppose you've got a schema diagram?!

I have looked at the various documentation sites, inc here: Database Schema - MythTV

but I've yet to see any nice drawings (I'm more of a visual person)

I know... I should update the documentation myself...

If there isn't anything around, I'll have a go - I think MySQL workbench can reverse engineer a database into a drawing??

Anyway, back to the original thread, yes, I'm running out of hope for this too.

I worked my way back from the MythBackend status page (localhost:6544) and found that mythbackend is basically it's generating it's own "web" output.

I traced the source code back and got as far as httpstatus.cpp but I needed to find all the headers to work out where the object definitions came from.

Needless to say, it doesn't appear to be reading from the database.

Shame

I might look into this further as a side project ... I still want to be able to schedule large jobs (ie full machine backups) when things aren't recording...

Have a look at phpmyadmin. Then you can view the database in a webbrowswe. Take a look at the table "inuseprograms". IMHO thr place where mythtv store the status just in time.

Sorry, bad english.

Stefan

Hi Tmonster,

I've been trying to do just this for a while but am frustrated at every turn. This is what I've gleaned:

1. mythshutdown will tell you the status you are asking for and more (recording, flagging, grabbing EPG etc).

Code:

mythshutdown --check 1
if [ $? -eq 0 ] ; then echo 'Myth is idle' fi

Run mythshutdown --help for details.

2. Mythshutdown - MythTV
shows how to block a shutdown whilst running a script.

3. If you rename mythshutdown to mythshutdown.real and write a 'wrapper' called mythshutdown.sh which calls mythshutdown.real and keeps a log of all calls showing date, user, parameters and response code then you'll get something of an insight of what calls what when and where you might place your hooks.
Something like (off the top of my head - do a sanity check):

Code:

#!/bin/bash
mythshutdown.real $@
REPLY=$?
echo "$(date) $(whoami) called mythshutdown $*:  returned $REPLY">>mylog
exit $REPLY

A simple scheme would be to allow housekeeping at a time when the system is on and is likely to have a low load. (eg 10.15pm) and simply lock shutdown.
I've seen reports that that is not successful so in that case create a marker file which prevents closedown - in mythshutdown wrapper 'spoof' responses to say 'busy' whilst the marker file exists.

I'd prefer something a little more subtle and present thinking is that I need to intercept mythshutdown --setwakeup which is an indication that Myth thinks everthing is finished. If my conditions are met (it's after 10pm, no more recordings for at least 6 hours, I've let mythwelcome time out, housekeeping not already run today, you get the idea) then that's a good time for doing logrotates etc (how to do that? a root owned setuid script?). Whilst they are running, prevent closedown. Perhaps 'spoof' responses to mythshutdown to return 32 for any --status calls and 1 for any --check calls until the rotates are finished or simply call --lock.

Also, a 'user job' can be used to set a marker indicating that a recording has been made so a database backup is needed - that needs to be done after backend has stopped (so goes into a backend wrapper - or calls backend stop? It's getting terrible isn't it!).

However, I'll freely admit that this is only the thinking this week, I've had many false starts and I'd welcome other input to this quest.

Sorry if this is a bit of a ramble, but it's very much work in progress!
Have fun!
Phil

Hi PhilB

You've had a really good look into this, haven't you!

I started messing around with the auto-power on (ACPI Wakeup - MythTV) yesterday with the thinking that something there might be a good place to hack

MythWelcome seems to be a device that allows Myth to keep the PC on, then turn it back off again when it's not going to be recording - I was thinking about hanging on that as well - much like the way you were going.

I'd not even considered MythShutdown - there's so many components to look at... I think I should have a good go at a system block diagram as well as a db schema diagram!

Anyway, food for thought - I'll have a think over your comments later and see what comes up!

Cheers

Oh yes - I didn't mention that I am running under the ACPI shutdown / mythwelcome regime which is perhaps very important.
Welcome works very well.
Phil