[01:35] <tgm4883> dmfrey, ping
[01:35] <dmfrey> hey there
[01:35] <tgm4883> dmfrey, just started listening to the last mythtvcast
[01:35] <tgm4883> so you had issues upgrading to 0.26 as well?
[01:35] <dmfrey> yeah
[01:35] <tgm4883> interesting
[01:35] <dmfrey> same issue in the mailing list
[01:36] <tgm4883> dmfrey, not exactly, it's actually a different issue
[01:36] <tgm4883> unless we aren't talking about the same thread
[01:36] <dmfrey> /etc/mythtv/config.xml didn't get populated with the db creds
[01:36] <dmfrey> so apt-get failed
[01:37] <tgm4883> dmfrey, hmm, ok so apt-get couldn't find the db during post install?
[01:37] <dmfrey> once adding the data to the config.xml file, and running dpkg-reconfigure mythtv-database all was good
[01:37] <dmfrey> yes
[01:37] <tgm4883> did you just need to convert the /etc/mythtv/config.xml file, or did you have to add data?
[01:38] <dmfrey> i had to add the values for username, password, etc.
[01:38] <tgm4883> dmfrey, so the values weren't there at all
[01:38] <dmfrey> it is almost as if it pre-populated values
[01:38] <dmfrey> then didn't want to add the existing ones
[01:39] <tgm4883> so the values were wrong
[01:39] <tgm4883> but they were there? just incorrect values?
[01:39] <dmfrey> yes
[01:39] <tgm4883> so let me explain the nature of that thread, what was fixed, and what process does what thing
[01:39] <dmfrey> not the same as in ~/.mythtv/config.xml
[01:39] <dmfrey> ok
[01:40] <tgm4883> dmfrey, well that is an issue then, because ~/.mythtv/config.xml should be a symlink to /etc/mythtv/config.xml
[01:40] <dmfrey> let me check, i don't think it is
[01:40] <tgm4883> anyway, let me explain what happens
[01:41] <dmfrey> ok
[01:41] <dmfrey> btw, not a symlink, just a file in ~/.mythtv
[01:41] <dmfrey> mysql.txt is however to /etc/mythtv/mysql.txt
[01:41] <tgm4883> the original issue with not being able to find the db, was that the post install for mythtv-database only looked for the old version of the field names in the XML file (IIRC, they were DBName, DBUser, etc.)
[01:41] <dmfrey> ah, ok
[01:41] <tgm4883> This was a packaging bug and was fixed a few months ago
[01:42] <tgm4883> so anyone updating to 0.26 from 0.25 today won't run into that issue
[01:42] <tgm4883> (or from 0.26 to a newer version of 0.26, which is what was actually causing problems)
[01:42] <dmfrey> that's good to know, i can relay that on the next show
[01:43] <tgm4883> so now the post install for mythtv-database looks for the new version and if it doesn't find it, falls back to looking for the old version
[01:43] <tgm4883> Then there is the actual conversion of the config.xml file from the old version into the new version
[01:43] <tgm4883> that is handled by mythtv, and our packaging has nothing to do with that conversion (which I think was incorrectly stated on the last show)
[01:44] <dmfrey> ah, looking at it now, i see it has different fields in it
[01:44] <dmfrey> than the old one
[01:44] <tgm4883> dmfrey, so it appears there is another issue, where ~/.mythtv/config.xml is not a symlink to /etc/mythtv/config.xml
[01:44] <tgm4883> dmfrey, yea, it seems that upstream arbitrarly renamed those fields :/
[01:44] <dmfrey> is it on yours?
[01:44] <tgm4883> dmfrey, it most definitely should be a symlink
[01:45] <tgm4883> as should mythtv.txt in previous versions
[01:45] <tgm4883> lrwxrwxrwx 1 root   root      22 Oct  7 09:07 config.xml -> /etc/mythtv/config.xml
[01:46] <dmfrey> here is the diff between the 2 files: http://pastebin.com/k8dYqKbh
[01:46] <Zinn> [pastebin.com] dmfrey@mythcenter:~$ diff .mythtv/config.xml /etc/mythtv/config.xml 2,7d1 < < - Pastebin.com
[01:46] <tgm4883> dmfrey, and I know that I had zero issues upgrading from 0.25 to 0.26 on my backend, and also I tested it with a clean install in a VM
[01:46] <tgm4883> no issues there either
[01:47] <dmfrey> really weird, something has to different about the upgrade process between yours and mine to cause this
[01:47] <tgm4883> dmfrey, perhaps it is the non-symlinked config.xml file
[01:47] <dmfrey> you upgraded right from mythbuntu-control-centre?
[01:48] <tgm4883> if they weren't symlinked, then it could be that the two config.xml files differed
[01:48] <tgm4883> where one had the incorrect user/password
[01:48] <tgm4883> (which is sounds like was true)
[01:48] <dmfrey> /etc/mythtv/config.xml
[01:48] <tgm4883> dmfrey, I did apt-get update & apt-get dist-upgrade, but that should all be the same process
[01:48] <dmfrey> had fields in the xml, just values all wrong
[01:49] <tgm4883> dmfrey, did you ever have to reset your backend password and such?
[01:49] <dmfrey> yeah, did that after changing repos in mythbunut-control-centre
[01:49] <dmfrey> nope
[01:49] <tgm4883> mythbuntu or ubuntu+mythtv
[01:49] <dmfrey> mythbuntu
[01:49] <tgm4883> single user, or did you create multiple users?
[01:50] <dmfrey> single...well, mine and the mythtv user
[01:50] <tgm4883> you didn't create a mythtv user though right?
[01:50] <tgm4883> that should have already been done
[01:50] <dmfrey> nope, just my own in the installer
[01:51] <dmfrey> that one was created for me
[01:51] <tgm4883> and you didn't name that user mythtv did you?
[01:51] <dmfrey> nope, it is dmfrey
[01:51] <tgm4883> ok
[01:51] <tgm4883> superm1, ping
[01:52] <tgm4883> dmfrey, I'm going to try to recreate it again. I bet I can get it to reproduce that if I sever the link between the two and add bogus stuff to /etc/mythtv/config.xml
[01:52] <tgm4883> I just don't know A) in what situations that link will break, and B) how we can fix that
[01:52] <dmfrey> you can copy my diff from the pastebin if you like
[01:53] <dmfrey> i never noticed that file before this
[01:53] <dmfrey> was it introduced in .25 or .26?
[01:56] <tgm4883> dmfrey, config.xml?
[01:56] <dmfrey> yes
[01:57] <tgm4883> it's been around for as long as I remember, but IDK what used it
[01:57] <tgm4883> it has taken over for mythtv.txt (or mysql.txt)
[01:57] <dmfrey> hmm, i thought that info was all obtained from mysql.txt
[01:57] <tgm4883> mysql.txt isn't used anymore in 0.26
[01:57] <dmfrey> i still have that file and it is symlinked
[01:57] <dmfrey> ok
[01:58] <tgm4883> see http://www.mythtv.org/wiki/Release_Notes_-_0.26
[01:58] <Zinn> [www.mythtv.org] Release Notes - 0.26 - MythTV Official Wiki
[02:00] <dmfrey> gotcha, see it there in the Major Changes section
[02:59] <superm1> tgm4883: yeah
[03:00] <superm1> what up?
[16:02] <tgm4883> dmfrey, can you check if /home/mythtv/.mythtv/config.xml is a symlink to /etc/mythtv/config.xml?
[16:02] <dmfrey> it is not
[16:03] <dmfrey> also, wanted to mention to you last night but forgot...
[16:03] <dmfrey> this was a fresh install in august of 12.04 running .25, then the upgrade to .26 was originated from mytbuntu-control-centre a few weeks after .26 was released
[16:05] <tgm4883> dmfrey, hmm strange
[16:05] <tgm4883> dmfrey, so I'm unsure why that isn't a symlink, as it should be
[16:06] <tgm4883> I did verify that the first user's config.xml wasn't a symlink
[16:06] <dmfrey> should i make it one?
[16:06] <tgm4883> is the correct information in /home/mythtv/.mythtv/config.xml?
[16:06] <dmfrey> give me a few, i gotta remote into that box at home and check
[16:07] <tgm4883> ok
[16:07] <dmfrey> ah, that one is symlinked
[16:07] <dmfrey> and the one in my dmfrey account is not
[16:08] <tgm4883> dmfrey, ok, so that is what we were seeing too
[16:08] <tgm4883> dmfrey, do you recall what was in /etc/mythtv/config.xml? you mentioned that it looked auto-generated
[16:09] <superm1> if the stuff in /etc/mythtv/config.xml is busted, mythbackend wouldn't work
[16:09] <tgm4883> dmfrey, does that mean that your actual mythtv db password isn't auto-generated?
[16:09] <dmfrey> looks like it just had new generated values in it
[16:09] <superm1> because of teh symlink to ~mythtv/.mythtv/config.xml
[16:09] <dmfrey> it is, the correct value was not one that I specified
[16:10] <tgm4883> superm1, I think the issue is that incorrect info in that file breaks post install, but why is that file getting incorrect stuff?
[16:10] <dmfrey> the wrong one just looked like a new random one
[16:10] <superm1> but so nothing has broken in the packages themselves
[16:10] <tgm4883> superm1, and then becuase of that, it sounds like mythweb doesn't get updated and breaks as well
[16:10] <superm1> as in a fail to install/upgrade package et
[16:10] <tgm4883> causing both to require manual intervention
[16:11] <tgm4883> superm1, correct, it doesn't sound like it's broken packaging, at least to the point it isn't something we can check for and fix
[16:11] <tgm4883> superm1, although I still think we should symlink config.xml everywhere
[16:12] <superm1> tgm4883: ok i think this is because of that config file upgrade you were talking about, maybe it's before you put that fix in?
[16:12] <tgm4883> superm1, nope it was after
[16:12] <tgm4883> superm1, I know because they discussed it on the mythtv podcast and I thought, I fixed that already!
[16:12] <superm1> well why didn't i hit this on my fresh install yesterday
[16:12] <superm1> it seems like it should reproduce 100%?
[16:12] <tgm4883> dmfrey, when you did the fresh install in august, did you backup and restore the database from another install?
[16:13] <tgm4883> superm1, It doesn't, it's a specific situation
[16:13] <tgm4883> just got to figure out what that is ;)
[16:13] <superm1> haha
[16:13] <tgm4883> superm1, I wonder if the DB backup scripts backup/restore config.xml?
[16:13] <tgm4883> but only do it in the current user home
[16:14] <tgm4883> or if the users possibly do that?
[16:14] <tgm4883> -bare backs up /etc/mythtv/config.xml, but not the ones in the home directories
[16:21] <superm1> dmfrey: so was there ever any mucking you did with a backup/restore or modifying ~/.mythtv/config.xml or /etc/mythtv/config.xml or ~mythtv/.mythtv/config.xml manually before the upgrade to 0.26?
[16:22] <rhpot1991> dmfrey: any config.xml in your home dir should have been created and modified by the frontend executable itselsf
[16:22] <rhpot1991> its a copy not a symlink too
[16:25] <rhpot1991> dmfrey: can you compare the values in /etc/mythtv/mysql.txt and /etc/mythtv/config.xml
[16:26] <dmfrey> superm1, no
[16:26] <superm1> dmfrey: hmm.  that's peculiar because I followed pretty much the same scenario yesterday and didn't hit this
[16:27] <tgm4883> dmfrey, so you didn't restore a database backup?
[16:27] <dmfrey> the values in config.xml and mysql.txt in ~/.mythtv are the same
[16:27] <dmfrey> tgm4883, no
[16:28] <dmfrey> no need to
[16:28] <dmfrey> it was still a new install
[16:29] <tgm4883> dmfrey, ok, so here is the issue then. We're completely unable to reproduce the issue in either a VM, or on our production machines when we did the upgrade. And it doesn't make any sense why a generated password would be different in /etc/mythtv/config.xml than ~/.mythtv/config.xml
[16:29] <tgm4883> and that last part is the crucial part causing the issue
[16:29] <tgm4883> the WHY was that different
[16:30] <tgm4883> dmfrey, so if you are telling us that you basically did a fresh 0.25 install, no restore, then upgraded to 0.26 and it broke, then IDK why that would happen as it should happen EVERY time
[16:30] <rhpot1991> dmfrey: you have more than one backend?
[16:30] <dmfrey> rhpot1991, no
[16:31] <dmfrey> same issue happened to both Pat and I
[16:31] <dmfrey> and tgm4883 you said it was not the same issue as on the mythtv-users mailing list?
[16:31] <dmfrey> but I fixed it in the same manner
[16:32] <tgm4883> dmfrey, correct.
[16:32] <tgm4883> dmfrey, not exactly, you edited the values to be correct. The mailing list thread edited the fields to be the correct name
[16:32] <dmfrey> ah, right
[16:33] <tgm4883> dmfrey, so you edited the generated DB password to be the right one, they edited <DBPassword> to <Password>
[16:33] <tgm4883> or whatever the field is called now
[16:33] <dmfrey> gotcha
[16:36] <tgm4883> dmfrey, I had another question, but I can't remember it right now :/
[16:37] <dmfrey> let me know when you do :)
[16:38] <tgm4883> dmfrey, basically we have to figure out why that was different, so we're running though different scenarios that would make that happen
[16:39] <tgm4883> dmfrey, I remember now. When you did the upgrade to 0.26, did you use update-manager or apt-get or aptitude, or something else?
[16:39] <superm1> should that matter?
[16:40] <tgm4883> superm1, no it shouldn't. But since we can't reproduce it I'd like to get as much info as possible
[16:40] <dmfrey> updated the repositories in mythbuntu-control-centre, the apt-get update
[16:41] <tgm4883> if we can get exact steps to reproduce, and then we can reproduce, then we can figure it out
[16:41] <tgm4883> dmfrey, same as me and most others :/
[16:42] <tgm4883> superm1, but right now, we've got some weird issues that a handful of people have. And I'm not even sure there are any other people having the same issue as dmfrey
[16:42] <tgm4883> so IDK
[16:42] <dmfrey> in the latest spin, is .26 set to default?
[16:43] <dmfrey> if so, then i don't think you need to worry about it
[16:43] <tgm4883> dmfrey, 0.26 will be in raring
[16:43] <tgm4883> but if this is an issue, we'll still have to worry about upgrades from 0.25
[16:44] <tgm4883> (although I'm beginning to think this is a one-off)
[16:48] <gracent> Hi guys, has anyone else experienced a black screen 'hang' when changing channels (0.26, fully updated) ?
[16:52] <tgm4883> gracent, probably need to look at your /var/log/mythtv/mythbackend.log file when you try to change channels
[16:58] <gracent> tgm4883: thanks, I did last time and there was a mention of 'lock failed'. Have just put yesterdays fixes on so I'll see if it still occurs!
[16:58] <tgm4883> gracent, ok, I've not had that issue with 0.26 and my hdhomerun prime
[16:59] <tgm4883> although I don't use livetv very often, only when testing stuff
[17:01] <gracent> tgm4883: yeah, it's kinda breaking the PAF here :D
[17:01] <gracent> tbs tuners
[17:02] <gracent> recorded is perfect
[17:02] <tgm4883> gracent, so it sounds like it might be taking a long time to lock to the channel
[17:02] <tgm4883> gracent, you might try upping the timeout in mythtv-setup
[17:03] <gracent> hmm that's an idea!
[17:03] <gracent> when it happens it's 'unrecoverable' in that I have to ssh in to kill the frontend