New climate device now a Denon

[WhateverFits]

I created a new climate device, checked it in, and have been using it for quite some time now. I realized that I had forgotten something in one of the modes ("off") and went to go fix it. I made my change and saved. Now it dropped all the configuration and then reloaded it all as a Denon receiver. Um, what? I went and reverted in sqlCVS and no change. Now I hit reload and all my code is gone and loading up as a Denon receiver. All I was doing was trying to turn off my fan.

Help please!

[tschak909]

I am sorry this happened, what device template is it? I will try to find the relevant IR group, most likely it got clobbered due to an anonymous commit. Was this change approved?

-Thom

[WhateverFits]

Thanks Thom! Yup, I had already committed, it got approved, I updated, all was well. I went in and fixed the IR Command Group number to the correct one and it came back. Then, I edited again and it got blown away again. A simple update command brings it back each time. I obviously have something corrupt in one of my tables and it might have been something I did or any number of updates or changes. Any clue as to where that might be? I can poke into code if you can give me a place to look closer. I'm a rather good debugger but I just don't know enough of the LMCE codebase to know where to start. Thanks again!

[tschak909]

Essentially, the IR database is not downloaded to a LinuxMCE installation, in its entirety.

(when you see me talk camel case, I am talking about database tables)

/usr/pluto/bin/WebDB_GetIR.sh is used to grab the relevant PK_InfraRedGroup from the InfraredGroup table. This is linked to the DeviceTemplate (as a FK_InfraredGroup).

So basically, this script is asking my web server for a particular code group, and it comes back, and the relevant rows are altered in your database.

This is where things get a little murky...

We have a very cleverly designed system called sqlCVS, which loosely replicates a master database, amongst potentially tens of thousands of LinuxMCE users, this is done using the psc_* tables and columns in each table to implement a global primary key, which is carried across to multiple installations.

When you sqlcvs update, it checks your psc_* stuff, against the master server, to figure out (1) which rows have been deleted, (2) which rows have been added, and (3) which rows have been modified...and then executes a series of transcactions to get things in sync.

These psc_* numbers are used to figure out what the next primary key ID should be, when a new infra red group, device template #, whatever, is added...and since this database has had a LOT of modification, deletions, etc.. those primary key numbers have a big gap between the primary key, and what the global primary key is, (e.g. device templates right now, are somewhere around 2254, where the psc_id for that table is now in the 2400s, so new device templates will have a primary key # of 2401, UNTIL THEY ARE cHECKED IN, at which point, when they are approved, they get renumbered in the process, to 2255, or whatever... the same is for the IR groups...SOMETIMES THIS WORKS...SOMETIMES IT DOESN'T... this is why it is critical, if you're developing templates etc, t ALWAYS KEEP YOUR DATABASE IN SYNC, BEFORE YOU MAKE CHANGES, to try and mitigate these problems...

We really need database people to come in and try to improve this situation, it's a clever schema that was hoisted upon us by a mad scientist (Aaron Baalbergen, the guy who founded Pluto, and we've had to live with it, and while some of us understand the concepts very well, none of us have audited or tried to understand sqlCVS code to try and solve these problems.

I don't know if i've managed to explain anything, or if i've confused the shit out of you, but let me know.

-Thom

[phenigma]

I created a new climate device, checked it in, and have been using it for quite some time now. I realized that I had forgotten something in one of the modes ("off") and went to go fix it. I made my change and saved. Now it dropped all the configuration and then reloaded it all as a Denon receiver. Um, what? I went and reverted in sqlCVS and no change. Now I hit reload and all my code is gone and loading up as a Denon receiver. All I was doing was trying to turn off my fan.

Help please!

What has happened is that your template, when approved, clobbered the Denon IR Group in the Denon template.  I had to fix IR group because it was affecting Denon users.  If you sqlCVS update of the IR table you should find the IR group is selectable from the IR editing window.  Your database may now be out of sync and may not be able to pick up the IR group properly.  If this is the case it will require manual intervention and fixing of your local database (a tedious task).

The reason this happened was that another template was submitted and approved after yours was submitted, but prior to it being approved.  This is a known issue with the sqlCVS system.  If you catch me on IRC this weekend Saturday aft/evening (eastern standard time) or sunday then I can help you fix your database, if needed.   Update your IR table and see if you receive the new IR Group, it is on schema and showing properly on my systems.

J.

[WhateverFits]

Thanks guys! I'm not adverse to digging into my database and fixing things. Fixing sqlCVS might be a little difficult and time consuming. I'm not afraid of a challenge, but my master's project is supposed to be taking more of my time than it is. Phenigma, I'll see if I can hit you up later, I'm out of town most of this weekend so I'm not free to work on it until next week some time.

[phenigma]

  Whenever you have the time!

J.