[other] some thoughts about Area 51 testing (1 Viewer)

[megahorst]

During the last days I had some thoughts about Area 51 testing.

When I have a look to the Area 51 section it seems to me that there are not so many users testing the teams new features and enhancements. I can imagine that this can be frustrating for the developers from time to time and more testing could bring more stability and ideas to all the new things.
If the MePo team shares my opinion my thoughts might help to solve the problem. If the team thinks, that it is OK as it is there is of course no need to change anything.

From my point of view there are 2 points that led to the small amount of testers:

The language barrier
Not all of the users are able to speak English. I can imagine that there are a lot of users outside that are willing to help but are not able to give there feedback in English.
Have you thought about Area 51 sections in the language specific forums?
Some willing users could support the team with the maintaining of these sections.

• translating the english area 51 threads with new features to their native language
• first level support of the testers (solving of installation problems, ...)
• collect the feedback, translate it to English and bring it to the English Area 51 section

"Too complex" installation of the patches
I can imagine that, there are users outside which are a little afraid for changing files within their MePo installation and only a very few users are having separate developing PCs for testing things.
For all these users it might be to complex to participate Area 51 testing today.

To solve this MePo could be extended with the ability to fetch the patchfiles out of other directories than the original files.
What I mean:
Today we have

...\program files\Team Mediaportal\mediaportal\<a  lot of files and directories>

and

...\program files\Team Mediaportal\TV Server\<a  lot of files and directories>

What about having

...\program files\Team Mediaportal\mediaportal\Area51<id>\<a  lot of files and directories>

and

...\program files\Team Mediaportal\TV Server\Area51<id>\<a  lot of files and directories>

too?

The Area51<id> directory and subdirectories are the places to store the patched files.
The <id> extension could be used to have more than one Area51 project installed.

The testing could be started with new commandlineparameters for mediaportal.exe and tvserver.exe
For example:

mediaportal.exe /area51-001

could take take files of the

...\program files\Team Mediaportal\mediaportal\Area51-001\

directories.
Files that are not within the area51 subdirectories could be taken from the original directories.

The developers could prepare archives where the files are already stored within their right places and the testers only have to expand the archive and start mediaportal or the tv-server with the command line extension.
This would lead the original installation untouched and after testing the users (or their wifes / girlfriends) could start MePo without being influenced by the patched files.

 

[Sebastiii]

Hi,
I like the idea but seems to complex to setup (from code point of view) but maybe someone else has idea
@Developers what do you think ?

 

[Vasilich]

there are 2 points that led to the small amount of testers:

actually i think there is 3rd one: unfortunately only some of people willing to help are able to give meaningful/helpful feedback. What can be more frustrating for developer than reading smth like "your patch doesn't work" without explanation what was done, how to reproduce the failure etc. (and i am not talking about absence of SystemSpecs and logs attached yet!).

Have you thought about Area 51 sections in the language specific forums? Some willing users could support the team with the maintaining of these sections.

in that case this "someone" has to translate everything - from testing purposes to bugreports with error messages coming in non-english language...

mediaportal.exe /area51-001

but that idea is interesting. We need to look into code to evaluate how hard will it be to implement.

 

[tourettes]

mediaportal.exe /area51-001

but that idea is interesting. We need to look into code to evaluate how hard will it be to implement.

It is a source for some nice bugs. This about the issues that could be caused by non-compatible settings, having to make sure all directshow filters are registered between the swapping etc.

Also test related implementation is not somethign that production code should be have, more logic is a source for bugs - and it is bad especially when it is not caused by the production code but instead of some test code.

 

[Paranoid Delusion]

The language barrier
Not all of the users are able to speak English. I can imagine that there are a lot of users outside that are willing to help but are not able to give there feedback in English.
Have you thought about Area 51 sections in the language specific forums?

Impossible to maintain, sadly like most international groups we have to use a single language to communicate, which for the main is English just about every where (don't shoot me on that statement )

 

[arion_p]

Having MP load some files from an alternate location can be very hard, depending on which file you want in this alternate location. A lot of files/assemblies are being referenced directly and MP itself has no control (although it could inject its own assembly resolver/loader). Still, some patches change MediaPortal.exe itself, so you would have to start MP from a different folder. All in all it is too complex and error prone.

A much simpler and safer solution would be to allow multiple installations of MP in different folders. This way you can have a production installation and several testing installations. Area51 patches would then be full installers, so testing is consistent. Each installation would ofc use it own data (separate config, databases etc). The only issue with this (or any other similar solution) is DX filters that are registered. This can be solved in two ways:

1. Have MP register all its filters on start-up
2. Have a batch file to register the filters (belonging to the same installation as the batch file)

1st option is fully automatic, but will slow down start up. 2nd option is manual and can result in unreliable test results.

 

[tourettes]

1. Have MP register all its filters on start-up
2. Have a batch file to register the filters (belonging to the same installation as the batch file)

1st option is fully automatic, but will slow down start up. 2nd option is manual and can result in unreliable test results.

#1 would require MP to be run on admin rights #2 would require the .bat to be run as admin.

 

[arion_p]

Yep totally forgot about UAC/elevated access. So #2 seem more appropriate. Perhaps adding a check in MP start up to verify the right filters are registered would help with test result consistency.