[mythtv-users] Latest Mythtv 0.28 broke input priorities, xfsrestore backup woes

[Stephen Worthington]

On Sun, 27 Nov 2016 20:26:52 -0500, you wrote:

>In case I haven't quite figured out the concept of "if it ain't broke,
>don't fix it", this one takes the cake:
>
>After upgrading to the latest MythTV via Mythbuntu, I noticed that my
>input priorities got messed up.  I have a system where my HD-PVR is used
>as a last resort.   After installing the latest updates, which broke my
>video as described in my prior thread, I noticed that all of my
>recordings were scheduled to occur via the HD-PVR.   I went into
>mythtv-setup, and noticed that the HD-PVR had a priority of "-1" and the
>3 HDHR inputs all had a priority of "0".
>
>Now, it's been a while since I set it up, but according to
><https://www.mythtv.org/wiki/Setup_Input_Connections>, -1 isn't even a
>valid priority.
>
>I tried re-setting priorities via mythtv-setup, but it didn't seem to
>help.  At this point, I decided to just restore from my latest backup.
>I use xfsdump to back up the system before any changes.   After
>restoring from backup I was greeted with the first-time MythTV setup
>screen.  :(
>
>After a little bit of troubleshooting, I realized that my
>/etc/mythtv/config.xml file was missing!   Increasing verbosity in
>xfsrestore and doing an interactive restore, I see:
>
>-----
>
> -> ls /etc/mythtv
>            4032 session-settings
>         4127166 session-settings~
>        50343916 config.xml
>         4884092 mysql.txt~
>
> -> add /etc/mythtv
>
> -> extract
>
> --------------------------------- end dialog
>---------------------------------
>
>xfsrestore: mkdir etc
>xfsrestore: mkdir etc/mythtv
>xfsrestore: dump session label: ""
>xfsrestore: dump session id: f132cc65-5bd4-4a58-a810-52398fe99326
>xfsrestore: stream 0, object 0, file 0
>xfsrestore: restoring non-directory files
>xfsrestore: media file 0 in object 0 of stream 0
>xfsrestore: restoring etc/mythtv/session-settings (4032 221708883)
>xfsrestore: restoring regular file ino 4032 etc/mythtv/session-settings
>xfsrestore: truncating etc/mythtv/session-settings from 0 to 1170
>xfsrestore: restoring etc/mythtv/session-settings~ (4127166 4079738789)
>xfsrestore: restoring regular file ino 4127166 etc/mythtv/session-settings~
>xfsrestore: truncating etc/mythtv/session-settings~ from 0 to 1169
>xfsrestore: restoring etc/mythtv/mysql.txt~ (4884092 1828724895)
>xfsrestore: restoring regular file ino 4884092 etc/mythtv/mysql.txt~
>xfsrestore: truncating etc/mythtv/mysql.txt~ from 0 to 99
>xfsrestore: restore complete: 125 seconds elapsed
>xfsrestore: Restore Status: SUCCESS
>root at jerky:/mnt/rescue#
>
>-----
>
>
>From the above I see that /etc/mythtv/config.xml does indeed exist.
>However, when attempting to restore the file, it silently fails!  I even
>tried restoring from a different xfsdump backup, and it behaves exactly
>the same way.
>
>
>So at this point:
> - Has anybody noticed any trouble with input priorities for recordings
>with the latest MythTV 0.28?
> - I know that it has nothing to do with MythTV, but in case anybody is
>familiar with xfsdump/xfsrestore, does anybody have any idea what could
>cause the symptoms I'm seeing above.   I've been pretty happy with this
>backup/restore scheme in the past, and I have successfully restored from
>backups before.  But silently skipping a file seems pretty catastrophic.
>
>
>Thanks!
>-WD

You probably do not want to use the Input Priority settings these days
- use the Schedule Order and LiveTV Order settings instead.  If you
use input priorities, then you can have recordings wait for a repeat
showing so they can use a higher priority tuner.  Of course, if that
is actually what you want, then by all means use input priorities.  I
have my DVB-T tuners with higher priorities than my DVB-S2 ones,
because the satellite versions of the channels are all SD, but the
DVB-T ones are HD.  But within my DVB-T tuners, I use the Schedule
Order settings.

I have always understood the various priority values in different
places in the database as allowing negative and positive numbers. That
is because they all get numerically combined in the scheduler to work
out what the highest priority action is, and sometimes you want a
negative number to say that using that thing is something that should
be avoided where possible.  So I think the documentation on that web
page is probably wrong in saying the value is 0 to 99.  The field in
the database (capturecard.recpriority) is an "int" and it is likely
that you can put in any value that will fit in the database, so
negative numbers and much larger numbers would be fine.

My input priority values have not changed from what I set them to.

MythTV Version : v0.28-97-ge9d0543
MythTV Branch : fixes/0.28
Network Protocol : 88
Library API : 0.28.20161120-1
QT Version : 5.5.1