Concordance

Op 10-03-12 19:30, Scott Talbert schreef:
> ls -l /dev/harmony*

    ls -l /dev/harmony*
    ls: kan geen toegang krijgen tot /dev/harmony*: Bestand of map
    bestaat niet


Translated from Dutch: the folder doesn' t exist.

    ls -l /dev/bus/usb/006/003
    crw-rw-r-- 1 root root 189, 642  9 mrt 19:51 /dev/bus/usb/006/003


    grep c111 /etc/udev/rules.d/99-libconcord.rules
    SYSFS{idVendor}=="046d", SYSFS{idProduct}=="c111", MODE="0660",
    GROUP="dialout"

This last one I had already checked against the outcome of lsusb, which 
indeed reveals these product- and vendor id.

Thanks for your help!

Jogchum

On Sat, 10 Mar 2012, Jogchum Reitsma wrote:

>       ls -l /dev/bus/usb/006/003
>       crw-rw-r-- 1 root root 189, 642  9 mrt 19:51
>       /dev/bus/usb/006/003
> 
>
>       grep c111 /etc/udev/rules.d/99-libconcord.rules
>       SYSFS{idVendor}=="046d", SYSFS{idProduct}=="c111", MODE="0660",
>       GROUP="dialout"
> 
> This last one I had already checked against the outcome of lsusb, which
> indeed reveals these product- and vendor id.

Well, for some unknown reason, udev doesn't appear to be processing the 
rule correctly.  It isn't setting the dialout group on the device file. 
Are you sure that the dialout group exists?  "grep dialout /etc/group"?

You could also try running "udevadm monitor --property" and then plug in 
the remote control.  See what that outputs.

Scott

Op 10-03-12 20:23, Scott Talbert schreef:
> grep dialout /etc/group

    grep dialout /etc/group
    dialout:x:16:jogchum

So, apparently the group exists. Which comes to no suprise with me, 
since I added myself to this group trough Yast, the sysadmin tool from 
OpenSuse.

But why these udev rules are not obliged (they *are* seen, as I 
demonstrated in the messages log some posts before in this tread)? Can 
it be that the new systemd in OpenSuse 12.1 kicks in here? Should I post 
questions on the opensuse forums (but, cross posting is not netiquette, 
I know)?

regards, Jogchum

On Sat, 10 Mar 2012, Jogchum Reitsma wrote:

> Op 10-03-12 20:23, Scott Talbert schreef:
>       grep dialout /etc/group
>
>       grep dialout /etc/group
>       dialout:x:16:jogchum
> 
> So, apparently the group exists. Which comes to no suprise with me, since I
> added myself to this group trough Yast, the sysadmin tool from OpenSuse.
> 
> But why these udev rules are not obliged (they *are* seen, as I demonstrated
> in the messages log some posts before in this tread)? Can it be that the new
> systemd in OpenSuse 12.1 kicks in here? Should I post questions on the
> opensuse forums (but, cross posting is not netiquette, I know)?

One thing you could try is to change the "SYSFS" in the relevant udev rule 
to "ATTR" to see if that might fix it.

But yes, you should at the very least file a bug with OpenSUSE as this 
sounds like a problem with their packaging of concordance.

On Sat, 2012-03-10 at 20:36 -0500, Scott Talbert wrote:
> On Sat, 10 Mar 2012, Jogchum Reitsma wrote:
> 
> > Op 10-03-12 20:23, Scott Talbert schreef:
> >       grep dialout /etc/group
> >
> >       grep dialout /etc/group
> >       dialout:x:16:jogchum
> > 
> > So, apparently the group exists. Which comes to no suprise with me, since I
> > added myself to this group trough Yast, the sysadmin tool from OpenSuse.
> > 
> > But why these udev rules are not obliged (they *are* seen, as I demonstrated
> > in the messages log some posts before in this tread)? Can it be that the new
> > systemd in OpenSuse 12.1 kicks in here? Should I post questions on the
> > opensuse forums (but, cross posting is not netiquette, I know)?
> 
> One thing you could try is to change the "SYSFS" in the relevant udev rule 
> to "ATTR" to see if that might fix it.
> 
> But yes, you should at the very least file a bug with OpenSUSE as this 
> sounds like a problem with their packaging of concordance.

Scott - I mailed a fairly large patch to this list back in January,
together with extensive explanation / justification, which should
considerably improve the behaviour of libconcord in re udev on modern
distros. I didn't hear any kind of reply, though. I was hoping it would
be merged upstream.

I suspect the SYSFS/ATTR thing may well be to blame here, yes. Recent
udev builds have now stopped just warning about the SYSFS syntax (which
has been deprecated for about five years, IIRC) and now flat out refuse
it.

My patch fixes that, and also takes advantage of udev's ACL support to
allow access to the remote for locally logged-in users (only) with no
abuse of the 'dialout' group.

The post I made was:

http://sourceforge.net/mailarchive/forum.php?thread_name=1326769277.1782.23.camel%40adam&forum_name=concordance-devel

The patch is still being carried in Fedora's libconcord:

http://pkgs.fedoraproject.org/gitweb/?p=libconcord.git;a=blob;f=libconcord-0.23-modern_udev.patch;h=5efd8f4a41db0f7977bcefda3cd7c5456ffc0110;hb=HEAD

so users of Fedora get seamless access to Harmony remotes, it 'just
works' so long as libconcord and congruity are installed.

Jogchum, you may find this patch useful on openSUSE 12.1. I suspect it
probably has a new enough udev to use the 'new-generation udev' stuff in
my patch.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

Op 11-03-12 02:36, Scott Talbert schreef:
> On Sat, 10 Mar 2012, Jogchum Reitsma wrote:
>
>> Op 10-03-12 20:23, Scott Talbert schreef:
>>        grep dialout /etc/group
>>
>>        grep dialout /etc/group
>>        dialout:x:16:jogchum
>>
>> So, apparently the group exists. Which comes to no suprise with me, since I
>> added myself to this group trough Yast, the sysadmin tool from OpenSuse.
>>
>> But why these udev rules are not obliged (they *are* seen, as I demonstrated
>> in the messages log some posts before in this tread)? Can it be that the new
>> systemd in OpenSuse 12.1 kicks in here? Should I post questions on the
>> opensuse forums (but, cross posting is not netiquette, I know)?
> One thing you could try is to change the "SYSFS" in the relevant udev rule
> to "ATTR" to see if that might fix it.
>
> But yes, you should at the very least file a bug with OpenSUSE as this
> sounds like a problem with their packaging of concordance.
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> concordance-devel mailing list
> concordance-devel@...
> https://lists.sourceforge.net/lists/listinfo/concordance-devel
>
Indeed after changing SYSFS to ATTR (on all relevant lines), and BUS to 
SUBSYSTEM (on line 4) I can see the Harmony with concordance -iv without 
being root.

In the dialogue chain website-congruity-remote the remote is detected by 
congruity in the first step, and the site is notified of this success.

Now the second step - the real update - goes wrong: the site gathers the 
info to be transported to the remote, and congruity pops up OK,
"Check website"  and " Prepare Remote" are OK, but then " Erase Flash" 
fails (and all the subsequent steps are not taken, of course). Congruity 
gives these details:

      Error while erasing flash
         (libconcord function erase_config error 6)

    Traceback (most recent call last):
       File "/usr/local/bin/congruity", line 702, in _WorkerFunction
         self._WorkerFunctionBody()
       File "/usr/local/bin/congruity", line 838, in _WorkerFunctionBody
         py_object((self._DgUpdate, self.dg_erase))
       File "/usr/local/lib/python2.7/site-packages/libconcord.py", line
    97, in __call__
         raise LibConcordException(self.func_name, result)
    LibConcordException: libconcord function 'erase_config' failed with
    error code 6 ('Error while erasing flash')

lsusb and concordance -iv (issued as normal user) still see the remote, 
so it seems to me this new failure has nothing to do with the udev rules.

Any hints? Is logging available?

Thanks again!

PS AFAICS OpenSuse 12.1 has no concordance or congruity packaged; I 
compiled it from source.

Op 11-03-12 03:12, Adam Williamson schreef:
> On Sat, 2012-03-10 at 20:36 -0500, Scott Talbert wrote:
>> On Sat, 10 Mar 2012, Jogchum Reitsma wrote:
>>
>>> Op 10-03-12 20:23, Scott Talbert schreef:
>>>        grep dialout /etc/group
>>>
>>>        grep dialout /etc/group
>>>        dialout:x:16:jogchum
>>>
>>> So, apparently the group exists. Which comes to no suprise with me, since I
>>> added myself to this group trough Yast, the sysadmin tool from OpenSuse.
>>>
>>> But why these udev rules are not obliged (they *are* seen, as I demonstrated
>>> in the messages log some posts before in this tread)? Can it be that the new
>>> systemd in OpenSuse 12.1 kicks in here? Should I post questions on the
>>> opensuse forums (but, cross posting is not netiquette, I know)?
>> One thing you could try is to change the "SYSFS" in the relevant udev rule
>> to "ATTR" to see if that might fix it.
>>
>> But yes, you should at the very least file a bug with OpenSUSE as this
>> sounds like a problem with their packaging of concordance.
> Scott - I mailed a fairly large patch to this list back in January,
> together with extensive explanation / justification, which should
> considerably improve the behaviour of libconcord in re udev on modern
> distros. I didn't hear any kind of reply, though. I was hoping it would
> be merged upstream.
>
> I suspect the SYSFS/ATTR thing may well be to blame here, yes. Recent
> udev builds have now stopped just warning about the SYSFS syntax (which
> has been deprecated for about five years, IIRC) and now flat out refuse
> it.
>
> My patch fixes that, and also takes advantage of udev's ACL support to
> allow access to the remote for locally logged-in users (only) with no
> abuse of the 'dialout' group.
>
> The post I made was:
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=1326769277.1782.23.camel%40adam&forum_name=concordance-devel
>
> The patch is still being carried in Fedora's libconcord:
>
> http://pkgs.fedoraproject.org/gitweb/?p=libconcord.git;a=blob;f=libconcord-0.23-modern_udev.patch;h=5efd8f4a41db0f7977bcefda3cd7c5456ffc0110;hb=HEAD
>
> so users of Fedora get seamless access to Harmony remotes, it 'just
> works' so long as libconcord and congruity are installed.
>
> Jogchum, you may find this patch useful on openSUSE 12.1. I suspect it
> probably has a new enough udev to use the 'new-generation udev' stuff in
> my patch.
Adam,

Thanks. As you can see from my last reply to Scott, updating the rules 
file has made it possible to get access to the remote as a normal user, 
so this problem was solved that way.

I suppose this patch is a rules-file itself, so I can take it, remove 
line numbering and save it as 70-acl.rules in /etc/udev/rules.d ? Done 
so already, so I hope my assumption is correct...

regards, Jogchum

On Sun, 2012-03-11 at 14:36 +0100, Jogchum Reitsma wrote:
> Op 11-03-12 03:12, Adam Williamson schreef:
> > On Sat, 2012-03-10 at 20:36 -0500, Scott Talbert wrote:
> >> On Sat, 10 Mar 2012, Jogchum Reitsma wrote:
> >>
> >>> Op 10-03-12 20:23, Scott Talbert schreef:
> >>>        grep dialout /etc/group
> >>>
> >>>        grep dialout /etc/group
> >>>        dialout:x:16:jogchum
> >>>
> >>> So, apparently the group exists. Which comes to no suprise with me, since I
> >>> added myself to this group trough Yast, the sysadmin tool from OpenSuse.
> >>>
> >>> But why these udev rules are not obliged (they *are* seen, as I demonstrated
> >>> in the messages log some posts before in this tread)? Can it be that the new
> >>> systemd in OpenSuse 12.1 kicks in here? Should I post questions on the
> >>> opensuse forums (but, cross posting is not netiquette, I know)?
> >> One thing you could try is to change the "SYSFS" in the relevant udev rule
> >> to "ATTR" to see if that might fix it.
> >>
> >> But yes, you should at the very least file a bug with OpenSUSE as this
> >> sounds like a problem with their packaging of concordance.
> > Scott - I mailed a fairly large patch to this list back in January,
> > together with extensive explanation / justification, which should
> > considerably improve the behaviour of libconcord in re udev on modern
> > distros. I didn't hear any kind of reply, though. I was hoping it would
> > be merged upstream.
> >
> > I suspect the SYSFS/ATTR thing may well be to blame here, yes. Recent
> > udev builds have now stopped just warning about the SYSFS syntax (which
> > has been deprecated for about five years, IIRC) and now flat out refuse
> > it.
> >
> > My patch fixes that, and also takes advantage of udev's ACL support to
> > allow access to the remote for locally logged-in users (only) with no
> > abuse of the 'dialout' group.
> >
> > The post I made was:
> >
> > http://sourceforge.net/mailarchive/forum.php?thread_name=1326769277.1782.23.camel%40adam&forum_name=concordance-devel
> >
> > The patch is still being carried in Fedora's libconcord:
> >
> > http://pkgs.fedoraproject.org/gitweb/?p=libconcord.git;a=blob;f=libconcord-0.23-modern_udev.patch;h=5efd8f4a41db0f7977bcefda3cd7c5456ffc0110;hb=HEAD
> >
> > so users of Fedora get seamless access to Harmony remotes, it 'just
> > works' so long as libconcord and congruity are installed.
> >
> > Jogchum, you may find this patch useful on openSUSE 12.1. I suspect it
> > probably has a new enough udev to use the 'new-generation udev' stuff in
> > my patch.
> Adam,
> 
> Thanks. As you can see from my last reply to Scott, updating the rules 
> file has made it possible to get access to the remote as a normal user, 
> so this problem was solved that way.
> 
> I suppose this patch is a rules-file itself, so I can take it, remove 
> line numbering and save it as 70-acl.rules in /etc/udev/rules.d ? Done 
> so already, so I hope my assumption is correct...

Um...no, not really. When libconcord is built it 'generates' the udev
rules file, depending on whether you tell it to use generic udev
support, hal/consolekit support or hal/policykit support. The basic rule
template that's used gets changed based on which you ask for, and a
simple script builds a udev rules file with several dozen lines, each
based on the template selected, one for each Harmony USB ID libconcord
knows of.

My patch is to libconcord's udev rules generation script; it renames the
existing 'generic udev' template to be 'old udev' support and replaces
it with a new 'generic udev' template which uses modern syntax and also
uses udev's ACL support to make the node accessible to all
locally-logged in users, no special group membership required. It also
patches the docs to explain this.

So no, you can't just rename any file in the patch and save it as a udev
rule, that's not going to work. But you could edit your existing
libconcord rules file and adjust it to match my
UDEV_NEW_NO_POLICY_TEMPLATE, which is:

ATTR{idVendor}=="%s", ATTR{idProduct}=="%s", ENV{ID_REMOTE_CONTROL}="1"
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

On 03/10/2012 06:12 PM, Adam Williamson wrote:
> On Sat, 2012-03-10 at 20:36 -0500, Scott Talbert wrote:
>> On Sat, 10 Mar 2012, Jogchum Reitsma wrote:
>>
>>> Op 10-03-12 20:23, Scott Talbert schreef:
>>>       grep dialout /etc/group
>>>
>>>       grep dialout /etc/group
>>>       dialout:x:16:jogchum
>>>
>>> So, apparently the group exists. Which comes to no suprise with me, since I
>>> added myself to this group trough Yast, the sysadmin tool from OpenSuse.
>>>
>>> But why these udev rules are not obliged (they *are* seen, as I demonstrated
>>> in the messages log some posts before in this tread)? Can it be that the new
>>> systemd in OpenSuse 12.1 kicks in here? Should I post questions on the
>>> opensuse forums (but, cross posting is not netiquette, I know)?
>>
>> One thing you could try is to change the "SYSFS" in the relevant udev rule 
>> to "ATTR" to see if that might fix it.
>>
>> But yes, you should at the very least file a bug with OpenSUSE as this 
>> sounds like a problem with their packaging of concordance.
> 
> Scott - I mailed a fairly large patch to this list back in January,
> together with extensive explanation / justification, which should
> considerably improve the behaviour of libconcord in re udev on modern
> distros. I didn't hear any kind of reply, though. I was hoping it would
> be merged upstream.

Sorry, I completely missed that email. Lemme go find it and reply.

-- 
Phil Dibowitz                             phil@...
Open Source software and tech docs        Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't matter
 and those who matter don't mind."
 - Dr. Seuss

On Sun, 11 Mar 2012, Jogchum Reitsma wrote:

> Now the second step - the real update - goes wrong: the site gathers the
> info to be transported to the remote, and congruity pops up OK,
> "Check website"  and " Prepare Remote" are OK, but then " Erase Flash" fails
> (and all the subsequent steps are not taken, of course). Congruity gives
> these details:
>
>        Error while erasing flash
>           (libconcord function erase_config error 6)
> 
> lsusb and concordance -iv (issued as normal user) still see the remote, so
> it seems to me this new failure has nothing to do with the udev rules.
> 
> Any hints? Is logging available?

Yes, this probably doesn't have anything to do with udev rules.  Can you 
try recompiling concordance with debug enabled:

./configure CPPFLAGS=-D_DEBUG

and then re-run your configuration update, but from concordance directly, 
ie, instead download the Update.EZHex file and run "concordance 
Update.EZHex"

Scott

Op 12-03-12 03:41, Scott Talbert schreef:
> concordance Update.EZHex
Results are:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
concordance Update.EZHex
Concordance 0.23
Copyright 2007 Kevin Timmerman and Phil Dibowitz
This software is distributed under the GPLv3.

DEBUG (FindRemote): bNumEndpoints 2
DEBUG (check_ep): address 81 attrib 03 max_length 64
DEBUG (check_ep): address 02 attrib 03 max_length 64
Requesting Identity: 100%                 done
DEBUG (find_config_binary): actual data size 101382
DEBUG (find_config_binary): reported data size 101382
DEBUG (find_config_binary): reported checksum 12 0c
DEBUG (find_config_binary): actual checksum 12 0c
DEBUG (Post): Connecting to: members.harmonyremote.com
DEBUG (Post): Path: EasyZapper/New/ProcUpdate/Receive_Zaps.asp
DEBUG (Post): Cookie: HR%5FUSER%5FLANGUAGE=nld; SKIN%5FID=Harmony; 
PSWD=QI%2F7kqiPfaui5F56sTf0Aw%3D%3D; AUSER=jehojakim; 
CREATE%5FTIME=20090429+142628; IS%5FRETURNING%5FUSER=True; 
CookieKeyValue=%7B6A02E1FB%2DBE01%2D6802%2DB3D8%2D9DDF00018E2B%7D%7B6AF8D7ED%2D0012%2D6AA6%2D0001%2D8E6BBFD80BE2%7D%7B51220104%2D0100%2D258E%2DA96E%2DA680B0D8A8CF%7D; 
ServerID=1107; ASPSESSIONIDAABSQQTR=AHPGGCJABHDNJIEMMOEJNKPB; 
HRLB=17230128161042410837; ASPSESSIONIDCACQRTRQ=MGPOBCODFJFJHMDFJCHBPLFC
DEBUG (Post): UserId: 5329309
DEBUG (Post): post data: 
<EASYZAPPERDATA><DATAVALUES/><EVENTS/><VERSIONINFORMATION><VERSION><CLIENTSOFTWARE>7.3.0</CLIENTSOFTWARE><CLIENTSOFTWARETYPE>Windows 
XP 
(x86.1):Java</CLIENTSOFTWARETYPE><SOFTWARE>3.0</SOFTWARE><SOFTWARETYPE>0</SOFTWARETYPE><ID>{6A02E1FB-BE01-6802-B3D8-9DDF00018E2B}{6AF8D7ED-0012-6AA6-0001-8E6BBFD80BE2}{51220104-0100-258E-A96E-A680B0D8A8CF}</ID><BOARD>3.0.0</BOARD><FLASH>0xFF:0x12</FLASH><PROTOCOL>9</PROTOCOL><ARCHITECTURE>9</ARCHITECTURE><SKIN>22</SKIN><REGIONS/></VERSION></VERSIONINFORMATION></EASYZAPPERDATA>

DEBUG (Post): 
Data=%3CEASYZAPPERDATA%3E%3CDATAVALUES%2F%3E%3CEVENTS%2F%3E%3CVERSIONINFORMATION%3E%3CVERSION%3E%3CCLIENTSOFTWARE%3E7.3.0%3C%2FCLIENTSOFTWARE%3E%3CCLIENTSOFTWARETYPE%3EWindows%20XP%20(x86.1)%3AJava%3C%2FCLIENTSOFTWARETYPE%3E%3CSOFTWARE%3E3.0%3C%2FSOFTWARE%3E%3CSOFTWARETYPE%3E0%3C%2FSOFTWARETYPE%3E%3CID%3E%7B6A02E1FB-BE01-6802-B3D8-9DDF00018E2B%7D%7B6AF8D7ED-0012-6AA6-0001-8E6BBFD80BE2%7D%7B51220104-0100-258E-A96E-A680B0D8A8CF%7D%3C%2FID%3E%3CBOARD%3E3.0.0%3C%2FBOARD%3E%3CFLASH%3E0xFF%3A0x12%3C%2FFLASH%3E%3CPROTOCOL%3E9%3C%2FPROTOCOL%3E%3CARCHITECTURE%3E9%3C%2FARCHITECTURE%3E%3CSKIN%3E22%3C%2FSKIN%3E%3CREGIONS%2F%3E%3C%2FVERSION%3E%3C%2FVERSIONINFORMATION%3E%3C%2FEASYZAPPERDATA%3E%0D%0A&UserId=5329309
DEBUG (Post): POST /EasyZapper/New/ProcUpdate/Receive_Zaps.asp HTTP/1.1
User-Agent: HarmonyBrowser/7.3.0 (Build 15; UpdatedFrom 7.3.0.15; Skin 
logitech; Windows XP 5.1; x86; en; rv: 1.8.0.2) Gecko/20060125
Content-Type:  application/x-www-form-urlencoded
Host: members.harmonyremote.com
Cookie: HR%5FUSER%5FLANGUAGE=nld; SKIN%5FID=Harmony; 
PSWD=QI%2F7kqiPfaui5F56sTf0Aw%3D%3D; AUSER=jehojakim; 
CREATE%5FTIME=20090429+142628; IS%5FRETURNING%5FUSER=True; 
CookieKeyValue=%7B6A02E1FB%2DBE01%2D6802%2DB3D8%2D9DDF00018E2B%7D%7B6AF8D7ED%2D0012%2D6AA6%2D0001%2D8E6BBFD80BE2%7D%7B51220104%2D0100%2D258E%2DA96E%2DA680B0D8A8CF%7D; 
ServerID=1107; ASPSESSIONIDAABSQQTR=AHPGGCJABHDNJIEMMOEJNKPB; 
HRLB=17230128161042410837; ASPSESSIONIDCACQRTRQ=MGPOBCODFJFJHMDFJCHBPLFC
Content-Length: 709


DEBUG (Zap): Connected!
DEBUG (Zap): 769 bytes sent
DEBUG (Zap): 709 bytes sent
DEBUG (Zap): Received: HTTP/1.1 200 OK
Date: Mon, 12 Mar 2012 16:00:57 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Length: 59
Content-Type: text/xml
Cache-control: private

<?xml version="1.0" ?><DATA><RESULT>Success</RESULT></DATA>
DEBUG (Zap): done with web post
Preparing Update:                         done
Invalidating Flash:                       done
DEBUG (HID_ReadReport): Timeout on interrupt read from device
Erasing Flash:       Failed to upload config: Error while erasing flash
Failed with error 6
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Hope this info gives some light...

Jogchum

Tried it, just to be sure, also as root: same result.

Jogchum

On Mon, 12 Mar 2012, Jogchum Reitsma wrote:

> Preparing Update:                         done
> Invalidating Flash:                       done
> DEBUG (HID_ReadReport): Timeout on interrupt read from device
> Erasing Flash:       Failed to upload config: Error while erasing flash
> Failed with error 6

Looking into this some, it looks like there may be an existing bug in 0.23 
for the Harmony 525, but it appears to be fixed in CVS.  Can you try using 
the version in CVS?

Scott

On 03/12/2012 05:39 PM, Scott Talbert wrote:
> On Mon, 12 Mar 2012, Jogchum Reitsma wrote:
> 
>> Preparing Update:                         done
>> Invalidating Flash:                       done
>> DEBUG (HID_ReadReport): Timeout on interrupt read from device
>> Erasing Flash:       Failed to upload config: Error while erasing flash
>> Failed with error 6
> 
> Looking into this some, it looks like there may be an existing bug in 0.23 
> for the Harmony 525, but it appears to be fixed in CVS.  Can you try using 
> the version in CVS?

Huh? I don't see anything in CVS to remote.cpp or libconcord.cpp since 0.23
was released. The last 5xx fix was 1.39 to libconcord/libconcord.cpp.

I do see this:

http://sourceforge.net/tracker/?func=detail&aid=3469523&group_id=201579&atid=978127

I have usblogs for the 550... which I was under the impression, was the same
architecture as the 525... but that could be incorrect.

Can I get a 'concordance -vi'? I have a feeling I'm going to need snoopypro
logs from a windows box in order to fix this.

-- 
Phil Dibowitz                             phil@...
Open Source software and tech docs        Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't matter
 and those who matter don't mind."
 - Dr. Seuss

>> Looking into this some, it looks like there may be an existing bug in
>> 0.23
>> for the Harmony 525, but it appears to be fixed in CVS.  Can you try
>> using
>> the version in CVS?
>
> Huh? I don't see anything in CVS to remote.cpp or libconcord.cpp since
> 0.23
> was released. The last 5xx fix was 1.39 to libconcord/libconcord.cpp.
>
> I do see this:
>
> http://sourceforge.net/tracker/?func=detail&aid=3469523&group_id=201579&atid=978127

This is what I was looking at (remote_info.h):

Revision 1.13 - (view) (download) (as text) (annotate) - [select for diffs]
Sun Mar 13 09:39:14 2011 UTC (12 months ago) by jaymzh
Branch: MAIN
Changes since 1.12: +2 -2 lines
Diff to previous 1.12

From: Stephen Warren <s-t-concordance@...>

Fix the flash_base for 525 which was broken in the reformat.

Signed-off-by: Stephen Warren <s-t-concordance@...>
Signed-off-by: Phil Dibowitz <phil@...>

On Tue, 2012-03-13 at 00:25 -0400, Scott Talbert wrote:
> >> Looking into this some, it looks like there may be an existing bug in
> >> 0.23
> >> for the Harmony 525, but it appears to be fixed in CVS.  Can you try
> >> using
> >> the version in CVS?
> >
> > Huh? I don't see anything in CVS to remote.cpp or libconcord.cpp since
> > 0.23
> > was released. The last 5xx fix was 1.39 to libconcord/libconcord.cpp.
> >
> > I do see this:
> >
> > http://sourceforge.net/tracker/?func=detail&aid=3469523&group_id=201579&atid=978127
> 
> This is what I was looking at (remote_info.h):
> 
> Revision 1.13 - (view) (download) (as text) (annotate) - [select for diffs]
> Sun Mar 13 09:39:14 2011 UTC (12 months ago) by jaymzh
> Branch: MAIN
> Changes since 1.12: +2 -2 lines
> Diff to previous 1.12
> 
> From: Stephen Warren <s-t-concordance@...>
> 
> Fix the flash_base for 525 which was broken in the reformat.
> 
> Signed-off-by: Stephen Warren <s-t-concordance@...>
> Signed-off-by: Phil Dibowitz <phil@...>

That one definitely broke several remotes, yes. We had a Fedora bug open
on it:

https://bugzilla.redhat.com/show_bug.cgi?id=772517

and several reporters with 5xx models reported that the update (which
backported that patch) fixed it. So it does seem that's very likely
Jogchum's problem.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

On 03/12/2012 09:25 PM, Scott Talbert wrote:
>>> Looking into this some, it looks like there may be an existing bug in
>>> 0.23
>>> for the Harmony 525, but it appears to be fixed in CVS.  Can you try
>>> using
>>> the version in CVS?
>>
>> Huh? I don't see anything in CVS to remote.cpp or libconcord.cpp since
>> 0.23
>> was released. The last 5xx fix was 1.39 to libconcord/libconcord.cpp.
>>
>> I do see this:
>>
>> http://sourceforge.net/tracker/?func=detail&aid=3469523&group_id=201579&atid=978127
> 
> This is what I was looking at (remote_info.h):
> 
> Revision 1.13 - (view) (download) (as text) (annotate) - [select for diffs]
> Sun Mar 13 09:39:14 2011 UTC (12 months ago) by jaymzh
> Branch: MAIN
> Changes since 1.12: +2 -2 lines
> Diff to previous 1.12
> 
> From: Stephen Warren <s-t-concordance@...>
> 
> Fix the flash_base for 525 which was broken in the reformat.
> 
> Signed-off-by: Stephen Warren <s-t-concordance@...>
> Signed-off-by: Phil Dibowitz <phil@...>

Ah, good call.

However, the bug I link to sees the same issue in January of this year with
HEAD :(

-- 
Phil Dibowitz                             phil@...
Open Source software and tech docs        Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't matter
 and those who matter don't mind."
 - Dr. Seuss

Op 13-03-12 05:18, Phil Dibowitz schreef:
> On 03/12/2012 05:39 PM, Scott Talbert wrote:
>> On Mon, 12 Mar 2012, Jogchum Reitsma wrote:
>>
>>> Preparing Update:                         done
>>> Invalidating Flash:                       done
>>> DEBUG (HID_ReadReport): Timeout on interrupt read from device
>>> Erasing Flash:       Failed to upload config: Error while erasing flash
>>> Failed with error 6
>> Looking into this some, it looks like there may be an existing bug in 0.23
>> for the Harmony 525, but it appears to be fixed in CVS.  Can you try using
>> the version in CVS?
> Huh? I don't see anything in CVS to remote.cpp or libconcord.cpp since 0.23
> was released. The last 5xx fix was 1.39 to libconcord/libconcord.cpp.
>
> I do see this:
>
> http://sourceforge.net/tracker/?func=detail&aid=3469523&group_id=201579&atid=978127
>
> I have usblogs for the 550... which I was under the impression, was the same
> architecture as the 525... but that could be incorrect.
>
> Can I get a 'concordance -vi'? I have a feeling I'm going to need snoopypro
> logs from a windows box in order to fix this.
concordance -iv
Concordance 0.23
Copyright 2007 Kevin Timmerman and Phil Dibowitz
This software is distributed under the GPLv3.

DEBUG (FindRemote): bNumEndpoints 2
DEBUG (check_ep): address 81 attrib 03 max_length 64
DEBUG (check_ep): address 02 attrib 03 max_length 64
Requesting Identity: 100%                 done
   Model: Logitech Harmony 525 (Mocha Decaf)
   Skin: 22
   Firmware Version: 3.0
   Firmware Type: 0
   Hardware Version: 3.0
   External Flash: 512 KiB - FF:12 25F040
   Architecture: 9
   Protocol: 9
   Manufacturer: Harmony Remote 0-3.0.0
   Product: Harmony Remote 0-3.0.0
   IRL, ORL, FRL: 64, 64, 0
   USB VID: 046D
   USB PID: C111
   USB Ver: 0916
   Serial Number: {6A02E1FB-BE01-6802-B3D8-9DDF00018E2B}
         {6AF8D7ED-0012-6AA6-0001-8E6BBFD80BE2}
         {51220104-0100-258E-A96E-A680B0D8A8CF}
   Config Flash Used: 103% (-8104 of -7808 KiB)

Success!


Regards, Jogchum (this line is not from concordance -iv  :-) )

On 03/12/2012 10:34 PM, Jogchum Reitsma wrote:
>    Serial Number: {6A02E1FB-BE01-6802-B3D8-9DDF00018E2B}
>          {6AF8D7ED-0012-6AA6-0001-8E6BBFD80BE2}
>          {51220104-0100-258E-A96E-A680B0D8A8CF}
>    Config Flash Used: 103% (-8104 of -7808 KiB)

That's a fun bug, lol.

> Regards, Jogchum (this line is not from concordance -iv  :-) )

Adam and Scott are right - there's a huge 525 bugfix in CVS head, can you
check that out and build? Let me know if you any problems with that. If that
doesn't fix it, we'll have to dig deeper.

Thanks.

-- 
Phil Dibowitz                             phil@...
Open Source software and tech docs        Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't matter
 and those who matter don't mind."
 - Dr. Seuss

On 03/12/2012 10:37 PM, Phil Dibowitz wrote:
> On 03/12/2012 10:34 PM, Jogchum Reitsma wrote:
>>    Serial Number: {6A02E1FB-BE01-6802-B3D8-9DDF00018E2B}
>>          {6AF8D7ED-0012-6AA6-0001-8E6BBFD80BE2}
>>          {51220104-0100-258E-A96E-A680B0D8A8CF}
>>    Config Flash Used: 103% (-8104 of -7808 KiB)
> 
> That's a fun bug, lol.
> 
>> Regards, Jogchum (this line is not from concordance -iv  :-) )
> 
> Adam and Scott are right - there's a huge 525 bugfix in CVS head, can you
> check that out and build? Let me know if you any problems with that. If that
> doesn't fix it, we'll have to dig deeper.

The bug filed in January was just confirmed fixed in CVS HEAD, so I'm extra
sure that your bug is fixed in HEAD.

(For those curious, I'm assuming since the bug was fixed on March 13, 2011 and
the bug was filed in January 2012 the dude claiming he'd tried CVS HEAD had
made a mistake.)

-- 
Phil Dibowitz                             phil@...
Open Source software and tech docs        Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't matter
 and those who matter don't mind."
 - Dr. Seuss

Op 13-03-12 16:28, Phil Dibowitz schreef:
> On 03/12/2012 10:37 PM, Phil Dibowitz wrote:
>> On 03/12/2012 10:34 PM, Jogchum Reitsma wrote:
>>>     Serial Number: {6A02E1FB-BE01-6802-B3D8-9DDF00018E2B}
>>>           {6AF8D7ED-0012-6AA6-0001-8E6BBFD80BE2}
>>>           {51220104-0100-258E-A96E-A680B0D8A8CF}
>>>     Config Flash Used: 103% (-8104 of -7808 KiB)
>> That's a fun bug, lol.
>>
>>> Regards, Jogchum (this line is not from concordance -iv  :-) )
>> Adam and Scott are right - there's a huge 525 bugfix in CVS head, can you
>> check that out and build? Let me know if you any problems with that. If that
>> doesn't fix it, we'll have to dig deeper.
> The bug filed in January was just confirmed fixed in CVS HEAD, so I'm extra
> sure that your bug is fixed in HEAD.
>
> (For those curious, I'm assuming since the bug was fixed on March 13, 2011 and
> the bug was filed in January 2012 the dude claiming he'd tried CVS HEAD had
> made a mistake.)
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
>
>
> _______________________________________________
> concordance-devel mailing list
> concordance-devel@...
> https://lists.sourceforge.net/lists/listinfo/concordance-devel

I downloaded the GNU tarball from CVS, and compiled it with debug 
settings enabled. Though I have yet to test the remote itself, things 
seem to go a lot better. Outcome as follows:

concordance Update.EZHex
> Concordance 0.23
> Copyright 2007 Kevin Timmerman and Phil Dibowitz
> This software is distributed under the GPLv3.
>
> DEBUG (FindRemote): bNumEndpoints 2
> DEBUG (check_ep): address 81 attrib 03 max_length 64
> DEBUG (check_ep): address 02 attrib 03 max_length 64
> Requesting Identity: 100%                 done
> DEBUG (find_config_binary): actual data size 101382
> DEBUG (find_config_binary): reported data size 101382
> DEBUG (find_config_binary): reported checksum 12 0c
> DEBUG (find_config_binary): actual checksum 12 0c
> DEBUG (Post): Connecting to: members.harmonyremote.com
> DEBUG (Post): Path: EasyZapper/New/ProcUpdate/Receive_Zaps.asp
> DEBUG (Post): Cookie: HR%5FUSER%5FLANGUAGE=nld; SKIN%5FID=Harmony; PSWD=QI%2F7kqiPfaui5F56sTf0Aw%3D%3D; AUSER=jehojakim; CREATE%5FTIME=20090429+142628; IS%5FRETURNING%5FUSER=True; CookieKeyValue=%7B6A02E1FB%2DBE01%2D6802%2DB3D8%2D9DDF00018E2B%7D%7B6AF8D7ED%2D0012%2D6AA6%2D0001%2D8E6BBFD80BE2%7D%7B51220104%2D0100%2D258E%2DA96E%2DA680B0D8A8CF%7D; ServerID=1107; ASPSESSIONIDAABSQQTR=AHPGGCJABHDNJIEMMOEJNKPB; HRLB=17230128161042410837; ASPSESSIONIDCACQRTRQ=MGPOBCODFJFJHMDFJCHBPLFC
> DEBUG (Post): UserId: 5329309
> DEBUG (Post): post data:<EASYZAPPERDATA><DATAVALUES/><EVENTS/><VERSIONINFORMATION><VERSION><CLIENTSOFTWARE>7.3.0</CLIENTSOFTWARE><CLIENTSOFTWARETYPE>Windows XP (x86.1):Java</CLIENTSOFTWARETYPE><SOFTWARE>3.0</SOFTWARE><SOFTWARETYPE>0</SOFTWARETYPE><ID>{6A02E1FB-BE01-6802-B3D8-9DDF00018E2B}{6AF8D7ED-0012-6AA6-0001-8E6BBFD80BE2}{51220104-0100-258E-A96E-A680B0D8A8CF}</ID><BOARD>3.0.0</BOARD><FLASH>0xFF:0x12</FLASH><PROTOCOL>9</PROTOCOL><ARCHITECTURE>9</ARCHITECTURE><SKIN>22</SKIN><REGIONS/></VERSION></VERSIONINFORMATION></EASYZAPPERDATA>
>
> DEBUG (Post): Data=%3CEASYZAPPERDATA%3E%3CDATAVALUES%2F%3E%3CEVENTS%2F%3E%3CVERSIONINFORMATION%3E%3CVERSION%3E%3CCLIENTSOFTWARE%3E7.3.0%3C%2FCLIENTSOFTWARE%3E%3CCLIENTSOFTWARETYPE%3EWindows%20XP%20(x86.1)%3AJava%3C%2FCLIENTSOFTWARETYPE%3E%3CSOFTWARE%3E3.0%3C%2FSOFTWARE%3E%3CSOFTWARETYPE%3E0%3C%2FSOFTWARETYPE%3E%3CID%3E%7B6A02E1FB-BE01-6802-B3D8-9DDF00018E2B%7D%7B6AF8D7ED-0012-6AA6-0001-8E6BBFD80BE2%7D%7B51220104-0100-258E-A96E-A680B0D8A8CF%7D%3C%2FID%3E%3CBOARD%3E3.0.0%3C%2FBOARD%3E%3CFLASH%3E0xFF%3A0x12%3C%2FFLASH%3E%3CPROTOCOL%3E9%3C%2FPROTOCOL%3E%3CARCHITECTURE%3E9%3C%2FARCHITECTURE%3E%3CSKIN%3E22%3C%2FSKIN%3E%3CREGIONS%2F%3E%3C%2FVERSION%3E%3C%2FVERSIONINFORMATION%3E%3C%2FEASYZAPPERDATA%3E%0D%0A&UserId=5329309
> DEBUG (Post): POST /EasyZapper/New/ProcUpdate/Receive_Zaps.asp HTTP/1.1
> User-Agent: HarmonyBrowser/7.3.0 (Build 15; UpdatedFrom 7.3.0.15; Skin logitech; Windows XP 5.1; x86; en; rv: 1.8.0.2) Gecko/20060125
> Content-Type:  application/x-www-form-urlencoded
> Host: members.harmonyremote.com
> Cookie: HR%5FUSER%5FLANGUAGE=nld; SKIN%5FID=Harmony; PSWD=QI%2F7kqiPfaui5F56sTf0Aw%3D%3D; AUSER=jehojakim; CREATE%5FTIME=20090429+142628; IS%5FRETURNING%5FUSER=True; CookieKeyValue=%7B6A02E1FB%2DBE01%2D6802%2DB3D8%2D9DDF00018E2B%7D%7B6AF8D7ED%2D0012%2D6AA6%2D0001%2D8E6BBFD80BE2%7D%7B51220104%2D0100%2D258E%2DA96E%2DA680B0D8A8CF%7D; ServerID=1107; ASPSESSIONIDAABSQQTR=AHPGGCJABHDNJIEMMOEJNKPB; HRLB=17230128161042410837; ASPSESSIONIDCACQRTRQ=MGPOBCODFJFJHMDFJCHBPLFC
> Content-Length: 709
>
>
> DEBUG (Zap): Connected!
> DEBUG (Zap): 769 bytes sent
> DEBUG (Zap): 709 bytes sent
> DEBUG (Zap): Received: HTTP/1.1 200 OK
> Date: Tue, 13 Mar 2012 16:23:08 GMT
> Server: Microsoft-IIS/6.0
> X-Powered-By: ASP.NET
> Content-Length: 59
> Content-Type: text/xml
> Cache-control: private
>
> <?xml version="1.0" ?><DATA><RESULT>Success</RESULT></DATA>
> DEBUG (Zap): done with web post
> Preparing Update:                         done
> Invalidating Flash:                       done
> Erasing Flash:        50%          DEBUG (EraseFlash): erase sector  2: 820000 - 830000
> 100%          DEBUG (EraseFlash): erase sector  3: 830000 - 840000
>         done
> Writing Config:      100%    99 KiB       done
> Verifying Config:    100%    99 KiB       done
> Finalizing Update:                        done
> DEBUG (FindRemote): bNumEndpoints 2
> DEBUG (check_ep): address 81 attrib 03 max_length 64
> DEBUG (check_ep): address 02 attrib 03 max_length 64
> DEBUG (HID_ReadReport): Timeout on interrupt read from device
> DEBUG (GetIdentity): Failed to read from remote
> DEBUG (FindRemote): bNumEndpoints 2
> DEBUG (check_ep): address 81 attrib 03 max_length 64
> DEBUG (check_ep): address 02 attrib 03 max_length 64
> Resetting Remote:    100%                 done
> DEBUG (HID_ReadReport): Timeout on interrupt read from device
> Setting Time:                             done
> DEBUG (Post): Connecting to: members.harmonyremote.com
> DEBUG (Post): Path: EasyZapper/New/ProcUpdate/Receive_Complete.asp
> DEBUG (Post): Cookie: HR%5FUSER%5FLANGUAGE=nld; SKIN%5FID=Harmony; PSWD=QI%2F7kqiPfaui5F56sTf0Aw%3D%3D; AUSER=jehojakim; CREATE%5FTIME=20090429+142628; IS%5FRETURNING%5FUSER=True; CookieKeyValue=%7B6A02E1FB%2DBE01%2D6802%2DB3D8%2D9DDF00018E2B%7D%7B6AF8D7ED%2D0012%2D6AA6%2D0001%2D8E6BBFD80BE2%7D%7B51220104%2D0100%2D258E%2DA96E%2DA680B0D8A8CF%7D; ServerID=1107; ASPSESSIONIDAABSQQTR=AHPGGCJABHDNJIEMMOEJNKPB; HRLB=17230128161042410837; ASPSESSIONIDCACQRTRQ=MGPOBCODFJFJHMDFJCHBPLFC
> DEBUG (Post): UserId: 5329309
> DEBUG (Post): post data:<EASYZAPPERDATA><DATAVALUES/><EVENTS/><VERSIONINFORMATION><VERSION><CLIENTSOFTWARE>7.3.0</CLIENTSOFTWARE><CLIENTSOFTWARETYPE>Windows XP (x86.1):Java</CLIENTSOFTWARETYPE><SOFTWARE>3.0</SOFTWARE><SOFTWARETYPE>0</SOFTWARETYPE><ID>{6A02E1FB-BE01-6802-B3D8-9DDF00018E2B}{6AF8D7ED-0012-6AA6-0001-8E6BBFD80BE2}{51220104-0100-258E-A96E-A680B0D8A8CF}</ID><BOARD>3.0.0</BOARD><FLASH>0xFF:0x12</FLASH><PROTOCOL>9</PROTOCOL><ARCHITECTURE>9</ARCHITECTURE><SKIN>22</SKIN><REGIONS/></VERSION></VERSIONINFORMATION></EASYZAPPERDATA>
>
> DEBUG (Post): Data=%3CEASYZAPPERDATA%3E%3CDATAVALUES%2F%3E%3CEVENTS%2F%3E%3CVERSIONINFORMATION%3E%3CVERSION%3E%3CCLIENTSOFTWARE%3E7.3.0%3C%2FCLIENTSOFTWARE%3E%3CCLIENTSOFTWARETYPE%3EWindows%20XP%20(x86.1)%3AJava%3C%2FCLIENTSOFTWARETYPE%3E%3CSOFTWARE%3E3.0%3C%2FSOFTWARE%3E%3CSOFTWARETYPE%3E0%3C%2FSOFTWARETYPE%3E%3CID%3E%7B6A02E1FB-BE01-6802-B3D8-9DDF00018E2B%7D%7B6AF8D7ED-0012-6AA6-0001-8E6BBFD80BE2%7D%7B51220104-0100-258E-A96E-A680B0D8A8CF%7D%3C%2FID%3E%3CBOARD%3E3.0.0%3C%2FBOARD%3E%3CFLASH%3E0xFF%3A0x12%3C%2FFLASH%3E%3CPROTOCOL%3E9%3C%2FPROTOCOL%3E%3CARCHITECTURE%3E9%3C%2FARCHITECTURE%3E%3CSKIN%3E22%3C%2FSKIN%3E%3CREGIONS%2F%3E%3C%2FVERSION%3E%3C%2FVERSIONINFORMATION%3E%3C%2FEASYZAPPERDATA%3E%0D%0A&UserId=5329309
> DEBUG (Post): POST /EasyZapper/New/ProcUpdate/Receive_Complete.asp HTTP/1.1
> User-Agent: HarmonyBrowser/7.3.0 (Build 15; UpdatedFrom 7.3.0.15; Skin logitech; Windows XP 5.1; x86; en; rv: 1.8.0.2) Gecko/20060125
> Content-Type:  application/x-www-form-urlencoded
> Host: members.harmonyremote.com
> Cookie: HR%5FUSER%5FLANGUAGE=nld; SKIN%5FID=Harmony; PSWD=QI%2F7kqiPfaui5F56sTf0Aw%3D%3D; AUSER=jehojakim; CREATE%5FTIME=20090429+142628; IS%5FRETURNING%5FUSER=True; CookieKeyValue=%7B6A02E1FB%2DBE01%2D6802%2DB3D8%2D9DDF00018E2B%7D%7B6AF8D7ED%2D0012%2D6AA6%2D0001%2D8E6BBFD80BE2%7D%7B51220104%2D0100%2D258E%2DA96E%2DA680B0D8A8CF%7D; ServerID=1107; ASPSESSIONIDAABSQQTR=AHPGGCJABHDNJIEMMOEJNKPB; HRLB=17230128161042410837; ASPSESSIONIDCACQRTRQ=MGPOBCODFJFJHMDFJCHBPLFC
> Content-Length: 709
>
>
> DEBUG (Zap): Connected!
> DEBUG (Zap): 773 bytes sent
> DEBUG (Zap): 709 bytes sent
> DEBUG (Zap): Received: HTTP/1.1 200 OK
> Date: Tue, 13 Mar 2012 16:24:09 GMT
> Server: Microsoft-IIS/6.0
> X-Powered-By: ASP.NET
> Content-Length: 59
> Content-Type: text/xml
> Cache-control: private
>
> <?xml version="1.0" ?><DATA><RESULT>Success</RESULT></DATA>
> DEBUG (Zap): done with web post
> Contacting website:                       done
> Success!
>   ----------------------------------------------------------------------------------------------

and the remote shows the devices I added and deleted OK.

I will test it tonight, and be back here. But all in all it seems OK, 
aside maybe this messages (part of the above results)

DEBUG (HID_ReadReport): Timeout on interrupt read from device
DEBUG (GetIdentity): Failed to read from remote
DEBUG (FindRemote): bNumEndpoints 2
DEBUG (check_ep): address 81 attrib 03 max_length 64
DEBUG (check_ep): address 02 attrib 03 max_length 64
Resetting Remote:    100%                 done
DEBUG (HID_ReadReport): Timeout on interrupt read from device
Setting Time:                             done



regards, Jogchum

----------------------------------------------------------------------------------------

Op 13-03-12 16:28, Phil Dibowitz schreef:
> On 03/12/2012 10:37 PM, Phil Dibowitz wrote:
>> On 03/12/2012 10:34 PM, Jogchum Reitsma wrote:
>>>     Serial Number: {6A02E1FB-BE01-6802-B3D8-9DDF00018E2B}
>>>           {6AF8D7ED-0012-6AA6-0001-8E6BBFD80BE2}
>>>           {51220104-0100-258E-A96E-A680B0D8A8CF}
>>>     Config Flash Used: 103% (-8104 of -7808 KiB)
>> That's a fun bug, lol.
Tested the remote quickly: everything work as expected.

Thanks a lot, all of you!

regards, Jogchum