JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

RMIR v2.14 available
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
lbschenkel



Joined: 13 Sep 2015
Posts: 13

                    
PostPosted: Mon Mar 21, 2022 6:21 am    Post subject: Reply with quote

I noticed that RMIR discards the comments in Girr files during import. I fixed the issue and submitted the patch here: https://sourceforge.net/p/controlremote/patches/2/

Patch is also below:
Code:

diff --git a/km/src/main/java/com/hifiremote/jp1/ExternalSignal.java b/km/src/main/java/com/hifiremote/jp1/ExternalSignal.java
--- a/km/src/main/java/com/hifiremote/jp1/ExternalSignal.java   (revision 1900)
+++ b/km/src/main/java/com/hifiremote/jp1/ExternalSignal.java   (date 1647860711881)
@@ -226,6 +226,7 @@
   public static ExternalSignal getExternalSignal( Command cmd )
   {
     ExternalSignal es = new ExternalSignal();
+    es.setNotes( cmd.getComment() );
     Decode decode = null;
     try
     {
@@ -339,7 +340,7 @@
   @Override
   public String getNotes()
   {
-    return null;
+    return notes;
   }

   @Override
@@ -353,10 +354,16 @@
     this.error = error;
   }

+  public void setNotes( String notes )
+  {
+    this.notes = notes;
+  }
+
   public static Remote remote = null;  // For passing from loadExternalFile to callers

   private ArrayList< LearnedSignalDecode > decodes = null;
   private LearnedSignalDecode preferredLSDecode = null;
   private String signalName = null;
   private String error = null;
+  private String notes = null;
 }


Can you please incorporate that into the codebase? This will greatly improve my workflow where I maintain the "master" code lists in a Girr file and would like to have the comments preserved when importing into RMIR.
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Tue Mar 22, 2022 5:50 am    Post subject: Reply with quote

lbschenkel wrote:
I noticed that RMIR discards the comments in Girr files during import. I fixed the issue and submitted the patch here: https://sourceforge.net/p/controlremote/patches/2/

I tested this. The problem is existing and the patch fixes it. Recommended.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
lbschenkel



Joined: 13 Sep 2015
Posts: 13

                    
PostPosted: Tue Mar 22, 2022 9:43 am    Post subject: Reply with quote

I also found another bug, reported to https://sourceforge.net/p/controlremote/bugs/43/

Quote:

When using RMIR v2.14.3, with remote URC-7955 (604803), if I try setting up a controlled DSM bound to a shifted key, and then save the file, then RMIR can no loader read the file: "Error loading file". If I set the DSM to a non-shifted key, or delete the DSM, then the problem disappears.

I have attached a minimal test case. The attached file was a download of the remote after a factory reset, and a single DSM set up with a shifted key (no upgrades). The file cannot be loaded by RMIR.

Also: if I upload such configuration to the remote, then I can no longer download from the remote.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Tue Mar 22, 2022 2:28 pm    Post subject: Reply with quote

@lbschenkel

Thank you for the patch and the bug report, but please post any bugs or other comments HERE and not on SourceForge. I do not monitor SourceForge for such things.
_________________
Graham
Back to top
View user's profile Send private message
TiceRex



Joined: 29 Jun 2012
Posts: 51

                    
PostPosted: Tue Mar 22, 2022 2:53 pm    Post subject: RMIR inconsistency Reply with quote

Could you please consider changing the RDF for URC-7935, reported here:
http://www.hifi-remote.com/forums/viewtopic.php?p=144583#144583

Or is this thread only for program changes? Where should I report an issue of RDF's?
Back to top
View user's profile Send private message
lbschenkel



Joined: 13 Sep 2015
Posts: 13

                    
PostPosted: Tue Mar 22, 2022 3:15 pm    Post subject: Reply with quote

mathdon wrote:

Thank you for the patch and the bug report, but please post any bugs or other comments HERE and not on SourceForge. I do not monitor SourceForge for such things.


Good thing that I'm posting it here, then. Wink
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Mar 23, 2022 12:45 pm    Post subject: Reply with quote

@lbschenkel

I have applied your patch concerning Girr comments, which will be in the next build. I am investigating the bug report.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Thu Mar 24, 2022 1:13 pm    Post subject: Reply with quote

I have now posted development build RMIR v2.14.4 in the RMIR Development folder on SourceForge.

@Ibschenkel: This includes your patch and also fixes the bug with Controlled Macros on shifted keys.

@TiceRex: This includes your correction to the RDF for the URC-7935.
_________________
Graham
Back to top
View user's profile Send private message
lbschenkel



Joined: 13 Sep 2015
Posts: 13

                    
PostPosted: Sun Apr 03, 2022 6:03 am    Post subject: Reply with quote

mathdon wrote:

@Ibschenkel: This includes your patch and also fixes the bug with Controlled Macros on shifted keys.

Works perfectly, thanks.

In the meantime, I found another problem. I am not sure if it's in the remote, or in RMIR. My remote is a URC-7955. I have one of those Panasonic TVs that require a long press (~2 seconds) on the power button to turn on. Therefore when I need to turn on the TV I use a controlled macro with a "Hold" of 2s or more. This works in my other remote (Nevo C2).

When activating the macro (the very same macro that works in the other remote) I saw that the TV would not turn on. When I put the same discrete code in a physical button and I held it, it worked. After a lot of troubleshooting I realized that if I create a controlled macro and only put a single command with a 'hold' of many seconds, it would not hold: the LEDs in the remote and in the TV would blink briefly, as if the button was just pressed without any hold. But in my macro of many commands, I could see the hold happening so I was confused. After playing a bit more, I realized what was going on: for some reason, the hold is applying to the *next* button in the macro, not the button where I put the hold. For example: if I have a macro with button A(hold=2) followed by B, then B is the button held by 2 seconds.

So, to make it work for my case, I have to put the hold in the previous command before the 'discrete power on'. That ended up "fixing" the problem. This works even if the previous button is "TV" (to select the device "TV" in the remote).

I have no idea if this bug is in the remote while executing the macro or in RMIR that somehow uploads a macro with the hold information in the wrong place (by the way: if I download from the remote I see the hold where I put it, so it does not "move"). If this is a bug in the remote's firmware, I wonder if RMIR could work around it by "shifting" the holds to the previous entry in the macro (I know, this is kinda ugly, and it's unclear what to do when the hold is in the first entry).

I am aware that this can be hard for you to reproduce, especially if you don't have the hardware, so please let me know what I can do to help getting to the bottom of this.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sun Apr 03, 2022 8:04 am    Post subject: Reply with quote

Many thanks for that interesting report. I have a URC-7955, have timed the signals accurately with IRScope and can confirm that it does behave as you have observed. It is not a bug in RMIR, the data is uploaded correctly. Whether it is a bug in the remote is unclear, as controlled macros are not documented anywhere in UEI literature. They are just something that I discovered in my investigations and decided to take advantage of by implementing them in RMIR.

As far as the UEI implementation is concerned, they are closely related to the implementation of macros in the XSight Lite, where they are the only form of macro. In the XSight Lite each macro step is set as a pair of buttons, a device button followed by the desired signal for that device. That construction is forced, there is no alternative. In the URC-7955 and similar, RMIR does not impose this construction but it can be done manually. I have found today by experimenting that if you set each signal that you require as a device button followed by a signal button, putting the hold time on the device button, the delay time on the signal button and the other two times (device delay and signal hold) as zero, it behaves as you would like. The signal is held for the time set on the device button and is followed by a delay for the time set on the signal button. So I suggest you adopt this as a work-around for your case.

It would be possible for me to force this in RMIR, as for the XSight Lite, but that would remove some flexibility that others may find useful. A common use of controlled macros is to create fast macros in which all the times are zero and forcing the inclusion of a device button before every signal button would be an unnecessary complication. So I hope you will be content with the above explanation and work-around.
_________________
Graham
Back to top
View user's profile Send private message
lbschenkel



Joined: 13 Sep 2015
Posts: 13

                    
PostPosted: Sun Apr 03, 2022 8:30 am    Post subject: Reply with quote

mathdon wrote:

It would be possible for me to force this in RMIR, as for the XSight Lite, but that would remove some flexibility that others may find useful. A common use of controlled macros is to create fast macros in which all the times are zero and forcing the inclusion of a device button before every signal button would be an unnecessary complication. So I hope you will be content with the above explanation and work-around.


Thanks for the explanation. I understand why unconditionally adding extra device buttons is not desirable (I wouldn't like that either), and now that I know what's happening I'm content with a workaround.

However, I have two suggestions to make:
- RMIR could warn when a controlled macro containing holds is saved, and the remote is URC-7955, and explain that due to the way the remote works the hold need to be in the previous button in the macro. (I'm just trying to prevent the next person from spending countless hours in frustration as I did.)
- Maybe RMIR could be "smart" and, for this remote, and only in the case of a button with hold, automatically add a device button before the function button and apply the hold there. And if there's a device button already, and no hold, just set the hold without adding it. You get the idea.

Maybe the best of both worlds would be to detect such situation on a macro for this remote, and RMIR offers to "fix" the macro on save, and the user can confirm/deny. Then the user is always informed and also in control.

What do you think? I totally understand if this is not appealing for you, though.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sun Apr 03, 2022 1:07 pm    Post subject: Reply with quote

I will look into your first suggestion. I don't think the other two are do-able, though. If there is no device button already present, it is not possible to know what device is intended. If the macro is intended to be device-independent then there needs to be no device included. The XSight Lite does not have this latter possibility as it only supports DSMs. I think that with these remotes, any fix must be left to the user and that all RMIR can do is warn about this strange behaviour.

There are only three remotes currently known to support Controlled Macros. These are the URC-7980, URC-7955 and URC-7880. I have all three, and will test with each of them, but I expect to find that the problem is common to all of them as they share a lot of common code and I see no reason why they should differ in this respect. I don't think it is a bug. All three remotes have a number of features that are not fully implemented, this appears to be one, so we don't know how it was intended to work when complete. My Bluetooth extenders for these remotes work by completing other features that were left incomplete.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Apr 06, 2022 12:54 pm    Post subject: Reply with quote

I have now posted development build RMIR v2.14.5 in the RMIR Development folder on SourceForge. The support for Real-time Macros has been updated to allow them to be created in RMIR on keys that support them, while previously they could only be edited once created on the remote itself. This updated support also allows creation of Real-time DSMs. The feature, or bug if you prefer, that Ibschenkel has identified with the hold duration in Controlled Macros now triggers a descriptive warning message in appropriate circumstances. It is displayed if on creation or edit, a Controlled Macro has a hold duration greater than 0.1sec on a non-device button. I chose 0.1sec, which is the smallest nonzero hold duration, rather than zero itself as users creating the fastest possible macro may find that zero does not work, so I am treating 0.1sec as "effectively zero". To avoid being annoying, the warning is displayed at most once in any RMIR session, a fact which is mentioned in the displayed message.

I would welcome any comments on this development build.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Fri Apr 15, 2022 12:30 pm    Post subject: Reply with quote

I have now posted development build RMIR v2.14.8 in the RMIR Development folder on SourceForge. This is a substantial update on the previous development versions. The changes are primarily to support features of the URC-3660, see this thread, but they also improve support for MultiMacros for all remotes that support them. MultiMacros have, until now, been pretty invisible in RMIR. If you knew which keys of a remote supported them then you could create more than one macro bound to the same key and they would be uploaded to the remote as a MultiMacro, which is one that sends the constituent macros in turn on successive presses of the key concerned. Now, with such remotes you get offered a choice of normal or multi macro when creating a new macro entry, with each type showing for bound key only the ones that support the chosen type.

For remotes such as the URC-7955 and URC-7880 that support Real-time Macros on dedicated keys, these macros can now be created in RMIR while previously they could only be edited once created on the remote itself. A few minor bugs have also been fixed.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sun Apr 17, 2022 8:00 am    Post subject: Reply with quote

Development build 8 has now been replaced by RMIR v2.14.10 in the same development folder, see the preceding post. This fixes two bugs in build 8 related to the new features of that build.
_________________
Graham
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control