I use DHCP at home, as most do, for convenience. Last week I changed the router at home to one compatible with DD-WRT as I was setting IPv6 up at home (something I should blog about later). When I set it up, until I migrated the old DHCP config over, everything on the LAN that had static DHCP allocations went a bit crazy. Once that was resolved everything went back to normal… or so I thought.
However I’d noticed that MythTV wasn’t recording anything. When looking through it had listed all of it’s encoders as remote and “currently not connected”, interesting I thought. It looked like somewhere along the line that box had got 192.168.5.6 instead of 192.168.5.5. So it didn’t think it was, well it’s self. Changing the DHCP assignments quickly resolved this.
A week later I noticed whilst programs had been recording, they were all sitting queued in Job Queue. Restarting the backend process nor did restarting the box. So I had a quick look on it’s DB and noticed the recordings were showing as remote, not local as they should be. Delving a bit further I noticed that it was listing the recordings as being recorded on “sidekick.oob.an0key.net” instead of “sidekick”. I’d set the domain on the router, and it was happily distributing via DHCP.
So to resolve my issue, I changed the hostname manually, back to sidekick.
To do this on ubuntu is pretty simple, edit
/etc/hostname
with the desired hostname and then
/etc/init.d/hostname.sh restart
However I was now stuck, with all the recordings showing as being recorded on the ‘remote’ host. The only way to fix this would be to edit the database manually. This is where it the less adventurous may want to stop.
So log on to your MySQL instance, it’ll prompt for MySQL’s root password.
sidekick:~# mysql -p -u root
Use mythtv’s database named mythconverg in my setup.
use mythconverg;
Then print the structure and contents of the jobqueue table.
select * from jobqueue;
This is what I was presented with.
mysql> select * from jobqueue;
+-----+--------+---------------------+---------------------+------+------+-------+--------+---------------------+-------------------------+------+-------------------------+---------------------+
| id | chanid | starttime | inserttime | type | cmds | flags | status | statustime | hostname | args | comment | schedruntime |
+-----+--------+---------------------+---------------------+------+------+-------+--------+---------------------+-------------------------+------+-------------------------+---------------------+
| 284 | 1001 | 2011-02-03 17:11:00 | 2011-02-03 17:15:01 | 256 | 0 | 0 | 272 | 2011-02-03 17:15:53 | sidekick | | Successfully Completed. | 2011-02-03 17:15:01 |
| 283 | 1004 | 2011-02-02 22:00:00 | 2011-02-02 23:05:00 | 256 | 0 | 0 | 1 | 2011-02-03 17:25:24 | sidekick.oob.an0key.net | | | 2011-02-02 23:05:00 |
| 282 | 1001 | 2011-02-02 21:00:00 | 2011-02-02 22:00:01 | 256 | 0 | 0 | 1 | 2011-02-03 17:25:24 | sidekick.oob.an0key.net | | | 2011-02-02 22:00:01 |
| 279 | 1007 | 2011-02-01 21:00:00 | 2011-02-01 22:00:01 | 256 | 0 | 0 | 1 | 2011-02-03 17:25:24 | sidekick.oob.an0key.net | | | 2011-02-01 22:00:01 |
So I can see the that the job ran fine that came in after I changed the hostname. So what I decided to try is to update the hostname, and also the scheduledtime too as it was in the past.
mysql> update jobqueue set
-> status=1,hostname="sidekick",comment="",schedruntime="2011-02-03 17:30:01" where status=1;
So this will update the hostname and schedruntime for anything with status 1 (which means queued). I ran that and restarted mythtv-backend, and all the queue was then worked though.
Job done. Hopefully this may help someone else in a sticky position.
