Hey Miro, I want my Web TV!

Reporting

The bug in question has already been raised, and in several places. Debian describes it as “miro crashes when done playing a video” and assigns it bug number 464862. Although originally reported in version 1,0 and classified as “grave”, the bug is still found in version 1,1,2 and there is no response from the developer in the bug tracking system. Fortunately upstream were already aware of this bug a week before it was filed with Debian, and they describe it as “miro.real segfaults at the end of every video playback” with bug number 9545.

Things start to get tangled when you notice the upstream bug report contains a comment back downstream to Red Hat bug number 431268: “segfault playing with xine-lib”, which has a comment linking to an earlier Red Hat bug, number 392281, “Miro does not play videos”. Fortunately this chain does have an end, and leads to a workaround for the bug in the comments, which people have claimed is successful.

Adapting the workaround

Although the instructions for the workaround are quite detailed, they did not immediately work for me, and I believe they are in need of some adaptation or extra specification for users of some other Linux distributions, like Debian. I made the change to the source file (the excerpt given was lines 76 – 78 in my copy), and downloaded the required packages (which were called gstreamer0.10-plugins-bad, gstreamer0.10-plugins-ugly, and gstreamer0.10-ffmpeg) but this just caused Miro to load in some half-complete state where I couldn’t select any videos. Loading it on the command line, however, told me much more, and by researching the files mentioned in the error messages, I realised that Python required me to install a few more packages. First I installed python-gst0.10, then after some more error messages, gstreamer0.10-x. This seemed to do the trick.

Conclusion

This switch to the gstreamer backend resulted in a few other changes. Happily, the bug which has the title “Miro open 30 small windows on startup and asks for a bug report” in Debian (bug 454603) is fixed by this change, although it is also fixed in 1,0-2 package of Miro, (but this did not propagate to the testing suite and now Miro has been removed from testing completely). Less positively, the quality in some videos seems worse now, both in terms of aural and visual clarity. The audio seems scratchy, even making words hard to hear, and the video seems blocky and rough throughout some files. There are some other codec issues too, I believe, but I haven’t done an exhaustive test. One symptom I have to report is that on some YouTube videos I do not hear any sound when I set them playing, but on one such video I managed to get the audio to begin by navigating around in the file. Hopefully I will be able to endure these annoyances until a new version is released and makes its way downstream.

How many hours of web-based video must the channels you subscribe to create per week, and what percentage of it must be worth archiving for future repeat-viewing, before it offers an experience equivalent to or better than terrestrial broadcast? What is the form of the function which expresses the value of a growing archive of media over time?