Hi,
it was about time to publish a streamdev release for VDR 2.0. Streamdev-0.6.1 is now available from http://projects.vdr-developer.org/projects/plg-streamdev/files. The server plugin requires at least VDR 1.7.25. The client plugin should even work with VDR 1.6. On VDR version up to 1.7.33 the Makefiles have to be replaced by the old versions which are shipped along with the source.
Besides bugfixes and internal changes the following features have been added since 0.6.0:
The client plugin can now provide multiple devices, allowing the client to receive more than one transponder from the same server (e.g. for PiP or clientside recordings). So it is no longer necessary to add a copy of the plugin unless you want to connect with multiple servers.
Basic support for HTTP streaming of recordings. There is still a lot to do. In particular a proper menu and remuxing are missing. At the moment the recording is streamed "as-is" (usually TS), even if the menu suggests something different.
In addition to the HTML menu and the M3U playlists, the HTTP server now also offers RSS feeds. Some smart TV apps should be able to make use of it.
A new option in streamdev-server suspends local output when starting. The default value "auto" will do this only if no output device is detected.
Here's the complete changelog: - Updated Slovak translation (thanks to Milan Hrala) - Updated Finnish translation (thanks to Rolf Ahrenberg) - Disabled PS remuxer which is said to produce anything but PS - The patches intcamdevices and ignore_missing_cam are no longer required on VDR >= 1.7.30. The localchannelprovide patch became obsolete with VDR 1.7.21. - Added option to suspend live TV when the server starts - Set device occupied when streamdev switches away LiveTV on the server, to reduce the risk that the VDR main loop immediately switches back, resulting in a black screen on the client (reported by hummel99) - Fixed channel switch issues with priority > 0 (reported by hummel99) - Removed noisy debug messages - Fixed HTTP menu destruction - API change of VDR 2.1.2 - Fixed priority handling, messed up when adding multi-device support - Added HTTP "Server" header (suggested by hivdr) - Ignore dummy file extensions (.ts, .vob, .vdr) when parsing HTTP URIs - Select start position for replaying a recording by parameter pos=. Supported values are resume, mark.#, time.#, frame.# or a plain # representing a percentage if < 100 or a byte position otherwise (thanks to hivdr) - Start cSuspendCtl hidden or it will prevent idle shutdown (thanks to thomasjfox) - Fixed recordings menu inode numbers: ino_t is a long long on some systems - Updated Slovak translation (thanks to Milan Hrala) - Adapted Makefiles to VDR 1.7.36+ (thanks to macmenot). Old makefiles have been renamed to Makefile-1.7.33. - API changes of VDR 1.7.38 (thanks to mal@vdr-developer) - Added simple recordings menu in HTTP server - Restructured menuHTTP classes - Added RSS format for HTTP menus - Recordings can now also be selected by struct stat "st_dev:st_ino.rec" - Implemented multi-device support for streamdev client (suggested by johns) - Basic support for HTTP streaming of recordings - Close writer when streamer is finished - Don't abort VTP connection if filter stream is broken - Restructured cStreamdevStreamer: Moved inbound buffer into actual subclass. - In cStreamdevStreamer dropped Activate(bool) and moved its code into Start(). - Moved cStreamdevFilterStreamer to livefilter.[hc] - Return HTTP/1.1 compliant response headers plus some always useful headers - Return HTTP URL parameters ending with ".dlna.org" as response headers - Store HTTP URL parameters in a map - Support HTTP HEAD requests with external remuxer - Fixed always using priority 0 for HTTP HEAD requests - Start writer right after creating it - Corrected typos (thanks to Ville Skyttä) - Fixed compiler error in client/device.c with VDR < 1.7.22 (reported by Uwe@vdrportal) - Updated Italian translation (thanks to Diego Pierotto) - Added DeviceName() and DeviceType() to client device. The server IP and the number of the device used on the server are returned respectively.
Have fun, Frank
Hello,
I'm using a pretty complex vdr configuration, with 4 DVB-S2 devices, every one of them is connected to 5 or 6 LNB's. The main (streamdev-server) vdr instance is using all the 4 adapters, and vdr-sxfe for output. I also run 2 more vdr instaces with stremdev-client (without real DVB adapter), also using vdr-sxfe. (All the 3 vdrs are running on the server machines, vdr-sxfes are running on remote, client systems). I would like to explain my problem as simpe, as possible: Let's say, that my /dev/dvb/adapter0 is providing 3 channels: CH1, CH2, CH3, and my adapter 1 is providing 4 channels: CH1..CH4. On the main vdr I'm watching CH1 using adapter 1. Until the client is watching CH1..CH3, I have no problem watching the server vdr, as the client uses adapter0. As the client switches to CH4, the main VDR also switches to CH4, as it can stream it only using my currently being used adapter1. I tried several priority setups to handle this, but I wasn't able to change this behaviour. My goal would be, to be 100% sure, that whatever happens on the client side, it shouldn't affect the one who is watching the server (and the client should get a "channel not available" message.)
thanks for the great work!
istván
2013.11.28. 22:48 keltezéssel, Frank Schmirler írta:
Hi,
it was about time to publish a streamdev release for VDR 2.0. Streamdev-0.6.1 is now available from http://projects.vdr-developer.org/projects/plg-streamdev/files. The server plugin requires at least VDR 1.7.25. The client plugin should even work with VDR 1.6. On VDR version up to 1.7.33 the Makefiles have to be replaced by the old versions which are shipped along with the source.
Besides bugfixes and internal changes the following features have been added since 0.6.0:
The client plugin can now provide multiple devices, allowing the client to receive more than one transponder from the same server (e.g. for PiP or clientside recordings). So it is no longer necessary to add a copy of the plugin unless you want to connect with multiple servers.
Basic support for HTTP streaming of recordings. There is still a lot to do. In particular a proper menu and remuxing are missing. At the moment the recording is streamed "as-is" (usually TS), even if the menu suggests something different.
In addition to the HTML menu and the M3U playlists, the HTTP server now also offers RSS feeds. Some smart TV apps should be able to make use of it.
A new option in streamdev-server suspends local output when starting. The default value "auto" will do this only if no output device is detected.
Here's the complete changelog:
- Updated Slovak translation (thanks to Milan Hrala)
- Updated Finnish translation (thanks to Rolf Ahrenberg)
- Disabled PS remuxer which is said to produce anything but PS
- The patches intcamdevices and ignore_missing_cam are no longer required on
VDR >= 1.7.30. The localchannelprovide patch became obsolete with VDR 1.7.21.
- Added option to suspend live TV when the server starts
- Set device occupied when streamdev switches away LiveTV on the server, to
reduce the risk that the VDR main loop immediately switches back, resulting in a black screen on the client (reported by hummel99)
- Fixed channel switch issues with priority > 0 (reported by hummel99)
- Removed noisy debug messages
- Fixed HTTP menu destruction
- API change of VDR 2.1.2
- Fixed priority handling, messed up when adding multi-device support
- Added HTTP "Server" header (suggested by hivdr)
- Ignore dummy file extensions (.ts, .vob, .vdr) when parsing HTTP URIs
- Select start position for replaying a recording by parameter pos=. Supported
values are resume, mark.#, time.#, frame.# or a plain # representing a percentage if < 100 or a byte position otherwise (thanks to hivdr)
- Start cSuspendCtl hidden or it will prevent idle shutdown (thanks to thomasjfox)
- Fixed recordings menu inode numbers: ino_t is a long long on some systems
- Updated Slovak translation (thanks to Milan Hrala)
- Adapted Makefiles to VDR 1.7.36+ (thanks to macmenot). Old makefiles have
been renamed to Makefile-1.7.33.
- API changes of VDR 1.7.38 (thanks to mal@vdr-developer)
- Added simple recordings menu in HTTP server
- Restructured menuHTTP classes
- Added RSS format for HTTP menus
- Recordings can now also be selected by struct stat "st_dev:st_ino.rec"
- Implemented multi-device support for streamdev client (suggested by johns)
- Basic support for HTTP streaming of recordings
- Close writer when streamer is finished
- Don't abort VTP connection if filter stream is broken
- Restructured cStreamdevStreamer: Moved inbound buffer into actual subclass.
- In cStreamdevStreamer dropped Activate(bool) and moved its code into Start().
- Moved cStreamdevFilterStreamer to livefilter.[hc]
- Return HTTP/1.1 compliant response headers plus some always useful headers
- Return HTTP URL parameters ending with ".dlna.org" as response headers
- Store HTTP URL parameters in a map
- Support HTTP HEAD requests with external remuxer
- Fixed always using priority 0 for HTTP HEAD requests
- Start writer right after creating it
- Corrected typos (thanks to Ville Skyttä)
- Fixed compiler error in client/device.c with VDR < 1.7.22 (reported by
Uwe@vdrportal)
- Updated Italian translation (thanks to Diego Pierotto)
- Added DeviceName() and DeviceType() to client device. The server IP and the
number of the device used on the server are returned respectively.
Have fun, Frank
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi István,
On Fri, 29 Nov 2013 12:17:58 +0200, Füley István wrote
Let's say, that my /dev/dvb/adapter0 is providing 3 channels: CH1, CH2, CH3, and my adapter 1 is providing 4 channels: CH1..CH4. On the main vdr I'm watching CH1 using adapter 1. Until the client is watching CH1..CH3, I have no problem watching the server vdr, as the client uses adapter0. As the client switches to CH4, the main VDR also switches to CH4, as it can stream it only using my currently being used adapter1. I tried several priority setups to handle this, but I wasn't able to change this behaviour. My goal would be, to be 100% sure, that whatever happens on the client side, it shouldn't affect the one who is watching the server (and the client should get a "channel not available" message.)
The "channel not available" message is the expected behaviour when a negative priority is configured on the client. With a priority of 0 or higher on the client, the client should get CH4. The server would then switch to CH1 on adapter0 if adapter0 isn't in use with priority >= 0, otherwise switch to CH4 with a "streaming active" message.
Can you confirm with the current 0.6.1 releases on client and server that the problem still exists if you configure a negative priority on the clients? If yes, I'll try to reproduce your setup at home.
Regards, Frank
2013.11.29. 15:19 keltezéssel, Frank Schmirler írta:
Hi István,
On Fri, 29 Nov 2013 12:17:58 +0200, Füley István wrote
The "channel not available" message is the expected behaviour when a negative priority is configured on the client. With a priority of 0 or higher on the client, the client should get CH4. The server would then switch to CH1 on adapter0 if adapter0 isn't in use with priority >= 0, otherwise switch to CH4 with a "streaming active" message.
Can you confirm with the current 0.6.1 releases on client and server that the problem still exists if you configure a negative priority on the clients? If yes, I'll try to reproduce your setup at home.
Regards, Frank
I made further tests in the weekend, and configuring negative priorities on clients works now: the server's output stays untouched, and the "Channel not available" appears on client side.
Thanks, and keep up the good work,
István
On Thu, Nov 28, 2013 at 8:48 PM, Frank Schmirler vdr@schmirler.de wrote:
Hi,
it was about time to publish a streamdev release for VDR 2.0. Streamdev-0.6.1 is now available from http://projects.vdr-developer.org/projects/plg-streamdev/files. The server plugin requires at least VDR 1.7.25. The client plugin should even work with VDR 1.6. On VDR version up to 1.7.33 the Makefiles have to be replaced by the old versions which are shipped along with the source.
Hi Frank,
Thanks for all your hard work with streamdev.
I have been using the VDR Samsung SmartTV VDR plugin which relies on streamdev for transfer of live channels over the network and it uses its own proprietary implementation for the transfer of recordings. I have tried using it over wifi as well as powerline. The recordings (SD and HD) play flawlessly over the network, however the streaming of live channels using streamdev results in regular buffering (SD and HD) and eventually the TV just gives up playing them. Is there any buffer options or other configurable settings within streamdev that might alleviate this problem? I can't seem to find much that would help.
Look forward to hearing from you and TIA.
Hi Morfsta,
On Fri, 29 Nov 2013 14:35:03 +0000, Morfsta wrote
I have been using the VDR Samsung SmartTV VDR plugin which relies on streamdev for transfer of live channels over the network and it uses its own proprietary implementation for the transfer of recordings. I have tried using it over wifi as well as powerline. The recordings (SD and HD) play flawlessly over the network, however the streaming of live channels using streamdev results in regular buffering (SD and HD) and eventually the TV just gives up playing them. Is there any buffer options or other configurable settings within streamdev that might alleviate this problem? I can't seem to find much that would help.
Maybe you suffer from some sort of network congestion. Currently there's no buffering option. Streamdev starts streaming as soon as possible. Try adding a short delay at the beginning of void cStreamdevWriter::Action(void) in file server/streamer.c, e.g. cCondWait::SleepMs(500);
Regards, Frank
On Sat, Nov 30, 2013 at 3:30 PM, Frank Schmirler vdr@schmirler.de wrote:
I have been using the VDR Samsung SmartTV VDR plugin which relies on streamdev for transfer of live channels over the network and it uses its own proprietary implementation for the transfer of recordings. I have tried using it over wifi as well as powerline. The recordings (SD and HD) play flawlessly over the network, however the streaming of live channels using streamdev results in regular buffering (SD and HD) and eventually the TV just gives up playing them. Is there any buffer options or other configurable settings within streamdev that might alleviate this problem? I can't seem to find much that would help.
Maybe you suffer from some sort of network congestion. Currently there's no buffering option. Streamdev starts streaming as soon as possible. Try adding a short delay at the beginning of void cStreamdevWriter::Action(void) in file server/streamer.c, e.g. cCondWait::SleepMs(500);
If his recordings stream fine and the problem is only with live tv, how could that possibly be network congestion?
Hi,
On Sat, 30 Nov 2013 16:36:14 -0800, VDR User wrote
If his recordings stream fine and the problem is only with live tv, how could that possibly be network congestion?
I should have written "temporary network congestion".
When streaming a recording, the client can pre-buffer data to prevent buffer underruns. With live TV this is not possible as data becomes available just in time. So fluctuations in the available network bandwidth could have an impact. The fact that streamdev uses TCP to transmit the stream might be an additional problem here as packet loss leads to retransmission.
As Morfsta is able to view HD recordings while he seems to get problems even with SD live TV, bandwith alone surely isn't the problem. But temporary congestion or high packet loss due to e.g. interference sound reasonable to me.
Regards, Frank
On Mon, Dec 2, 2013 at 11:39 AM, Frank Schmirler vdr@schmirler.de wrote:
Hi,
On Sat, 30 Nov 2013 16:36:14 -0800, VDR User wrote
If his recordings stream fine and the problem is only with live tv, how could that possibly be network congestion?
I should have written "temporary network congestion".
When streaming a recording, the client can pre-buffer data to prevent buffer underruns. With live TV this is not possible as data becomes available just in time. So fluctuations in the available network bandwidth could have an impact. The fact that streamdev uses TCP to transmit the stream might be an additional problem here as packet loss leads to retransmission.
As Morfsta is able to view HD recordings while he seems to get problems even with SD live TV, bandwith alone surely isn't the problem. But temporary congestion or high packet loss due to e.g. interference sound reasonable to me.
Regards, Frank
Difficult to trace these problems isn't it? I get a sustained transfer rate when copying files over of around 15MB/sec - so I would have thought this would be ample for SD and HD streaming?
I was just surprised to find very few options to play with in streamdev with regard to buffer sizes etc. I presume this is by design and the way in which it works?
Hi,
On Wed, 4 Dec 2013 19:10:04 +0000, Morfsta wrote
Difficult to trace these problems isn't it? I get a sustained transfer rate when copying files over of around 15MB/sec - so I would have thought this would be ample for SD and HD streaming?
As long as there's no concurrent bandwidth consuming activity that should be enough.
I was just surprised to find very few options to play with in streamdev with regard to buffer sizes etc. I presume this is by design and the way in which it works?
Well, there was no demand yet ;)
Can you try adding the sleep command as suggested in my first answer? Maybe try a short delay (e.g. 500 ms) and a long delay (e.g. 3000 ms). If it helps, I'll add a setup option.
Regards, Frank
On Fri, Dec 6, 2013 at 8:55 AM, Frank Schmirler vdr@schmirler.de wrote:
Can you try adding the sleep command as suggested in my first answer? Maybe try a short delay (e.g. 500 ms) and a long delay (e.g. 3000 ms). If it helps, I'll add a setup option.
Hi Frank,
Putting in a delay of 500ms definitely improves things - its been streaming awhile without any buffering / drop outs.
Thanks
-
Frank Schmirler -
Füley István -
Morfsta -
VDR User