Building from Source
The only solution in this case is to build mms from source. I’ve downloaded the latest
, and build it with these switches:
--use-internal-ffmpeg --enable-debug --enable-tv --enable-game --enable-weather --enable-notify-area --enable-clock --enable-python --enable-lirc --enable-clock --disable-inotify --enable-alsaplayer --disable-ffmpeg-thumb --enable-rip
Resolving the dependencies would be an easy job, if you do have the package sources. Lucky me, we do have the package sources, because I’ve delivered an
deb-src into the
sources.list.d file. Having the sources around, it’s an easy task to find out all dependencies you need to build the package from source. Usually e.g. a
aptitude build-dep mms-plugin-rip
would install all ever needed development packages onto your machine, and you won’t ever run into a dependency problem while running the
./configure procedure. Don’t be afraid, if a huge dependency list for only a single plugin slaps into your face. It’s fully normal for MMS to have huge dependencies, and it could drive you insane resolving them manually. Be thankful for this feature, and be thankful to your PPA package maintainer. In our case all our kudos go to Roman Müllenschläder.
If you read “MMS 1.2.0” or something, then we are talking about the new – highly experimental – MMS version. It’s really not ready to be used, and is for developers mainly. Even if it’s ready, you won’t see much of a change, because the work is going on beneath the surface. Work is going on to make MMS remotely controllable, like VDR is today (port 2001), and the theming and plugin architecture will be rewritten from scratch. Knowing these facts, you won’t expect results soon, so stick with the 1.1.x branch for now, like I do for quite a while. And if you remember the time it took to jump from MMS 1.0.x onto 1.1.x, you’ll automatically will lower your expectations. But this is also the reason, why MMS is that stable, and that’s why I’m using it for years now on an every day basis.