[vdr] Random and slow behaviour with streamdev

Jan Ekholm jan.ekholm at smultron.net
Tue Oct 21 17:28:21 CEST 2008


Today I tried out streamdev for the first time ever with a fresh 1.6.0 
installation of VDR. I followed the docs on the homepage and got the CVS 
version. The plugin compiled fine and I had no problems getting it all 

What I want to achieve is live TV streaming from VDR to an MPlayer (or 
something else if MPlayer sucks) client. No EPG is needed nor any other extra 
features, only raw audio/video is needed.

I simply start VDR with a "-P streamdev" parameter and then connect using 
MPlayer from another host and below is what happens in 75% of my trials. When 
it manages to connect and stream it looks perfect. The host "hex" is where VDR 

% mplayer http://hex:3000/C-15-3-33
MPlayer 1.0rc2-4.3.2 (C) 2000-2007 MPlayer Team
[extra MPlayer info]
Playing http://hex:3000/C-15-3-33.
Resolving hex for AF_INET6...
Couldn't resolve name for AF_INET6: hex
Resolving hex for AF_INET...
Connecting to server hex[]: 3000...
Cache size set to 320 KBytes
Cache fill:  0.00% (0 bytes)   nop_streaming_read error : Resource temporarily 
Cache fill:  0.00% (0 bytes)
Exiting... (End of file)

This entire process takes about 10s and both systems are fairly fast PC:s. The 
channel above is not encrypted. This is what VDR logs for the above test:

18:06:57 .. [12756] Streamdev: Accepted new client (HTTP)
18:06:57 .. [12795] streamdev-writer thread started (pid=12743, tid=12795)
18:06:57 .. [12796] streamdev-livestreaming thread started (pid=12743, 
18:06:57 .. [12797] receiver on device 2 thread started (pid=12743, tid=12797)
18:06:57 .. [12798] TS buffer on device 2 thread started (pid=12743, 
18:07:08 .. [12756] client (HTTP) has closed connection
18:07:08 .. [12756] streamdev: closing streamdev connection to
18:07:08 .. [12796] streamdev-livestreaming thread ended (pid=12743, 
18:07:08 .. [12795] streamdev-writer thread ended (pid=12743, tid=12795)
18:07:08 .. [12756] cTS2PES got 3 TS errors, 1 TS continuity errors
18:07:08 .. [12756] buffer stats: 752 (0%) used
18:07:08 .. [12798] TS buffer on device 2 thread ended (pid=12743, tid=12798)
18:07:08 .. [12797] buffer stats: 376 (0%) used
18:07:08 .. [12797] receiver on device 2 thread ended (pid=12743, tid=12797)

So apparently MPlayer doesn't see any data and gives up after 10 seconds. It 
does not matter wether I specify TS, PS, ES or PES as the stream protocol. 
Similar results for when the WWW-interface is used together with Dragon Player 
(or Xine), although it seems as some channels from a particular channel group 
works better and others never work.

Any hints as to what could be wrong? Or as people seem to use this plugin just 
fine, where I should be looking for the PEBKAC. :)

Kind regards,
    Jan Ekholm

        Five exclamation marks, the sure sign of an insane mind.
                                              -- Terry Pratchett, Reaper Man

More information about the vdr mailing list