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

1. Presentation

1.1. Description

MuMuDVB (Multi Multicast DVB) is a program that redistributes streams from DVB or ATSC (Digital Television) on a network (also called IPTV) using multicasting or HTTP unicast.It supports satellite, terrestrial and cable TV, in clear or scrambled channels and run on PC as well as several embedded platforms. It is intended to multicast (the stream is sent once and the network equipments split the data for the different clients) a whole DVB transponder (set of channels sent on the same carrier frequency) by assigning each channel a different multicast group. It detects the different services present as well as their important parameters for streaming, rewrite the main DVB tables to show clients only the right stream in each group.

History : MuMuDVB is originally a modification of dvbstream that cr@ns made to stream TV in a few hundred rooms.

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, Matthias Šubik, Krzysztof Ostrowski

  • Others, please see git logs

When contacting about an issue, please join 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 and follow changes, 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

  • Flexible configuration mechanism using templates

  • Support for embedded platforms based on UCLIBC and ANDROID

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

If you want to compile for OpenWRT, please follow OpenWRT tutorial

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)
  --enable-android        Support for Android (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 following the instructions here : LinuxTv DVB-apps page
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, their PIDs (Program IDentifiers), names, and Logical channel numbers.

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 channel list or the PIDs are changed, MuMuDVB will automatically update the channels.

In autoconfiguration MuMuDVB will try to detect everything and keep the user set parameters fixed. So you can tune manually only things which are relevant for your usage like the multicast IP. You can also use templates to generate multicast IP or other parameters.

We will review autoconfiguration starting without personalization then the cases when you want to change specific parameters for a (several) channel(s).

6.1. Pure 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 in autoconfiguration except if you need to specify special parameters.

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 autoconfiguration 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 addresses 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 autoconfiguration. To disable them put sap=0 in your config file. By default, SDT rewriting is activated if you use autoconfiguration. To disable it put rewrite_sdt=0 in your config file. By default, PAT rewriting is activated if you use autoconfiguration. To disable 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 which allows to specify the service identifier of the channels you want to be configured.
A detailled, documented example configuration file can be found in doc/configuration_examples/autoconf_full.conf

6.1.1. 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)

Other options: Ip, port

You can also use templates for specifying the ip addresses or the port, for example if you want to use the service identifier (unique channel number in the transponder) in your ip address, you can use autoconf_ip4=239.42.%sid_hi.%sid_lo. Maybe you will notice different transponders having different channels with the same service identifier, you can then use other template to make your IP unique autoconf_ip4=239.10*%server+%card.%sid_hi.%sid_lo.

Please refer to doc/README_CONF.txt (HTML version) in the section "Autoconfiguration parameters" to see which options accept which templates

Other keywords can be easily added if necessary, please contact if you have particular needs.

6.2. Advanced autoconfiguration

If the autodection mechanisms of Autoconfiguration are not suiting your needs, for example you need special IP for your channels or special names, you can force manually all channel parameters. The channel parameters specified by the user will not be overriden by autoconfiguration.

The channels are identified in DVB by their service identifier (SID), so you will need to specify this number to allow MuMuDVB know which channel you are refering too.

Some examples to show you the possibilities:

6.2.1. Specific IP

For example you need to specify a particular IP address for the channel with the service identifier 517, you can use the following configuration file



The IP address of all the other channels will be attributed using the default scheme, or the template you can define using autoconf_ip4,autoconf_ip6

6.2.2. Extra channels

You can also use this personalization to add specific channels, with the following example you will obtain all detected channels plus one extra which is the one you specified.


name=my dump channel

6.2.3. Specific channels with specific IP

This mode can be combined with autoconf_sid_list if you want to restrict the channels autodetected, in the following example we want to stream two channels and specify their IPs

autoconf_sid_list=516 517



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 address. It avoids to give to the client the list of the multicast ip addresses.

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 > 2.0.0

SAP announces are enabled by default, you will find them in the local network left submenu of the playlist

7.2.2. VLC < 2.0.0

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

7.2.3. VLC > 0.8.2 && VLC < 2.0.0

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.

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

You can ask the channel by the channel name. The search is case insensitive. If your channel name contains spaces, replace them by - character.

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


will give you the channel with name "Your TV station name". This works also with xine and mplayer.

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 address in your web browser.

To get the channel list (in JSON) just enter the address 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 autoconfiguration :

Just add cam_support=1 to your config file

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

  • For each scrambled channel add the 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

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.

Here some documentation about IPv6 and multicasting

RFCs concerning IPv6 scopes and addressing

What is MLD snooping (equivalent of IGMP in IPv6) and how to configure it on HP switches MLD snooping on Procurve

Support of IPv6 on Cisco switches IPV6 on cisco

Extract of the previous page

Layer 2 Switches
IPv6 traffic forwarding does not impact Layer 2 LAN switches, since these devices do not need to look at the Layer 3 header to forward an IPv6 frame; thus IPv6 hosts can be transparently attached to the following Cisco products. In addition, Layer 2 switches may integrate dedicated IPv6 features such as native IPv6 network management or MLD snooping (Cisco products marked with "*" in the list).
• Cisco Catalyst Express 500 Series Switch
• Cisco Catalyst 2900XL Series Switch
• Cisco Catalyst 2960 Series (*)
• Cisco Catalyst 3500XL Series Switch
• Cisco Catalyst 3560, 3560-E, 3750 and 3750-E Series Switch (*)
• Cisco Catalyst 4500 Series Switch
• Cisco Catalyst 4500-E Series Switch (*)
• Cisco Catalyst 5000 Series Switch
• Cisco Catalyst 6500 Series Switch (*)

Also Cisco introduced IPv6 Multicast in Cisco IOS Software Releases 12.0(26)S, 12 .2(18)S, and12.3(2)T. It has been deployed in numerous business-critical IPv6 Multicast networks.

Some useful commands for ipv6 multicast debugging under linux

Show the open sockets
netstat -6tulp

See the traffic (on iface eth0)
tcpdump -ni eth0 ip6

See the traffic to a particular address (here the SAP IPv6 announces)
tcpdump -ni eth0 ip6 host FF05::2:7FFE

Read an IPv6 stream with VLC (under linux)
vlc -vvv --ipv6 udp://@\[ff15::1\]:1234

17. 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).

18. 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

18.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

18.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

18.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 )

18.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