1.7: MP1 Development

The Inside Scoop Banner
Volume 1, Issue 7 

As many of you know from a recent news release, arion_p and chemelli have taken on the task of managing MP1 development. These guys are not easy to catch, they work almost every spare minute on MP1 these days, trying to get MP 1.1.0 released. However, with the recent successful release of RC3, I finally managed to catch up with them and ask them about their new roles, and the future of MP1. So here is the Inside Scoop from our new Managers about MP1 Development

chemelli.jpg About chemelli                              About arion_p arion_p_small.jpg

MP1 Development

1. What inspired you to agree to become MP1 Development Manager?

Chemelli: The idea came to my mind after some team members spoke with Infinityloop and he told me that my name was quite frequently suggested by them. I was not at all convinced to take the ‘job’ because of my limited coding knowledge. I have been working in IT for fifteen years but not at all as a developer. However, since no one else was moving to do something, I contacted Arion and asked him to share the responsibility and balance the knowledge - him on the code side and me on the Team rules and management. He liked the idea. So I announced to the Team that we were going to share the chair. They asked us if one was the "vice" or “deputy” of the other, but I immediately said we share it fifty-fifty.

I felt I could help better in MP1 Development than in the early stage of MP2.

Arion: Yes, It was Simone that dragged me into this! Joking aside, this was not an easy decision. I think that everyone in the team agrees that MP1 needs to keep advancing until MP2 reaches a state of development where it can start replacing its predecessor. However, considering that MP1 code base sometimes acts like a Pandora's box, not many developers are willing to put a lot of effort in it, or are experienced enough to handle such a challenge. However, it would be a shame if no one stepped up; and I'll share a little secret with you - I enjoy fixing bugs more than a sane developer should!

I believe many were relieved that Simone and I offered to take this position.

Chemelli: I cannot agree more about that last statement. Wink

2. Why two of you?

Arion: Actually I would never even have considered proposing myself as an MP1 Dev Manager. I have only been in the team for two years, which I do not consider long enough to have good understanding of all the code in MP1 or have knowledge of why certain design decisions have been made.

Additionally, due to real life work and family, my time for the project is rather limited so I could never do this alone. Simone, on the other hand, has been with the team for quite some time and he seems to remember every discussion ever made in the forums. He has very good knowledge of how things should work in MP but due to his lack of development background he didn't feel so confident about this role. So it was a natural choice to join forces, that's what we do in Team MediaPortal.

Chemelli: Yes, exactly as Arion says, we complement each other. This way the team gets the strengths from both of us.

3. What is your main area of interest/expertise in MP1 Development?

Arion: I try to get involved in as many areas as possible. But some areas are naturally easier for me to work on. While I started by working on porting WebEPG to TV-Server, I have also helped improve various aspects of the TV features of MediaPortal (TV Guide, RTSP streaming, TsReader etc) and have done some minor bug fixing in the skin engine. In general I would say TV is my main interest (which is what makes MP stand out from the rest).

Chemelli: I started out on the MP Team as a tester, mainly for the analog part of TV-Server. Once I joined the Development Group, I noticed that two areas were left alone and had a lot of work to be done: the Installer (Deploy Tool) and setup - the Configuration and TV setup. I reworked the Deploy Tool from the embryo that gemx wrote, to the installer we have currently. I worked hand in hand with Chefkoch who took care of the NSIS installers. We even got a dedicated Mantis project just for the Deploy Tool.

In the meantime, I tried to make configuration and TV setup as intuitive and bug free as possible. While I was working on those two areas, I noticed that our SVN trunk was really "dirty" - a lot of stuff was duplicated, unused, or badly positioned. So I started cleaning it up, with several different goals like the removal of MS directX.dll from our distribution, the removal of C++ code in the skin engine, and directshow filters as well as the removal of about ten unused or deprecated filters like the TsFileSource, duplicate TsWriter code and MPTS (MediaPortal Transport Stream). Plus, we fixed some bugs deleting several third party filters.

I also worked with Chefkoch on IRSS (InfraRed Server Suite) when and-81 became too busy with ‘real-life’ to continue developing it. I am really proud of it because IRSS has been officially promoted to be THE remote solution for MP2!

I have spent a lot of time on logs because not that many users, or even team members, read them carefully. Several times I found the logs were missing vital information needed to understand what happens. For example, I recently added the file name of the skin file generating an error in the error.log, thus making it easier to spot and fix.

These days, I have started continuing the development of the WorldMap plugin, just because I want to learn new things and help the Team even more.

4. What are your goals for MP1 Development?

Arion: With MP1 reaching a mature stage in its life cycle, we want it to stay as stable as possible, while still having some edge. We want MP1 to be a reliable media center application and we want it to keep up with the competition until MP2 gets out. To accomplish this, we need to carefully consider each new feature or improvement and evaluate how it could affect stability. Of course, as has already been said (many times indeed), we want development to be community driven so that the main manpower of the team can focus on MP2.

Chemelli: Yes, one of our main goals is to encourage community development. We want the community to continue to code for MP1 until MP2 is ready. So we need to be ‘fair’ to our community developers who submit patches to our Development Forums. In the past, sometimes we had to tell our community developers that a patch was not committed because it was too late in the development cycle. So we want to improve our response time to patch submissions so this does not happen in future.

Of course, another goal is to "free" other development team members so they can begin to work on MP2.

5. What is the plan for after MP 1.1.0?

Arion: This will mainly depend on the state MP 1.1.0 is in, when released. If there are serious bugs that we find after the release, we will need to have a bug fix release (like we did with 1.0.2 for 1.0.1). If however bugs are minor, we want to do a feature release that will include some improvements and a few new features. Still, development will mostly be directed towards perfecting what already works, rather than adding completely new features.

Chemelli: Yes, we want to take care not to introduce too many new features that reduce the stability of MP and take it back to an alpha stage again. Sometimes the community expects every suggestion or proposal in the forums to be approved. However, we have to carefully consider any new features to ensure MP remains as stable as possible. Of course, we are all eager to add new features whenever possible and that is one of the main goals for getting MP 1.1.0 released – to lift the feature freeze.

6. What is the best way users can help?

Arion: As always users can help by posting detailed bug reports with full logs, so that spotting and/or reproducing the bugs is easier. We need the users to work with us constructively in order to squeeze every possible bug out of MP. If they have development experience they can also help by providing patches to fix bugs, or improve MP1 in general. However keep in mind that not every patch submitted will eventually be included. It will depend on the nature of the patch (bug fix/feature), risk involved, code quality and how many users will benefit from the patch.

Chemelli: To submit detailed bug reports users should:

  • Enter and update System Specs in the User Control Panel in the forum. Without these we cannot tell the system variables that may lead to a solution of the problem.
  • Test using only Blue3/wide skins
  • Ideally, use a test system without any extensions installed, or at least disable them
  • As Arion said, submit full logs using Debug mode logging. This is easy now with the new Debug Mode.
  • Provide the steps to reproduce the problem

We say this over and over, and it is in a Sticky post/Announcement that appears in almost every forum, yet still we get useless bug reports. This wastes everyone's time and does not encourage developers to want to fix bugs.

It would also be very helpful if users responded to let us know if a fix worked, or appreciate the time we spent on it. The only reward we get is appreciation, but that is pretty rare. It might also encourage more developers to fix bugs.

7. What changes/improvements would you like to make in the Development Process?

Arion: With stability always in mind, we have been talking about doing some adjustments to the development process. These include two major aspects of the process:

a) Proper release planing. By planning what fixes, improvements and new features will be implemented in each release before we start working on it, we can have a good estimate of the time needed for the release. This will allow us to have more control and shorten the release cycle to a more manageable length.

b) Binary testing. Before a change/patch is applied to SVN we want it to have been tested thoroughly enough that we know it will not affect stability or introduce major bugs that may need considerable time to fix and throw off any planning or schedules. While we have already been doing some binary testing, it was only on a case by case basis.

Chemelli: I agree with Arion. I also feel we need more developers interested in bug fixing. A real team effort for bug fixing will make everything quicker -> 1.1.0 final released -> end of feature freeze. We have done it really well sometimes, but I would like to see that happen more often.

8. What is the purpose of the shorter RC release cycles? Is that something you would like to continue and if so why?

Arion: Shorter RC release cycles is something we intend to keep. It allows us to get better feedback from the community. It also helps get cleaner bug reports and move development forward. In conjunction with release planning, this will lead to shorter release cycles which in turn will help keep stability to the desired level while still keeping the interest of both developers and users.

Chemelli: Yes, the main purpose of the shorter RC cycles is to get the next stable version out quickly, allowing us to put some - I want again to stress some - new features in MP1, so we can keep up with the competition.

9. Will you provide SVN snapshots again?

Chemelli: It is too difficult to handle RC + weekly snapshots during the RC release cycle. We need a common user base - installation and configuration - to get useful bug reports. So we need all testers using the same RC release, not different snapshots. After 1.1.0 final we can plan snapshots to get new features tested. Once these are mainly working, we can plan a 1.2.0 release. However, this means we will again have a feature freeze and RC cycles with no snapshots.

Arion: I have to agree with Simone on this. SVN snapshots are good for getting quick feedback and testing new features from the community but they do not work out well for bug fixing, especially when hard to find bugs are involved. In order to nail down bugs we need to limit the variables as much as possible so we all need to test using the same release. On each RC release, team members always keep an intact installation of the published RC for a couple of weeks so that we test on the same grounds as our users.

Many people might think that SVN builds are just more frequent RC releases, but that is not true. RC releases are internally tested (as much as our manpower allows) before being published, while SVN builds receive little to no testing. This means that an SVN build might have obvious and easily reproducible bugs, in which case we will be stormed by an overwhelming number of bug reports for something we can easily spot and fix with limited testing. With RC releases we have already taken care of those bugs and we can focus on more rare bugs that internal testing cannot find.

10. What do you feel is the biggest improvement in MP 1.1.0?

Arion: It is hard to single out a specific improvement because there have been so many important ones (some of which I've also been involved). I would say the most important improvements are compatibility with a wide range of H.264 codecs and Windows 7 support.

Chemelli: For me it is stability. Our developers have made a great effort to fix all known hard crashes and memory leaks. My feeling is that now even my parents can use MP as their main TV/radio/movie manager without the pain of it crashing.

11. What do you like least/most about being MP1 Development Manager?

Chemelli: I believe we all have to follow the same rules or it is not fair. Also, sometimes we have to force things a bit or nothing will happen. However, I don’t like being seen as a dictator, enforcing rules on others. So that is hard for me personally.

I really like the idea of having a MP1 Dev Manager (no matter who it is) because I really feel it gives us more organization. I'm very proud the Team selected me and I'll do my best. Plus I am so pleased to share the job with Arion because, luckily, he is not a ‘sane’ developer and likes fixing bugs. All in all it's going well.

Arion: I have always liked the democratic nature of the team (some have even suggested that it is too democratic Laughing) and I don't want that to change. So in that respect I think my job as a MP1 Development Manager is quite easy.

On the technical aspect however, I can often have a rather strong opinion (when I can back it up with hard facts). This can put people off sometimes, so I'm always uncomfortable when I have to review other developers' code.

In danger of repeating myself, I would like to say that as much as I was surprised that Simone chose to ask me to share this position and the team approved of that, I think that together we can actually help MP1 keep getting better.


MediaPortal has grown so much in the past year or two. With over 1,000,000 downloads annually, it is continually becoming a more mainstream and stable media center application. It's not easy to manage the growing pains during this transition, but luckily, we have chemelli: 'The Cleaner' and arion_p 'The Fixer' to guide us on the road to MP2.  I guess that makes infinite.loop 'The Godfather'. Cool

About The Project

The vision of the MediaPortal project is to create a free open source media centre application, which supports all advanced media centre functions, and is accessible to all Windows users.

In reaching this goal we are working every day to make sure our software is one of the best.

         

Quick Navigation

  • Home
  • About MediaPortal
  • Bugtracker
  • Download
  • Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!
  • Our Partners

Support MediaPortal!

The team works very hard to make sure the community is running the best HTPC-software. We give away MediaPortal for free but hosting and software is not for us.

Care to support our work with a few bucks? We'd really appreciate it!


Wir benutzen Cookies

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern (Tracking Cookies). Ebenfalls dienen sie der Personalisierung von Ads (Werbung). Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.