problems with simultaneous record and play with FREEBOX network recorder

[anonymous]

Fedora 7 SVN trunk of mythtv My tv service provider uses IP/UDP broadcast with their set-top box. I can connect and configure my fedora box to receive the streams, and I can successfully watch them with vlc and play/record them with mplayer/mencoder. I am able to record two streams with two instanced of mencoder fine, however when I try to record one with mythtv and watch another live, both the recording and the live show garble and lock up.

[Dave <megadave@…>]

(I was the person that submitted this report originally)

FWIW, I've just put together a new box, used the current SVN, and this problem is still there. On a whim, I fired up multiple (4) instances of VLC tuning the same source I'm trying to use with myth, and was able to successfully watch 4 different programs at the same time. If anyone has any fixes/workarounds they want me to try let me know. I've added my email addy.

[Dave <megadave@…>]

some additional info, which may be of use.

<djc_> mythbacke 28572 mythtv 20u IPv4 113084 UDP *:8208 <djc_> and here is vlc: <djc_> wxvlc 28671 mythtv 9u IPv4 113565 UDP 236.0.12.3:8208 <djc_> so vlc is binding a specfic multicast IP, whereas myth is binding *

<djc_> the service provider runs ethernet to the tv, they put a small box there, which you normally 'tune' with.. then it outputs on ch 3 to the tv over coax (it also has NTSC and SVID out) <djc_> ive taken the ethernet, removed it from their device, and connected it to my box <djc_> and I can tune one program just fine, even with myth <djc_> the problem comes when I try to create two 'network recorder' capture cards, and tune two <djc_> i can run multiple vlc instance and watch multiple programs and it works fine.. with myth the video becomes unintelligble when i try to tune more than one

<djc_> and reading over that thread at ​http://lists.samba.org/archive/linux/2006-September/016144.html

<djc_> suggests the problem, which makes perfect sense <djc_> two vlc's work fine. heck even four of them (each one tuned to a different show) work fine <djc_> so the funkiness is in myth <djc_> and i beleive it has to do with it binding a wildcard instead of the specific multicast ip for what its tuning

[Dave <megadave@…>]

Here is a sample of the .m3u file I am using. You can see that all the streams use the same port, and vary only by IP.

#EXTINF:0,49 - HGTV
udp://@236.0.12.50:8208
#EXTINF:0,50 - FOOD
udp://@236.0.12.51:8208
#EXTINF:0,51 - SPIKETV
udp://@236.0.12.52:8208
#EXTINF:0,52 - USA
udp://@236.0.12.53:8208
#EXTINF:0,53 - FX
udp://@236.0.12.54:8208

[Dave <megadave@…>]

In .../mythtv/libs/libmythlivemedia/groupsock/GroupsockHelper.cpp :

netAddressBits ReceivingInterfaceAddr? = INADDR_ANY;

Seems to be the culprit. I can't quite work out how to change this to have it use the specific address of the multicast group being joined

[Dave <megadave@…>]

Ok, I think there may be multiple 'network recorders', and apparently I have been working with each. I think in the recent release, there was both a 'CRC network recorder', which only took one url, and the 'FreeBOX network recorder', which took an m3u file. In the current trunk (which is where I am working from now) there appears to be only one called just 'Network Recorder', and it seems to be supported by the code in libmythtv/iptv/, and for udp urls, specifically libmythtv/iptv/iptvfeederudp.cpp, which relys on code in. libmythlivemedia/groupsock/* for actual UDP socket binding.

The chain of calls seems to pass along the port# to bind, but I cant seem to find wether the address (host) in the original URL is available anywhere to the groupsock code, such that it could be modified to bind that address rather than INADDR_ANY, which it appears to currently be hardcoded to do in GroupsockHelper?.cpp via:

// By default, use INADDR_ANY for the sending and receiving 
netAddressBits SendingInterfaceAddr = INADDR_ANY;
netAddressBits ReceivingInterfaceAddr = INADDR_ANY;

And then subsequently, with no possibility of ReceivingInterfaceAddr? changing:

  // Note: Windoze requires binding, even if the port number is 0
#if defined(__WIN32__) || defined(_WIN32)
#else
  if (port.num() != 0 || ReceivingInterfaceAddr != INADDR_ANY) {
#endif
    MAKE_SOCKADDR_IN(name, ReceivingInterfaceAddr, port.num());
    if (bind(newSocket, (struct sockaddr*)&name, sizeof name) != 0) {

I'd really like to change that call to MAKE_SOCKADDR_IN to use the actual address, and I'm wondering if the actual address contained in the URL is available at this level, or would it have to be added in the parameters of the parent functions?

[Dave <megadave@…>]

On 10/26/07, Ross Finlayson wrote:

I've only just found that the code used within mythtv for their 'Network Recorder' implementation seems to have originated with you. I've been trying to fix what seems to be a bug in this code, and while I think I've tracked the issue to its underlying cause, I'm not proficient enough with the code to be able to actually fix it.

The basic problem is that when attempting to run two instances of the code at once to receive two different UDP multicast streams, the two streams become intermixed, apparently due to the socket being bound to INADDR_ADY, rather than the specific multicast address of the desired stream.

The variable "ReceivingInterfaceAddr?" was intended just for this purpose.

Try adding the line

ReceivingInterfaceAddr? = our_inet_addr("x.y.z.w");

at the start of your application. (Replace "x.y.z.w" with the IP address of your desired interface.)

Well, actually theres the problem. I actually realized thats what I need to set. The problem is I'm not sure where to obtain that address. Note that I need not the address of the Ethernet port, but the address of the specific multicast stream being opened, and I can't quite figure out if/where that is being stored and/or if its being passed to the Groupsock functions. Does the live555 code handling the URL parsing, or is that handled elsewhere by mythtv?

Eg, if we are opening udp://236.12.0.9:8208/ I need to know the 236.12.0.9 similarly, if udp://236.12.0.23:8208/ I need the 236.12.0.23

• Show quoted text -

In the future, questions about the "LIVE555 Media Server" should be sent to the "live-devel@…" mailing list (see <​http://lists.live555.com/mailman/listinfo/live-devel/> to subscribe). Support for the server (and the "LIVE555 Streaming Media" software in general) is via that mailing list. --

Ross Finlayson Live Networks, Inc. ​http://www.live555.com/

[Dave <megadave@…>]

Ok, since ReceivingInterfaceAddr? seems to be a global, I have tried setting it in libs/libmythtv/iptv/iptvfeederudp.cpp as follows.

    ReceivingInterfaceAddr =  our_inet_addr( parse.host().latin1() );
    Groupsock *socket = new Groupsock(*_live_env, addr, parse.port(), 0);

Unfortunately, while that does result in it binding the socket correctly, the livemedia code seems to have some sort of problem identifying the 'source address for multicast'. I will note that the interface in question that has access to the multicast network does not have an IP address - which didnt seem to cause a problem with the socket was bound to INADDR_ANY. I tried setting an 169.x.y.z IP addresss on it, and that didn't help any.

[Dave <megadave@…>]

Ok. If I set ReceivingInterfaceAddr?, as before, in iptvfeederudp.cpp, but also set it to INADDR_ANY in ourSourceAddressForMulticast() in GroupsockHelper?.cpp, right before the call to setupDatagramSocket, then the code works properly for my situation. I'll clean it up and make a proper patch for anyone else that wants to test it, even though it should be only two changed lines of code.

[Dave <megadave@…>]

Ok, skip that patch. In my poking around I must have done something else, becuase I've tried it with just that patch and its not working. Back to the editor....

[Dave <megadave@…>]

Ok, this one I tested and it works.

[Benoît LORAND <benoit.lorand@…>]

i use this one since some weeks ans it solve my problem with view/recording freebox channels.

many thanks Dave !!!

is this patch will be include to svn version soon

[megadave@…]

logexcerpt.txt (attached for review by greg) is from a related but different problem with the network recorder. Occasionally after running for a while the recorder thinks it has successfully recorded a program, and it shows in media library, but when selected the UI indicates that the file cannot be found. The log refers to two different episodes of 'Jimmy Neutron' (I have a 6 yr old son :P) - both of which exhibited this problem.

[jyavenard@…]

May I know against what revision of SVN this patch has been made against.

With the current trunk version, the MPEG2TS playback is broken, the image quality is poor and there's a loss of sync between sound and video (check this bug report: ​http://svn.mythtv.org/trac/ticket/4739

rev #14618 works. But that's quite a far back.

[megadave@…]

Wow. After some time of not really watching tv at all (I had taken my mythtv setup offline), I decided the other day to get set back up. I decided to reinstall completely from scratch. I grabbed 0.21 (the latest releast) from svn, installed it on a fedora 9 box. I figured this fix would have been added ages ago, since its trivial, and it worked for me and at least one other person.

Imagine my surprise, once I get everything running, and try to record or watch two programs at once and still have the same problem. I come back here and this patch never got incorporated. So I will install it myself against 0.21.

I'm not sure if .21 was released prior to my submitting this, and myth's release cycles are just *really* slow, and if I'm the *only* person with a setup remotely similar to this, or.. I don't know.

Most users would probably have just decided "Oh, mythtv sucks", and either went with something else. I actually took the time to track this down, and even though I am not a coder, managed to work up a fix, and submitted a patch. I can't imagine that this change would interfere with any other functionality, so I'm just wondering what I need to do to get this incorporated.

[JYA]

I have just tried your fix against 0.21-fixes. It applied properly.

However, it doesn't fix the bug. Trying to show two IPTV channels will crash both frontends on my side.

[anonymous]

jyavenard,

I think you and I are looking at different bugs. This patch fixes a bug in the backend which isn't related to crashes.

The problem this patch fixes, is that when recording two network udp multicast streams at the same time which use the same port number but different multicast IP addresses, the streams get intermixed (and both end up as gibberish), because the recorder in the backend binds a wildcard IP instead of the specific multicast IP for each stream.

It still continues to fix the problem I was having.

[anonymous]

This patch works for me as well in in the subversion head. I had to adjust it a bit as it refers to .latin1() in the iptvrecorderudp.cpp instead of toLatin1()

[anonymous]

Replying to anonymous:

This patch works for me as well in in the subversion head. I had to adjust it a bit as it refers to .latin1() in the iptvrecorderudp.cpp instead of toLatin1()

and by iptvrecorderudp.cpp I meant iptvfeederudp.cpp

[greg]

(In [18968])

Closes #3873 . Fixes a problem when more than 1 IPTV stream

is coming in to the same box using the same destination port and myth was not restricting which IP it was listening on.

[Github]

Fix RTP IPTV with multiple IPTV interfaces. 1ed419ad applied a fix for udp IPTV where more than one interface was available, it didn't apply the fix for rtp which uses the same socket code. Fixes #8767, Refs #3873

Branch: master Changeset: 37cacb609357d785145f0f1a463d627feb6852f5