An HTML version of this file is availaible on MuMuDVB’s website.

1. Presentation

1.1. Description

MuMuDVB (Multi Multicast DVB) is originally a modification of dvbstream that cr@ns made. We have decided to redistribute it.

Now, it’s a standalone project.

MuMuDVB is a program that redistributes streams from DVB (Digital Television) on a network (also called IPTV) using multicasting or HTTP unicast. It can multicast a whole DVB transponder by assigning each channel a different multicast IP. It detects the different services present, rewrite the main DVB tables to show clients only the right stream in each group.

1.2. Website

2. Authors and contacts

Upstream author
  • Manuel Sabban (getopt)

  • Stéphane Glondu (man page, debian package)

  • Special thanks to Dave Chapman (dvbstream author and contributor)

  • Pierre Gronlier, Sébastien Raillard, Ludovic Boué, Romolo Manfredini

When contacting about an issue, please join the config file used and the output of MuMuDVB in verbose mode ( -vvv on the command line) and any other information that could be useful.

3. Contents and features

3.1. Features overview

  • Stream channels from a transponder on different multicast IPs

  • Support for scrambled channels (if you don’t have a CAM you can use sasc-ng, but check if it’s allowed in you country/by your broadcaster)

  • Support for automatic configuration i.e channels discovery, see Autoconfiguration section

  • Generation of SAP announces, see SAP section

  • Support of DVB-S2, DVB-S, DVB-C, DVB-T and ATSC

  • Possibility to partially rewrite the stream for better compatibility with set-top boxes and some clients. See PAT Rewrite and SDT Rewrite sections.

  • Support for HTTP unicast see http unicast section

  • Support for RTP headers (only for multicast)

  • CAM menu access while streaming (using a web/AJAX interface - see WEBSERVICES.txt and CAM_menu_interface.png for screenshot)

  • Software descrambling through oscam dvbapi and libdvbcsa

3.2. Detailled feature list

  • Can show reception level when streaming

  • Show if channels are successfully descrambled by the CAM

  • Makes a list of streamed and down channels in real time

  • Can deamonize and write his own process id in a file

  • Supports standard and universals LNBs

  • Can stop himself if it receives no data from the card after a defined timeout

  • Stops trying tuning after a configurable timeout

  • The mandatory pids are always sent with all channels :

    • PAT (0): Program Association Table

    • CAT (1): Conditionnal Access Table

    • NIT (16): Network Information Table: intended to provide information about the physical network.

    • SDT (17): Service Description Table: data describing the services in the system e.g. names of services, the service provider, etc.

    • EIT (18): Event Information Table: data concerning events or programmes such as event name, start time, duration, etc.

    • TDT (20): Time and Date Table: information related to the present time and date.This information is given in a separate table due to the frequent updating of this information.

  • Can suscribe to all multicast groups (IGMP membership request) in order to avoid some switches to broadcast all channels see problems with HP switches.

  • Supports autoconfiguration, see Autoconfiguration section

    • In autoconfiguration mode, MuMuDVB follow the changes in the PIDs and update itself while running.

  • Debian flavor initialisation scripts

  • The buffer size can be tuned to reduce CPU usage, see reduce MuMuDVB CPU usage section.

  • Can avoid the sending of scrambled packets

  • Automatically detect the scrambling status of a channel

  • Can reset the CAM module in case of a bad initialisation

  • Can sort the EIT PID to send only the ones corresponding to the current channel

  • Data reading can be done using a thread, see thread reading section.

  • Playlist generation, see playlist

  • Templates support

  • Simple webservice exposing detailed streaming status (see WEBSERVICES.txt)

4. Installation

4.1. From sources

4.1.1. From a snapshot

If you downloaded a snapshot, you will have to generate the auto(conf make etc …) files. In order to do this you will need the autotools, automake, gettext and libtool and, type in the folder of MuMuDVB

autoreconf -i -f

Then you have a source which can be installed as a release package.

4.1.2. From a release package

In order to install MuMuDVB type:

$ ./configure [configure options]
$ make
# make install

The [configure options] specific to MuMuDVB are:

  --enable-cam-support    CAM support (default enabled)
  --enable-scam-support   SCAM support (default enabled) (see note below)
  --enable-coverage       build for test coverage (default disabled)
  --enable-duma           Debbuging DUMA library (default disabled)
If you want to compile MuMuDVB with clang/llvm, you have to install llvm-gcc and add CC=llvm-gcc LD=llvm-ld or CC=clang LD=llvm-ld to your [configure options].

You can have a list of all the configure options by typing

$ ./configure --help
The CAM support depends on libdvben50221, libucsi (from linuxtv’s dvb-apps). The configure script will detect automatically the presence of these libraries and deactivate the CAM support if one of them is not present. In the case of fedora, the dvb-apps package does not contains the headers, you have to install it manually follwing the instructions here :
The SCAM support depends on libdvbcsa from videolan. The configure script will detect automatically the presence of these libraries and deactivate the SCAM support if one of them is not present. It needs also trunk version of oscam to get control words. Oscam configuration is described below in section concerning software descrambling v2 inside mumudvb.
The decoding of long channel names for autoconfiguration in ATSC depends on libucsi (from linuxtv’s dvb-apps). The configure script will detect automatically the presence of this library and deactivate the long channel name support if it is not present. The full autoconfiguration will still work with ATSC but the channel names will be the short channels names (7 characters maximum)
If you want to compile the doc i.e. generate HTML files using asciidoc, type make doc. The rendering for the tables will work with asciidoc 8.4.4 (can work with lower version but not tested).

In order to install starting scripts (debian flavor) type:

# cp scripts/debian/etc/default/mumudvb /etc/default/mumudvb
# cp scripts/debian/etc/init.d/mumudvb /etc/init.d/mumudvb
It is advised to create a system user for MuMuDVB, e.g. : _mumudvb, you have to add this user to the video group and make the directory /var/run/mumudvb RW by this user. By doing this, you’ll be able to get all the features of MuMuDVB.

4.2. From Debian package

If you want to install a version which is not in your repositories, you can install it by hand by typing:

# dpkg -i mumudvb*.deb

Otherwise you can use aptitude/synaptic as usual

5. Usage

The documentation for configuration file syntax is in doc/README_CONF.txt (HTML version).


mumudvb [options] -c config_file
mumudvb [options] --config config_file

Possible options are:

-d, --debug
        Don't deamonize and print messages on the standard output.

-s, --signal
        Print signal strenght every 5 seconds

-t, --traffic
        Print the traffic of the channels every 10 seconds

-l, --list-cards
        List the DVB cards and exit

        The DVB card to use (overrided by the configuration file)

        The server id (for autoconfiguration, overrided by the configuration file)

-h, --help
        Show help

        More verbose (add for more)

        More quiet (add for less)

        Debug option : Dump the stream into the specified file

Signal: (see kill(1))

    SIGUSR1: switch the signal strenght printing
    SIGUSR2: switch the traffic printing
    SIGHUP: flush the log files

6. Autoconfiguration

MuMuDVB is able to find the channels in the transponder and their PIDs (Program IDentifiers).

Without autoconfiguration, you have to set the transponder parameters, and for each channel, the multicast ip, the name and the PIDs (PMT, audio, video, teletext etc…)

If the PIDs are changed, MuMuDVB will automatically update the channels except if you put autoconf_pid_update=0 in your configuration file.

MuMuDVB is able to do two kinds of autoconfiguration:

6.1. Full autoconfiguration

This is the easiest way to use MuMuDVB.

Use this when you want to stream a full transponder or a subset of a transponder (using autoconf_sid_list).

You don’t have to specify any channel using this mode

In this mode, MuMuDVB will find for you the different channels, their name and their PIDs (PMT, PCR, Audio, Video, Subtitle, Teletext and AC3).

In order to use this mode you have to: - Set the tuning parameters to your config file - Add autoconfiguration=full to your config file - You don’t have to set any channels - For a first use don’t forget to put the -d parameter when you launch MuMuDVB: e.g. mumudvb -d -c your_config_file

Example config file for satellite at frequency 11.296GHz with horizontal polarization

The channels will be streamed over the multicasts ip adresses 239.100.c.n where c is the card number (0 by default) and n is the channel number.

If you don’t use the common_port directive, MuMuDVB will use the port 1234.

By default, SAP announces are activated if you use this autoconfiguration mode. To deactivate them put sap=0 in your config file. By default, SDT rewriting is activated if you use this autoconfiguration mode. To deactivate it put rewrite_sdt=0 in your config file. By default, PAT rewriting is activated if you use this autoconfiguration mode. To deactivate it put rewrite_pat=0 in your config file.
If you want to select the services to stream, you can use the autoconf_sid_list option.
A detailled, documented example configuration file can be found in doc/configuration_examples/autoconf_full.conf

6.1.1. Name templates and autoconfiguration

By default the name of the channel will be the name of the service defined by the provider. If you want more flexibility you can use a template.

For example, if you use autoconf_name_template=%number-%name The channels name will be in the form :

  • 1-CNN

  • 2-Euronews

There is different keywords available:

Keyword Description


The name given by the provider


The MuMuDVB channel number


The channel primary language


The DVB card number


The tuner number


The server number specified by server_id or the command line


The logical channel number (channel number given by the provider). Your provider have to stream the LCN. The LCN will be displayed with three digits including 0. Ex "002". If the LCN is not detected, %lcn will be replaced by an empty string.


Same as above but with a two digits format


The channel service id (decimal for the port, hexadecimal for ipv6)


The channel service id. The two higher bits (between 0 and 255)


The channel service id. The two lower bits (between 0 and 255)

Please refer to doc/README_CONF.txt (HTML version) to see which options accept which templates

Other keywords can be easily added if necessary.

6.2. Simple autoconfiguration

This autoconfiguration mode will soon disapear. If you absolutely need it except for setting the channel names and their IP adresses, please contact.

Use this when you want to control the name of the channels, and their IPs better than using the templates.

  • You have to add autoconfiguration=partial in the head of your config file.

  • For each channel, you have to set:

    • the Ip adress (except if you use unicast)

    • the name

    • the PMT PID

MuMuDVB will find the audio, video, PCR, teletext, subtitling and AC3 PIDs for you before streaming.

If you put more than one PID for a channel, MuMuDVB will deactivate autoconfiguration for this channel.
A detailled, documented example configuration file can be found in doc/configuration_examples/autoconf_partial.conf
Simple autoconfiguration can fail finding the good pids if a PMT pid is shared within multiples channels. In this case you have to add the service_id option to the channel to specify the service id.

7. SAP announces

SAP (Session Announcement Protocol) announces are made for the client to know which channels are streamed and what is their name and adress. It avoids to give to the client the list of the multicast ip adresses.

VLC and most of set-top boxes are known to support them.

MuMuDVB will automatically generate and send SAP announces if asked to in the config file or if you are in full autoconfiguration mode.

The SAP announces will be only sent for alive channels. When a channel goes down, MuMuDVB will stop sending announces for this channel, until it goes back.

7.1. Asking MuMuDVB to generate SAP announces

For sending SAP announces you have to add sap=1 to your config file. The other parameters concerning the sap announces are documented in the doc/README_CONF.txt file (HTML version).

7.1.1. SAP announces and full autoconfiguration

If you use full autoconfiguration, you can use the keyword %type in the sap_default_group option. This keyword will be replaced by the type of the channel: Television or Radio.


If you put sap_default_group=%type, you will get two sap groups: Television and Radio, each containing the corresponding services.

7.2. Configuring the client to get the SAP announces

7.2.1. VLC > 0.8.2

You have to enter the settings, choose advanced settings. The SAP announces are in playlist→service discovery.

Don’t forget to save the settings.

You should have now a SAP section in your playlist.

7.2.2. VLC < 0.8.2

Click on the "Settings" menu, then on "add interface" and choose SAP playlist. Then open you playlist, the SAP announces should appear automatically.

8. HTTP Unicast

In addition to multicast, MuMuDVB also supports HTTP unicast. This make you able to use MuMuDVB on networks wich doesn’t support multicast.

There is one listening connection, the channel is selected via the HTTP path, see further.

And you can have listening sockets per channel, in this case the client will always get the same channel independantly of the path.

Be careful with unicast, it can eat a lot of bandwith. Think about limitting the number of clients.
If you don’t want the (always here) multicast traffic to go on your network set multicast=0

8.1. Activate HTTP unicast

To enable HTTP unicast you have to set the option unicast. By default MuMuDVB will listen on all your interfaces for incoming connections.

You can also define the listening port using port_http. If the port is not defined, the default port will be 4242.

8.2. Activate "per channel" listening socket

You can create listening connections only for a channel. In this case, when a client connect to this socket he will alway get the same channel independantly of the HTTP path.

8.2.1. If you use full autoconfiguration

You need to set the option autoconf_unicast_start_port which define what is the output port for the first discovered channel (for the following channels the port will be incremented).

8.2.2. If you don’t use full autoconfiguration

For the channels for which you want to have a listening unicast socket you have to set the option unicast_port which define the listening port of the socket

8.3. Client side, the different methods to get channels

8.3.1. Using a playlist

MuMuDVB generates m3u playlists.

If you server is listening on the ip and the port 4242,

In this playlist the channels will be announced with URLs type /bysid/ (see below), if you want a playlist for single channel sockets, use the URL /playlist_port.m3u.
Playlists for multicast are also generated, they are accessible using the following names: "playlist_multicast.m3u" and "playlist_multicast_vlc.m3u"

8.3.2. Single channel socket

If the client connect to a single client socket he will get the associated channel independantly of the path.

If you server is listening on the ip and the port for the channel is 5000,


8.3.3. Get the channel by number

You can ask the channel by the channel number (starting at 1).

If you server is listening on the ip and the port 4242,


will give you the channel number 3. This works also with xine and mplayer.

8.3.4. Get the channel by service id

You can ask the channel by the service id.

If you server is listening on the ip and the port 4242,


will give you the channel with the service id 100, or a 404 error if there is no channel with this service id. This works also with xine and mplayer.

8.3.5. Get the channel by name

This is not implemented for the moment, it will be implemented in a future release

8.3.6. Get the channels list

If you server is listening on the ip 10.0.1 and the port 4242,

To get the channel list (in basic html) just enter the adress in your web browser.

To get the channel list (in JSON) just enter the adress in your web browser.

8.4. HTTP unicast and monitoring

This HTTP connection can be used to monitor MuMuDVB.

Monitoring information is avalaible in JSON format ( vis the following urls /monitor/signal_power.json and /monitor/channels_traffic.json

It’s quite easy to add new informations to these files if needed.

9. Monitoring

You can use Monit to monitor MuMuDVB an restart it when it experiences problems (MuMuDVB kill himself when big issues appear).

You have to install the init scripts (automatic if you used the Debian package) and add the following lines to your /etc/monit/services file:

check process mumudvb with pidfile /var/run/mumudvb/
    start program = "/etc/init.d/mumudvb start"
    stop program = "/etc/init.d/mumudvb stop"
The 0 have to be replaced by the DVB card number if you have multiples cards.

For more detailled information, refer to the Monit Website.

MuMuDVB usually run for many days without problems, but with monit you are safe. Monit is also able to send e-mails in case of problems.

10. Scrambled channels support

Important note : check the contract with your broadcaster to see if you are allowed to stream the scrambled channels you’re subscribed to.

10.1. Hardware descrambling

MuMuDVB supports scrambled channels via hardware descrambling i.e. a CAM (Conditionnal Access Module). It can ask the CAM to descramble multiple channels if the CAM supports it (Aston Pro, or PowerCam Pro are known to work with multiple channels).

If you are limited by the number of PIDs the can can decrypt simultaneously, it is possible to ask the CAM to decrypt only the audio and video. This feature is not implemented, please ask if you need it.

The hardware descramblig uses almost no CPU, all the descrambling is made by the CAM.
MuMuDVB doesn’t query the CAM before asking for descrambling. The query is not reliable. Most of CAMs answer a menu when the descrambling is not possible and MuMuDVB will display it on the standard error.

The information concerning the CAM is stored in '/var/run/mumudvb/caminfo_adapter%d_tuner%d''' where %d is the DVB card number.

Example contents of '/var/run/mumudvb/caminfo_carte%d'''
CAM_Menu_String=PowerCam_HD V2.0
In case of issues with some king of CAMs the libdvben50221 could have to be patched: Link to the patch

10.1.1. How to ask MuMuDVB for descrambling?

You are using full autoconfiguration :

Just add cam_support=1 to your config file

You are using partial autoconfiguration or no autoconfiguration
  • Add cam_support=1 to your config file (before the channels)

  • For each scrambled channel add the cam_pmt_pid option. This option is made for MuMuDVB to know wich PID is the PMT PID wich will be used to ask for descrambling

You have an example of CAM support in doc/configuration_examples/autoconf_partial.conf

10.2. Hardware CAM issues

Some hardware CAM are not directly connected to the tuner, one can choose the stream sent to the CAM. This can make the work slightly more complicated to run the CAM since you have to ensure the right stream is sent to the CAM.

10.2.1. Digital Devices Cine CT V6

We always use cards and hardware from Digital Devices( - Octopus CI - Cine S2 V6.5

After a lot of problem with mumudvb and the ci card we found out, that the hardware wasn’t detected by mumudvb. The folder /dev/dvb looked like :

        - Adapter0
        - Adapter1
        - Adapter2
        - Adapter3

/dev/dvb/Adapter0 and Adapter1 had the following content:

demux0  dvr0  frontend0  net0

/dev/dvb/Adapter2 and Adapter3 had the following content:

sec0    ca0

So there was no connection between the tuner and the CI.

So we tried to load the driver of the card with a different parameter to get everything into one single folder.

sudo modprobe ddbridge adapter_alloc = 3


/dev/dvb/ includes only adapter0

Content of adapter0:

ca0  demux0  dvr0  frontend0  net0  sec0
ca1  demux1  dvr1  frontend1  net1  sec1

After that we had to pipe the stream from the frontend truth the CI modul. This part is still very buggy and we don’t know exactly how that works.

sudo echo "02 02" > /sys/class/ddbridge/ddbridge0/redirect
sudo echo "03 03" > /sys/class/ddbridge/ddbridge0/redirect

At the moment we have the problem that we can use only one tuner. :(

Here you can see some more information about this problem

10.3. Software descrambling v1

Important note : this solution is not allowed by some provider contracts.

MuMuDVB has been reported to work with software descrambling solutions like sascng + newcs + dvbloopback.

In this case you don’t need to set the cam_support option. Just ajust the card option to fit with your virtual dvbloopback card.

If you use these solutions, see reduce MuMuDVB CPU usage section.

10.3.1. Some information on how to configure SASC-NG

The following informations have been given by MuMuDVB users on the MuMuDVB-dev mailing list

When the channels are not sucessfully descrambled (channel down in MuMuDVB) the following options are reported to improve the situation

--sid-nocache --buffer 8M --sid-filt=200 -D

You can try also the option --sid-allpid It seems to happend with transponders with a lot of channels (TV or RADIO channels).

10.4. Scrambling status

The scrambling status is stored together with the streamed channel list.

Example l'Histoire:PartiallyUnscrambled PL:PartiallyUnscrambled 5:HighlyScrambled
  • FullyUnscrambled : less than 5% of scrambled packets

  • PartiallyUnscrambled : between 5% and 95% of scrambled packets

  • HighlyScrambled : more than 95% of scrambled packets

10.5. Software descrambling v2

Important note : this solution is not allowed by some provider contracts.

MuMuDVB now has support for software descrambling on its own, to do that you’ll need to have trunk version of oscam and libdvbcsa installed. To enable you have to add to global options scam_support=1 on program options add oscam=1 Other setting are documented at doc/README_CONF.txt (HTML version), there is also a configuration example available at configuration_examples/oscam.conf

If channel has a lot of bandwidth it may be needed to extend ring buffer size.

If cw’s don’t get in time defined as decsa delay(default 500000us=0.5s), you may try to extend it (decsa_delay max is 10000000, and send_delay should be lower than decsa_delay, because we can’t send descrambled packets befor they’re being descrambled) for example:


note that bigger delays in ring buffer may need also extending ring buffer size

In debug mode number of packets in the buffer is reported and buffer overflow is detected, you should use that to tweak your delays and ring buffer size. In http state.xml number of packets in the buffer is also reported.

Use the latest version of oscam from trunk, older versions did not have support for pc dvbapi. Instructions how to compile are on
When using oscam with more than 16 channels adjust macro definition MAX_DEMUX (line below) on oscam header module-dvbapi.h to number of your channels
#define MAX_DEMUX 16
When using multiple channels per card (more than (ecm_change_time)/(2*card_response_time)), you may get timeouts on oscam on mumudvb startup, it’s because on startup oscam asks card for two cw’s at the same time. It should get right after a while. Currently there is no solution for that bug.

10.5.1. Some information on how to configure oscam

In the oscam.conf file add the following options

        enabled = 1
        au = 1
        boxtype = pc
        user = mumudvb
        pmt_mode = 4
        request_mode = 1

11. PAT (Program Allocation Table) Rewriting

This feature is mainly intended for set-top boxes. This option will announce only the streamed channel in the Program Allocation Table instead of all transponder channels. Computer clients parse this table and decode the first working program. Set-top boxes usually try only the first one which give usually a blank screen in most of the channels.

To enable PAT rewriting, add rewrite_pat=1 to your config file. This feature consumes few CPU, since the rewritten PAT is stored in memory and computed only once per channel.

PAT rewrite can fail (i.e. doesn’t solve the previous symptoms) for some channels if their PMT pid is shared. In this case you have to add the service_id option to the channel to specify the service id.

12. SDT (Service Description Table) Rewriting

This option will announce only the streamed channel in the Service Description Table instead of all transponder channels. Some clients parse this table and can show/select ghost programs if it is not rewritten (even if the PAT is). This can rise to a random black screen.

To enable SDT rewriting, add rewrite_sdt=1 to your config file. This feature consumes few CPU, since the rewritten SDT is stored in memory and computed only once per channel.

If you don’t use full autoconfiguration, SDT rewrite needs the service_id option for each channel to specify the service id.

13. EIT PID (Event Information Table) Sorting

This option will make MuMuDVB stream only the EIT packets corresponding to the streamed channel instead of all transponder channels. Some clients parse this table and can show/select ghost programs (even if the PAT and the SDT are rewritten).

The EIT PID contains the description of the current program and the future programs. It is used to build the Electronic Program Guide.

To enable EIT sorting, add sort_eit=1 to your config file.

If you don’t use full autoconfiguration, EIT sorting needs the service_id option for each channel to specify the service id.

14. Reduce MuMuDVB CPU usage

Normally MuMuDVB reads the packets from the card one by one and ask the card if there is data avalaible between each packets (poll). But often the cards have an internal buffer. Because of this buffer, some pollings are useless. These pollings eat some CPU time.

To reduce CPU usage, one solution is to try to read several packets at the same time. To do this use the option dvr_buffer_size.


To see if the value you put is too big or to low, run MuMuDVB in verbose mode, the average number of packets received at the same time will be shown every 2 minutes. If this number if below your buffer size, it is useless to increase it.

The CPU usage reduction can be between 20% and 50%.

15. Data reading using a thread

In order to make MuMuDVB more robust (at the cost of a slight CPU consumption increase), MuMuDVB can read the data from the card using a thread. This make the data reading "independant" of the rest of the program.

In order to enable this feature, use the option dvr_thread.

This reading uses two buffers: one for the data just received from the card, one for the data treated by the main program. You can adjust the size of this buffers using the option dvr_thread_buffer_size. The default value (5000 packets of 188 bytes) should be sufficient for most of the cases.

The message "Thread trowing dvb packets" informs you that the thread buffer is full and some packets are dropped. Increase the buffer size will probably solve the problem.

16. IPv6

MuMuDVB supports IPv6 multicasting. It is not enabled by default you have to activate it using the multicast_ipv6 option

To "enjoy" multicasting you need a switch which supports the Multicast Listener Discovery protocol.

IPv6 use extensively the concept of scoping. By default MuMuDVB uses the scope "site-local" (ie multicast addresses starting with FF05) the SAP announcements are also sent with this scope. If you need to have more flexibility on this side, please contact.

For more details, please consult the IPv6 page on MuMuDVB’s website

17. Technical details (not sorted)

  • CPU consuming: MuMuDVB takes 15% CPU of a celeron 2.6GHz with an Hauppauge card and linux version 2.6.9 when streaming a full transponder (about 30MBit/s)

  • Try to avoid old via or nForce chipsets and in general ultra low cost motherboards. They can’t deal with a lot of data on the PCI bus.

  • When the program starts, he writes the channel list in the file /var/run/mumudvb/channels_streamed_adapter%d_tuner%d (where %d are the card number and the tuner number). This file contains streamed channels (updated every 5 seconds) in the form: "name:ip:port:Scramblingstatus"

  • MuMuDVB is able to support as many cards as the operating system does. Old versions of udev+glibc were not able to support more than 4 cards but this problem is solved using relatively recent versions (udev > 104 and libc6 > 2.7)

  • When daemonized, MuMuDVB writes its process identifier in /var/run/mumudvb/, where %d is replaced by the card number and the tuner number

  • MuMuDVB supports satellite in the Ku band, with universal or standard LNBs. The support of satellites in the S or C band is implemented via the use of the lo_frequency option. See doc/README_CONF.txt (HTML version).

18. MuMuDVB Logs

MuMuDVB can send it’s logs to the console, to a file or via syslog. It can also be several of these channels. The formatting of the logs can also be adjusted.

By default, the logs are sent to the console if not daemonized and via syslog otherwise.

If the logs are sent to a file, you can ask MuMuDVB to flush the file using the SIGHUP signal.

For more detail about these features see doc/README_CONF.txt (HTML version).

19. Known issues

19.1. VLC can’t read the stream but it is fine with xine or mplayer

  • For VLC, you must specify the PMT PID besides audio and video PIDs. It’s a frequent issue. To solve it you can use the verbose mode of VLC (vlc -v) and you’ll see a ligne like: [00000269] ts demuxer debug: * number=1025 pid=110 you’ll have the PMT PID associated with your program number, you can also use dvbsnoop, or see how to get pids in doc/README_CONF.txt (HTML version). Another solution is to use full autoconfiguration.

19.2. VLC reads the video but no audio

  • This problem can happend if the PCR (i.e. clock) information is not carried with the video. In this case you have to check if the PCR PID is in the PIDs list.

19.3. MuMuDVB can’t deamonize

  • In order to deamonize, MuMuDVB needs the directory /var/run/mumudvb/ to be writable, in order to write his process identifier and the channel list.

19.4. The system crashes or freeze

  • Old via chipset or nForce chipset are not professional chipsets. They can’t deal with a lot of data on PCI. But you can try to tune your BIOS.

19.5. Tuning issues with DVB-T

  • You must check tuning settings, knowing that auto bandwidth usually does’nt work.

19.6. The set-top box display a blank screen

  • If the stream is working well when reading it with a computer and not with your set-top box, this is probably because your set-top box needs the PAT PID to be rewritten. To do this add rewrite_pat=1 to your config file.

19.7. Simple autoconfiguration fails finding the right pids

  • This can happend if a PMT PIDs is shared among multiple channels, see simple autoconfiguration section for more details.

19.8. The CAM is complaining about locked channels

  • Some viaccess CAMs can have a lock for "mature" channels. To deactivate this lock go on the CAM menu using "gnutv -cammenu" for example (from linuxtv dvb-apps).

You have to set the maturity rating to maximum and unlock Maturity rating in Bolts submenu.

19.9. VLC doesn’t select the good program even with PAT rewriting

You also have to rewrite the SDT PID using the rewrite_sdt option

19.10. HELP ! my multicast traffic is flooded (I have a HP procurve switch)

The best explanation is found in the HP multicast routing guide.

On switches that do not support Data-Driven IGMP, unregistered multicast groups are flooded to the VLAN rather than pruned. In this scenario, Fast-Leave IGMP can actually increase the problem of multicast flooding by removing the IGMP group filter before the Querier has recognized the IGMP leave. The Querier will continue to transmit the multicast group during this short time, and because the group is no longer registered the switch will then flood the multicast group to all ports.

On ProCurve switches that do support Data-Driven IGMP (“Smart” IGMP), when unregistered multicasts are received the switch automatically filters (drops) them. Thus, the sooner the IGMP Leave is processed, the sooner this multicast traffic stops flowing.

Switches without problems (supporting data driven igmp):

  • Switch 6400cl

  • Switch 6200yl

  • Switch 5400zl

  • Switch 5300xl

  • Switch 4200vl

  • Switch 3500yl

  • Switch 3400cl

  • Switch 2900

  • Switch 2800

  • Switch 2500

Switches WITH problems (NOT supporting data driven igmp):

  • Switch 2600

  • Switch 2600-PWR

  • Switch 4100gl

  • Switch 6108

So if you have one of the above switches this is "normal". The workaround is to make MuMuDVB join the multicast group. For this put multicast_auto_join=1 in your configuration file.

19.11. MuMuDVB is eating a lot of CPU with sasc-ng !

If you use sasc-ng + dvbloopback, MuMuDVB will eat more CPU than needed.

A part of this CPU time is used to descramble the channels, another part is due to the way dvbloopback is implemented and the way MuMuDVB ask the card.

To reduce the cpu usage, see reduce MuMuDVB CPU usage section. In the case of using MuMuDVB with sasc-ng this improvement can be quite large. Or you can use oscam.

19.12. The reception is working but all the channels are down

If the signal is good but MuMuDVB tells you that all the channels are down and you are sure about your pids it can be due to your CAM module if you have one. Try after unplugging your CAM module.

19.13. I want to stream from several cards

The solution is simple: just launch a MuMuDVB process for each card.

19.14. I want to stream the whole transponder on one "channel"

MuMuDVB can stream all the data received by the card to one "channel" (multicast or unicast). In order to do this you have to use the put the PID 8192 in the channel PID list.

19.15. I have several network interfaces and I want to choose on which interface the multicast traffic will go

In order to specify the interface, you can specify a route for the multicast traffic like :

route add -net netmask dev eth2

or use multicast_iface4 and multicast_iface6 options

19.16. What does the MuMuDVB error code means ?

Here’s a short description of the error codes


19.17. I get the message "DVR Read Error: Value too large for defined data type" what does it mean ?

This message means that an overflow append in the ard drivers buffer. I.e MuMuDVB was not able to get the packets sufficiently fast. This issue can have various causes, anything which an slow down (a lot) MuMuDVB an create this message. To avoid it you can try threaded_read see thread reading section.

An explanation can be networking issues :

I experienced the "DVR Read Error…" message very often on my Streaming Server (ia64 Madison 1.3Ghz) (with errors in the video). I could solve the problem by exchanging the network switch. The old switch was limiting multicast traffic to 10Mb/s per port. This limit is not documented.

I have tested the limit the programm dd and mnc (Multicast netcat,

dd if=/dev/zero bs=188 count=1000000 | ./mnc-bin

I looked with "iftop" at the current network statistics and with my old switch i saw the limit at 10Mb/s with another switch I was able to transmit 92Mb/s ~ 100% of the avaiable bandwith.

Thanks to Jan-Philipp Hülshoff for the report

20. Using MuMuDVB with "particular" clients

People were able to use MuMuDVB with various clients, I will report here the tutorials I received for some of them

20.1. XBMC (for XBOX originally)

Description: XBMC (XBMP really) started as a program for modified XBOX consoles. In the following years, XBMC has grown into a multi-platform, multi-architecture media center that runs on most standard hardware. The hardware and legal limitations of the XBOX were always a concern and the Team has instead focused on running on the hardware that most people already have.

Tutorial: Here`s what You have to do, open Your favorite text editor and write an ip address with the protocol You are using of the particular program and port save it as something.strm. You have to create .strm files for every program You are streaming. Once you have done that fire up WinSCP and connect to the ip address of Your XBMC box if You are using the live version username and password is xbmc xbmc if You have installed the live version then You have provided the username and password during install process. Now copy theoes .strm files to the XBMC box in lets say home folder. Now in XBMC go to the video menu then click add source then click browse and navigate to the home folder and click ok then u have to give the name of that source use what ever You like and click ok and thats it. Go to the video menu You will see that You have a folder named as You named the source open it and You will see all of Yours .strm files click on it and it will start to play the stream from mumudvb. Works weather You are using multicast or unicast.

Thanks to Ivan Cabraja for the tutorial

20.2. MythTV

Description: MythTV is a Free Open Source software digital video recorder (DVR) project distributed under the terms of the GNU GPL.

Tutorial: Configuring Mythtv and mumudvb

20.2.1. Mumudvb Configuration:

You need to turn pat rewriting on (i.e. rewrite_pat=1).

You can use either multicast or udp streaming to mythtv (udp streaming is achieved by using a non-multicast ip address in the configuration file i.e. ip= Http unicast streaming is not supported in mythtv, but RTSP should be when this is implemented in mumudvb.

The channel name needs to be in the following format "channel number" - "channel name" (e.g. name=1 - TV One )

20.2.2. Mythtv configuration:


In mythtv-setup you need to add a new "network recorder" capture card. Enter the address of the playlist mumudvb provides in the "M3U URL" field. This will be something like

You then create a video source as normal, and associate this with the "Network recorder" capture card via the "input connections" option.

You then need to carry out a channel scan (while you are associating the video source or via the channel editor).

The channel scan appears to hang on 0%, but just select finish after a couple of seconds. This should have loaded the channels defined in the M3U file into mythtv.

Relying on the EIT information embedded in the stream does not appear to work, so you need to load this information from an external xmltv source. You do this by going into the channel editor and adding the correct xmltv ID for each channel. Once you have done this you exit out of mythtv-setup and run something like: mythfilldatabase --file 1 freeview.xml (where in this case the the xmltv file is called freeview.xml).

To allow recording and viewing of multiple channels from the one transponder, you need to add additional (identically configured) "network recorder" capture cards. For example if you want to be able to record two channels and watch a third at the same time you need to have set up a total of three network recorder cards.


if you are streaming channels from several transponders (by using several instances of mumudvb) you have two options:

1) The obvious thing to do is to define a different network recorder for each transponder (with the appropriate playlist defined), each transponder has to be associated with a different video source (assuming each transponder contains different channels). However, this does not seem to work well, with regular crashes when changing channels, and it also requires that you first switch between video sources to be able to change between channels on different transponders [this may be due to my lack of skill at configuring mythtv]

2) An easier way is to generate a custom m3u file, that contains the channels of all the transponders. This also allows you to define the xmltvid of each channel as well - removing the need to do this manually in the channel editor. In this case when you set up the network recorders, you can enter a file path for the location of the m3u file, as opposed to accessing it via a web-server (e.g. file///home/nick/channels.m3u ). Once again you simply make multiple copies of the (identical) network recorder capture card if you want to record/watch multiple channels.

An example of a m3u file is as follows (in this case the first four channels defined are from one mumudvb instance, and the last two from another - of course care has to be taken in configuring the various mumudvb instances to make sure none of the channels are assigned the same port etc):

#EXTINF:0,1 - TV1
#EXTINF:0,2 - TV2
#EXTINF:0,6 - TVNZ 6
#EXTINF:0,7 - TVNZ 7
#EXTINF:0,3 - TV3
#EXTINF:0,4 - c4

Thanks to Nick Graham for the tutorial