View source for User:Esev/Archived ToDo Items

== 2010/11/07 ==
=== Investigate power button issues ===
I'm having issues when pressing the Power button on my [[Gyration_GYR4101US]] remote.  If I'm controlling a non-pluto device, and press power, the device turns off but my receiver and TV are not switched back to the Orbiter OSD.

This isn't fixed yet.  The fix that is in place won't work correctly for Live AV audio sources.  They will still turn the TV back on.  Need to read and understand this function.  Right now in ''StreamEnded'' it calls this function with 0 and NULL for the ''Current'' arguments.  I might be able to pass in the MD's device and use the Prior media type for the current media type and things will work.  Need to test this.
<pre>
void
Media_Plugin::HandleOnOffs(
    int PK_MediaType_Prior,
    int PK_MediaType_Current,
    map<int,MediaDevice *> *pmapMediaDevice_Prior,
    map<int,MediaDevice *> *pmapMediaDevice_Current,
    MediaStream *pMediaStream,
    EntertainArea *pEntertainArea)
</pre>

Also should look into how the 'HOME' key works on the Orbiter's remote.  For some reason when the code was removed the 'HOME' key didn't switch back on the Orbiter OSD.  I'm wondering if I make this change will I break something there.  Need to look at the Orbiter's ''Orbiter::GotActivity( int PK_Button )'' function.  It turns on the screen if it is off.  ''if( !m_bDisplayOn ) CMD_Display_OnOff( "1",false )''.  Maybe m_bDisplayOn is getting set for the case when audio is playing with no video.


Might also consider turning off the OSD if only audio is playing and the audio was started via a remote Orbiter.  I think that could be accomplished by not setting the ''pMediaDevice_MD->m_bDontSendOffIfOSD_ON''.

See also:
* [http://svn.linuxmce.org/trac.cgi/changeset/23325 Changeset 23325 - Don't turn the TV on when music stops playing]
* [http://forum.linuxmce.org/index.php?topic=10895.0 OSD Orbiter does not display after stopping non-pluto media device]

<hr />

=== Volume control of non-pluto devices ===
See this forum [http://forum.linuxmce.org/index.php?topic=10789.0 post] and ticket [http://svn.linuxmce.org/trac.cgi/ticket/746 #746].  It doesn't seem to matter if the end device has pipes or not.  The volume messages are always sent to the device, not the audio/video pipes of the remote MD.

==== #LinuxMCE-devel on 20101102 ====
 <TSCHAKeee2> esev: be very careful re volume pipes                   
 <TSCHAKeee2> esev: volume commands should only go to the app server _IF_ an audio device isn't in the pipes.
 <esev> TSCHAKeee2: what if the audio device in the pipes is in a different room?                                                                     
 <TSCHAKeee2> you need to follow those pipes                          
 <TSCHAKeee2> if there is no audio pipe setup for an EA, then the App Server should be used

==== See also ====
* Regarding Entertainment areas
** [[Control_a_TV_or_cable/satellite_box#Programmer.27s_guide|Programmers guide for Media_Plugin]]
** [[Rooms#Multiple_Entertainment_Areas_in_One_Room|Entertainment Areas]]
** [[Media_Scenarios]]
** [[Generic_PC]]
* Source code
** DCERouter.cpp line 2076 - DCERouter handles the device pipes?  I would have figured those would be handled by the media plugin.
** MediaPlugin.cpp line 2169 - This is where the vol up/down commands wind up
<pre>
08	11/02/10 23:23:31.944		Received Message from 21 (OnScreen Orbiter / Home Theater) to 59 (BDP-S350 / Home Theater), type 1 id 89 Command:Vol Up, retry none, parameters: <0xa88fdb90>
08	11/02/10 23:23:31.944		  Parameter 41(StreamID): 1004 <0xa88fdb90>
10	11/02/10 23:23:31.944		AddMessageToQueue(ProcessQueue) adding message from 21 to 59 type 1 id 89 to queue size was: 0 <0xa88fdb90>
10	11/02/10 23:23:31.944		AddMessageToQueue(ProcessQueue) sent broadcast <0xa88fdb90>
10	11/02/10 23:23:31.944		ProcessQueue woke up with size: 1 <0xb662fb90>
10	11/02/10 23:23:31.944		ProcessQueue sending message from 21 to 59 type 1 id 89 to queue now size: 0 <0xb662fb90>
10	11/02/10 23:23:31.944		ProcessQueue Calling realsendmessage from queue <0xb662fb90>
08	11/02/10 23:23:31.944		Forwarding 89 Command:Vol Up up pipe to 139 (TX-SR602) <0xb662fb90>
</pre>

<hr />