MOC

Those of you who have been watching the SVN HEAD might have had the feeling that not much has been happening over the past six months. But over that period many, many hours have been spent interrogating under bright lights those historical bugs which remained in order to fix as many of them as possible before the release of MOC 2.5.0. read more

Those of you who have been watching the SVN HEAD might have had the feeling that not much has been happening over the past six months. But over that period many, many hours have been spent interrogating under bright lights those historical bugs ... [More] which remained in order to fix as many of them as possible before the release of MOC 2.5.0. Many bugs were fixed but unfortunately there are several bugs which have run away too fast to catch or which are of low impact and for which the fixes developed are potentially too disruptive to introduce this late in the release cycle. The new problems which are being reported now are largely single-user failures in extraordinary conditions for which MOC is often not the prime suspect. Therefore, unless some show-stopping bug emerges from its hidey-hole, what is now the current SVN HEAD will be released in a week or so (with only additional administrative patches) as the stable MOC 2.5.0. In order to shorten the release cycle (and not prolong my own frustration at not being able to move on with MOC 2.6 development), I am not releasing this as another beta. That decision may come back to bite me, but I'm feeling fairly confident it won't (and if it does there's always 2.5.1). I would encourage those of you who have helped in the past with pre-release testing to checkout the current SVN HEAD for a thorough thrashing over the next few days. Forums: General discussion [Less]

I'll be having more to say on what I would like to see in MOC bug reports after version 2.5 is out and I have more time to do so, but I recently reread an essay by Simon Tatham and it agrees with much of what I would have to say. I first read it many ... [More] years ago from a contract programmer and FOSS user's point of view. I thought it was good then, but I was somewhat shielded from end user bug reports by support staff. Now, rereading it as a FOSS developer, it resonates with me much more deeply. Not only does his essay help to inform users how to report bugs, it also explains (in user-friendly terms) the process we programmers need to go through to locate and fix the bug. Knowing that, users will understand why programmers ask the questions they do and how to answer them appropriately. Simon says of programmers: They will want to know lots of details about your computer, so they can work out how it differs from theirs. A lot of these details will depend on the particular program, but one thing you should definitely be ready to provide is version numbers. The version number of the program itself, and the version number of the operating system, and probably the version numbers of any other programs that are involved in the problem. I would go further and say that you should always provide the MOC version you are using in the initial report. It is easily obtained using mocp --version but is so frequently missing from MOC bug reports. It is important because repeatedly asking for it is time wasting, and trying to reproduce the problem without it is pointless. I'm seriously considering just ignoring bug reports which do not include it. An obvious implication of posting a bug report is that I will need to talk to you; be prepared to talk to me. I may not do so immediately, so it's important that you frequently monitor the thread on which you reported your problem. But there is only so much can be done on the Forum, and at some stage I may well have to continue the conversation by e-mail. Please make sure that the e-mail address you registered with is one on which mocmaint can talk to you. If I can't talk to you I probably can't fix your problem (and probably won't try very hard). Don't stop talking to me half way through (at least, not without explanation). If you do that, you're wasting the time of both of us and it would probably have been better if you hadn't posted the problem at all. Worse, you may have stopped someone else who was serious about finding a solution posting the problem themselves. If you find a solution to your problem yourself, let us know! If it's a MOC issue, then maybe improvements can be made; if not, then at least I won't waste time by continuing to work on it. Others may also be experiencing the same problem and could benefit from your solution. Simon also says: In this essay I'll try to state clearly what makes a good bug report. Ideally I would like everybody in the world to read this essay before reporting any bugs to anybody. Certainly I would like everybody who reports bugs to me to have read it. I, too, would certainly like everybody who reports MOC bugs to have read it. Forums: General discussion [Less]

Forums: General discussion I'll be having more to say on what I would like to see in MOC bug reports after version 2.5 is out and I have more time to do so, but I recently reread an essay by Simon Tatham and it agrees with much of what I would ... [More] have to say. I first read it many years ago from a contract programmer and FOSS user's point of view. I thought it was good then, but I was somewhat shielded from end user bug reports by support staff. Now, rereading it as a FOSS developer, it resonates with me much more deeply. Not only does his essay help to inform users how to report bugs, it also explains (in user-friendly terms) the process we programmers need to go through to locate and fix the bug. Knowing that, users will understand why programmers ask the questions they do and how to answer them appropriately. Simon says of programmers: They will want to know lots of details about your computer, so they can work out how it differs from theirs. A lot of these details will depend on the particular program, but one thing you should definitely be ready to provide is version numbers. The version number of the program itself, and the version number of the operating system, and probably the version numbers of any other programs that are involved in the problem. I would go further and say that you should always provide the MOC version you are using in the initial report. It is easily obtained using mocp --version but is so frequently missing from MOC bug reports. It is important because repeatedly asking for it is time wasting, and trying to reproduce the problem without it is pointless. I'm seriously considering just ignoring bug reports which do not include it. An obvious implication of posting a bug report is that I will need to talk to you; be prepared to talk to me. I may not do so immediately, so it's important that you frequently monitor the thread on which you reported your problem. But there is only so much can be done on the Forum, and at some stage I may well have to continue the conversation by e-mail. Please make sure that the e-mail address you registered with is one on which mocmaint can talk to you. If I can't talk to you I probably can't fix your problem (and probably won't try very hard). Don't stop talking to me half way through (at least, not without explanation). If you do that, you're wasting the time of both of us and it would probably have been better if you hadn't posted the problem at all. Worse, you may have stopped someone else who was serious about finding a solution posting the problem themselves. If you find a solution to your problem yourself, let us know! If it's a MOC issue, then maybe improvements can be made; if not, then at least I won't waste time by continuing to work on it. Others may also be experiencing the same problem and could benefit from your solution. Simon also says: In this essay I'll try to state clearly what makes a good bug report. Ideally I would like everybody in the world to read this essay before reporting any bugs to anybody. Certainly I would like everybody who reports bugs to me to have read it. I, too, would certainly like everybody who reports MOC bugs to have read it. [Less]

I'll be having more to say on what I would like to see in MOC bug reports after version 2.5 is out and I have more time to do so, but I recently reread an essay by Simon Tatham and it agrees with much of what I would have to say. read more

I'll be having more to say on what I would like to see in MOC bug reports after version 2.5 is out and I have more time to do so, but I recently reread an essay by Simon Tatham and it agrees with much of what I would have to say. I first read it ... [More] many years ago from a contract programmer and FOSS user's point of view. I thought it was good then, but I was somewhat shielded from end user bug reports by support staff. Now, rereading it as a FOSS developer, it resonates with me much more deeply. Not only does his essay help to inform users how to report bugs, it also explains (in user-friendly terms) the process we programmers need to go through to locate and fix the bug. Knowing that, users will understand why programmers ask the questions they do and how to answer them appropriately. Simon says of programmers: They will want to know lots of details about your computer, so they can work out how it differs from theirs. A lot of these details will depend on the particular program, but one thing you should definitely be ready to provide is version numbers. The version number of the program itself, and the version number of the operating system, and probably the version numbers of any other programs that are involved in the problem. I would go further and say that you should always provide the MOC version you are using in the initial report. It is easily obtained using mocp --version but is so frequently missing from MOC bug reports. It is important because repeatedly asking for it is time wasting, and trying to reproduce the problem without it is pointless. I'm seriously considering just ignoring bug reports which do not include it. An obvious implication of posting a bug report is that I will need to talk to you; be prepared to talk to me. I may not do so immediately, so it's important that you frequently monitor the thread on which you reported your problem. But there is only so much can be done on the Forum, and at some stage I may well have to continue the conversation by e-mail. Please make sure that the e-mail address you registered with is one on which mocmaint can talk to you. If I can't talk to you I probably can't fix your problem (and probably won't try very hard). Don't stop talking to me half way through (at least, not without explanation). If you do that, you're wasting the time of both of us and it would probably have been better if you hadn't posted the problem at all. Worse, you may have stopped someone else who was serious about finding a solution posting the problem themselves. If you find a solution to your problem yourself, let us know! If it's a MOC issue, then maybe improvements can be made; if not, then at least I won't waste time by continuing to work on it. Others may also be experiencing the same problem and could benefit from your solution. Simon also says: In this essay I'll try to state clearly what makes a good bug report. Ideally I would like everybody in the world to read this essay before reporting any bugs to anybody. Certainly I would like everybody who reports bugs to me to have read it. I, too, would certainly like everybody who reports MOC bugs to have read it. Forums: General discussion [Less]

I'll tell you what I wanted, what I really, really wanted, and that was that after MOC 2.5.0-beta1 was released into the wild we'd see no new bugs and could put out a stable release shortly thereafter. Unfortunately, we don't always get what we ... [More] want. But finally, MOC 2.5.0-beta2 is here! MOC 2.5.0-beta1 was largely a success, but still the scurrying sound of both old and new bugs were heard and we've been tracking them through the undergrowth ever since. Most have been squished, some not. MOC 2.5.0-beta2 tidies things up. In this release there are some fixes for new problems, and also for some old problems for which new clues have enabled progress to be made. Significant changes in this release: Provided locking support for non-thread-safe FFmpeg/LibAV library functions. Provided better FFmpeg or LibAV discrimination. Provided better audio duration reliability determination. Added handling for "planar" codecs. Excluded experimental codecs from decoding. Fixed many ongoing FFmpeg/LibAV API breakages. Fixed bugs in 24-bit sample handling. Made processing of keymap file consistant with that of config file. Restored screen to console mode after reporting fatal errors. Populated playlist panel when loading default playlist file. Removed default playlist autofocus at start. Fixed some screen upsets when tags contain UTF-8 characters. Fixed assertion when a second client is started. Fixed slow memory leak in client on long-playing streams. Fixed handling of huge (greater than 2 GiB) files. Fixed sub-second audio truncation on ALSA. Fixed segfault when using '--format' without an audio playing. The issues not resolved in this release but which will be worked on for 2.5.0-beta3 mainly fall into two categories: Internet connection problems, and Misreporting of audio durations. I hope it won't be as long in the making as either of the two preceding 2.5 releases have been and will be followed very shortly by the final (and exceedingly stable) MOC 2.5.0 release. John Fitzgerald, MOC Maintainer. Release: Development release. [Less]

I'll tell you what I wanted, what I really, really wanted, and that was that after MOC 2.5.0-beta1 was released into the wild we'd see no new bugs and could put out a stable release shortly thereafter. Unfortunately, we don't always get what we ... [More] want. But finally, MOC 2.5.0-beta2 is here! MOC 2.5.0-beta1 was largely a success, but still the scurrying sound of both old and new bugs were heard and we've been tracking them through the undergrowth ever since. Most have been squished, some not. MOC 2.5.0-beta2 tidies things up. In this release there are some fixes for new problems, and also for some old problems for which new clues have enabled progress to be made. Significant changes in this release: Provided locking support for non-thread-safe FFmpeg/LibAV library functions. Provided better FFmpeg or LibAV discrimination. Provided better audio duration reliability determination. Added handling for "planar" codecs. Excluded experimental codecs from decoding. Fixed many ongoing FFmpeg/LibAV API breakages. Fixed bugs in 24-bit sample handling. Made processing of keymap file consistant with that of config file. Restored screen to console mode after reporting fatal errors. Populated playlist panel when loading default playlist file. Removed default playlist autofocus at start. Fixed some screen upsets when tags contain UTF-8 characters. Fixed assertion when a second client is started. Fixed slow memory leak in client on long-playing streams. Fixed handling of huge (greater than 2 GiB) files. Fixed sub-second audio truncation on ALSA. Fixed segfault when using '--format' without an audio playing. The issues not resolved in this release but which will be worked on for 2.5.0-beta3 mainly fall into two categories: Internet connection problems, and Misreporting of audio durations. I hope it won't be as long in the making as either of the two preceding 2.5 releases have been and will be followed very shortly by the final (and exceedingly stable) MOC 2.5.0 release. John Fitzgerald, MOC Maintainer. Release: Development release. [Less]

I'll tell you what I wanted, what I really, really wanted, and that was that after MOC 2.5.0-beta1 was released into the wild we'd see no new bugs and could put out a stable release shortly thereafter. Unfortunately, we don't always get what we want. But finally, MOC 2.5.0-beta2 is here! read more

I had set myself the goal of getting MOC 2.5-beta2 out during the month of September, but despite my best intentions real world concerns have managed to interfere once again with the MOC Master Plan. We really need to get MOC 2.5.0 out because it ... [More] will form a stable base from which MOC can move forward. Once it is, the various contributions which have been on hold for what seems like forever can be merged into the code base and made publicly available. Then there are a number of mechanisms which need to be put in place to support upcoming new features. Finally, we can start introducing that new functionality. I'm really looking forward to that new work, and it's frustrating not to be able to get on to it. Not only is it more rewarding to work on than bug fixing, but it also addresses a lot of those odds and ends that people have asked for over the years and provides some much improved capabilities for MOC users. It may not appear that much effort is going into MOC any more, but that's far from the truth and there is much going on which isn't publicly visible. Many of those new features are well advanced but there's still a lot left to be done. MOC does have a future, but it's a small team and there are many demands on the time of its members. Some weeks MOC gets a lot of attention, other weeks... not so much. Forums: General discussion [Less]