no protocol found with name nec1 no repeats

stif · Post by **stif** » Wed Apr 13, 2016 12:05 am

[hi guys
i have problem ,
when i tried upgrade device to my atlas 4 remote ,``say file load error no protocol found with name nec1 no repeats`` i know is about protocol problem ,but how can i do add this protocol i supossed i need edit protocol.ini file,
file i tried update is jynxbox v3.rmdu
please help me my jynxbox control is broken i need make work my atlas.
rmir 2.0 prolific usb/ no problem updating dreambox and openbox rmdu files

Post by **The Robman** » Wed Apr 13, 2016 6:51 am

Edit the RMDU file using Notepad (or similar) and remove the "no repeats" portion of the protocol name.

Post by **The Robman** » Wed Apr 13, 2016 8:35 am

I couldn't find a file called jynxbox v3.rmdu, the following is the only JynxBox upgrade out there, so I updated it to use the regular NEC1 protocol.

https://www.hifi-remote.com/forums/dload ... e_id=11671

Post by **mathdon** » Wed Apr 13, 2016 4:36 pm

As the "no repeats" protocols were considered to be only of interest to Slingbox users, they are hidden by default in RMIR. If you open the Options menu in RMIR, you will find an option "Show Slingbox protocols". It is a persistent option, so if you check it, it will remain checked each time you open RMIR until you uncheck it. When checked, the "no repeats" protocols become available in RMIR.

This is a recent addition to RMIR, so if you don't see the option on the menu, you will need to upgrade to the latest build to find it.

Post by **The Robman** » Wed Apr 13, 2016 4:54 pm

Graham, what happens if someone who's not interested in Slingbox, and therefore doesn't have the option checked, opens an RMDU file that has one of the no repeat protocols pre-selected? Even without the option being checked, I think it should still open the file correctly with the protocol selected, as that would allow the user to select the standard version.

Post by **mathdon** » Thu Apr 14, 2016 7:13 am

Rob, that's a good point. I'll think about it, as it is not trivial to do. The option affects the reading of protocols.ini when RMIR is opened, so if it is not checked then RMIR behaves as if the no repeat protocols were not present in protocols.ini.

Post by **The Robman** » Thu Apr 14, 2016 8:26 am

Ah, I see how that would be tricky, so how about this, how about adding a new parameter that we can just use for the no repeat versions which links back to the original protocol, so if RM encounters one of these protocols that it can't load, it switches the selection to the original.

I see the obvious problem, if the no repeats protocol isn't loaded, you don't have visibility to the parameter in question, so would it be possible that when you're loading protocols.ini and you see that you have a no repeat protocol that you're choosing not to load, could you load a cross-ref table that would link the NR version to the original version?

Or maybe, we re-think the idea of hiding the NR versions and just include them all the time?