[vdr] Random and slow behaviour with streamdev
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]
Resolving hex for AF_INET6...
Couldn't resolve name for AF_INET6: hex
Resolving hex for AF_INET...
Connecting to server hex[192.168.1.4]: 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 ..  Streamdev: Accepted new client (HTTP) 192.168.1.6:44378
18:06:57 ..  streamdev-writer thread started (pid=12743, tid=12795)
18:06:57 ..  streamdev-livestreaming thread started (pid=12743,
18:06:57 ..  receiver on device 2 thread started (pid=12743, tid=12797)
18:06:57 ..  TS buffer on device 2 thread started (pid=12743,
18:07:08 ..  client (HTTP) 192.168.1.6:44378 has closed connection
18:07:08 ..  streamdev: closing streamdev connection to
18:07:08 ..  streamdev-livestreaming thread ended (pid=12743,
18:07:08 ..  streamdev-writer thread ended (pid=12743, tid=12795)
18:07:08 ..  cTS2PES got 3 TS errors, 1 TS continuity errors
18:07:08 ..  buffer stats: 752 (0%) used
18:07:08 ..  TS buffer on device 2 thread ended (pid=12743, tid=12798)
18:07:08 ..  buffer stats: 376 (0%) used
18:07:08 ..  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. :)
Five exclamation marks, the sure sign of an insane mind.
-- Terry Pratchett, Reaper Man
More information about the vdr