Misterhouse notes

Just some notes for myself about recent learnings around misterhouse and insteon.

Device Linking

From what I understand now, when adding a new device to my network, I need to link it with the PLM.  To respond to the PLM (and by proxy MH) , I generally don't have to do anything but set up the device in the MHT file.  Newer devices this year, however, have changed the protocol, and MH can longer automatically discover and link the devices into the PLM as a responder to the PLM.  So, for newer devices, I have to manually link by using the set button on both the device and the PLM.  

For Linc devices, linking is a two way street since the device can send status to MH when the button is pressed.  For this, I generally have to hold the device's set button for 3 seconds, and then in MH under the PLM control, select "complete linking as responder".    It may vary by device on how to put it into link mode as a controller (ie update the PLM when the button is pressed).

Email troubles

Today I received an email from the guy that runs the server I use as a mail relay.  Apparently, my asterisk box has been sending constant email to his mail server (smart host forwarding).  I think what was happening is that I had set my .forward on the asterisk box to send to "user@host" where host is my own server at home.  That server uses exim4.  I really could never figure out how to make "user@host" stay local.  Via some trial and error I finally found that "user@mydomain" seems to work and the email isn't forwarded to the smart host but stays put on my server.  I just need to remember this in the future, hence my post here to remind me.

UPDATE:
I didn't have it quite right before.  A couple of issues.  First, the asterisk box wasn't delivering email to local users.  Instead it punted and sent it to the relay which didn't recognize it either.  This was fixed by setting mydestination to "localhost, <myhostname>" in the postfix config file.  After that, mail would get delivered locally when using unqualified user names for the email address, as well as user@<myhostname>.  The second issue was that my exim4 main mail server didn't recognize user@hostname (where hostname is the exim4 server name) as being local and would send it to the relay.  This is the same problem the asterisk server had, but this is fixed in update-exim4.conf.conf by setting dc_other_hostnames to include the exim4 server name.  It previously only had my domain name in it which is why user@<mydomain> was getting delivered locally.

Typical

I hate it when this happens but it happens far too often with upgrades.  I upgraded my laptop to Ubuntu 12.04 (which is another post to be made).  About a month later (today) I need to put some photos from my camera into digikam.  When I start up digikam I get this error:


You have insufficient privileges on the database.
Following privileges are not assigned to you:
CREATE TRIGGER
Check your privileges on the database and restart digiKam.

A google search turns up https://bugs.kde.org/show_bug.cgi?id=262321 ( a Jan 2011 bug)

Basically, some change was made to digikam in how it uses the database, but it doesn't quite work right with mysql.  The work around is to give the digikam user full privs on the entire mysql database.

There is this comment:

--- Comment #15 from davidebasilio <marsicanbear gmail com>  2011-11-07 16:12:55 --- 
Digikam 2.3.0 is out http://www.digikam.org/drupal/node/632
But it looks like noone took care of this bug since 2.0.0 
Will it ever be fixed? 
BTW, this is tagged as wishlist, but I do not really think that's correct. This 
is a bug. 


</end comment>


So, it's almost 18 months later and this is a still an issue!  The glacial pace at which these fixes get introduced combined with the super fast pace new features (and bugs) get introduced really frustrates me.  Now I have to do a work around which some years later will cause some problem and I'll never make the connection.


Check out this comment from the bug:

Bruno Friedmann 2011-03-31 08:13:20 UTC

Marcel, in fact I don't know how you can do that, due to upstream (bug/feature) the creation of triggers apparently are root reserved in mysql, due to replication feature of the database engine. ref http://dev.mysql.com/doc/refman/5.0/en/stored-programs-logging.html So for the "normal" embedded mysql there's no troubles as it's run like superuser by end user. The real impact is about using digikam in shared mode (centralized mysql server). So digikam can said : hey we didn't support that, but as it has, it will become a big regression. Time to interface digikam to virtuozzo ? :D

I mean, why do they offer the option to run shared mode if they aren't going to make sure it works on every release?  This is one of my big gripes about FOSS software - they build lots and lots of doors that you can open, but only a few will lead you to safety and many lead you to your doom (although they appear perfectly safe).  I chose the door to using a shared mysql server and I am now paying the price.




UPDATE (6/25)--
I finally got digikam working again.  There were numerous issues and I am not sure which one was the culprit.  First, some operations in mysql gave me errors or warnings about some mysql internal tables that had the wrong number of fields (20 vs 16).  It seemed this was due to an upgrade that didn't complete normally.  I ran mysql_upgrade --force and complained about some ampache tables that needed repairing.  After that it gave me this error:

Error: Incorrect database name '#mysql50#mysql.orig'

I had to remove the mysql.orig directory from /var/lib/mysql

 After fixing those, it seemed to update the database correctly.  The other thing I did (and maybe this wasn't required) was add the
create_index_if_not_exists() proc to the digikam databases per this bug (https://bugs.kde.org/show_bug.cgi?id=276052).

Now digikam works again.  But if you search for "digikam failed to upgrade" you will see lots of threads talking about failures to upgrade the schema for digikam from 5 to 6.

Ampache woes

So at some point something went horribly wrong with my ampache setup. I decided to try the ampache script that renamed files using the tag information. This seemed like a good idea, because my files weren't all named or organized in a consistent way. After a couple attempts, I noticed that all my songs in ampache were by an artist who's name started with the directory path to the file. Great. At the time I was pretty sure I had messed up the mp3 tag data because after rebuilding the catalog in ampache, nothing changed. Artist name was still the directory name (/mnt/usb_mmedia/music/itunes/...). I tried to fix things a couple times but I seemed to make it worse.

Fast forward maybe a year to the past week. I decide it's time to go fix my library. I wanted to start by fixing the MP3 tags, so I downloaded some utils and started to work. But I couldn't find anything wrong with the mp3 tags. The artist was correct here. I also noticed when playing a song through ampache that the artist name seemed to come out correctly there as well. So what the heck is going on?

I start putting print statements in the ampache code to see what it is doing when I verify the catalog. I eventually discover that it is not looking up mp3 tags when building the catalog and instead trying to generate the information from the filename. This is happening because I no longer had an entry in the ampache config file for mp3 tag processing order. I put that back in and everything goes back to normal in Apache.

So why was I missing that config line? It goes back to another problem I had with ampache where catalog verification/creation would hang at some point as the mp3id library would get stuck and chew up memory. This was a known issue with ampache which happened on some files who have corrupted tag information. It was quite hard at the time to identify which files these were and besides, I didn't know how to fix them. The only option was to stop ampache from reading the mp3 tag information by removing the tag order config key. It worked find until I tried to verify the catalog.

This is exactly why I do not like to employ hack work arounds, they always come back to bite you later.

The other stupid thing about all this is that ampache was using a deprecated php method (eregi) and would spit out errors during catalog verification. The response from the ampache devleoper was to downgrade php to an older version or use the alpha version of ampache. Really? What kind of choice is that? Have you ever tried to downgrade something in linux? Remember these systems are a tight-nit web of dependencies. You can't just go around back-revving major packages. I don't know how the stable version of ampache was even going to work on recent distribution releases. I had to replace all the calls in the ampache source code with the proper methods, then everything worked. Thanks open source!