[Remoting] Store/Load learned events doesn't work anymore (1 Viewer)

[moh]

Hi *,
maybe here is the better place to post such stuff:

----- <snip> -----

MediaPortal Version: 0.2.1.0
Windows Version: Windows XP Professional SP2
CPU Type: Intel Pentium III 700
HDD: Samsung 80MiB E-IDE
Memory: 640 MiB SDR
Motherboard: Gigabyte BX2000
Motherboard Chipset: Intel 440BX
Motherboard Bios: n/a
Video Card: HIS Radeon 9550
Video Card Driver:
Sound Card: Soundblaster PCI 1024
Sound Card AC3:
Sound Card Driver:
1. TV Card: n/a
1. TV Card Type: n/a
1. TV Card Driver: n/a
2. TV Card: n/a
2. TV Card Type: n/a
2. TV Card Driver: n/a
3. TV Card: n/a
3. TV Card Type: n/a
3. TV Card Driver: n/a
4. TV Card: n/a
4. TV Card Type: n/a
4. TV Card Driver: n/a
MPEG2 Video Codec: n/a
MPEG2 Audio Codec: n/a
Satelite/CableTV Provider: n/a
HTPC Case: Simple Desktop
Cooling: Fanless
Power Supply:
Remote: Medion MD 41169 via IRMan
TV: 4:3 CRT
TV - HTPC Connection: SCART (Peritel)

----- <snip> -----

Hi,
I just updated to MP 0.2.1.0.
When I try to learn remote commands in the configuration app, all seems ok - pressing the remote keys again shows the correct action. But when closing and reopening the config app all learnings are _lost_. It's reproducible anytime.
As far as I can see the learned commands aren't stored anymore, in earlier versions of MP (0.2.0.0 and backwards) this was done in a file called 'remotevalues.xml'.
But such a file is neither read nor written in MP 0.2.1.0.

Any ideas? Please help - remoting is a fundamental thing of a mediacenter....

<edit>
Reproduction:
1. Goto Remote -> SerialUIR in the cnfig app
2. Learn some commands and verify that learing was successful
3. Close and reopen config app, previously learned commands are _lost_
4. You can repeat this several times, but the result is the same

The latest svn-snapshot also doesn't resolve this issue.
</edit>

Regards,
moh

----- <snip> -----

Ok, did a little bit more investigation on this.

It seems that the private contructor (singleton?) of the SerialUIR.cs

		private SerialUIR()
		{
      remotefile = Config.GetFile(Config.Dir.Config, "remotevalues.xml");
		}

is never called - that means the remote-file variable is never initialized.

And because the persistor and loader which make use of this variable are encapsulated in try-catch-blocks without handling an exception the config-app behaves normal - but internally that part goes wrong.

		public void SaveInternalValues()
		{
			try
			{
				System.Xml.XmlTextWriter writer = new System.Xml.XmlTextWriter(remotefile, System.Text.Encoding.Unicode);

				writer.WriteStartElement("docElement");
				foreach(string key in commandsLearned.Keys) 
				{
					writer.WriteStartElement("entry");
					writer.WriteAttributeString("actionInt", ((int)commandsLearned[key]).ToString());
					writer.WriteAttributeString("actionDescription", (commandsLearned[key]).ToString());
					writer.WriteString(key);
					writer.WriteEndElement();
				}
				writer.WriteEndElement();
				writer.Close();
			}
			catch(Exception)
			{
			}
		}

Ok - this seems to be a real bug. Can somebody confirm this and add this to the bugtracking-system?

TIA,
moh

 

[moh]

Ok,
here you have the solution:

The problem is, that the internal overloaded constructor in core\SerialUIR\SerialUIR.cs doesn't call the parameterless constructor - but this one initializes the config-file variable. The parameterless constructor is never called.

The fix is simple: Either you call the parameterless ctor within the called one, or you completely remove the logic (but leave the ctor to override the null-ctor) from the unused constructor and put it into the other one (just one line, nothing complicated).

I'll attach you two patches, each for one possible fix/solution. Only one is needed - it's you decision.

I have tested it and it works, feel free to review and test it, too - as I already said, it's quite simple fix...

Please add this to the curren trunk - so that I can update my MP through nightly builds...

btw: Please avoid empty catch blocks ;-)

Regards and TIA,
moh

 

[moh]

Added this issue to the sourcforge-tracker as request #1588225

Best regards,
moh