The VideoLAN Forums

Hello all,
I'm posting in this "OS independent" section of the forum because I found that the problem I had and that I have described on viewtopic.php?f=12&t=42549 seems to happen on Windows too.

I have a linux-based satellite receiver called IPBox. It's very similar to the more famous DreamBox, and does indeed run the same software. It is supposed to be able to stream data on the network as it comes from the satellite in the form of an MPEG-TS stream; VLC is the viewer of choice, and the web interface (called Enigma) has convenient links to direct VLC to the correct URL for the streaming, not to mention a cool "WEB-X-TV" functionality based on the VLC browser plugin. The quickest way to access the stream of the current channel is to use an URL like http://root:password@ipaddress/video.m3u. In my case, I left the default password (ipbox) and the IP address is 192.168.0.25, easily shortened through /etc/hosts to "ipbox".

The problem I have is that when I try to open http://root:ipbox@ipbox/video.m3u (or any more exact link provided by the web interface, such as http://192.168.0.25:31339/0,0451,0201,028b), more often than not I will get no window with the video. Nothing at all, it stays there downloading the streaming video but not showing anything. If I open the "Statistics" window, I will see the bitrate of the channel and the total amount of data transferred so far, but no video ever appears. Trying again might make it work, but sometimes I need to change channels and go back to the one I tried to watch, but that doesn't guarantee anything. Sometimes I just give up. Funny enough, trying MPlayer OSX 2 usually works even when VLC fails, but the video it shows is very sluggish, with pixelation (similar to interruptions in the MPEG stream) and with no easy way -- if there is one at all -- to change the deinterlace mode, and so on. In general, I'd rather like to use VLC, but I'm a little clueless as to what's going on. I also tried fiddling with the demux options for TS streams, and I did so a little randomly, but I don't seem to have changed anything. I even went for the complete deletion of user prefences, just to be sure I had a clean VLC (I did so both on Mac and on Windows), but nothing changed either.

My machine is an iMac intel 2.16 GHz with 2 GB of RAM; I run OS X 10.5.1 and the VM runs Windows XP SP2.

For the VLC gurus out there, here is what the log says when the stream DOES work: (some other harmless warnings will follow during the whole streaming session)

This is what I get when the stream DOES NOT work: And that's it, nothing else ever appears even though the stream does come down, as shown by the statistics:

It seems, as the log implies anyway, that the stream can't seem to get demultiplexed.

As far as I found, this seems to be a moderately common problem with Dreambox/Ipbox users. Is there any solution, or any test I can do to try and track it down? Thank you very much!

Using wget, I downloaded some piece of a stream that VLC didn't open. It doesn't open the dumped stream either, while mplayerosx (and mpegstreamclip) seem to be opening it -- the problem with mplayer is that it's VERY sluggish, so it's not an option. If you open this in VLC and keep an eye on the messages window, you can see pretty much what I get live. Hopefully some developer will be able to have a look at it. Here is the dump: http://sogno.net/tmp/stream.ts.
Note that it's not really a matter of "waiting it out": earlier today I let vlc try to catch on a stream for over ten minutes, but nothing ever appeared.

Thank you in advance.

I have the exact same issue as described above by jollino.

I have a dreambox which is connected to my Foxtel Satellite TV service (Australia).

I have tested this with VLC 0.86d on both Mac OS X and Windows XP.

When i try to play the mpeg2 transport stream coming from the dreambox VLC just sits there downloading, but never displays any video, or plays any audio.

However if i stream the audio component only, it works fine, so the problem seems to be with the video component.

I have managed to get mplayer to successfully play the stream, I had the same problem as jollino with a jerky picture etc with mplayer, but I have got it working 100% perfectly by using the mad decoder for audio:

mplayer -ac mad -vf pp=lb -cache 2000 "$(wget -q -O - http://root:dreambox@192.168.1.64/video.m3u)"

However I would really like to get this working in VLC, as that is my preferred application.

I used mplayer to dump a sample to a .ts file, VLC still refuses to play this file, just like it does when streaming it. But maybe someone can use the .ts file to do some debugging and see what is going on? mplayer can play this file fine.

Download the .ts here - http://www.2shared.com/file/2821909/e4551b4d/test.html

Thanks Everyone!

Cheers.

I dont know how to get logs out of VLC, but this is what mplayer shows in the console when you play the stream:

ok, i figured out how to get logs from VLC
Then it just sits there still downloading over the network, but not displaying anything

I'm glad to know I'm not the only one with this issue. I have been using MPlayer too, albeit with a less comfortable way: an applescript downloads video.m3u and copies its contents to the clipboard, so I can paste the URL into MPlayer OS X. This is because mplayer doens't allow selection of audio track on the fly (about the only reason I'd prefer to use VLC), and plays them all together or takes the first one (which might not be what I want; I am not sure why the behavior changes randomly, so I have to "count" the audio tracks from the URL and remove all but what I need. Quite messy, I tell you.

The weird thing is that it works on and off, sometimes it's perfect and other times it just doesn't work, without a pattern.
Another thing I noticed is that connecting to port 31338 (not 31339) using the apid OR the vpid as the resource (e.g. http://1.2.3.4:31338/29f) shows the video OR plays the audio. I have no idea if it's possible to multiplex them on port 31338... that would be perfect.

Just wondering: what decoder do you have? The Dreambox DM500 I got for my parents seems to work fine. I admit I'm tempted to sell the ipbox 350S and get a dreambox DM600 for this reason, as I am seldom where I have the ipbox and I'd like to watch tv through the network...

Hello all,

I encounter the _exact_ same problems with a DM500 running Gemini 4.20 image (Gemini_420_DM500_17122007.img). The tricky thing is that watching the stream is a hit or miss thing, and it depends on which channel I'm trying to watch (some don't work at all).

Any idea on how to investigate / debug this further ? Apparently VLC has a hard time demuxing the stream coming from the DM500. I've tried this on VLC version 0.8.5 and 0.8.6d on Windows but would happily dig this on a more "appropriate" platform (if it would help).

TIA,

Florian

A few more details (vlc 0.8.4 on Linux):
When attempting to open the stream vlc aborts with smth like:

root@D620:~/Desktop# vlc http://192.168.1.99:31339/0,0024,0320,0321
VLC media player 0.8.4 Janus
libdvbpsi error (PSI decoder): TS discontinuity (received 12, expected 0) for PID 0
[00000261] main playlist: stopping playback

A bit more detailed output:
...
[00000274] main private debug: pre buffering
[00000274] main private debug: received first data for our buffer
[00000274] main private debug: prebuffering done 40880 bytes in 0s - 235 kbytes/s
[00000270] main input debug: creating demux: access='http' demux='' path='192.168.1.99:31339/0,0024,0320,0321'
[00000275] main demuxer debug: looking for demux2 module: 41 candidates
[00000155] main module debug: using demux2 module "ts"
[00000275] ts demuxer debug: DEMUX_SET_GROUP 0 (nil)
[00000270] main input debug: `http://192.168.1.99:31339/0,0024,0320,0321' successfully opened
[00000275] ts demuxer debug: pid[800] unknown
[00000275] ts demuxer debug: pid[801] unknown
libdvbpsi error (PSI decoder): TS discontinuity (received 12, expected 0) for PID 0
[00000275] ts demuxer debug: PATCallBack called
[00000275] ts demuxer debug: new PAT ts_id=2 version=4 current_next=1
[00000275] ts demuxer debug: * number=0 pid=16
[00000275] ts demuxer debug: * number=201 pid=44
[00000275] ts demuxer debug: * number=204 pid=35
[00000275] ts demuxer debug: * number=401 pid=33
[00000275] ts demuxer debug: * number=402 pid=38
[00000275] ts demuxer debug: * number=906 pid=39
[00000275] ts demuxer debug: * number=229 pid=40
[00000275] ts demuxer debug: * number=230 pid=41
[00000275] ts demuxer debug: * number=303 pid=34
[00000275] ts demuxer debug: * number=403 pid=36
[00000275] ts demuxer debug: * number=408 pid=37
[00000275] ts demuxer debug: * number=411 pid=42
[00000275] ts demuxer debug: * number=1024 pid=258
[00000275] ts demuxer warning: lost synchro
[00000275] ts demuxer debug: skipping 80 bytes of garbage
[00000001] main vlc debug: removing all interfaces
...

Any advice would be highly appreciated.

TIA,

Florian

P.S. Opening the stream with MPlayer 1.0-rc1 as posted above works perfectly.

Okay, it seems like the problem is more common than I thought. I recently got ahold of a Dreambox DM500 (original, not a clone) to use in another room, and I loaded Gemini 4.30 on it. The VLC access is unpredictable from that too and I haven't noticed any pattern. The fact that this happens with all models of Dreambox-like receivers and with all sorts of images makes me think that there is some joint issue with Enigma and VLC's DVB module (libdvbpsi), but I'm not sure which is at fault.

Certainly the Dreambox might output malformed data, yet mplayer seems to be able to read it on all platforms. I suppose that the only thing we could do, unless there is a good programmer among us who is able to fix the problem, is to file a bug ticket on both VLC's bugtracking sytem and on Enigma's, if there is one.

I am pretty sure that the problem on the VLC side lies in libdvbpsi (the latest version can be checked out with "svn://svn.videolan.org/libdvbpsi/trunk libdvbpsi-trunk"). According to http://www.videolan.org/developers/libd ... geLog.html, there has been some work going on and both a developer and a patch-submitter seem to know how the internals work. Perhaps we could contact them directly, and we could provide them with some dumped TS stream ("wget http://dreambox:31339/etc" would be enough) so they could make some additional tests.

If you all agree, I can take care of gathering as many details as possible from my setup, which doesn't differ too much form yours, and file a bug ticket on both systems, or try to get in touch with developers of both Enigma and VLC.
In the meantime, I think we should recap what decoders we have, what image we are running on them, and which version of VLC and on which platform we are using. As for me:

IPBox 350S - ABcom 17.10.2007 -- VLC 0.8.6e OS X / Windows XP
Dreambox DM500 - Gemini 4.30 -- VLC 0.8.6e OS X / Windows XP

Completely agree. We can consistently replicate the bug and have enough debugging info to file for a bug. We could detail at length the platforms we're using, but I don't think that is relevant. OTOH a recorded stream that shows the problem should highlight the issue, and in that respect the "test.ts" stream posted above "works" perfectly -- VLC chokes on it whereas mplayer has no problems whatsoever.

So it would be great if you can file the bug and hope we'll get this fixed soon. Please let me know if I can assist with anything, and keep us (i.e. this thread) posted.

TIA,

Florian

I have opened a ticket at https://trac.videolan.org/vlc/ticket/1489, perhaps you could register to VLC's trac and add your own logs / TS file?

I really do hope this gets fixed, I also sent a message to a freelance developer who works on IPboxes...

A developer(?), cmassiot, just changed the status of the bug report to "Bugs paradize". Apparently, that tag applies to "Any bugs that have no definite deadline release."

Sources:
https://trac.videolan.org/vlc/ticket/1489#comment:1
https://trac.videolan.org/vlc/milestone/Bugs%20paradize

Nice to know that somebody is working on it.

I registered to VLC's trac, but apparently I'm not able to _add_ smth to a already submitted bug. I hope the devel's will look/post in this thread for more info, ask for more output or so.

Here's hoping for a quick bug fix.

The dm500 doesn't always include the PMT in the transport stream. Therefore vlc doesn't know what to do. Don't know if it's really a vlc bug.

Ok, thanks for the info... Although maybe not a VLC bug, but the de-muxing operation in other players are more robust -- and able to deal with it -- than libdvbpsi

And yes, I'm not particularly proud in __possibly__ advocating supporting a "broken" source, but still...

Indeed, an IPbox developer confirmed to me that the stream sent out by Enigma is not always standard-compliant. However, the PMT information is apparently not strictly needed for the stream to be decoded (see MPlayer), therefore VLC could just go ahead anyway too. In any case, the PMT is given as the second comma-delimited parameter in the URL (I'm not sure how exactly MPlayer deals with that).

I'd just like to add that I'm experiencing the same problem as jollino and windsok, and have confirmed it with 0.86d on both Windows XP SP2 and Mac OS X 10.4.11.

Interestingly, there was a time in the past year when VLC did work with the Dreamboxes. I know that back in 2006 there was at least one instance where a change broke compatibility too.

I haven't tried different Dreambox images, as I don't think the transport stream encoding will vary appreciably between them, though the web interface that launches VLC certainly can.

If anyone wants more test data from a third site, I'm happy to provide it.

strat, please add your report to https://trac.videolan.org/vlc/ticket/1489 ... perhaps some coder will consider it a little more (even though VLC is free so we can't expect any timeframe).

As for the web interface launching VLC, all it does it making it open /video.m3u; in theory, VLC should open and play the live stream simply by having it access http://root:dreambox@1.2.3.4/video.m3u -- replacing dreambox with your password and 1.2.3.4 with the dreambox's IP.