We've been working on subtitle support for Miro in the subtitle branch. Yesterday, Ben merged the changes into the master branch. As of this morning, nightly builds have subtitle support. Yay!

There are still a few things to implement and the code hasn't had much of a chance to settle. Also, there are still some things I think should get refactored and it's likely we'll be tweaking the interface going forward as we use it more.

Still, it's good to have landed the bulk of this feature. It's probably not wildly useful yet, but it gives us some ground work towards building better subtitle distribution/creation infrastructure going forward.

minutes

2.6 status (roadmap)

• subtitle work is almost done
• lots of bugs to work on, but some might have been fixed in 2.5.4--Janet is going to retest
• lots of little bugs to work on left--we could use the help if anyone is interested in contributing!

Paul

• Worked on Miro Community 0.8.5. It's pretty close to done--there are two outstanding bugs.
• Hoping to push out Miro Community 0.8.5 out in the next few days. Lots of bug fixes, cool new administration stuff.
• After that, there are a few big bugs for 0.9 to work on.

Janet

• Worked on getting 2.5.4 out. Looks like it's been a good release with few complaints.
• Working on figuring out the shutdown crash for Miro on Windows. This has been difficult and very trial-and-error.
• Worked on Miro Community testing.

Ben

• Worked with Janet on that shutdown crash.

Luc

• Worked on Miro 2.6 issues from bugzilla. Just kind of going through and cherry-picking easy issues and nasty issues.

Will

• Pushed out 2.5.4.
• Worked on menu refactoring.
• Worked on subtitles stuff.

bugzilla

• 10 bugs/feature-requests created
• 3 bugs marked WONTFIX
• 3 bugs marked FIXED
• 1 bugs marked INVALID

minutes

2.5.4 status (roadmap)

• Will fixed an additional bug on Monday that Janet tested and it looks fine.
• Will is going to build builds today. Then we'll test them and probably do a release Thursday morning and update the appcast file on Friday.

2.6 status (roadmap)

• subtitle work is almost done
• menus need to be refactored to finish up subtitle work
• lots of little bugs to work on left--we could use the help if anyone is interested in contributing!

Paul

• spent the week working on bugs in Miro Community
• started working on custom templates allowing admins to change the way their site works
• ten or so bugs left on the 0.9 roadmap to do
• going to triage the bugs in order to push out a 0.9 sooner

Janet

• working on finding an automated ui tester
• worked on Miro Community testing, too

Will

• did a bunch of fixes
• getting ready to push out a 2.5.4
• plans to work on refactoring the menus next

Ben

• implemented subtitle support on linux
• worked on osx bug fixes
• started looking into VLC freeze issues

bugzilla

• 7 bugs/feature-requests created
• 2 bugs marked DUPLICATE
• 6 bugs marked FIXED
• 1 bugs marked WORKSFORME
• 2 bugs marked INVALID

notes

I wasn't on last week's devcall. Thus, no notes.

I've been talking about removing the xine renderer for 6 months now. I don't do this lightly--generally we want to add features, not remove them. However, we're a _really_ small team of developers working on Miro and one of the things I'm focusing on for the Miro 2.6 development cycle is to reduce and simplify wherever we can so that we can focus on the work ahead of us. Also, the gstreamer folks are doing a fantastic job and that project is really coming along. I feel very confident that switching to gstreamer is a good move.

Today is the day I did the deed. As of c1c6f33, the gtk-x11 platform of Miro no longer uses the xine renderer. This checkin removes all the xine code from the codebase.

A while back, I threw together a VLC renderer that mostly works. Other renderers can be built in the same way--the infrastructure is there for anyone to create new renderers and ship them as separate packages.

Even though this is a good move, I do realize it leaves some people out in the cold. If you are interested in championing the xine renderer and starting a project to build and maintain it, let me know and I'll do what I can to help out.

We've been working on reducing the complexity of the code for Miro 2.6. We've done this in a few different ways and I want to summarize them here.

moved binary kit stuff to separate repositories

This dropped the size of the git repository for miro a lot. Cloning the repository is much faster now. Plus it's easier to build Miro on Windows and OSX from the source tarball.

moving libtorrent out of portable

On Linux, this allows us to rely upon Linux distributions to have packages for libtorrent (the Rasterbar version) and the Python bindings. We don't need to compile libtorrent as part of the Miro build process anymore. That dropped the build time like a rock, reduced the tarball size, and removed a bunch of issues from configuring and compiling Miro on Linux.

removing sorts.pyx and fasttypes.pyx

Removing these allowed us to remove the build dependency on Boost. That removes a bunch of assy code we had in the setup.py file. This also reduced the time it takes to build Miro on Linux.

adjustments to setup.py to be more whiny when things are missing

I added some code to the gtk-x11 setup.py to make it clearer when it's missing build dependencies. I then tested this on Kubuntu Karmic, Fedora 12, and OpenSUSE 11.2. Miro will still try to run if it's missing things--I'll look into this soon.

updated gtkx11 build docs

I went through and updated the build recipes in the gtk-x11 build docs page. I updated the recipes for Ubuntu Karmic, added recipes for Fedora 12 and OpenSUSE 11.2 (though it won't work because I couldn't find a libtorrent rasterbar package), and removed a bunch of old recipes that would never work. I'm planning to do Gentoo and some other distributions next.

I updated the build and runtime requirements lists, too.

removing xine

This hasn't been done yet, but it'll happen soon. This will remove some build requirements and it'll make our lives easier since we'll only have to support one renderer on Linux. Supporting two takes a time and effort and we're only doing a so-so job of it. Better to cut xine loose and focus on gstreamer. I'm sorry that this will affect some people. I'm hoping to rework the code so that additional renderers can be released as separate packages like I did with frontends.

conclusion

We're focusing on reducing the complexity of the codebase and build requirements to make it easier for new people to pick it up, build and contribute. If there's anything else we can do on this front--or better if there's anything YOU can help us do--let us know.

minutes

2.5.4 status

• Ben made some fixes for 12301, those will get merged in.
• Need to sync translations
• A new set of branch builds today and a release at the end of this week or early next week

subtitle support status

• Luc has it implemented for OSX. Still need implementations for Linux and Windows.
• Will's working on the Windows implementation.
• Ben's going to look into moving the menu/submenu code to portable.
• Either Ben or Will will work on the Linux implementation when their plates clear.

Ben:

• spent a while working on bug 12301. bunch of fixes that'll go into 2.5.4.
• researched "pumping up the volume"; looks possible so he's going to implement it.

Luc:

• frustrating week working on gstreamer subtitles support
• had problems getting his test files to play correctly with Miro on Ubuntu Karmic
• wants to hand off gstreamer subtitle support to someone else
• worked on scrollbar problem with osx

Janet:

• tested 2.5.4, tested 12301 fixes, and did a bunch of Miro Community testing

Paul:

• worked on bugs for Miro Community 0.9

Will:

• will merge in ben's 12301 work, sync translations, and make a set of 2.5 branch builds
• will work on subtitle support for windows
• will work on subtitle support for linux

bugzilla

• 9 bugs/feature-requests created
• 3 bugs marked WORKSFORME
• 1 bugs marked INVALID
• 2 bugs marked DUPLICATE
• 1 bugs marked WONTFIX
• 1 bugs marked FIXED

notes

Several people said they read the reports weekly and find them very useful, so I'll continue writing them.

One person mentioned how there's no public information about Miro development. That's not correct. Here's a list of urls of public information:

• Bugzilla timeline http://bugzilla.pculture.org/roadmap.cgi
• Bugzilla roadmap http://bugzilla.pculture.org/timeline.cgi
• Git repository web frontend http://git.participatoryculture.org/miro
• Release notes for releases https://develop.participatoryculture.org/trac/democracy/wiki/ReleaseNotes
• We have #miro and #miro-hackers on freenode.net for IRC.
• Develop mailing list http://participatoryculture.org/mailman/listinfo/develop
• Planet Miro http://planet.getmiro.com/
• Miro blog http://www.getmiro.com/blog/
• Identi.ca group http://identi.ca/group/miro

We switched the miro repository url from https://git.participatoryculture.org/miro/ to http://git.participatoryculture.org/miro/. If you were using https, then you should switch the origin url in the .git/config file. It's unlikely that's the case, though, since it's been broken for over a month now.

I finished the work to remove the binary kit data from the miro repository today. Removing the binary kit data from the repository changed all the shas. To alleviate the problems this causes, I did the following:

1. Ran a git filter-branch --commit-filter that added a line to the end of every commit message stating what the original commit sha was. The shas are referenced in Bugzilla, so this maintains the papertrail.
2. Moved the "old git repository" to miro.old. If you're building Miro versions prior to Miro 2.6, it'll probably be easier to do that in the old git repository because the binary kit material is there.
3. Binary kit materials were moved to separate repositories.

The end result of this is that we went from 900mb for the repository and a full checkout to about 136mb. Clones are faster, it uses less space on disk, and you're not saddled with a bunch of binary date you probably aren't going to use. It's also much easier on the build boxes which are old and don't have a lot of disk space kicking around.

If you have any questions, comments, or problems, let me know.

minutes

2.5.4 status

• Work is going well. There's a new bug that we should look into. But we've done RC builds and we're sending notes to users who are having problems with 12101 in hopes they'll test.
• If things go well, we'll probably do a release in a week.

Luc

• Did most of the implementation for subtitle support in VLC with Miro on Windows. Doesn't have a Windows build environment, so he's passing this off to Ben or Will to finish up on Windows.
• Hoping to have the repository changes done asap.

Will

• Keeping tabs on 2.5.4 rc1 testing progress.
• Helped prisioner on IRC get Miro building on Windows with mingw32. Keeping tabs on that progress with the hope that we can switch from building with Visual Studio 2003 to mingw32.
• Planning to do the big repository filtering today.
• Planning to take on the subtitles in VLC on Windows work for Luc

Ben

• Did a bunch of 2.5.4 work.
• Finished the fasttypes removal work.
• Got some more data on 12301. Going to look into it to see if there's anything we can divulge from it.

Janet

• 2.5.4 rc1 looks good except for bug 12426.
• Continued working on building the test infrastructure for Miro Community. Has two volunteers helping with building test cases.

Paul

• Working on Miro Community features: html editing for comments, fixing the submit a video flow, added an RSS feed for categories, ...
• Back to working on Miro Community bugs.

Nick

• Morgan is going to work on another theme for Miro Community.
• Working on making Miro Community easier to modify.

bugzilla

• 11 bugs/feature-requests created
• 1 bugs marked DUPLICATE
• 7 bugs marked FIXED

notes

Are these reports useful to anyone? No one has commented, no one has mentioned them on IRC or email, ... If they're not useful and no one is reading them, then I should be spending my time elsewhere.

About a week ago, Joe contributed a patch to disable the screensaver on KDE when Miro is playing fullscreen. I don't run any systems with KDE on them. I'd love to get some help testing this patch so that we can include it in the next release of Miro.

The bug for this work is http://bugzilla.pculture.org/show_bug.cgi?id=3067. The patch is at http://bugzilla.pculture.org/attachment.cgi?id=1980.

Let me know whether this patch works or doesn't work for you either in the comments of this blog entry or in the comments of the bug.