United Kingdom
OK guys, some points:
(1) I think that we all recognise that MP1 is desperately short of developers. As a result we must accept that some bugs will go unfixed, and some suggested improvements will go unimplemented.
(2) Any solution for the "red-dot problem" must give the correct indication in all cases. If there are circumstances where the indication is incorrect, that solution should not be included in the product. @catavolt 's current implementation does almost everything, but:
(a) It requires the "Latest Media Handler" plugin.
(b) It gives the incorrect indication if a recording starts after the user has started watching live TV, recorded TV, or video. I believe that this is a limitation of the LMH solution.
For these reasons, I think that we should look elsewhere for a solution to the red dot problem.
(3) The MP Wiki lists various conditions that can be specified on the <visible> tag. One of these is the condition "Player.Recording", but it is marked as "not implemented" (along with a number of others). Suppose we decided to implement this condition, then it would be possible in the OSD xml files to add controls that used this condition to make a red dot appear if one or more programmes were recording. What it would not be possible to do is display any details of the programmes being recorded.
(4) We already have a red-dot solution for MP text panels. If one or more programmes is recording, a red dot appears dynamically on a text panel in a position specified by the skin author (center top for "DefaultWideHD"). I watched this yesterday while viewing the "Home" panel as a recording was about to start. Without touching the remote, the red dot suddenly appeared on the "Home" panel. This means that the active-recording condition is continuously monitored by some part of the MP client, and it displays the red dot when the first recording starts, and removes the red dot when the last recording ends.
(5) The red dot on MP text panels is defined by the contents of "TvOverlay.xml". This is where the skin author defines:
(a) what he wants to use as the active-recording indicator (typically a red dot),
(b) where the indicator is to be placed on the panel, and
(c) whether it is to be animated.
I have just scanned the "DefaultWideHD" source files, and "TvOverlay.xml" is not included or imported anywhere. So it is a file that the MP client loads at MP start-up. The part of the MP client that processes "TvOverlay" must have some way of determining whether a recording is active, i.e. there must be the equivalent of a function called "IsTvServerRecording()" that returns "true" or "false". So, to implement the red dot, the part of the MP client that processes the "Player.Recording" visibility condition should invoke "IsTvServerRecording()" to determine whether the control is visible, and make the red dot visible or invisible as appropriate.
(6) I am not familiar with the internals of MP, but it seems to me that the above suggested implementation ought to be a relatively simple change to implement, since the difficult part of determining whether TV Server is recording has already been implemented in the MP client.
This implementation does not provide all of the "bells and whistles" provided by @catavolt 's implementation, but I think that the proposed implementation is:
(a) Do-able (it is a small change only).
(b) Gives a correct indication in all cases.
-- from CyberSimian in the UK
(1) I think that we all recognise that MP1 is desperately short of developers. As a result we must accept that some bugs will go unfixed, and some suggested improvements will go unimplemented.
(2) Any solution for the "red-dot problem" must give the correct indication in all cases. If there are circumstances where the indication is incorrect, that solution should not be included in the product. @catavolt 's current implementation does almost everything, but:
(a) It requires the "Latest Media Handler" plugin.
(b) It gives the incorrect indication if a recording starts after the user has started watching live TV, recorded TV, or video. I believe that this is a limitation of the LMH solution.
For these reasons, I think that we should look elsewhere for a solution to the red dot problem.
(3) The MP Wiki lists various conditions that can be specified on the <visible> tag. One of these is the condition "Player.Recording", but it is marked as "not implemented" (along with a number of others). Suppose we decided to implement this condition, then it would be possible in the OSD xml files to add controls that used this condition to make a red dot appear if one or more programmes were recording. What it would not be possible to do is display any details of the programmes being recorded.
(4) We already have a red-dot solution for MP text panels. If one or more programmes is recording, a red dot appears dynamically on a text panel in a position specified by the skin author (center top for "DefaultWideHD"). I watched this yesterday while viewing the "Home" panel as a recording was about to start. Without touching the remote, the red dot suddenly appeared on the "Home" panel. This means that the active-recording condition is continuously monitored by some part of the MP client, and it displays the red dot when the first recording starts, and removes the red dot when the last recording ends.
(5) The red dot on MP text panels is defined by the contents of "TvOverlay.xml". This is where the skin author defines:
(a) what he wants to use as the active-recording indicator (typically a red dot),
(b) where the indicator is to be placed on the panel, and
(c) whether it is to be animated.
I have just scanned the "DefaultWideHD" source files, and "TvOverlay.xml" is not included or imported anywhere. So it is a file that the MP client loads at MP start-up. The part of the MP client that processes "TvOverlay" must have some way of determining whether a recording is active, i.e. there must be the equivalent of a function called "IsTvServerRecording()" that returns "true" or "false". So, to implement the red dot, the part of the MP client that processes the "Player.Recording" visibility condition should invoke "IsTvServerRecording()" to determine whether the control is visible, and make the red dot visible or invisible as appropriate.
(6) I am not familiar with the internals of MP, but it seems to me that the above suggested implementation ought to be a relatively simple change to implement, since the difficult part of determining whether TV Server is recording has already been implemented in the MP client.
This implementation does not provide all of the "bells and whistles" provided by @catavolt 's implementation, but I think that the proposed implementation is:
(a) Do-able (it is a small change only).
(b) Gives a correct indication in all cases.
-- from CyberSimian in the UK
