ReQuest request : )
ericmedley
Posts: 4,177
Has anyone here worked with ReQuest media servers? And, if so, what is your experience with AMX integration?
Your opinion counts!
ejm
Your opinion counts!
ejm
0
Comments
We sell and install Request products and we are very happy with them. Request has great modules, that are open and well documented. Ive installed and programmed both the N and the F series units, and am in the process of programming a Video Request piece. All and all I am very pleased with the product
If you use the UI module you'll need to change at least 2 lines that do not work. The first is
//else if(m_btnIndex>=11 && m_btnIndex<=11+MAX_NAVIGATOR_LIST_SIZE)
TO
else if(m_btnIndex>=11 && m_btnIndex<11+MAX_NAVIGATOR_LIST_SIZE)
Get rid of the = or it won't work.
Another:
else if(m_btnIndex>=96 && m_btnIndex<=101) // Play Now
{ //send_command vdvAudioRequestFseries[m_zone],"'MOVE-',itoa(m_lineSelected[m_port])"
// m_port does not work with zone 2
send_command vdvAudioRequestFseries[m_zone],"'MOVE-',itoa(m_lineSelected[m_zone])"
That's what I can think of right now.
One VRQ works fine from multiple TPS, but the second VRQ fails to update its dynamic images. The second VRQ lists all the movies with the correct titles and data, but the images from the first VRQ show up.
Obviously something simple I am missing.
Also, automatic DVD recognition is very touch and go. I would not promise this feature, but sub out to a data grooming service.
The ARQ is the most fun piece of gear I have bought for myself.
Again, though, when controlling one ARQ from multiple touch panels the interface seems to get hung up regularly.
I know that I have to kill the update to the touch panels that are not actively controlling the ARQ, as they seem to bog down pretty quickly.
You've been most helpful. thanks again...
The open module code gives you a great starting point.
I hope other companies DO THE SAME, as I still don't know why they hide the code. Could it be because it is written so poorly?
I wasn't too impressed with the Video Request product though and we have ended up replacing most of the ones we sold with Kaleidescape systems because of the issues with reliability, disc lookup and time it takes to load a dvd etc.
The official company line is that people used to change the code around in the System Calls, and then call for support, the support guys would spend several hours trying to figure out why the code wasn't working, and then people would finally go "oh yea, I changed this line in the system call" and the support guys would've wasted their time. As a result, instead of allowing people to mess with their code and then ask for support when it didn't work, AMX decided not to release the code for modules.
At least, thats what I was told during training
J
There are also some legitimate cases where the protocols are covered by NDAs which require AMX to only release binary versions of the module. I don't think this is true for 90% of the modules out there, though...
Jeremy
I've heard both of these excuses for not releasing the module code.
AMX could just have a policy: if you change the code, don't call us for support.
As for the protocol covered by a NDA: I've never come across a device protocol that I couldn't find and if I did I'd never use the device.
As you can tell, I'm very adamant about this topic.
I feel new (and not so new) programmers could really learn from seeing module code... yes, the good and the bad code.
I do understand their problem. I've done technical support before. I know the mantra: "If they say nothing has changed, they have changed 'something.' "
My problem is that it is very difficult to debug a black box. Also, I find that modules, in general, are not designed to work with larger scale integrations. If you have one touch panel controlling one device things go well. However, if you start to use multiple touch panels controlling multiple devices, the system breaks down.
I've noticed that it has gotten better over time. many of the newer modules seem to work a lot better.
I've also noticed that the protocol has gotten tighter. That's a big plus!
I typically only use the comm files and write my own interface. I really appreciate when the module writer has done a thorough job of implementing the protocol.
However, for my stiuation, I'm not really saving a whole lot of time in programming, since the user interface is what seems to take the most time in programming. In many cases, it's just easier for me to communicate directly with the device anyway.
They tend to leave the user_interface file open and the comm file closed. I almost wish it was the other way 'round...
I realize that at the heart of this is quality control of support and protection of intellectual property. It's a battle we won't win...
right, because people will listen to that
Trusting people to be intelligent is never a good business strategy.
I happen to agree with you, I think new programmers SHOULD have some example code available to them to learn from. When I learned how to do this I had to ask a lot of incredibly basic questions in these forums because the only example code I had to learn from was some old Access code. I downloaded the Access to Netlinx conversion manual, but it didn't help much. I eventually managed to take the programmer classes and get my cert, and I've got a fairly decent handle on what I'm doing now, but it took a lot longer than I wanted it to.
J
If I have a module that I changed from your original module.
OR
I'm TRYING to write a module from scratch.
I'll take the call from the programmer that changed my module every time.
Where is the logic in "we don't want you to change our modules".
I see... we are being saved from our-self.
If a programmer is changing the module, then there must be something wrong with it.
It seems ever time I've tried to use a module, the end results are:
the client wanting something the module doesn't provide or it doesn't work properly from the start.
As Eric mentioned above, I also have never used a module in a large project.