Rework of TV and Radio configuration (1 Viewer)

[michael_t]

Description of change:
Rework for the MP config tool based on MP 1.3

This change brings the configuration for TV and radio together in one common section in the config tool. The radio configuration is now a subsection of the TV section.

More changes:
- This change includes the bugfix 0004218: Radio plugin ignores the "Show the All Channels group" setting.
- The radio channelgroups are fetched directly from the tvservice (TvController), so there is no (more) need for direct database access from the MP config tool.
- The hostname field has now a dropdown that lists all available MP TV Servers in the network (must be in the same workgroup or domain). Manual entries in the hostname field are still allowed.

The source code can be found in the FEAT-4263-Rework_TV_Radio_Configuration branch in github.

Steps to install and test
Replace the following files with the files provided in the zip archive:
...\MediaPortal\TvControl.dll
...\MediaPortal\Configuration.exe
...\MediaPortal\plugins\windows\TvPlugin.dll
...\MediaPortal TV Server\TvControl.dll
...\MediaPortal TV Server\TvService.exe
Make sure that the original files are completely deleted or renamed with another extension but ".dll".

Open the config tool and test the new features

Release notes
29.03.2013 (only Configuration.exe has to be replaced if you have installed one of the previous versions)
- Improved error messages and logs

13.03.2013 (only Configuration.exe has to be replaced if you have installed one of the previous versions)
- Added a timeout for network scan

11.03.2013 (only Configuration.exe has to be replaced if you have installed one of the previous versions)
- Got rid of the ugly blue color for the selection in the Hostname combobox
- Updated the tab index of all modified sections

10.03.2013 (only Configuration.exe has to be replaced if you have installed the initial version)
- Hostname can now be selected from a list of TV servers available in the loacal network
- The TV config sections are reordered and renamed

05.03.2013
- Initial release

Michael

 

[azzuro]

only Cosmetics proposition :
can you rename : "TV" general tab to "TV/RADIO"

is targeted for 1.4 ?

 

[michael_t]

only Cosmetics proposition :
can you rename : "TV" general tab to "TV/RADIO"

The main section "TV" contains lots of tv only settings, so "TV / Radio" might be misleading. But I am not happy about this, too and I would be thankful for good ideas how to rearrange the tv and radio settings better on the sections.

is targeted for 1.4 ?

If someone (who is it now? - I lost the track on all these discussions) decides to put it on the roadmap...
Seriously: This change contains a change (addition of one method) to the IController interface. I think that this is no problem (not even for downwards compatibility) since this interface is only used for one reason - to implement the TvController of the TV Service which is used for remotely calling its methods. Thus an additional method cannot harm - if the client knows and uses it, it's ok and if it does not know of it, it won't miss it. But I think some more experienced people should hav a look at this code, if it is safe before scheduling it for a version.

Michael

 

[Holzi]

Is there already a mantis ticket for this?

 

[HomeY]

is targeted for 1.4 ?

If someone (who is it now? - I lost the track on all these discussions) decides to put it on the roadmap...

Once it's added to Mantis, it's added to the roadmap (based on the target version you set). After 1.3 Final the Train Model will take affect, so once it's finished, tested & documented, it can be merged/included in the next Train

 

[elliottmc]

@michael_t I notice you added a mantis entry for this fix, and then deleted it. Should this have been deleted?

It looks as though this fix encompasses your other fixes in this area, so it would be good to have a single mantis entry to cover all fixes, so we can get it tested and scheduled for the next release after 1.3.0.

 

[HomeY]

Maybe it's best to add a Mantis 'Rework TV / Radio Configuration' and set 4218 as child of. Then all the rework stuff can get tested in that branch.

@michael_t while you're working on this TV part, could i ask you to take a look at this proposal (and maybe this 1 also)

 

[michael_t]

@michael_t I notice you added a mantis entry for this fix, and then deleted it. Should this have been deleted?

It looks as though this fix encompasses your other fixes in this area, so it would be good to have a single mantis entry to cover all fixes, so we can get it tested and scheduled for the next release after 1.3.0.

I had already created a mantis entry when I remembered the discussion about necessary approval of planned features / changes and then I removed it.
It is no problem to re-open this entry, but I am still uncertain about when and how a new feature or a change (not a bugfix) can be set up in mantis. Does it need the approval of someone (whom?) or can everybody create new mantis entries and schedule them to the version he/she thinks it is suitable? But wouldn't this mean that every feature / change a developer puts into mantis will be integrated into MP when it is ready (developed, tested and documented) - no matter what it is? Or are mantis entries removed from the schedule (by whom?) if they do not find enough acceptance to be integrated?

More generally and quite off-topic:
My personal opinion is that there should be a strategic product planning that defines the direction of the future MP development. This plan should not cover details in the sense of mantis entries or a release planning, but we should have a common idea of where the train is going to. Wether the train takes 2, 3 or 4 stops until it arrives at the next destination does not matter, but we must set the switches to avoid straying around without a target.
Thus I would appreciate a broad feature / functionality discussion which should not be made from a developer's, but from a user's point of view: What new / improved features are our users expecting? What are the main problems they face with MP, which should be eliminated? What are our "competitors" planning? What are the future trends in home media entertainment?
The answers to these questions would help us to agree on a common plan where the journey should go to in the next one, two years and which route we want to take. Then it would be much easier to make a comprehensible decision on what should be put into mantis (in the sense of: this will definitively be integrated into MP when it is ready) and what should be postponed or given up at all.

Michael

 

[elliottmc]

It's an obvious needed fix. I approve !

 

[HomeY]

I had already created a mantis entry when I remembered the discussion about necessary approval of planned features / changes and then I removed it.
It is no problem to re-open this entry, but I am still uncertain about when and how a new feature or a change (not a bugfix) can be set up in mantis. Does it need the approval of someone (whom?) or can everybody create new mantis entries and schedule them to the version he/she thinks it is suitable? But wouldn't this mean that every feature / change a developer puts into mantis will be integrated into MP when it is ready (developed, tested and documented) - no matter what it is? Or are mantis entries removed from the schedule (by whom?) if they do not find enough acceptance to be integrated?

Copied post to the Workflow FAQ thread.