I have a button with a learned IR code that puts my pre/pro into 6 Ch bypass mode. Clicking the button works fine with multiple clicks toggling into and out of 6 Ch.

When I link to the button from another button it works OK. If I add any other command after the link, the IR code is sent twice (as if the button were clicked twice). The code seems clean since it works fine from the original button.

Has anyone seen this or have any ideas for me? I've updated to the latest firmware and PENG version (I'd hoped the firmware would fix it).

Thanks.

Sounds like the IRcode is a repeating code, one button push and it sends it once but if you hold the button it keeps repeating the code. I beleive this is a bug in the PENG macros, it keeps the button in a depressed state long enough to send out multiple commands. I had this problem with my Sony TV and the browse arrows. I was lucky and discovered a code that made them nonrepeating no matter how long the button was pressed. Sorry I don't have a better answer for you.

Archer

I've got a SONY TV, and have had the same problem. (My fiancee is really upset about the loss of her 16*9-mode macro.)

Can you please point me to the alternate non-repeating codes for the arrows for the menus? I looked through the IR code DB here, and couldn't find anything.

Beau,
Here's the link to the Sony nonrepeating codes...

[Link: remotecentral.com]

Archer

Um, some of those codes look pretty dirty. Has anyone tried non-repeating codes like these:

Up
0000 0067 000d 0000 0060 0018 0018 0018 0018 0018 0030 0018 0018 0018 0030 0018 0030 0018 0030 0018 0030 0018 0018 0018 0018 0018 0018 0018 0018 03f5

Down
0000 0067 000d 0000 0060 0018 0030 0018 0018 0018 0030 0018 0018 0018 0030 0018 0030 0018 0030 0018 0030 0018 0018 0018 0018 0018 0018 0018 0018 03de

Left
0000 0067 000d 0000 0061 0018 0018 0018 0018 0018 0030 0018 0018 0018 0030 0018 0030 0018 0018 0018 0030 0018 0018 0018 0018 0018 0018 0018 0018 040c

Right
0000 0067 000d 0000 0060 0018 0030 0018 0030 0018 0018 0018 0018 0018 0030 0018 0030 0018 0018 0018 0030 0018 0018 0018 0018 0018 0018 0018 0018 03f5

Daniel,
I tried the codes you supplied but after I paste them into PENG the last 4 digits always change to 0000 and then it does not work. I'm not familar with modifying the codes, so I wouldn't now where to go next. The original code that is dirty and does work, is one came came over on my 2000 conversion and then I modified the others from that code.

Archer

Archer,

Thanks for the reply. You've pointed me in the right direction. Just need to see if I can find a non-repeating code (unlikely though).

I really like my 3000 but I'm sorely disappointed in the quality of the software. I'm a software engineer myself so I know there really is no excuse for the bugs I see. It's plain sloppiness on the part of the programmer and likely poor management just makes it worse. They might get the kinks worked out but if they had better quality it would be cheaper for all of us (time = money).

Thanks again. Sorry for the little rant. :-)

Too bad you don't have any experience with programming. If you did you'd know that bugs are inevitable. I have seen nothing in PENG that I think is "sloppiness". Considering the size of the program and the fact that it has to work in Windows I think they've done a very good job. (The lack of programmability of the 4th firm button is clearly more involved that they are letting on and is not just a bug. I suspect there's a firmware or hardware bug on that one.)
Barry

Regarding quality of the product - have you read the posts on this forum? My post did not indicate I was talking soley of PENG. I'm looking at the whole product. I have experience working on both poor and high quality software, so I can spot the difference. Thanks.

Ok, some people will excuse the poor quality. They'll also be very accepting of a first release being riddled with defects. The bug that is preventing me from getting a working macro is just dumb. It's as likely a design error as a programming error, but it's still an error.

This is NOT complex software. Programs like PENG have been written many times before - look at Visio as one example. While this is a new generation of remote for Philips, they've done this before. Do they forget everything? Do they know how to reuse existing, debugged code?

I'm not sending my 3000 back. I'm waiting on fixes and my desired PCF works >90% of the time. That doesn't mean I'm not going to point out sloppy programming. Keep praising buggy software and you'll keep getting buggy software.

Your concept of quality is obviously much lower than mine.

PENG is based on NEOedit code, which was completely rewritten from ProntoEdit (notice how the program went from a 4.5mb download on PE 2.0 to 26.2mb on PENG?)

pandasys:
1) what does Visio have to do with PENG, one is several hundred $ vector graphic software and the other is free software to edit a remote. Plus I have heard many people curse at Visio as well
2) most complaints are features we want not actual bugs
3) repeating a code a few times is normal, since most devices need a code repeated as a confirmation. And if you were as smart as you think, it is easy to make any repeating code to stop

1) Visio was ONE example of software that does basic object layout. There are many more. The point is this type of software has been done to death and is not complicated (Visio is much more complicated and I wasn't going to go though a laundry list of others). The original poster said PENG is complicated - it is not that complicated.

2) I haven't complained about "features".

3) If it's so easy why didn't you tell me how. If you want to show me how easy it is I'll post the code and you can show me. Is repeating a code normal? Why does it only happen in a macro? Which is broken, the button or the macro? I guess it's a feature it works differently in a macro. :-)

As for complete rewrites of software, that just means the first versions were poor and this version likely is as well since it's from the same people. Proper layering and encapsulation means you don't have to completely rewrite software. Making your GUI independent of the underlying data representation means continual improvement of the editor without worrying about data format changes. These are beginner topics for any programmer.

Also, proper unit testing of this software would not have allowed these obvious defects to reach the light of day. It's obvious that testing is lacking. Plus, proper testing makes software cheaper, not more expensive. Needless to say, system testing doesn't appear any better that any unit testing that may exist. One thing the rise of lightweight Agile development processes have caused is some of the most ardent hacks have realized the importance of test first. Some people still haven't realized it.

Let me reiterate for the people who have such strong emotion about a hunk of software, I don't think the product is unusable. It has some obvious bugs that point to poor quality control. Without seeing the actual development, at least we can see testing needs serious work. But, the defects could have been introduced in the design phase. Doesn't matter, they're still defects.

I'm not criticizing a person; it's the software.

does PENG have bugs? yes
does PENG lack features we want? yes



these do sound like attacks on people
---------------

2)


most of the complaints are people missing some of the features that were in PE.

3)


if you look around a bit

[Link: remotecentral.com]


when you push a button on a normal remote, the fractions of a second of contact are enough to send the code several times. The device needs several iterations to confirm it is the right code. Maybe your code is dirty, or maybe your device is more sensitive (i.e. expects with a single push n repeats and is getting a few more.)

1) No. Obviously Philips processes are so lax there software contains easily detectable defects. They obviously don't enforce well-known testing techniques.

2) Again, I'm complaining about a defect. The various descriptions of crashes, hangs, and bad data files are also not "features".

3) Ok, so I can convert the IR code to something human understandable. So what? The code is clean and is being sent multiple times. If I wanted it sent multple times, I'd encode it that way. Why are they simulating a button press anyway? Why not just send the IR code and if the code needs to be sent multiple times make the user write it that way? Why force actions to be tied to buttons? I can't control exactly what gets sent because anything sent is tied to some timer that decides how long a button click takes?

The time between a button down and button up determines if it is a simple click or the user is holding down the button. That I can't control the exact code sent to the device is a defect. You could argue it is a design defect, but it is a defect.

Or am I missing someway to create an action that is not associated with a GUI widget? You know, simple MVC. The only way I see to get to an action is to link to a button. Simulating a button click to perform an action is pretty lame, especially when there is a timing problem that causes a code to be repeatedly sent. It behaves differently in a macro than when clicked. Telling the user this is working as designed is a very poor response.

if you understand something, then you can make it do what you want. try reading it again and put your great software engineer brain to work