Author Topic: Is there proper way to vet and submit new/improved device templates?  (Read 1953 times)

alx9r

  • Guru
  • ****
  • Posts: 187
    • View Profile
Is there proper way to vet and submit new/improved device templates for distribution as a stock template?

I have a device template for Denon Receivers that I have tweaked that is an improvement (at least on my system) over the stock one that came with snapshot 23359.  The shortcoming in the stock template is that it allows extraneous switch input commands to reach the receiver which causes audio to cut-out for several seconds when starting playback of media. 

The template I am referring to is AVC-A1SRA (RS232) #71.  Thom and Andrew mentioned recent work on that template here (but sadly it didn't fix this problem as was hoped): http://forum.linuxmce.org/index.php?topic=7393.msg51364#msg51364

A detailed description of the problem and solution are detailed in my two posts here:
http://forum.linuxmce.org/index.php?topic=7393.msg51362#msg51362
http://forum.linuxmce.org/index.php?topic=7393.msg52184#msg52184

The problem and solution are well understood and I'd like to get this fix into the mainstream code so we don't have to tweak this template manually on each new installation.

Alex

Murdock

  • Guru
  • ****
  • Posts: 229
    • View Profile
Re: Is there proper way to vet and submit new/improved device templates?
« Reply #1 on: November 06, 2010, 09:09:27 pm »
The recommended method to update or create a device template is to upload a new trac ticket (http://svn.linuxmce.org/)

phenigma

  • wants to work for LinuxMCE
  • **
  • Posts: 976
    • View Profile
Re: Is there proper way to vet and submit new/improved device templates?
« Reply #2 on: November 08, 2010, 11:43:05 pm »
First create a trac ticket to follow the template submission.  Update sqlCVS on your core.  Verify that your templates are still correct.  Do an sqlCVS diff on your core and submit it to sqlCVS, be sure to reference the trac ticket # you created in the sqlCVS batch description when you submit your sqlCVS diff.  You will be told the sqlCVS batch id's after a submission to sqlCVS.  Reply to the trac ticket you created earlier and reference the sqlCVS batch id's from your submission.  This way trac references the sqlCVS batch id's (and vice versa).

I believe there are instructions on the wiki that instruct you how to perform the sqlCVS update & diff.  You could also jump onto IRC for assistance.

J.
« Last Edit: November 08, 2010, 11:51:28 pm by phenigma »

b4rney

  • Guru
  • ****
  • Posts: 454
    • View Profile
Re: Is there proper way to vet and submit new/improved device templates?
« Reply #3 on: November 15, 2010, 10:17:46 pm »
The solution is as follows:
In the ruby code, keep track of which input is currently selected.  Only send an input selection string to the receiver when the input changes.  That way a gap in audio is only heard when the input actually changes.
Alex, can you post or pm more details of your fix for the audio dropping problem please? I know you will be submitting the trac ticket but I'd like to try it out as soon as possible.
Barney

alx9r

  • Guru
  • ****
  • Posts: 187
    • View Profile
Re: Is there proper way to vet and submit new/improved device templates?
« Reply #4 on: November 16, 2010, 07:35:04 pm »
The solution is as follows:
In the ruby code, keep track of which input is currently selected.  Only send an input selection string to the receiver when the input changes.  That way a gap in audio is only heard when the input actually changes.
Alex, can you post or pm more details of your fix for the audio dropping problem please? I know you will be submitting the trac ticket but I'd like to try it out as soon as possible.
Barney

I'm not sure what additional details you're looking for b4rney.  The heavy lifting is detailed in the txt attachment in my posting here:

http://forum.linuxmce.org/index.php?topic=7393.msg52184#msg52184

With that attachment, you can manually populate all the ruby rectangles of a new device template for that receiver.  The power commands and the switchInput() function does the protection against extraneous commands.

Alex

alx9r

  • Guru
  • ****
  • Posts: 187
    • View Profile
Re: Is there proper way to vet and submit new/improved device templates?
« Reply #5 on: November 16, 2010, 08:46:31 pm »
First create a trac ticket to follow the template submission.  Update sqlCVS on your core.  Verify that your templates are still correct.  Do an sqlCVS diff on your core and submit it to sqlCVS, be sure to reference the trac ticket # you created in the sqlCVS batch description when you submit your sqlCVS diff.  You will be told the sqlCVS batch id's after a submission to sqlCVS.  Reply to the trac ticket you created earlier and reference the sqlCVS batch id's from your submission.  This way trac references the sqlCVS batch id's (and vice versa).

I believe there are instructions on the wiki that instruct you how to perform the sqlCVS update & diff.  You could also jump onto IRC for assistance.

J.

Hi phenigma,
Somehow I missed this post earlier.  I'm pretty sure I can follow the directions in your post but I have a few questions:

1. What happens when I "submit" the sqlCVS diff?  Is there someone who reviews it before it becomes available to others performing a sqlCVS update?
2.  Is there some point in the process where a small group can be enlisted to test the newly available device template without the template being spread too far and wide?  Despite that the template works great on my system, it seems that it ought to be tested on other people's systems before it should become mainstream.  Otherwise there is a real chance of my new template actually being worse than the existing one.
3. Should I be changing the existing Denon receiver template or creating a new one with a new name and ID?  It seems like there would be arguments for both options.

Alex

b4rney

  • Guru
  • ****
  • Posts: 454
    • View Profile
Re: Is there proper way to vet and submit new/improved device templates?
« Reply #6 on: November 16, 2010, 11:37:18 pm »
Alex,

Sorry about that, missed the text file ... duh!

Thank you.
Barney

phenigma

  • wants to work for LinuxMCE
  • **
  • Posts: 976
    • View Profile
Re: Is there proper way to vet and submit new/improved device templates?
« Reply #7 on: November 17, 2010, 02:41:32 am »
Hi phenigma,
Somehow I missed this post earlier.  I'm pretty sure I can follow the directions in your post but I have a few questions:

1. What happens when I "submit" the sqlCVS diff?  Is there someone who reviews it before it becomes available to others performing a sqlCVS update?
2.  Is there some point in the process where a small group can be enlisted to test the newly available device template without the template being spread too far and wide?  Despite that the template works great on my system, it seems that it ought to be tested on other people's systems before it should become mainstream.  Otherwise there is a real chance of my new template actually being worse than the existing one.
3. Should I be changing the existing Denon receiver template or creating a new one with a new name and ID?  It seems like there would be arguments for both options.

Alex

No worries.

1. Once the sqlCVS diff is submitted, reply to your trac ticket and include the batch IDs.  Then the best course of action is probably to jump onto IRC and ask someone with access to svn and sqlCVS to review and approve your batches and close the trac ticket.  If the batch looks good, and there are no glaring problems, it will likely be approved.
2. After approval the updated template is available to everyone.  New installations will automatically acquire the newest version of the template, including your changes.  Existing installations may perform an sqlCVS update to get the updated version of the template.  There doesn't currently exist a reliable way to move templates around without this process.
3. I think that you should only create a new template if it would break (or change) functions with existing receivers using the template.  If this is something that existing Denon receivers, that currently use this template, should implement (and it sounds like it is) then modify the existing template.

Hope that helps.

J.