If you have a new remote that isn't recognized by RMIR, post the details here so we can help create a new RDF for it. Or, if there is an issue with an existing RDF or map, this is the place.
vickyg2003 wrote:I'd like the RCA remote added, as this seems to come up a lot,
You are referring to '31793179 (RCA RCRP05B black).rdf' right? If so I actually already moved that one as I agree it is a very popular one. That is the only one I already moved.
vickyg2003 wrote:
Also would like to have the 3032 Atlas moved from released to the Development stage, its definately not ready for primetime.
Also I am wondering if the slingbox-fake can be removed from the released file, since we've added all the binpl,binrv.... whatever for the slingbox.
For Atlas - we can definitely do that unless someone is working on updating it. I know nothing about Slingbox - so.. just let me know.
I hadn't planned on doing that, but can pretty easily do that if Mike will make one change to the output file routine and enclose the rdfnames in brackets[]. That eliminates the need for a line by line parse, and makes it so I can just pick it up and dump it in, without adding a whole bunch of code...
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
I hadn't planned on doing that, but can pretty easily do that if Mike will make one change to the output file routine and enclose the rdfnames in brackets[]. That eliminates the need for a line by line parse, and makes it so I can just pick it up and dump it in, without adding a whole bunch of code...
That would be great if that can be worked out - it would be nice to be able to do it all with your tool.
The first part is in the RDF file name. The second part should be in the RDF in the [FixedData] or [AutoSet] sections.
Thanks Mike, that really simplifies things on my side when I can just process it as a blob, instead of having to open it, and analzye each line.
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Real quick question, could somebody verify that the new section heading should be :
[SetupCodes]
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
alanrichey wrote:I see the sourceforge site still has the original versions of the Slingbox RDF files. These are a bit buggy and not designed properly for RM.
mdavej wrote: Don't forget about adding this line to the [General] section as well:
SetupValidation=Enforce
Value could also be Off or Warn, but I can't think of any reason not to use Enforce.
Ahh the plot thickens. I was totally unaware of that. Back to the drawing board.
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
mdavej wrote: Don't forget about adding this line to the [General] section as well:
SetupValidation=Enforce
Value could also be Off or Warn, but I can't think of any reason not to use Enforce.
Ahh the plot thickens. I was totally unaware of that. Back to the drawing board.
Should we use 'warn' for some beta testing?
Thanks,
xnappo
Your call, I've got it with Enforce right now, but Warn is just 4 letters away.
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
I don't know. Enforce can keep people out of trouble, but will force them to assign valid codes to unused devices, which is something they may not want to bother with. The only other time Enforce could be a problem is if the SetupCodes list is wrong, hence xnappo's beta testing request I suppose. So maybe Warn is the way to go for the time being.
mdavej wrote:I don't know. Enforce can keep people out of trouble, but will force them to assign valid codes to unused devices, which is something they may not want to bother with. The only other time Enforce could be a problem is if the SetupCodes list is wrong, hence xnappo's beta testing request I suppose. So maybe Warn is the way to go for the time being.
Yeah it just depends on how confident we are in the data. If we are pretty confident it is correct we can go with enforce...
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.