[vdr] [Announce] remotetimers-1.0.2
Hi, remotetimers-1.0.2 is now available from http://vdr.schmirler.de. No major changes, mostly making sure it compiles with VDR 2.2.0. Changelog: - Added compatibility for VDR 2.1.2 (thanks to Christopher Reimer and Lars Hanisch) - Added support for graphtft. Use -DUSE_GRAPHTFT when compiling to enable. (thanks to Jörg Wendel) - Updated MainMenuHooks patch for VDR 2.0.4 Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] epgsync-1.0.1
Hi, I just released epgsync-1.0.1 on http://vdr.schmirler.de. I've added a new option to schedule a resync every X hours and you may now use the SVDRP command PLUG epgsync SYNC to trigger a resync (this has always been possible by sending the SVDRP command to open the mainmenu, however that was undocumented and probably not obvious). Have fun, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Announce] streamdev-0.6.1
Hi, On Wed, 4 Dec 2013 19:10:04 +, 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Announce] streamdev-0.6.1
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] streamdev-0.6.1
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
[vdr] [Announce] remotetimers 0.1.7
Hi, today I published remotetimers-0.1.7 on http://vdr.schmirler.de. It brings some minor bugfixes plus the following new features: With (at least) VDR 1.7.28: - Patch for new LCARS skin: Include remote timers in the main menu timers list - Calculate free disk space in minutes based on size and length of recordings as in VDR 1.7.27. Just like VDR only displays free disk space information for the video directory filesystem, VDR takes only recordings on the video directory filesystem into account when calculating the average data rate. Remotetimers' recordings menu will show the free disk space of the filesystem corresponding to the currently selected directory. Naturally the average data rate is then calculated based on this filesystem's recordings. - The whole average data rate calculation is a nice thing, but it's not very helpful if you have both, SD and HD recordings on the same filesystem. How about an estimated free disk space in minutes based on the data rate of an individual recording? Just select a recording in remotetimers' recordings menu and hit either red (Edit recording) or blue (Info). In addition to size and length of the recording you'll get the free minutes based on the data rate of this recording in the title bar. For all VDR versions: - By default remotetimers syncs timers using channel IDs. So the order of channels on client and server may be completely different. Now remotetimers could also use the channel number to sync timers. In this mode of course the channel lists on client and server must be identical or it will wreak havoc. You could of course swap e.g. the positions of HD and SD (or DVB-S and DVB-T) variants of the same channel. Imagine you have a client which cannot display HD (or receives DVB-T only) but you always want to record HD (or from DVB-S) on the server: Voilà - that's the solution. - If the server recordings are mounted on a subdirectory of the local video directory you can have remotetimers monitors the server's .update file to keep the local recordings list up to date. Now remotetimers will not only monitor the .update file, it will touch it whenever the local .update file changes. So when a client deletes a recording, the server and other clients monitoring the server's .update file will update their recordings lists. CHANGELOG - If server recordings are mounted in a subdirectory of local video dir, make server and other clients aware of changes made by this client. - Fixed occasionally missed video directory mounts during startup. Now getting mtime and device id of .update file already in SetupParse(), i.e. before VDR starts to scan recordings. - Updated Slovak translations (thanks to Milan Hrala) - Added vdr-1.7.28-remote_instant_recordings.patch to display remote timers in skin LCARS' main menu view - Fixed RemoteTimers::ForEach service call - With 1.7.28 or newer, show remaining disk space in minutes based on size and length of currently selected recording in menus Recording info and Edit recording. - With 1.7.28 or newer, calculate remaining disk space in minutes based on size and length of all recordings on current filesystem. - Updated Italian translations (thanks to Diego Pierotto) - Updated the menu parts copied from VDR to 1.7.28 - New option to map channels by number instead of channel id when syncing between client and server. Useful if you want to view and record different variants of a simulcast channel on client and server (e.g. HD/SD or DVB-T/ DVB-S). Requires channels to be in same order (suggested by woz@vdrportal) - API changes of VDR 1.7.28 - Updated MainMenuHooks patch (thanks to Manuel Reimer) - Fixed compile error due to unknown type 'tI18nPhrase' - Released recordings must be re-read or they reappear in recordings menu Have fun, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] streamdev-0.6.0
Hi, the new streamdev release 0.6.0 is available from http://projects.vdr-developer.org/projects/plg-streamdev/files. The server-side setting Suspend behaviour has been dropped in 0.6.0 in favour of priority based precedence. A priority of 0 and above means that clients have precedence. A negative priority gives precedence to local live TV on the server. So if Suspend behaviour was previously set to Client may suspend or Never suspended, you will have to configure a negative priority. If the Suspend behaviour was set to Always suspended, the default values should do. *** Compatibility *** At least VDR 1.7.25 is required on the server. Negative priorities won't work as expected unless at least VDR 1.7.27 is installed. For the streamdev-client plugin at least VDR 1.5.16 is required. Due to changes in the client code, streamdev-client is not compatible with streamdev-server versions 0.5.1-priotest and 0.5.2-git. A vanilla 0.5.1, 0.5.2 or any 0.5.1-git version will do. *** Required config changes *** Configure the desired priorities for HTTP and IGMP Multicast streaming in the settings of streamdev-server. If you haven't updated all your streamdev clients to at least 0.5.2, configure Legacy Client Priority, too. In streamdev-client, you should set Minimum Priority to -99. Adjust Live TV Priority if necessary. *** Disclaimer *** Though the new version works for me, there are several things I don't use in my production environment and things I can't test at all (e.g. encrypted channels). Feedback welcome. *** Changelog *** - Reimplemented some client device methods - Proper fix for client sends ABRT after TUNE. Obsoletes many hacks in client - Added CLOCK_MONOTONIC timestamp and thread id to Dprintf - Silenced warning (thanks to Rolf Ahrenberg) - Updated Finnish translation (thanks to Rolf Ahrenberg) - Replaced server-side suspend modes with priority based precedence handling - Client-side priority handling for VDR = 1.7.25 and servers running VTP 1.0 - Introduced VTP protocol version numbering for easier compatibility handling between different client and server versions. The server includes the protocol version in its greeting string, the client reports its version with the new command VERS. - Dropped compatibility of streamdev-server with VDR 1.7.25 Have fun, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] streamdev 0.5.2
Hi, today I published streamdev 0.5.2 at http://projects.vdr-developer.org/projects/plg-streamdev/files which can be used with VDR 1.6 and 1.7. I also pushed some changes to git. The current git version now requires at least VDR 1.7.25 (better 1.7.27) and is completely priority driven. A negative priority gives precedence to live TV on the server, a priority of zero or more gives precedence to the client. For HTTP and IGMP multicast the priority is configured in the streamdev-server setup. The live TV priority of a streamdev-client is configured in the streamdev-client setup. For legacy clients (streamdev-client 0.5.1 or older) the priority is configured in streamdev-server as well. If you want to give the git version a try, I'd be particularly interested if the following things work like before: - clients with lower precedence like local live TV - encrypted channels - streamdev-server running streamdev-client (e.g. for mutually sharing DVB cards between two VDRs) Changelog of streamdev-0.5.2: - Use fileno() to retrieve the fd from a FILE structure (submitted by an anonymous user) - New special meaning show current channel when channel 0 is requested. Applies to HTTP streaming only (thanks to Rolf Ahrenberg) - Added streamdev-client support for upcoming streamdev-server versions with purely priority driven precedence. - API change of VDR 1.7.26: avoid device is no longer available - Fixed ProvidesChannel() on client always returning true since the new timeout option has been added. - Updated Finnish translation (thanks to Rolf Ahrenberg) - With VDR 1.7.25 priorities down to -99 will be used. Please update Minimum Priority in streamdev-client setup. - Use the new streamdev-client setup option Live TV Priority to control precedence among multiple clients. The VDR option Primary Limit which has previouly been used for this purpose has been dropped in VDR 1.7.25. - Timout for network operations now configurable in streamdev-client setup - Added timeout to Connect() - Report the server-side HTTP status 503 Service unavailable instead of the client-side error 409 Conflict when a channel is unavailable (suggested by Methodus) - Update of po headers and Finnish translation (thanks to Rolf Ahrenberg) - support for non-cycle-free setups (e.g. where two VDRs mutually share their DVB cards through streamdev-client/-server). Must be enabled in streamdev-server setup. Obsoletes recursion patches. - API change of VDR 1.7.22 - VDR 1.7.22 obsoletes cap_net_raw patch. Added cap_net_raw patch for VDR 1.7.5 - 1.7.21. - Update and UTF-8 conversion of Finnish po files (thanks to Rolf Ahrenberg) - Added Hide mainmenu entry option on server (thanks to Rolf Ahrenberg) - Added server menu with list of clients. Connections can be terminated with the red key. The former main menu action of suspending live TV moved to the blue key. - code cleanup and optimization (thanks to Ville Skyttä) - properly shutdown IGMP timeout handler thread when the plugin is stopped. Fixes occasional segfaults on VDR exit. - fixed memory leak in libdvbmpeg read_pes (thanks to Ville Skyttä) - dropped several unused functions in libdvbmpeg - restricted VTP command RENR to liemikuutio patch 1.32. Build fails with newer versions of this patch (thanks to Ville Skyttä) - updated outdated COPYING file and FSF address (thanks to Ville Skyttä) - include SDT and TDT in TS streams - the icy-name HTTP header sent with radio streams makes VLC pick the wrong demuxer. Send icy-name only for ES audio streams. - fixed regression of live TV must be switched in VDR main thread change: deadlock in IGMP streaming server when switching live TV. - streamdev-client returns true in its AvoidRecording() method introduced with VDR 1.7.19. Note however that the impact of NumProvidedSystems is higher. - updated device selection to code of VDR 1.7.19 - adaption to VDR 1.7.12 cReceiver API change - increased WRITERBUFSIZE. Has been reported to fix some ringbuffer overflows (thanks to Lubo Doleel) - check availability of channel if VTP command TUNE is called without prior PROV call (e.g. client side EPG scan) - added support for VDR 1.7.19 SignalStrength/SignalQuality - analog video channels use the same transponder and pid for different channels, so streamdev-client must always issue TUNE command - server must close the VTP connection also if filter stream is broken - fixed missing #ifdefs for new NumProvidedSystems setup option - new externremux.sh mencoder config options: audio pid by language code (-alang) and verbosity (-msglevel) (thanks to Pekko Tiitto) - writer must not spend too much time waiting in select() without checking if the thread has been cancelled - added Spanish translation (thanks to Javier Bradineras) - live TV must be switched in VDR main thread - dropped compatibility with VDR 1.5.16 - return value of streamdev-clients cDevice::NumProvidedSystems() now configurable in plugin setup Have fun, Frank
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Fri, 02 Mar 2012 11:06:03 +0100, Klaus Schmidinger wrote I'm currently considering giving GetDevice() another parameter: static cDevice *GetDevice(const cChannel *Channel, int Priority, bool LiveView, bool Query = false); and make it not do any CAM assignments or receiver detachments if Query is true, but only check whether there is any device available. Yes, please. This is on top of my additional wishes list and would finally save me the copy of cDevice::GetDevice() I have in streamdev which became necessary since GetDevice() got these side effects in VDR 1.5.0. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Fri, 02 Mar 2012 11:08:42 +0100, Klaus Schmidinger wrote On 01.03.2012 09:38, Frank Schmirler wrote: On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote Am 29.02.2012 16:17, schrieb Klaus Schmidinger: + The function cDevice::Receiving() now returns true if there is any receiver attached to the device. Its boolean parameter has no meaning any more. Please remember to drop the following line from PLUGINS.html, as it is now finally completely void: (any negative value will allow a cReceiver to be detached from its cDevice at any time.) This was handled via Receiving(true). This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug. Wouldn't it help to run those live related receivers with priority IDLEPRIORITY and having cDevice::Receiving() ignore receivers with priority IDLEPRIORITY? Wouldn't that get us back to square one? ;-) Well, no. Previously live TV and related receivers were treated the same way (same priority, both handled as if they were not present). Currently we have different priorities (-1 and -99) and both are not ignored. So the -99 receiver is not in the way when switching live TV, but it will have an impact on device selection. Ignoring receivers with IDLEPRIORITY (or likewise MINPRIORITY) would solve this. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Fri, 02 Mar 2012 13:01:23 +0100, Klaus Schmidinger wrote On 02.03.2012 12:54, Frank Schmirler wrote: On Fri, 02 Mar 2012 11:08:42 +0100, Klaus Schmidinger wrote On 01.03.2012 09:38, Frank Schmirler wrote: On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote Am 29.02.2012 16:17, schrieb Klaus Schmidinger: + The function cDevice::Receiving() now returns true if there is any receiver attached to the device. Its boolean parameter has no meaning any more. Please remember to drop the following line from PLUGINS.html, as it is now finally completely void: (any negative value will allow a cReceiver to be detached from its cDevice at any time.) This was handled via Receiving(true). This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug. Wouldn't it help to run those live related receivers with priority IDLEPRIORITY and having cDevice::Receiving() ignore receivers with priority IDLEPRIORITY? Wouldn't that get us back to square one? ;-) Well, no. Previously live TV and related receivers were treated the same way (same priority, both handled as if they were not present). Currently we have different priorities (-1 and -99) and both are not ignored. So the -99 receiver is not in the way when switching live TV, but it will have an impact on device selection. Ignoring receivers with IDLEPRIORITY (or likewise MINPRIORITY) would solve this. But where would that be different from the previous version, where all receivers with negative priorities have been ignored? Now I'm confused... Currently there's no such thing like a live TV related receiver (like for the osdteletext-plugin). A live related receiver will always follow the current live channel. So it shouldn't be in the way when switching channels and will probably never show up alone but always in company with the live TV transfer mode receiver. VDR up to 1.7.24 had transfer mode receiver at priority -1, live related receivers at -1. All negative priorities treated the same way, i.e. either totally ignored or not ignored at all. No black screen in transfer mode when a recording starts as the transfer mode receiver at -1 is not ignored (Receiving(true) in ProvidesChannel()). But for the same reason a live related receiver at -1 (or any other negative priority) isn't detached when the live channel is being switched. The same problem would also apply to low priority remote transfer mode receivers. The current state of the patch has transfer mode receiver at priority -1, live related receivers by default at -99. No receivers are ignored. Black screen in transfer mode when a recordings starts? Don't know if it's back but I assume the impact in GetDevice takes care of it. The live related receiver is still attached when switching live TV, but it no longer blocks the channel switch due to its lower priority. So low priority remote transfer mode should be fine, too. However the live related receiver isn't totally ignored. Receiving() will detect it an so it e.g. has an impact on device selection which is even higher than NumProvidedSystems(). Now lets assume, Receiving() would ignore a receiver at either IDLEPRIORITY or MINPRIORITY. Black screen? Still don't know ;). Live related receiver? Still attached when switching live TV and still not in the way due to low priority. Same for remote transfer mode. But now Receiving() no longer reports it, so no impact on device selection. The boolean parameter of Receiving() must still be ignored of course. Moving cStatus::MsgChannelSwitch(this, 0) and plugins with live related receivers reacting to it by detaching the receiver should achive the same. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote Am 29.02.2012 16:17, schrieb Klaus Schmidinger: + The function cDevice::Receiving() now returns true if there is any receiver attached to the device. Its boolean parameter has no meaning any more. Please remember to drop the following line from PLUGINS.html, as it is now finally completely void: (any negative value will allow a cReceiver to be detached from its cDevice at any time.) This was handled via Receiving(true). This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug. Wouldn't it help to run those live related receivers with priority IDLEPRIORITY and having cDevice::Receiving() ignore receivers with priority IDLEPRIORITY? The default priority of cReceiver should become IDLEPRIORITY instead of MINPRIORITY then. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wed, 29 Feb 2012 16:17:07 +0100, Klaus Schmidinger wrote Even though VDR itself doesn't have the necessity for remote receivers (yet), I see the problem for streamdev. I have therefore reconsidered this matter and will make the following changes for the next developer version: - Revised priority handling to allow receivers with a priority that is lower than that of live viewing (with suggestions from Frank Schmirler): + An idle device (one that is not used for live viewing and has no receiver attached to it) now has priority IDLEPRIORITY (-100). + An unused CAM slot now has priority IDLEPRIORITY. + The default priority of a cReceiver is now MINPRIORITY (-99). + A device that is used only for live viewing (no matter whether it's in Transfer Mode or real live mode) now has priority TRANSFERPRIORITY (-1). + The function cDevice::Receiving() now returns true if there is any receiver attached to the device. Its boolean parameter has no meaning any more. + The default value for the Priority parameter of the function cDevice::ProvidesChannel() has been changed to IDLEPRIORITY. When searching for a device for live viewing, VDR uses priority 0 for the search (thus avoiding any devices that are serving actual timer recordings), and - if going into Transfer Mode - gives the cReceiver a priority of -1. That way the next search for a live device will be able to use the one that is currently serving the Transfer Mode, because the search has a higher priority (this is pretty much the same as it was before). Now a remote transfer mode (which I assume is what streamdev and the like implement) can use a search priority of, say, -10, and a transfer priority of -11. That way the remote mechanism will also be able to reuse devices, just like local Transfer Mode. And local live mode can override remotely used devices due to its higher priority. I'm currently testing these changes in my own production VDR (local live and transfer mode only) and will release them in version 1.7.25 shortly. Let me know then if this works for you. Wow - this is good news. Thanks for reconsidering! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote On 27.02.2012 14:33, Frank Schmirler wrote: I suggest the following additional changes: - instead of any negative priority, only priority -MAXPRIORITY gets the special meaning of may be detached anytime - the constructor of cReceiver should use default priority -MAXPRIORITY, so not all plugins have to be updated to keep their previous behaviour - use LIVEPRIORITY-1 as priority for cTransfer I can't however overlook the impact these modifications have. Me neither - and that's why I strongly oppose them ;-) Then maybe it's time to return to KISS - perhaps in VDR 2.1.x? Maybe there's more obsolete stuff which can be thrown overboard. I feel it's time to start from scratch with the device selection code, keeping also the new challenges in mind (like e.g. the HD/SD or DVB-S/-T simulcast thingy). What exactly is the use case for this, anyway? VDR has two purposes: live view and recording. And the current priority scheme handles this pretty well IMO. I guess in the meantime you could add network streaming to the list of purposes, too. There are a lots of people using streamdev out there for VDR-to-VDR-, HTTP- or Multicast-Streaming of live TV. Especially the VDR-to-VDR-Streaming part is challenging. The easy case is a headless server somewhere in the attic. No need to care about live TV. But some people's server is their main VDR in the living room and they usually want clients with a priority which is lower than local live TV. That's the use case. At the moment it all works pretty well in streamdev, but the whole thing is quite fragile with respect to API changes, time-consuming to maintain (e.g. an almost 1:1 copy of cDevice::GetDevice) or laborious (e.g. synchronisation with VDR main thread for switching LiveTV). So it's not that streamdev depends on Udo Richter's patch or PrimaryLimit. But I was hoping for some perspective to get rid of some of the most ugly workarounds in the long run. The patch would have been a big step into that direction. Still, for a nice solution some more (but probably much less dramatic) modifications in the VDR core would be necessary. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Mon, 27 Feb 2012 21:29:44 +0100, Udo Richter wrote Am 27.02.2012 14:33, schrieb Frank Schmirler: Instead of a configurable LiveTV priority, your approach uses the fixed priority value 0 for LiveTV. The new idle priority of -100 opens the range for cReceivers with negative priority. The problem is, that *any* negative priority is still considered as may be detached anytime, so there's still no real cReceiver with less priority than live TV. Unfortunately not, because may be detached anytime is intentionally broken since VDR 1.3.7 (2004). Fixing it would reintroduce the Live TV freeze on recording start bug. Ah, I see. The Receiving(true) in cDvbDevice::ProvidesChannel which came in with 1.3.8. That was the missing piece. Thanks for pointing me there. - the constructor of cReceiver should use default priority -MAXPRIORITY, so not all plugins have to be updated to keep their previous behaviour - use LIVEPRIORITY-1 as priority for cTransfer Such -1 offset workarounds usually don't work, I would prefer not to have them. For example, one transfer device can still block another before detaching or via Streamdev. The only consistent solution is to give transfer mode the same priority as primary device live priority, either PrimaryLimit or 0. That was an attempt to get a solution without volatile. A don't ever use priority PrimaryLimit (or 0) elsewhere would have been better than nothing. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Hi,
On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
- Fixed handling the PrimaryLimit when requesting a device for live viewing
(reported by Uwe Scheffler).
Refers to the following change in device.c:
- if (device[i]-ProvidesChannel(Channel, Priority, ndr)) { // this
device is basicly able to do the job
+ if (device[i]-ProvidesChannel(Channel, (LiveView
device[i]-IsPrimaryDevice()) ? Setup.PrimaryLimit : Priority, ndr)) { //
this device is basicly able to do the job
With this modification the GetDevice parameter Priority becomes meaningless in
case LiveView is true. This should at least be mentioned in the function's
documentation in device.h.
Anyway, I think a better way to fix the problem would be to change the
priority parameter of the GetDevice calls involved from GetDevice(channel, 0,
true) to GetDevice(channel, Setup.PrimaryLimit, true). There are two calls
in device.c and one call in menu.c.
Imagine a two card system with PrimaryLimit 20, a high priority recording
(e.g. 50) running on the PrimaryDevice and a low priority recording (e.g. 10)
on the second card. With 1.7.24 live TV would not interrupt the low priority
recording, as PrimaryLimit priority is only used when checking the
PrimaryDevice, but priority 0 is used when checking the second card.
The way 1.7.24 resolves the problem is not wrong as according to MANUAL
PrimaryLimit is not meant to affect transfer mode. IMHO it should, as the
intention of this parameter is prefering LiveTV to low priority recordings.
I'm still hoping to get a more priority driven device selection. BTW: Any
update on this related issue:
http://www.mail-archive.com/vdr@linuxtv.org/msg14166.html?
Regards,
Frank
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Fri, 24 Feb 2012 19:33:06 +0100, Udo Richter wrote Am 24.02.2012 17:23, schrieb Klaus Schmidinger: IIRC that whole Primary Limit thing was introduced because in the beginning the full featured DVB cards were unable to record and play at the same time. So it could happen that a timer occupied the primary device and left the user with a black screen. Since the old FF cards have been given the ability to do simultaneous recording and replay a long time ago, and the new TT S2-6400 has been able to do this from the very start, I'd rather prefer to do away with the Primary Limit altogether - to make things simpler instead of more complex ;-) I was not aware of this as I have no FF card. For me, Primary Limit always was the Priority of Live TV. Ok, MANUAL talks about being allowed to use the primary DVB interface and not denial to affect live TV, but the use case recordings that should take place only when there is nothing else to do, but should never keep the user from viewing stuff on the primary interface clearly pointed into that direction. Always using priority 0 instead of a configurable Primary Limit means there's no way to get anything with less priority than live TV but without the may always be detached meaning of negative priorities. Streamdev is using the Primary Limit to control priorities between multiple clients and partially also between clients and server. Only partially due to transfer mode receiver device running with priority -1. Currently a plugin can't simply call GetDevice with a non-negative priority without disturbing Live TV in transfer mode. Some ugly workarounds were necessary in streamdev to handle this. Well, I don't like the idea of introducing yet another parameter (volatile) here. The priority should be sufficient to solve this. So if you can suggest a solution that works solely with priorities, I might take a look ;-) Well, the -1 priority on the transfer mode receiver device solves the receivers still attached when switching channels problem. But it introduces an exceptional case which causes problems (osdteletext) or makes apparently simple things hard to handle (streamdev GetDevice). Trading this for an explicit parameter sounds like a very good deal to me. Letting VDR know that a device will probably soon be detached was one of the smarter solutions to this. Another alternative I was thinking of was to let the device know that a receiver is 'live- related', and thus can be canceled for another live view, but the 'volatile' solution was more general. Maybe it would be possible to manually lower the transfer mode receivers to -1 when calling GetDevice with live view, and raise them back to PrimaryLimit (or 0) at the end. Not sure if that's more elegant... +1 for the volatile solution. Streamdev-server has to handle channel switches, too. On the server side they are not live-related, but the problem is the same: The receivers for the previous channel are still attached. Volatile would obsolete an other workaround in streamdev. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Abandoned project: Streamdev widget for Samsung TV
Hi, a while ago some guy started to implement a widget for Samsung TVs to access streamdev via HTTP (http://projects.vdr-developer.org/issues/545). Unfortunately there hasn't been any progress recently and he doesn't reply to mails either. Maybe someone with a Samsung TV is willing to take over? I take the streamdev part, so all it takes is some basic JavaScript knowledge, the SDK from http://www.samsungdforum.com/ and of course a capable Samsung TV ;) Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] remotetimers-0.1.6
Hi guys, I just published remotetimers-0.1.6 at http://vdr.schmirler.de/. The new release fixes a crash when moving a local timer to the server and a bug in the menu after modifying priority, lifetime or user IDs of a TS recording. The plugin has also been adapted to VDR 1.7.21 (not heavily tested yet). Changelog - Adapted handler of SVDRP command LSTR to VDR 1.7.21+ format, including the recording's length. - Updated the menu parts copied from VDR to 1.7.21 - README now mentions the new VDR default port. - Fixed RecordingInfo update for TS recordings. The altered lines were appended but re-writing a clean version of the info file failed. So the recording in the menu was not updated, instead an error message appeared. - Adapted to API change of VDR 1.7.21 (access recording priority/lifetime) - Fixed crash when moving a local timer to the server Have fun! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] remoteosd-0.1.1
Hi, I just published remoteosd-0.1.1 on http://vdr.schmirler.de. It fixes a crash when accessing menus without title (reported by Manfred Heindl) and updates the MainMenuHooks patch. With the remoteosd plugin you can access the menu of a remote VDR. You will need to install the following plugins: on local VDR: remoteosd and svdrpservice on remote VDR: svdrposd Have fun! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDHomerun and streamdev
On Tue, 02 Aug 2011 21:38:11 -0500, Rob Davis wrote On 27/07/11 20:37, Kirk Bromfield wrote: I had the same problem until I downgraded to streamdev 0.5.0 and hdhomerun_atsc_firmware_20100828.bin. I am not sure both of these changes are necessary as I changed both at the same time. :( Emerged vdr-streamdev instead of git and it's working now, thanks.. Could you provide a diff between these two versions? I'd like to find out why (current?) git isn't working for hdhomerun. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDHomerun and streamdev
On Wed, 3 Aug 2011 10:09:12 -0500, Rob Davis wrote Spoke too soon, It works as long as the channel is streaming/being viewed somewhere else. If, however, the channel is not showing, then streamdev sends the channel before it's tuned, which causes ffmpeg to throw an error as it thinks it's supposed to send an ac-3 track with 0 channels instead of 5.1 or 2.0. Is there a way to set a delay between tuning and sending the ts stream? What do you mean with streamdev sends the channel before it is tuned? As you mentioned ffmpeg, I assume you are refering to HTTP streaming here. For HTTP, streamdev first tunes the device, then it adds receivers for the channel's PIDs, sends the HTTP headers and finally starts to forward the data it receives from the device. So unless hdhomerun tunes the channel in the background, it should be tuned when streamdev starts to reply. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] svdrposd-0.1.1
Hi there, I just published a new release of svdrposd at http://vdr.schmirler.de. The plugin publishes the contents of the OSD menu on SVDRP. It's primarily used by the remoteosd plugin. The new release fixes a minor bug which caused problems when using the svdrp4j Java client. Have fun! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] perfect vdr remote?
On Wed, 27 Jul 2011 09:16:17 +1000, Torgeir Veimo wrote On 27 July 2011 01:49, VDR User user@gmail.com wrote: On Tue, Jul 26, 2011 at 7:39 AM, Torgeir Veimo torg...@netenviron.com wrote: The Philips Prestigo SRT9320 seem to have a perfect key layout for VDR. Does anyone have any experience with this remote with VDR? Yes, that's the one I use on my primary VDR at the moment. I'm very happy with it and my wife is also glad that she doesn't have to deal with a remote with tons of buttons she'd actually never use. I do agree that direct buttons are better for the most commonly used buttons, but I mostly use the menu/back, arrow keys/ok and the coloured buttons, almot none others. One the remote you liked to, the coloured buttons are far away from the arrow buttons, so it can't really be nice to handle? That's the point. You really don't need too many buttons for your daily work with VDR and on the SRT9320 all these buttons are close together. Maybe even more important: You can easily distinguish these buttons due to their different shape and position. No need to switch on the backlight in the dark, no need to look at the remote at all. That's also why I'd never go for a touchscreen-only remote. What else can I say? The remote is not too large and not too heavy as it includes a cell phone battery. Only need to recharge it every 3 months or so. Still the SRT9320 is not perfect. Decide yourself if one of these things matter to you: * not programmable via PC, only via touchscreen. But usability is ok. Just rearranging the buttons is a bit of a hassle. * no way to enter custom remote codes. Codes which are not in the builtin database can only be learned from an other remote. I had to ask someone with a Logitech Harmony to get the discrete codes for the HDMI inputs of my Samsung TV (even the original remote of the TV doesn't have these codes. The AV button there opens a menu where you can select the input with up/down). * devices with just a toggle power remote command are difficult to handle. Note that some devices (like my Samsung TV) do have discrete codes for power on and power off, but the original remote doesn't feature them. The SRT9320 internal database did already know about the discrete on/off codes for my TV. * don't expect software updates from Philips. They once published an updated firmware, but when I tried to update my remote the server was unreachable. Philips support told me, the update server will be made available again when a new update becomes available... * activity concept instead of plain makro support. It's not possible to assign makros to keys. All you get is switch on and switch off makros. The concept is unusual, but in the meantime I'd even say its superior when compared to simple makros. Let me explain: The main touchscreen menu gives you two modes: Either select an individual device (something I almost never use) or an activity. When you select an activity, its switch on makro is executed. Power on the required devices, switch AV inputs, do whatever you like in this makro. You can even enter delays or configure how long an individual code has to be sent (some devices need a long key press to power it on). Each activity is associated with its own key and touchscreen layout. This is nice for multi-purpose devices as you could even define different activities for the same device, but with different sets of keys depending on what you are about to do. Just select all the keys you need from the set of devices involved in this activity. Hit the power key twice to execute the switch off makro (poweroff devices, do whatever else needs to be done). Hit the power key once and the touchscreen will give you a list of all your devices with the possiblity to switch on the devices which are involved in this activity and switch off the devices which are not involved (in case some device didn't catch the power on/off command). Changing from one activity to an other will send the switch off makro of the current and the switch on makro of the next activity. This is where you'll run into trouble with devices which support only toggle power as they will be switched off and on again. Fortunately I don't have such a device any more, but I guess you could work around it by either using different activities or by not sending the power command in the switch on/off makros. Instead power on/off manually (hit power key once and select device from list). Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Ring buffer overflows with streamdev and remux script
Hi Lubo, On Wed, 13 Jul 2011 21:05:52 +0200, Lubo Doleel wrote solution: I've tripled the size of the ring buffer in vdr-streamdev-server and the problem is gone. No problems after hours of playback... which of the buffers did you change to which value? Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Streamdev to Streamdev with PVRInput card
On Wed, 8 Jun 2011 20:43:38 +0200, Martin Dauskardt wrote
When leaving OpenDvr, the bool is set to true.
It will only become false again during runtime, if vdr calls the
pvrinput- function SetChannelDevice() and determines the needed settings.
And this is your problem. There are no debug messages from
pvrinput's SetChannelDevice() or ProvidesChannel(), so vdr never
calls these pvrinput functions - although a channel switch for a
pvrinput device is requested.
But why? I have no idea. It works for you with vomp. It worked for
me with streamdev when I tested this last year. But I had only
streamdev-server running and used vlc to switch channels.
Streamdev-client won't forward calls to SetChannelDevice and ProvidesChannel
to the server, if the current channel and the requested new channel are on the
same transponder. Instead it will just go ahead and later add the PIDs of the
new channel to the current connection.
Pvrinput obviously uses the same frequencies (i.e. transponder) and even the
same PIDs for different channels, so streamdev-clients current behaviour is
bound to fail. According to an other posting in this thread, it is not
possible to use different frequencies, so it seems the problem needs to be
fixed in streamdev-client. Please try the following patch:
--- a/common.h
+++ b/common.h
@@ -23,7 +23,7 @@
# define Dprintf(x...)
#endif
-#define TRANSPONDER(c1, c2) (c1-Transponder() == c2-Transponder())
+#define TRANSPONDER(c1, c2) (c1-Transponder() == c2-Transponder()
!c1-IsSourceType('V'))
#define MAXPARSEBUFFER KILOBYTE(16)
AFAIKT the problem is streamdev-client only. So HTTP streaming with e.g. VLC
is not affected.
Regards,
Frank
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] remotetimers-0.1.5
Hi there, remotetimers-0.1.5 is available from http://vdr.schmirler.de. Older versions no longer compile with VDR 1.7.18. Changelog: - Always update help keys when changing user filter in recordings menu - Fixed wrong help keys in recordings menu when user filter is active - The red key to open a recordings directory didn't work - No longer using cRecordingInfo::Read(FILE) in VDR 1.7.3+. It's going to be a private member in VDR 1.7.18 - Added Slovak translation (thanks to Milan Hrala) Have fun, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Bug] VPS Recording not starting as long as another recording (with lower priority) is running
Hi, On Sun, 06 Mar 2011 17:15:44 +0100, Klaus Schmidinger wrote The problem is that the VPS code in vdr.c avoids devices that are currently recording. And since this is a rather complex area, I'm not sure if it's too good an idea to change this ;-) If you feel like it, you may want to take a look at the code under // Find a device that provides the required transponder: in vdr.c. Maybe you can come up with a better solution... Unless I've missed something, that code does not only ignore priorities but also the availability of CAMs. How about using cDevice::GetDevice(const cChannel*, int, bool) to find out which device will do the job? After all that's what cRecordControls::Start(...) uses later when looking for the device to actually start recording from. Streamdev-server already uses this method for quite a while to find out if a device is available. The only change required in cDevice::GetDevice would be that it needs to become a query only method again like it was before VDR 1.5.0. Currently it may detach receivers of the device it returns. Adding a query only flag to the method should do. Streamdev currently includes a copy of cDevice::GetDevice without the detach receivers part to get that query only behaviour. Would be happy if I could get rid of that. OT but related: Any chance to see Udo Richter's patch related to proper priorities on the transfer mode receiver device in VDR? This patch eliminates some more inconsistencies related to priorities. References: http://linuxtv.org/pipermail/vdr/2010-July/023240.html http://projects.vdr-developer.org/issues/10#note-10 Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Bug] VPS Recording not starting as long as another recording (with lower priority) is running
On Mon, 07 Mar 2011 13:33:47 +0100, Klaus Schmidinger wrote On 03/07/11 13:23, Frank Schmirler wrote: Hi, On Sun, 06 Mar 2011 17:15:44 +0100, Klaus Schmidinger wrote The problem is that the VPS code in vdr.c avoids devices that are currently recording. And since this is a rather complex area, I'm not sure if it's too good an idea to change this ;-) If you feel like it, you may want to take a look at the code under // Find a device that provides the required transponder: in vdr.c. Maybe you can come up with a better solution... Unless I've missed something, that code does not only ignore priorities but also the availability of CAMs. We only need the EIT data here, which is not encrypted. So it's sufficient to find a device that provides the raw transponder. Ah, I see. I ignored the fact, that at the moment this piece of code is only looking for a way to see the VPS start flag for the timer. Still the GetDevice call (or something alike) would become necessary when considering to interrupt a recording with lower priority. The low priority recording shouldn't be interrupted if the VPS recording cannot start later as e.g. the CAM is in use by a higher priority recording. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] remotetimers-0.1.4
Hi, I just released a new version of the remotetimers plugin on http://vdr.schmirler.de The new version includes some minor bugfixes plus the following new features: * By renaming a recording, it may now also be moved to a different filesystem by a background task. You can limit the bandwidth used for copying in the plugin setup. * The plugin offers several service calls to other plugins which are already used by yaepghd-0.0.3-ce (http://vdrportal.de/board/thread.php?postid=949924#post949924) Changelog: - Improved German translations - Updated Italian translations (thanks to Diego Pierotto) - Default server port is now 0, i.e. taken from svdrpservice - Fixed missing timer markers when opening the Schedule for the first time - Implemented moving recording to a different filesystem with optional bandwidth throttle - Cutting from menu failed for PES recordings since VDR 1.7.3 due to missing parameters to cMarks::Load - Moving recordings into folders named ' ' failed or caused unexpected results as VDR's text input control strips trailing whitespace. Now folder ' ' is assumed when renaming a recording and the name ends with the folder delimiter character - Don't rename a recording if the user completely wiped out the name - Added service interface for operating on timers - Updated MainMenuHooks patch to v1.0.1 Have fun! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] streamdev 0.5.1 / moved to projects.vdr-developer.org
Hi, a few month ago streamdev's CVS got lost when www.vdr-developer.org moved to a new server. In the meantime I moved the project to projects.vdr-developer.org. Unfortunately only the latest releases plus a few snapshots could be saved from the old CVS tree and imported into git. Streamdev's old address http://streamdev.vdr-developer.org now forwards to the new home http://projects.vdr-developer.org/projects/plg-streamdev. I just released the new version 0.5.1, mostly a bugfix release. Some of the fixes have also been applied to the 0.4 branch (for VDR 1.4.x). In case there's still interest in this old releases, please contact me and I'll publish a final 0.4.1. Changelog of 0.5.1: - updated copy of GetClippedNumProvidedSystems to the version used since VDR 1.7.15 (reported by carel@vdrportal) - fixed the code deciding if a device is in use for live TV or not. It did not work as expected for FF cards (reported by wtor@vdrportal) - increased client side timeout for TUNE command - more dsyslog messages to help troubleshouting channel switch issues - improved the channel switch code trying to move live TV to different card - make sure that a client doesn't interrupt replaying on server's FF card (reported by wtor@vdrportal) - switching away live TV failed even when always suspended (reported by Michal Novotny) - fixed regression: no receiver created for ES/PS/PES (reported by Gavin Hamill) - VTP no longer uses a static priority value for its server-side receivers. The server stores channel and priority requested with the PROV command and re-uses these values in a subsequent TUNE for the same channel. The new PRIO command is used to update the receiver's priority if necessary. - added parameter HEIGHT to externremux.sh - fixed syslog messages reporting local instead of remote IP and port - fixed regression of the GetDevice(...) change. Filter streaming to clients with a recent VDR version no longer worked. - log an error if externremux.sh is missing or not executable - since VDR 1.5.0 cDevice::GetDevice(...) is no longer a query only method. It detaches all receivers of the device it returns. So it is no longer suitable for testing the availability of a device. Added a copy of VDR's cDevice::GetDevice(...) without the detach receivers part as a workaround until a better solution is available - added dsyslog messages to help troubleshouting channel switch issues - VTP command SUSP didn't attach the player to the primary device - fixed incompatibilities with older make versions - replacing a connections receiver is now an atomic operation. Solves stuttering audio/video due to lost TS packets when adding/removing PIDs - disabled attribute warn_unused_result in libdvbmpeg - slightly increased thread priorities of cStreamdevWriter/Streamer (suggested by Rolf Ahrenberg) - fixed missing support for invisible channel groups (groups without name) in HTTP menu (reported by Timothy D. Lenz) - don't quote actual program call in externremux.sh, so you can run the program through e.g. nice or taskset just by extending the variable which holds the program name - in externremux.sh each mencoder audio and video codec has a dedicated variable for a default option string now. Still you can override each default option with an URL parameter - externremux.sh mencoder now uses scale parameter with negative height instead of -xy for scaling (suggested by vel_tins@vdrportal) - added FPS (frames per second) parameter to externremux.sh (suggested by vel_tins@vdrportal) - don't use std::map.at(). It's not available in older libstdc++ version (reported by Matthias Prill) - fixed extremux x264 using value of ABR for VBR (thanks to vel_tins@vdrportal) Have fun, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On Wed, 10 Nov 2010 19:09:46 +0100, Andreas Brachold wrote Am Mittwoch, den 10.11.2010, 12:23 +0100 schrieb Frank Schmirler: Guess a touch /video/.update would result in new IDs for all recordings. So one must be aware that if an ID is no longer available, the corresponding item has not necessarily been deleted. Why ? This is not even necessary ! Missing recordings should simple remove from list (LSTR) and new recordings should added at end of list. Currently VDR simply forgets and rereads all recordings. To apply only the changes, there's quite a lot to compare to decide if two recording objects are still the same - down to the contents of the info file. As an SVDRP program has to be able to deal with VDR restarts anyway, why not treat such a complete renumbering the same way? Anything else would not work with existing svdrp programs. Well, at the moment we don't even have reliable IDs and existing SVDRP programs seem to cope with it more or less. How could that become worse? From my point of view (xxv as svdrp client), I would not block the connection permanent. And I do not would to reread every time any recordings. I don't think anyone touches the .update file every few minutes. In remotetimers, before modifying/deleting an item I retrieve this item and compare it to what I've retrieved earlier. If it differs, the action is aborted and I refresh the whole list. And I probably have to keep the implementation that way. It's the only way to detect if an item has been modified in the meantime - even with reliable IDs and even with multi connection support. However exposing e.g. the VDR start time (unix timestamp) plus cRecordings/cTimers::state to SVDRP clients would help to detect restarts and list modifications beforehand. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On Tue, 09 Nov 2010 23:33:05 +0100, Udo Richter wrote In other words, store the unique ID in the info file permanently, right? What happens if two VDR instances write to the same video directory? What if you download a recording from a friend? In that case you might have two recordings with the same ID. How should that be handled? The VDR instance ID (commandline option -i) should become part of the recordings ID. If the instance ID is not 0, we would then get large numbers (InstanceID n | recordingNumber) or we need a separator (%d-%d). The instance ID is part of the filename. So for recordings of a friend, you should use a dedicated instance ID in the filename (something users probably will forget). An other problem to solve: old recordings will need an ID, too. And VDR will not always be able to update info.vdr (e.g. recording on a DVD). Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Recordings Numbering
On Wed, 10 Nov 2010 10:44:59 +0100, Klaus Schmidinger wrote The question at hand is whether the *number* used in the LSTR and LSTT command listings to identify a particular recording or timer, respectively, shall always start at 1 and count up, and be renumbered whenever an item is newly created ot deleted. Or whether that number shall simply count up and never be renumbered (as long as this instance of VDR lives). Anything beyond this is against the KISS principle ;-) ACK. Unique IDs over the lifetime of an SVDRP connection solve the actual problem. Everything beyond get's too complicated. Guess a touch /video/.update would result in new IDs for all recordings. So one must be aware that if an ID is no longer available, the corresponding item has not necessarily been deleted. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] MainMenuHooks-v1.0.1 Patch
Hi, here's a minor update for the MainMenuHooks patch. The patch allows plugins to replace some of VDR's mainmenu items. The new version returns a cOsdObject instead of a cOsdMenu, so now the patch may also be used by plugins drawing their own menu. @plugin authors: If your plugin supports MainMenuHooks-1.0, there's nothing to change in the program code. Just update the patch itself in case it is shipped as part of the source distribution Full changelog: - return a cOsdObject instead of its subclass cOsdMenu (thanks to jo...@vdrportal) - version number defines in config.h now follow the ususal conventions: MAINMENUHOOKSVERSNUM is now a number, the newly added define MAINMENUHOOKSVERSION is a string (suggested by gnaph...@vdrportal) - patch is now based on VDR 1.6.0 - updated documentation Regards, Frank MainMenuHooks-v1_0_1.diff.gz Description: application/gzip ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] streamdev CVS - recent tarball?
On Mon, 20 Sep 2010 12:14:28 +0100, Gavin Hamill wrote
Ah, it does work, but only if I use http://hostname:port/TS/.
PES/PS/ES do not work. I'm not bothered too much about PES/PS but ES
is very useful for streaming radio. How can I help to debug this further?
Thanks for reporting this regression. Streamdev-0.5.0 is not affected - only
the CVS version. Fix is attached.
Regards,
Frank
diff -r -u streamdev-0.5.0-CVS/server/livestreamer.c streamdev-0.5.0-esps/server/livestreamer.c
--- streamdev-0.5.0-CVS/server/livestreamer.c 2010-09-24 21:57:40.0 +0200
+++ streamdev-0.5.0-esps/server/livestreamer.c 2010-09-26 11:15:54.0 +0200
@@ -436,12 +436,13 @@
void cStreamdevLiveStreamer::StartReceiver(void)
{
- if (m_Device != NULL m_NumPids 0 IsRunning()) {
+ if (m_NumPids 0) {
Dprintf(Creating Receiver to respect changed pids\n);
cReceiver *current = m_Receiver;
m_Receiver = new cStreamdevLiveReceiver(this, m_Channel-GetChannelID(), m_Priority, m_Pids);
cThreadLock ThreadLock(m_Device);
- Attach();
+ if (IsRunning())
+ Attach();
delete current;
}
else
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities 0
Hi Rainer, On Thu, 23 Sep 2010 11:11:35 +0200, Rainer Blickle wrote i have a question regarding receivers with priority 0. I have taken a look at cDvbDevice::ProvidesChannel (1.7.15). When priority is 0 hasPriority gets set to true even if there are other receivers for a different channel. In this case NeedsDetachReceivers is set to false. If cDvbDevice::ProvidesChannel is called with a priority 0, then the Channel parameter has to be the Channel currently receiving on the device. Why: If the cDvbDevice::ProvidesChannel is called with priority 0 and a channel other than the current receiving, needsDetachReceived would be kept to false, the receiver would be added the the list of receivers, but the channel doesn't get switched. Or does the Channel doesn't matter if the priority is 0 ? My question: is my assumption correct ? I stumbled across this a while ago, too. A negative priority changes the semantics of this function. From the documentation of ProvidesChannel in device.h: The special Priority value -1 will tell the caller whether this device is principally able to provide the given Channel, regardless of any attached cReceivers. The only place in VDR where ProvidesChannel is called is from GetDevice. As a consequence GetDevice should never be called with a negative priority (even though GetDevice support priorities down to -99). This is somewhat unexpected. Negative priorities are used for receivers which may be detached anytime. If I'd been looking for an idle device for tuning some channel and attaching a receiver with negative priority, I would have used a GetDevice call with negative priority... Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
Hi, On Sun, 19 Sep 2010 12:59:43 +0200, syrius.ml wrote Frank Schmirler v...@schmirler.de writes: The black screen also appears the first time you connect to the streamdev-server using HTTP. (its primary output goes black for a second then it's ok) I have not been able to reproduce this on my machine, except when the server VDR was not suspended and no idle device was available. Fixed that in getdevice-0.5.diff. I can't find getdevice-0.5.diff anymore (http://www.vdr-developer.org/mantisbt/view.php?id=582 is broken) I've just tested streamdev 0.5-CVS + suspend.diff from your website. It seems to behave like before. (as described on top of this message) would getdevice-0.5.diff still apply on top of this streamdev version ? getdevice-1.0.diff is already part of the CVS snapshot on http://vdr.schmirler.de. Changes from getdevice-0.5: - ProvidesChannel: No need to detach if actual device is already tuned to requested transponder - Added dsyslog messages to help troubleshouting channel switch issues Please run VDR with full logging (-l 3) and check the logs - maybe the new dsyslog messages shed some light on the problem. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] streamdev CVS - recent tarball?
On Thu, 16 Sep 2010 01:30:27 +0300 (EEST), Mika Laitio wrote Any changes that streamdev would move to using git repositories in http://projects.vdr-developer.org ? Personally I don't care if it's called CVS, SVN or git. However I wouldn't want to loose the history, so I'd need someone with access to the internal CVS structures. Unfortunately the vdr-developer.org admins are not very responsive ATM. And of course I'd need to be in the mood for this sort of task. My spare time is very limited - I prefer spending it with coding. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] streamdev CVS - recent tarball?
Hi, On Fri, 10 Sep 2010 09:18:51 +0100, Gavin Hamill wrote I'm trying to compile streamdev 0.5.0 on an elderly 2006 Ubuntu and am getting some compile errors. Frank Schmirler says the current CVS contains fixes for that, but the CVS server at vdr-developer.org is down. Does anyone have a recent CVS checkout they wouldn't mind sending me? streamdev is the last thing I need to finally upgrade from VDR 1.4.7 :) unfortunately the problems on www/streamdev.vdr-developer.org persist. Until the problems have been resolved current snapshots plus a patch fixing http://www.linuxtv.org/pipermail/vdr/2010-September/023520.html are available from http://vdr.schmirler.de. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] streamdev doesn't suspend live TV
Hi Michal, On Sun, 29 Aug 2010 03:59:27 +0200, Michal wrote I think there is a bug in the way streamdev switches the channel before it starts streaming. I have only 1 tuner and suspend behaviour in streamdev-server is set to always suspended. Unfortunately streaming doesn't stop live TV when the channel is on a different transponder. Streamdev switches the channel in cConnectionHTTP::ProcessRequest(), but before streaming is started the channel is switched back on a different thread in the main while loop in vdr.c (the statement with comment Make sure we have a visible programme in case device usage has changed). Thanks for tracking that down. I've been able to reproduce this bug and prepared a fix for CVS. Unfortunately CVS and bugtracker on vdr-developer.org are still down. The patch won't help much if you cannot get the CVS version... Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
On Fri, 30 Jul 2010 15:03:30 +0200, syrius.ml wrote Just an offtopic note: i'm using 2 streamdev-client instances, in the setup menu i get streamdev-client and streamdev-client2. when I change an option from one instance it gets changed in the other's instance menu as well. (it's just an ui issue, setup.conf is updated correctly) Is your libvdr-streamdev-client2.so a (symbolic or hard) link to libvdr-streamdev-client.so? Don't do that. It must be a copy. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
On Tue, 27 Jul 2010 16:47:29 +0200, syrius.ml wrote syrius...@no-log.org writes: Frank Schmirler v...@schmirler.de writes: [...] I quickly hacked together a patch at http://www.vdr-developer.org/mantisbt/view.php?id=582. It's totally untested, but maybe you want to give it a try. Might take a while until I have time to test it. Ok it works as expected for VTP. Fine. Thanks for testing. The black screen also appears the first time you connect to the streamdev-server using HTTP. (its primary output goes black for a second then it's ok) I have not been able to reproduce this on my machine, except when the server VDR was not suspended and no idle device was available. Fixed that in getdevice-0.5.diff. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
On Tue, 27 Jul 2010 13:26:39 +0200, syrius.ml wrote Frank Schmirler v...@schmirler.de writes: [...] I quickly hacked together a patch at http://www.vdr-developer.org/mantisbt/view.php?id=582. It's totally untested, but maybe you want to give it a try. Might take a while until I have time to test it. Hi, The patch applies to the source, it even compiles. but it's unusable because of one unresolved symbol. (tested with the getdevice-0.3.diff patch and a clean vdr source tree) Uploaded getdevice-0.4.diff which fixes this issue. Thanks for reporting, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Announce] vdr-streamdev-0.5.0 / 0.4.0
On Fri, 23 Jul 2010 23:45:02 +0300, Anssi Hannula wrote Frank Schmirler kirjoitti tiistai, 20. heinäkuuta 2010 12:06:44: Just updated the archive due to two minor problems with externremux.sh: - externremux.sh was not executable in the archive - typo in value for quality parameter: should be wlan54 instead of wlan45 It would be appreciated if in the future you'd mark such a release 0.5.0a or 0.5.1 instead of replacing archives. Its never a good thing that there are multiple similarly named tarballs but with different content floating around, especially for downstream distributors. Agreed. Sorry for that. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to properly attach stream to live view?
Hi Udo, On Sun, 18 Jul 2010 15:45:02 +0200, Udo Richter wrote In short, -1 receivers are supposed to be disconnectable at any time, but transfer mode runs at -1 priority too, and should not be disconnected. Transfer mode runs at -1 so that an existing transfer mode does not block channel switching. The solution is to let the channel switch code know that the transfer source device will soon be available. Good shot. Streamdev suffers from a similar problem and would benefit from this patch, too. If a streamdev-client prepars to switch channels, the current stream blocks a device which will also become available a little later. At the moment streamdev temporarily detaches the client's receiver if no other device is able to do the job anyway. With the volatile flag this should no longer be necessary. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] vdr-streamdev-0.5.0 / 0.4.0
Hi there, I finally published new streamdev releases on http://streamdev.vdr-developer.org. Streamdev-0.4.0 is the final release for VDR 1.4.x. There won't be any more updates. Use streamdev-0.5.0 for recent VDRs. IMPORTANT: Please follow the upgrade instructions from the plugin's README file. When updating to streamdev-0.5.0, the following changes are necessary (even if you have been running streamdev-0.5.0pre from CVS before): * Streamdev-server's plugin config directory is now $VDRCONFDIR/plugins/streamdev-server/. Streamdev-server expects the file streamdevhosts.conf in this directory. It is also the default location of the externremux.sh script. * The externremux script is now responsible for emitting all HTTP response headers. Make sure you send out at least the Content-type header and a blank line to terminate the header block. I encourage you to try the new externremux.sh script which ships with the streamdev sources. It fixes several problems with script termination from earlier releases and allows you to change several remux parameters on the fly by specifying URL parameters. The URL path to access externremux changed from EXTERN to EXT. Check the HISTORY for a complete changelog. Here's a brief overview of the most important new features in 0.5.0: - HTTP authentication - CGI like interface and URL parameters for externremux.sh - rewrite of externremux.sh - Multicast streaming server option Thanks to all contributors and sorry for the long time it took to publish this new release. I'll try to release more often now, but don't take my word for it. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
Hi Rainer, On Mon, 5 Jul 2010 07:28:37 +0200, Rainer Blickle wrote Later in the code of cServerConnection::GetDevice, if the Method cDevice::GetDevice doesn't return a device, the current receiver gets detached. In my infrastructure this doesnt happend because the live receiver will nearly always gets detached ( The only exception is when a timer records). To prevent this, i changed the code in that way that the streamdev-receiver gets detached before calling cDevice::GetDevice). thanks for tracking this issue down and for the detailed bugreport. The DetachAllReceivers part in cDevice::GetDevice(...) was introduced in VDR 1.5.0. This change effectively turned this method from being a query only method into something with side effects. The proper (though not nice) solution seems to be copying cDevice::GetDevice(...) into streamdev server, leaving out the problematic parts. I quickly hacked together a patch at http://www.vdr-developer.org/mantisbt/view.php?id=582. It's totally untested, but maybe you want to give it a try. Might take a while until I have time to test it. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Test] Release candidate streamdev-0.5.0-rc1
On Fri, 25 Jun 2010 11:35:18 -0700, Timothy D. Lenz wrote I missed the the post about this and got cvs on 6/20/2010 trying to get video on the watch tv page of vdradmin. I get nothing. I've also tried pointing the browser directly at http://192.168.0.20:3000/ and while I get connection, I also get no video. I did install mencoder. The changes of 0-5.0-rc are in a different branch, so this problem's not related to the release candidate. Anyway - if you point a webbrowser to http://192.168.0.20:3000/, do you get a menu? If no, please check your streamdevhosts.conf and the plugin setup. If you get the menu, maybe the default streaming format in the plugin setup is wrong. Try http://192.168.0.20:3000/TS/1.ts for a TS stream of your first channel. If you don't get any further I suggest to continue off-list. What's in the log? On 6/25/2010 11:10 AM, Jan Willies wrote: 0.5.0 works great with vdr-2-vdr streaming, no issues for me. Thanks for testing and feedback, Jan! Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] volume change with right/left (was: Feature request: program guide scroll)
On Sun, 20 Jun 2010 08:54:23 +1000, Torgeir Veimo wrote While you're at it, what about a configurable option to have the right and left keys change volume instead of scrolling up and down? A lot of remotes have the volume on those keys. It could be disable by default while the menu is displayed of course. I wrote such a patch quite a while ago for VDR 1.4. Just ported it to VDR-1.7.12. Please see README for an explanation of the options. Patch is available from http://vdr.schmirler.de/volctrl/ Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] vdr-epgsync-0.0.4
Hi there, epgsync-0.0.4 is available for download at http://vdr.schmirler.de. Epgsync lets you import the EPG from an other (server) VDR. In addition to a simple 1:1 mapping, channels may be looked up by name. So you can even copy EPG of e.g. a DVB-S channel to an analog channel, which otherwise wouldn't have any EPG information. Most important change is the support for direct IPTV and analog integration into VDR 1.7.13+. Changelog: - VDR 1.7.13 obsoletes pluginparam-patch. Analog and IPTV now have dedicated channel source values. - Mapping channels by name failed when syncing in channel-by-channel mode and the channels to be imported were not part of the local channel list. (reported by ti...@vdrportal) - Don't log LSTE errors caused by remote channels which are unknown or don't provide a schedule (reported by f...@vdrportal) - Abort faster when stopping epgsync thread - Fixed missing translations in vdr 1.4.x Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TS Play Plugin - breaks streamdev and radio plugins
On Wed, 14 Apr 2010 07:37:37 +1200, Simon Baxter wrote
Sorry Frank - definitely patched. I just tried cleaning and
recompiling everything, don't seem to be getting the IsPesRecording
function error, but am still getting the cIndexFile mismatch:
server/recplayer.c: In member function 'uint64_t
cRecPlayer::positionFromFrameNumber(uint32_t)':
server/recplayer.c:253: error: no matching function for call to
'cIndexFile::Get(int, uchar*, int*)'
../../../include/vdr/recording.h:229: note: candidates are: bool
cIndexFile::Get(int, uint16_t*, off_t*, uchar*, int*)
../../../include/vdr/recording.h:231: note: int
cIndexFile::Get(uint16_t, off_t)
make: *** [server/recplayer.o] Error 1
I don't get it - it's calling a Get(int, uchar*, int*), which are
defined Get(int, uint16_t*, off_t*, uchar*, int*) ??
Great - almost there. Before your cleanup, the compiler complained about
no matching function for call to 'cIndexFile::Get(int, uint16_t*, off_t*)'
now it's
no matching function for call to 'cIndexFile::Get(int, uchar*, int*)'
So this time the #if VDRVERSNUM = 10703 in streamdev's server/recplayer.c
wasn't changed or not changed correctly. It should read #if 1.
I attached a patch for streamdev, making it automatically detect the tsplay
patch. Can you give it a try? Apparently you are using a patched streamdev.
According to one of your previous mails there's one '#if' more. Please modify
this additional '#if' as in the patch.
Regards,
Frank
Index: server/recplayer.c
===
RCS file: /var/cvsroot/streamdev/server/recplayer.c,v
retrieving revision 1.1
diff -u -r1.1 recplayer.c
--- server/recplayer.c 1 Jul 2009 11:00:49 - 1.1
+++ server/recplayer.c 14 Apr 2010 06:31:09 -
@@ -34,7 +34,7 @@
// FIXME find out max file path / name lengths
-#if VDRVERSNUM = 10703
+#if VDRVERSNUM = 10703 || defined(MAXVIDEOFILESIZETS)
indexFile = new cIndexFile(recording-FileName(), false, rec-IsPesRecording());
#else
indexFile = new cIndexFile(recording-FileName(), false);
@@ -58,7 +58,7 @@
for(i = 1; i 1000; i++)
{
-#if APIVERSNUM 10703
+#if APIVERSNUM 10703 || !defined(MAXVIDEOFILESIZETS)
snprintf(fileName, 2047, %s/%03i.vdr, recording-FileName(), i);
//log-log(RecPlayer, Log::DEBUG, FILENAME: %s, fileName);
file = fopen(fileName, r);
@@ -99,7 +99,7 @@
char fileName[2048];
-#if APIVERSNUM = 10703
+#if APIVERSNUM = 10703 || defined(MAXVIDEOFILESIZETS)
snprintf(fileName, 2047, %s/%05i.ts, recording-FileName(), index);
isyslog(openFile called for index %i string:%s, index, fileName);
@@ -222,7 +222,7 @@
{
if (!indexFile) return 0;
-#if VDRVERSNUM = 10703
+#if VDRVERSNUM = 10703 || defined(MAXVIDEOFILESIZETS)
uint16_t retFileNumber;
off_t retFileOffset;
#else
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] remote femon (was OT: Applications for the living room)
On Mon, 1 Mar 2010 15:04:31 +0200 (EET), Rolf Ahrenberg wrote Well, vdr-femon could disable zapping while a server is replaying. Patches are always welcome. :) The problem would not only show up while replaying. If someone is watching live TV on the server's primary device and it's not the same channel the client is receiving, the client will switch channels. The current implementation assumes a headless server running the dummydevice-plugin as primary device. To get rid of the channel switch, the client could pass the requested channel's ID in its plug femon info calls. The server femon would then lookup which device receives the corresponding transponder and return this device's signal information. What do you think? Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] remote femon (was OT: Applications for the living room)
On Wed, 24 Feb 2010 10:50:06 +0200, Theunis Potgieter wrote The only annoying bug that I found was, that if I ran femon on the client, it would stop the server's current replay of a recording. I guess that is the fault of vdr-femon? Currently femon provides signal information for VDRs ActualDevice only, i.e. the device which receives the DVB stream for output on the local primary device. So if a client wants to get signal information for its current channel, it has to tune the same channel on the server. And tuning a channel via SVDRP stops replaying recordings. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-remotetimers-0.1.3
Hi there, remotetimers-0.1.3 is available from http://vdr.schmirler.de. This version is required when running VDR 1.7.12. The only real new feature is support for folders.conf, which has been introduced by VDR 1.7.12. In this new config file you can define a list of directories and subdirectories. When editing a timer or a recording you can then select one of these entries instead of having to type it in. Remotetimers contains a backport of this new VDR feature, so you will get a folders.conf even with older VDR versions, but of course only in remotetimers own menus. Changelog: - API changes for VDR 1.7.12+ - Backported VDR 1.7.12 folders.conf. Edit timer and Edit recording menus feature folder selection regardless of VDR version. - Updated Italian translations (thanks to Diego Pierotto) - Dropped the now obsolete cMenuEditPathItem - Updated the menu parts copied from VDR to 1.7.12 - Silenced warning about suggested parentheses Have fun! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH v2] Gather necessary options for build in Make.global and include it.
Hi Paul, thanks for the patch - looks good. Some suggestions from me: 1) from VDR's Makefile, remove the line DEFINES += -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE It is already included from Make.global 2) in all plugin Makefiles, remove -fPIC from the line CXXFLAGS ?= -fPIC -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses It will be added by Make.global anyway 3) in Make.config.template, remove only the line DEFINES += -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE The lines with += -fPIC are still necessary, as Make.config resets CFLAGS/CXXFLAGS. 4) Script newplugin needs to be modified, too. Best regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Makefile] `-fPIC` not added to externally defined `C[XX]FLAGS` of PLUGINS if `Make.config` not available
On Mon, 25 Jan 2010 23:43:11 +0100, Paul Menzel wrote 1. Each `Makefile` of a plugin gets rewritten to always append `- fPIC` to `C[XX]FLAGS`. Here is an example for the plugin hello. 2. If `DEFINES` from the beginning is also needed, that we should factor the snippet out into a file `Make.plugins` and every plugin has to include it in its Makefile. What do you think? What alternative is preferable? When this is decided I would create a patch to change that in VDR. This has already been discussed during the last months, I just didn't take the time yet to propose a fix: http://www.linuxtv.org/pipermail/vdr/2009-July/020977.html http://www.linuxtv.org/pipermail/vdr/2009-December/021807.html Best regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Makefile] `-fPIC` not added to externally defined `C[XX]FLAGS` of PLUGINS if `Make.config` not available
On Tue, 26 Jan 2010 10:54:00 +0100, Paul Menzel wrote Am Dienstag, den 26.01.2010, 10:34 +0100 schrieb Frank Schmirler: This has already been discussed during the last months, I just didn't take the time yet to propose a fix: http://www.linuxtv.org/pipermail/vdr/2009-July/020977.html http://www.linuxtv.org/pipermail/vdr/2009-December/021807.html Thank you for the links. I could not figure out what alternativ is preferred though. If you tell me, I could prepare a patch. Well, there hasn't been much feedback... At first I preferred the copy Make.config.template to Make.config if it doesn't exist approach as it doesn't require any change in plugin Makefiles and adds just a single line to VDR's Makefile. But the cleaner solution is clearly include a Make.global in plugin plugin and VDR Makefiles before Make.config as preferred by Udo Richter. Would be great if you could prepare the patch. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] streamdev for xbmc testing-pvr2
Hi, On Fri, 15 Jan 2010 21:01:14 +0300, Goga777 wrote does support cvs version of streamdev plugin the xbmc testing-pvr2 branch ? or only http://streamdev.vdr-developer.org/snapshots/vdr- streamdev-0.5.0-pre-20090706.tgz will be good for xbmc pvr2 ? The snapshot has been taken right after adding xbmc support to streamdev-cvs. Of course you can take a recent cvs version, too. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-remotetimers-0.1.2
Hi there, I just released remotetimers-0.1.2 on http://vdr.schmirler.de. The new release is mostly adaption to VDR 1.7. There are two minor new features: The Recordings menu will show the available diskspace for the actual filesystem you are in - interesting for those who have subdirectories on different filesystems. Note that due to a bug in VDR this won't work if the video directory and the subdirectory are both network shares. A patch to fix this is included in the source distribution and has been submitted to Klaus. The title bar of the Edit recording and Recording info menus now includes the length and size of the recording. HISTORY: 2009-11-04: Version 0.1.2 - When navigating to subdirectories in the Recordings menu, show diskspace information of the corresponding filesystem - Added recording size and length to titlebar of Edit recording and Recording info menus - Support for TS recordings (rename, change priority/lifetime) - API change for VDR 1.7.3+ (thanks to Thomas Günther) - Updated the menu parts copied from VDR to 1.7.7 - Silenced warning about suggested parentheses - Fixed segfault when parsing a currently recording remote timer of a channel which is unknown to the local VDR Enjoy, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Announce] vdr-remoteosd-0.1.0 and vdr-svdrposd-0.1.0
On Thu, 08 Oct 2009 07:28:08 +0200, Steffen Barszus wrote Well explained, Steffen. Thanks. Just a few additional notes: You have streamdev-server and svdrpservice/osd plugins running on the server. You have running streamdev-client and remote-osd, remote- timer and whatever else plugin running on the client(s) svdrpservice is not a serverside but a client side plugin. It allows multiple plugins on the same client to share a single SVDRP connection to the server (remember, SVDRP accepts only one connection at a time). So e.g. while epgsync downloads the server's EPG you can still edit the server's timers. The client would carry the xineliboutput plugin and you connect on the client machine to the client machine vdr. Just to avoid confusion: xineliboutput on the client is just one possibility. Any output plugin will do (softdevice, dxr3, reelbox3, ...). In general my plugins become useful as soon as multiple VDR instances come into play. On the server you'd typically put streamdev-server, svdrposd, femon and dummydevice. The client runs some sort of output plugin, streamdev-client, remoteosd, epgsync, femon and either remotetimers or timersync. Note that the client VDR may run on the same machine as the server VDR. That's the setup described in the xineliboutput README for real multi client. I'd rather label it the thin client approach: **Server Machine* * DVB card SERVER-VDR streamdev-server * streamdev-client CLIENT-VDR xineliboutput * NETWORK **Client Machine* * xineliboutput frontend * as opposed to fat client: **Server Machine* * DVB card SERVER-VDR streamdev-server * NETWORK **Client Machine* * streamdev-client CLIENT-VDR output plugin of your choice * Fill in xineliboutput as the output plugin and add the frontend - you end up with the same components for both approaches, just the network is at a different place. Best regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] vdr-remoteosd-0.1.0 and vdr-svdrposd-0.1.0
Hi there, I just published new releases of the plugins remoteosd and svdrposd (formerly svdrpext) on http://vdr.schmirler.de. The most important changes are the overdue gettext support for remoteosd and a major speedup of the remote menu in combination with the new svdrposd plugin. The remoteosd plugin provides access to the menu of an other VDR. Remoteosd relies on the svdrpservice plugin, which is also available from my website. I renamed the svdrpext plugin to svdrposd. The plugin publishes the textual contents of the OSD menu on SVDRP. In order to access the menu of a remote VDR using the remoteosd plugin, svdrposd or its successor svdrpext must be installed on the remote VDR. Changelog remoteosd: - if available, use svdrposd-plugin instead of svdrpext-plugin - added gettext support (thanks to Diego Pierotto) Credits to Udo Richter for his po218n.pl backward compatibility script - added Italian translation (thanks to Diego Pierotto) - log error if svdrpservice or svdrpext/svdrposd are not installed - replaced all occurences of asprintf - fixed not parsing replace mainmenu settings Changelog svdrposd: - renamed plugin from svdrpext to svdrposd - new command LSTO - number of items parameter to OSDI is now optional - improved selection of current item if multiple items have the same text - fixed memleak; no longer relying on OsdClear() being called before assigning new values - code cleanup Have fun! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PVRInput and Streamdev
Hi Rob, On Tue, 04 Aug 2009 16:15:44 -0500, Rob Davis wrote I have just got a pvr500 working with pvrinput and vdr. However, streamdev doesn't seem to work with this card. Is this just my system or am I unlikely to get it working? The TS stream produced by pvrinput has no PAT/PMT tables and doesn't provide a PCR. TS streaming with streamdev-0.3.4 didn't work due to the missing PAT/PMT tables, as streamdev solely relied on PAT/PMT when in TS mode. This has been fixed. Take a current CVS version or use a snapshot from http://streamdev.vdr-developer.org. The missing PAT/PMT and the missing PCR are however still an issue when streaming to VLC. VLC won't accept a TS stream without these parts. Use PES streaming instead. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Plugin compiler arguments / Make.config
Hi there, since vdr-1.7.3, VDR is compiled with the additional arguments -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE Plugins should be compiled with the same arguments as otherwise one might get unresolved symbols when loading the plugin. Consistently, in vdr-1.7.4 these defines have been added to the plugin part of Make.config.template. But that won't fix anything for the people who don't use a Make.config at all (those who do, need to check if something has changed in the template when updating). How could this problem be solved conveniently? I'd opt for copying Make.config.template to Make.config if no Make.config exists yet. A good place to do this would be in make include-dir. The documentation and UPDATE files should remind those who copy Make.config from an older release to fit in necessary changes. Other options: * Additional file to include by VDR and plugin Makefiles with such mandatory defines - this somewhat contradicts the idea of Make.config. * In the Makefile of each affected plugin, check for the presence of Make.config. If it's missing, check the VDR version and if required, add the defines - naah! Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Running multiple instances of vdr 1.7.7 with streamdev
On Wed, 20 May 2009 17:24:24 +0200, Frank Schmirler wrote For some (historical?) reasons VTP uses priority 1 to attach its receiver. The other client most likely uses priority 0, so it is not allowed to switch channels. Please change the following line in streamdev's server/connectionVTP.c: m_LiveStreamer = new cStreamdevLiveStreamer(1); into m_LiveStreamer = new cStreamdevLiveStreamer(0); I just did some tests: to get a last one wins behaviour, priority 0 is still not enough. I had to use -1 instead: m_LiveStreamer = new cStreamdevLiveStreamer(-1); Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Running multiple instances of vdr 1.7.7 with streamdev
Hi, On Tue, 19 May 2009 19:45:30 +0100, scott wrote It does however switch channel when the second instance of vdr is started even though the second instance has no client connected. VDR insists on tuning a channel when started. So that's how it's supposed to be. Just keep the second instance running all of the time. After it has switched channel I am only able to zap to channels on the same transponder until I kill the second instance of vdr. For some (historical?) reasons VTP uses priority 1 to attach its receiver. The other client most likely uses priority 0, so it is not allowed to switch channels. Please change the following line in streamdev's server/connectionVTP.c: m_LiveStreamer = new cStreamdevLiveStreamer(1); into m_LiveStreamer = new cStreamdevLiveStreamer(0); I notice that this error is reported: vdr: [23426] ERROR: device 10 reported an invalid number (0) of supported delivery systems - assuming 1 Is that significant? No, that's ok. The assumed value 1 is fine. Should be fixed though to get rid of the message. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Running multiple instances of vdr 1.7.7 with streamdev
Hi Scott, On Thu, 14 May 2009 18:02:22 +0100, scott wrote I have on the streamdev server, the behaviour to Offer Suspend and Client may suspend to yes, I was hoping that with this setup I would get last one wins, except for recordings which always win. Is there something wrong with my setup? I have no patches applied. xineliboutput v1.0.4. Your client VDR keeps begging for channel STREAM-0 as the server's DVB card is obviously tuned to an other transponder and due to Offer Suspend the client is not allowed to tune to a different one. This however doesn't explain why live view on the server gets interrupted. Please send me a mail off-list if you're interested in debugging this. Have you tried Always Suspended? That should be closer to last one wins. I'd expect a transponder change on the client to switch live view on the server, too. Changing transponder on the server, I'd expect that the picture on the client freezes. Best regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR shutdown problem(?)
On Fri, 15 May 2009 13:55:03 -0700, VDR User wrote What's the best way to shut down VDR without the process exiting prematurely? By that I mean before it has performed all of it's cleanup tasks (like saving setup.conf, channels.conf, etc). I was told that the method that comes with runvdr (/usr/bin/killall -q -TERM) kills it instantly and it doesn't have time to do cleanup. VDR catches the TERM signal and terminates gracefully. You were told wrong. Also, can an svdrp command be added to perform a VDR shutdown? I notice the svdrp command QUIT described as Exit VDR but after testing this command, nothing happened. HITK power Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
On Mon, 9 Mar 2009 15:23:51 +0100, Tomáš Skočdopole wrote This week I switched to vdr-1.7.4 and streamdev-cvs (both without any patches). Its better than vdr-1.7.0 and streamdev-1.3.4 but popcornhour still sometimes freezes (while watching SD /HDTV channels) and power off from electrical network is needed. On German VDR portal (http://www.vdr-portal.de/board/thread.php?postid=795607#post795607) someone reported that things got much better after updating PCH A-110 firmware to the 2009-02-26 release. Changelog indicates: - Fixed TS with stream6 as teletext playback cause out of memory That would be a reasonable explanation for having to powercycle PCH... Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] remotetimers-0.1.1
Hi, I uploaded a new remotetimers release to http://vdr.schmirler.de which brings mostly bugfixes for the previous release 0.1.0. The remotetimers-plugin is a perfect add-on for streamdev-clients to add/edit/delete timers on the server VDR. Additional features: - multiuser support by assigning user IDs - modify name, priority and lifetime of recordings - serverside cutting of recordings - VDR patch for serverside instant recordings (REC / Pause keys) - progress bars for EPG menu - possibility to swap key bindings of Ok / Blue in the What's on menus - refresh recordings list after mount/unmount of video directory and even if server directory is mounted as a subdirectory of the local video directory Changelog of 0.1.1 - New setup option for swapping the key bindings of Ok and Blue in the What's on now/next menus (suggested by holg...@vdrportal) - Update recordings list after mount/unmount of video directory - Fixed remote cutting which didn't work if local video directory is equal to the server's video directory (reported by k...@vdrportal) - Fixed compile error in remote_instant_recordings-patch (reported by k...@vdrportal) - Fixed incompatibility with switchtimer-patch (reported by Andreas Schott) - Updated Italian translations (thanks to Diego Pierotto) Enjoy, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
On Tue, 17 Feb 2009 20:54:05 +0100, Tomáš Skočdopole wrote But I have solved long buffering times on popcornhour - i have created custom html page and in hyperlinks must be with VOD attribute: A href=... VOD.../A For popcornhour the CVS version of streamdev is required. You won't get far with streamdev-0.3.4. Among others, the HTML channels lists of the CVS version include the VOD attribute. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
On Wed, 18 Feb 2009 18:03:26 +0300, Goga777 wrote is it need to patch it for vdr 174 ? No need for a patch, however PES streaming has been disabled for VDR 1.7.3 and above. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] epgsync-0.0.3
Hi there, a new version of epgsync is online. With the epgsync plugin you can import the EPG of an other VDR. This is particularly useful for streamdev-clients without DVB card. Even though streamdev-server forwards the current transponder's EPG data to the client, the server can often provide more data (e.g. due to EPG scan or recordings on transponders the client rarely tunes). Note that streamdev-clients builtin EPG-sync option is considered to be obsolete and will be dropped soon. Now what's new in 0.0.3? Besides the overdue gettext support, two new setup options are available. It is possible to limit the import to a specific channel type (DVB-C/S/T, analog) and to lookup channels by name instead of ID. So you could e.g. copy the EPG of DVB channels to their analog counterparts. Download and more details on http://vdr.schmirler.de Enjoy, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote I have attached a raw TS capture (~10M) containing the PMT pid 132 which is revealing the problem. Hum - PID 132 is a french dolby track, not a PMT PID... Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
Hi, On Mon, 19 Jan 2009 10:44:18 +0100, Alexw wrote I have noticed a PMT parsing issue with VDR version 1.7.x. The bug is still present in version 1.7.3 but the behaviour is worst because it segfaults. First I found out that 2 lines where added in the ParsePmt method. Data += Data[0] + 1; // this is the first packet Length -= Data[0] + 1; At the moment I don't know exactly what is the meaning of this 2 operations. These lines are for handling the SI pointer field. Data[0] is the pointer field, which contains the byte offset to the actual data (usually 0). + 1 for the pointer field itself. The order of the two statements need to be reversed. First fix the length, then the data pointer: Length -= Data[0] + 1; Data += Data[0] + 1; Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
On Mon, 19 Jan 2009 11:20:45 +0100, Alexw wrote I have already tested the inversion. Reducing the length and after moving to the new offset. This change does not solve the issue. The Length variable can still decrease to a negative value. What happen when the byte offset is greater than 188? Then the packet was broken and shouldn't have been processed at all. By definition the pointer field is the number of bytes to skip in *this* TS packet. As the pointer field is not covered by a CRC check, it could be wrong. So you're right, it should be checked. Note that this does not only affect cRemux::ParsePmt() but also cRemux::ParsePat(). Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PMT in multiple TS packet bug
On Mon, 19 Jan 2009 13:32:07 +0100, Alexw wrote Yes Frank you are right. The problem is coming from bad CRC in the PMT (and the same apply to bad PAT). If Pmt.CheckCRCAndParse() fails, bad PMT data should be skipped. Bad CRC is caught by CheckCRCAndParse(). What I had in mind is a wrong value in the pointer field itself (e.g. due to bad weather conditions). In ParsePat() something like if (Data[0] + 1 = Length) return; should be sufficient. The same check is fine for ParsePmt(), but I'd additionally suggest to pass the TS PUSI field as third parameter. Otherwise it would not be possible to distinguish the first fragment from fragments following a broken one. if (PUSI) // this is the first packet if (Data[0] + 1 = Length) return; ... else if (pmtSize == 0) // fragment of broken packet - ignore return; else // this is a following packet, so we add it to the pmt storage ... Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3 (streamdev)
On Mon, 12 Jan 2009 11:30:36 +0100, jean-paul wrote Thanks its compiling but I get now a error with compiling streamdev. Patch: http://www.vdr-developer.org/mantisbt/view.php?id=506 Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3
On Mon, 12 Jan 2009 16:04:09 +0100, Klaus Schmidinger wrote On 12.01.2009 16:01, Nicolas Huillard wrote: The resume ID is described excactly as I use it : Defines an additional ID that can be used in a multi user environment, so that every user has his/her own resume files for each recording. The valid range is 0...99, with 0 resulting in a file named 'resume.vdr', and any other value resulting in 'resume.n.vdr'. ie. it does not define the VDR instance, but the user instance... In practice, I set this to the same 0 value on every VDR, because I want to be able to stop a replay on one VDR, and continue viewing it on another VDR, starting at the position I stopped it... Well, I thought that this id could also be used here, but apparently I was wrong. Ok, then let's have another id for this... Much appreciated - thanks! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3
On Tue, 06 Jan 2009 16:06:02 +0100, Klaus Schmidinger wrote Instead of Priority and Lifetime, the directory name now contains the channel number from which the recording was made, and the resume id of this instance of VDR. This avoids problems if several VDR instances record the same show on different channels, or even on the same channel. I'd opt for a dedicated VDR instance parameter instead of using the resume ID. In my understanding the resume ID corresponds to the actual user watching, hence the resume ID is subject to change. At least that's how I use it in the remotetimers-plugin. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] S2-3200 vdr needed material ?
On Thu, 8 Jan 2009 18:04:05 +0200 (EET), Mika Laitio wrote latest streamdev from CVS failed to build again 1.7.3 In the bugtracker you'll find a patch which makes streamdev compile again. It comments out the PES output stuff which causes the problems until a clean solution is available. http://www.vdr-developer.org/mantisbt/view.php?id=506 Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
On Sat, 20 Dec 2008 20:31:33 +0100, Udo Richter wrote On 15.12.2008 11:06, Frank Schmirler wrote: - no channel sync This would make an excellent addition to streamdev. Rather a separate plugin or at most part of epgsync-Plugin. Streamdev should stick to what it was meant for: streaming. Streamdev is a receiving device within VDR, and VDR can do automatic channel updates. So I think that its part of the job to provide channel information, just like providing epg data. And for channels with changing language IDs and similar this is even useful. It seems that we have a different understanding of the term channel sync. Streamdev-0.3.4 has the capabilities you're talking about. What I had in mind was merging or replacing the client's with the server's channels list. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
On Wed, 10 Dec 2008 11:59:47 +0200, Pertti Kosunen wrote Klaus Schmidinger wrote: Besides, isn't there the streamdev plugin that provides signals to other clients? I've never tried it myself, but I was under the impression that this is what people use in such cases... I've seen multi client streamdev users run multiple vdr daemons in server machine, one for each client. Maybe this could be improved to allow multiple instances of plugin run in one daemon? A single streamdev-server instance can be used by multiple clients. No need for multiple instances here. The setup you are talking about addresses the problem that you can't have independent clients with xineliboutput: There's one VDR instance with streamdev-server controling the DVB cars. Then for each client, there's a VDR instance with xineliboutput and streamdev-client. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !
On Mon, 24 Nov 2008 21:41:54 +0100, Nicolas Huillard wrote Alex Betis a écrit : On Mon, Nov 24, 2008 at 3:24 PM, Nicolas Huillard Guys, How about putting the system in suspend mode instead of powering it off and on again? Should take few seconds. Suspend to RAM as always been a pain in my various trials, but this is a much simpler goal than a complete laptop. Virtually no device to take down/bring up on a pure streamdev client. NFS handles must just survive the long delay, but it should be OK. 7 seconds until I get a picture on my EPIA 6000. And this is still pretty long, as I need to upload DXR3 firmware first, then start VDR. This also works around an annoying bug in the (non-upgraded) EPIA BIOS: the PXE LAN boot does not always initialize the network interface after a shutdown. One have to unplug power to boot correctly next time... Current via-rhine drivers have a module option to fix this: via-rhine.avoid_D3=1 For older kernes there's a patch: http://lkml.org/lkml/2004/9/17/242 Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !
On Tue, 25 Nov 2008 14:39:19 +0100, Nicolas Huillard wrote Frank Schmirler a écrit : Current via-rhine drivers have a module option to fix this: via-rhine.avoid_D3=1 For older kernes there's a patch: http://lkml.org/lkml/2004/9/17/242 I was sure it wouldn't hurt to ask on this ML... Next question : where should I put this ? https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=threadtopic_id=33621forum=10post_id=148956 says I should insert it in the initrd, but it's a bit difficult in my case (the same kernel/initrd is shared by many clients)... Clients which do not have a via_rhine card will ignore the parameter. So it's safe to enable it for all clients. I'd try to insert it on the PXE kernel command-line, but it's explicitely ignored by the kernel : ml6000 kernel: Unknown boot option `via_rhine.avoid_D3=1': ignoring ...or implicitely, when I just add avoid_D3=1 (ie. PXE does not boot after the next shutdown) You would use via_rhine.avoid_D3=1 if the driver was builtin to the kernel. When built as a module, it depends on how the modules are loaded. In an initrd sometimes insmod is used. It accepts module options on the commandline (insmod via_rhine avoid_D3=1). If modprobe is used, specify options via-rhine avoid_D3=1 in /etc/modprobe.conf (or a file in /etc/modprobe.d/). You must do it in the /etc/ directory which is mounted by the time modprobe is executed (so probably inside of your initrd). Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.1 video stream format
On Mon, 24 Nov 2008 14:41:44 +0100, Stefan Lucke wrote
- dumping the data I got via PlayVideo() to a file neither ffplay nor
mplayer can identify stream info from dumped data.
Unless I've overlooked some section repacker somewhere, there's a bug in
cPatPmtGenerator. I've already sent the attached patch to Klaus, but he didn't
have time to look at it yet.
Frank
--- remux.c.orig 2008-11-13 13:39:48.0 +0100
+++ remux.c 2008-11-13 16:32:57.0 +0100
@@ -2298,6 +2298,7 @@
p[i++] = 0x40; // flags (3), pid hi (5)
p[i++] = 0x00; // pid lo
p[i++] = 0x10; // flags (4), continuity counter (4)
+ p[i++] = 0x00; // pointer field (payload unit start indicator is set)
int PayloadStart = i;
p[i++] = 0x00; // table id
p[i++] = 0xB0; // section syntax indicator (1), dummy (3), section length hi (4)
@@ -2367,13 +2368,18 @@
MakeCRC(buf + i, buf, i);
// split the PMT section into several TS packets:
uchar *q = buf;
+ bool pusi = true;
while (i 0) {
uchar *p = pmt[numPmtPackets++];
int j = 0;
p[j++] = 0x47; // TS indicator
- p[j++] = 0x40 | (P_PNR 8); // flags (3), pid hi (5)
+ p[j++] = (pusi ? 0x40 : 0) | (P_PNR 8); // flags (3), pid hi (5)
p[j++] = P_PNR 0xFF; // pid lo
p[j++] = 0x10; // flags (4), continuity counter (4)
+ if (pusi) {
+ p[j++] = 0x00; // pointer field (payload unit start indicator is set)
+ pusi = false;
+ }
int l = TS_SIZE - j;
memcpy(p + j, q, l);
q += l;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
On Thu, 13 Nov 2008 19:28:54 +0100, jori.hamalainen wrote I tried to v3 patch offline from my PCH (just wget to a file and run mediainfo ffprobe etc). There seems to be progress - now ffprobe (and ffmpeg) indicates some errors in start of stream - which could be explained. I ran the file through ts-doctor and got following output and PCH plays the file ok. Recognizes audio as AC3 (without fix as DTS as reported previously). (...) Error: Invalid packet 1, skipped! Error: illegal_adaptation_field_type Starting at packet 2 00:00:00.000 A hexdump of the first few packets from both, the original and the fixed stream, would be fine. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
On Thu, 13 Nov 2008 01:43:01 +0100, Helge Lenz wrote After your patch TSDoctor does not find a PAT at all! Tested with both versions of the patch. Ouch - uploaded v3 of the patch. Again untested (sorry, I can't do any tests here). Somebody in the NMT forum claims that he has it working with vdr- 1.7.1 without any modifications. H264 streams should work too according to this post: http://www.networkedmediatank.com/showthread.php?tid=1696pid=92157 I think we're on the right track. From vdr-1.7.1 changelog: + The new class cPatPmtGenerator is used to generate a PAT/PMT pair that precedes the TS data in Transfer Mode. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
On Tue, 11 Nov 2008 13:02:48 +0100, jori.hamalainen wrote --- PMT 0 --- Packet : 1 The fixed file starts with a PMT packet. Could PCH be choking on the fact that the TS stream starts right in the middle of nowhere? I think this is a good quess. I don't know how much PCH reads the stream for PMT table (first 10kB, first 100kB,...?), so if it does not have it in time it quits the stream. So could streamdev be easily modified to provide PMT at stream start? And could PMT be rewritten later if new streams are found. With this I mean on first PMT you have audio/video-stream. And subtitle appears 60 seconds from the start so give new PMT with private subtitles streams as well? I opened a bug report (http://www.vdr-developer.org/mantisbt/view.php?id=496) and posted a quick hack which should strip off all packets before the first PAT and probably some packets before the first PMT (hopefully not including the PMT). The PMT part needs to be elaborated. Sending a PMT with basic information first should be possible and sounds like a good idea. I'll take a look into this the next days. How about the other symptom I was giving output. My VDR machine and its mplayer. Sometimes it recognizes stream as MPEG-2, and sometimes H.264. What do you believe, problem with TS stream or problem with Mplayer stream recognition. Could have the same cause... Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
On Tue, 4 Nov 2008 15:31:21 +0100, jori.hamalainen wrote PCH itself supports multiple audio (and subtitle) tracks at least on other formats - but I believe that with VDR it might not be working. I need to test this more when I get back to my PCH. http://www.hdd-player.de/syabas/showthread.php?tid=1777page=1 I don't know if this URL recommendation is because of the initial tests made by some guys where they received video but not audio. I think this +1 as a default might become a problem with channels with multiple sound tracks. Maybe there could be additional feature that do not automatically add +1 if count.apid 1? As of PES, without a +audio_pid_index all audio and dolby pids will be streamed. So on a channel with only one audio pid, a +1 won't make any difference. For channels with multiple audio/dolby pids, the streamdev html page already contains specific links for each. Look for the a-tags with class apid and dpid respectively. Rather add the vod/prebuf/tvid attributes there. With ES it's obvious that you get either video or audio, never both at the same time. By default (without +index) you get the video pid. If there is none (radio channel) you get the first audio pid. According to an open bug report, PS actually sends PES. Finally TS normally doesn't consider the actual audio pid. It streams most relevant pids (not only audio and video) according to the PMT. This format should be the best choice. It may not have worked by the time the guy at the NMT forum tried the first time, as streamdev didn't have a PAT repacker by that time. It is part of streamdev 0.3.4. Have you tried TS? - Added suffix for URL (TS w/ C-123-123-123.ts or S-12-123-123.ts, .ps, .vdr for PES and .mpeg for ES, extern no suffix) I wonder why these are needed? I think PCH uses filename based analyzing for stream type recognition. It was at the web forum above that URL like /PES/*.vdr should work. I doubt that *.vdr is known as an official filename extension for PES files. Maybe any (possibly otherwise unknown) extension would do? Could you verify that? So I guess if you see it possible to add this into tree - please do it. But if you see adding filename suffix a bad decision then don't. For my own experiments I can do this patching manually. And the patch is already out there for interested people to find. Filename suffixes have already been suggested a while ago. I'd be fine with them if they are necessary. Now the problem is that h.264 streaming is not working. It should happen via TS-container? And for this probably streamdev should be modified. I cannot tell why it is not working as PCH does not give any clue on it. Just returns to menu. Haven't checked if the PES remuxer actually supports h.264. TS would be a better choice anyway. Good luck, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
On Tue, 4 Nov 2008 11:59:10 +0100, jori.hamalainen wrote - Added automated audio track selection to default URL (+1) Is it a problem for PCH to receive multiple audio tracks? - Added suffix for URL (TS w/ C-123-123-123.ts or S-12-123-123.ts, .ps, .vdr for PES and .mpeg for ES, extern no suffix) I wonder why these are needed? These small enhancements are inside anchor tag and they do not affect other browsers, just MSP-compatible browsers - so in theory this patch could be built-in for streamdev. But naturally my vision is to have own GUI for MSP. I filed a feature request in the streamdev bugtracker: http://www.vdr-developer.org/mantisbt/view.php?id=494 I wouldn't want to commit it to streamdev, if it's only a temporary solution (until an MSP plugin is available). Drop me a line if you think it makes sense to commit it anyway. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] remotetimers-0.1.0
Hi there, I just released remotetimers-0.1.0 on http://vdr.schmirler.de. Changelog: - Plugin now has its own Recordings menu. Features: * filtering by user * editing of recordings (name, priority, lifetime, user) * starting local/remote cutter * replacement for VDR's Recordings menu (requires MainMenuHooks patch) - Multiuser support for Timers and Recordings (check README for details) - Dedicated setup options for user filter in Schedule, Timers and Recordings menus, either backed by VDR's Resume ID or set to a static value - Progress bars for What's on now? menu (thanks to [EMAIL PROTECTED]) - Patch for server-side instant recordings and paused live view - Keep recordings list up-to-date if server's video directory is mounted in a subdirectory of the local video directory - Updated Italian translations (thanks to Diego Pierotto) Version 0.1.0 is a development release. The core functionality should be fine, but some of the new features are either incomplete or not very well tested. In particular: - Renaming recordings on VDR's with multiple video directories has not been tested at all. BEWARE! You might loose your data! - Renaming recordings across filesystems not implemented yet - I added support for the timersync-plugin to the remote_instant_recordings patch as the patch might work with it, too. Maybe someone using timersync could give it a try and report back. Have fun, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and multicast streaming
On Mon, 20 Oct 2008 20:04:43 +0200, Artem Makhutov wrote do you know an solution to make VDR (maybe with the use of the sreamdev-plugin) to stream using multicast? There's no multicast support in streamdev yet (any volunteers?). However I've heard of some guys who got it working by using VLC as mediator. They connected VLC to streamdev-server and then used the VLC streaming wizard to multicast the transmission. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] stream recordings using the streamdev-plugin
On Mon, 20 Oct 2008 20:09:21 +0200, Artem Makhutov wrote I would like to stream my recorded movies using the streamdev-plugin. Is such a feature planned? It is planned, but currently I have no time to implement it. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and multicast streaming
On Tue, 21 Oct 2008 09:13:15 +0200, Theunis Potgieter wrote What is exactly involved in changing it from streaming to multi- casting, isn't it just changing the IP destination? Or does it require repacking it from mpeg2-ts to something else? Sorry if this is a stupid question. We are not limited to TS here - any of the formats streamdev can remux to should do. I'd say the following things are required: - Use UDP instead of TCP for streaming (is it just switching from SOCK_STREAM to SOCK_DGRAM or do we need to do something more, e.g. fixed/max. packet sizes?) - Provide some way to select the channel for multicast transmission and stop it when it's no longer needed (probably via streamdev http server menu. Or do these kinds of settop boxes support some sort of control protocol to enable/disable the stream?) Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] stream recordings using the streamdev-plugin
On Tue, 21 Oct 2008 11:17:34 +0400, Goga777 wrote does support streamdev-plugin h.264 format ? Basically yes. However some people reported load problems. YMMV. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and multicast streaming
On Tue, 21 Oct 2008 14:46:52 +0200, Artem Makhutov wrote The ADB-Boxes use Multicast-TS. I have captured a transmission from my IPTV provider. So you can take a look on it: http://www.makhutov.org/downloads/adb/ The .pcap file is not accessible. Would it contain the IGMP traffic, too? The boxes send IGMP Join / Leave Group messages, if you switch or turn on a channel. Streamdev could listen for such messages an enable/disable the streams. The IGMP Join Group messages are send in an interval (1 messege/minute). If an IGMP Leave Group message is recieved, or if no Join Message was received during 2 minutes then the stream sould be stopped. Makes sense - that's the way how it's supposed to work when subscribing to an Internet multicast stream, i.e. accross router boundaries. With streamdev, each channel would become a multicast group of its own. Multicast IPs are not an issue here. The IPv4 Local Scope for multicast addresses is large enough. But how do you configure them in the box? Or does it listen to some sort of announcements (getstream2 sends SAP/SDP packets)? The boxes also support HTML, so then can post data to a webpage, if the channel was switched. I am not sure if all boxes support this. At least the ADB boxes can do this. Some sort of user interface would be fine anyway. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] svdrpservice-0.0.4
Hi there, a new release of the svdrpservice-Plugin is available from http://vdr.schmirler.de HISTORY 0.0.4 - Italian translation (thanks to Diego Pierotto) - Commandline parameter for default server IP and port (suggested by [EMAIL PROTECTED]) - Automatic charset conversion (suggested by [EMAIL PROTECTED]) Includes patches for VDR 1.6.1 to make it report its charset in the SVDRP greeting message - Gettext support for VDR 1.5.7+ Credits to Udo Richter for his po218n.pl backward compatibility script - Accept empty responses (status code + space character) - No longer strip trailing whitespace from responses - Configurable timeouts ** What is the svdrpservice-plugin all about? It's a little helper used by a couple of other plugins (e.g. remotetimers and remoteosd) to contact an other VDR using SVDRP. So it doesn't make sense to install svdrpservice as long as no other plugin requires it. ** Some notes on the new charset conversion feature If two connected VDRs are using different charsets (e.g. a VDR 1.6 with UTF-8 and a VDR 1.4 with ISO-8859-15), svdrpservice will do an on-the-fly conversion. However the server must report the charset it uses or otherwise svdrpservice won't convert. Since VDR 1.6.0-2 and 1.7.1 the charset is included in the SVDRP greeting message. In the patches subdirectory of the plugin sources you will find patches for older VDRs (affects only a single line). Note that you don't need to patch the client VDR (i.e. the one running svdrpservice). Let me give you an example: - Server VDR running 1.6.0-2, client VDR running 1.4.7: You're all fine. No patch required - Server VDR running 1.4.7, client VDR running 1.6.0-2: You need to patch the server VDR here ** What bugs will be fixed by svdrpservice-0.0.4 - A remoteosd connection aborted whenever a menu with empty title was opened (e.g. extrecmenu plugin) - The name of a recording as returned by the SVDRP command LSTR may end with a space character. Previous svdrservice versions stripped that off. Some features of remotetimers 0.1.0 (not released yet) will fail on these recordings if an old svdrpservice version is running. Enjoy, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reelbox plugin - help compiling
On Thu, 18 Sep 2008 18:54:33 +, Josce wrote It now stops with this error: In file included from HdTrueColorOsd.c:34: fontsml-iso8859-15.c:1: error: 'tPixelData' in class 'cFont' does not name a type HdTrueColorOsd.c: In member function 'int Reel::HdTrueColorOsd::CacheFont(const cFont)': HdTrueColorOsd.c:147: error: 'FontSml_iso8859_15' was not declared in this scope HdTrueColorOsd.c:182: error: 'NUMCHARS' is not a member of 'cFont' HdTrueColorOsd.c:208: error: 'tCharData' is not a member of 'cFont' HdTrueColorOsd.c:208: error: 'charData' was not declared in this scope HdTrueColorOsd.c:209: error: 'NUMCHARS' is not a member of 'cFont' What is wrong here? I had the same error. IIRC your VDR is missing the truecolor OSD patch: http://www.vdr-wiki.de/wiki/index.php/OpenSUSE_VDR_DVB-S2_-_Teil3:_VDR#Patches_f.C3.BCr_Reelbox_Plugin_herunterladen Good luck! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to use VDR2VDR for h264 streaming?
On Tue, 29 Apr 2008 15:23:58 +0200, YUP wrote is it possible to use vdr-stream plugin to stream from one VDR (server) to another VDR( client) h264 encoded stream in the same way as it is implemented in VDR-2-VDR with mpeg2? Some time ago the VTP part of streamdev-server has been extended to support extern remux. The streamdev-client could select externremux by issuing a CAPS EXTERN instead of the standard CAPS TSPIDS (you will need to modify the source). Of course the client VDR needs to support h264 - patches are available - and externremux has to emit an h264 TS stream. That's the theory. Your mileage may vary. Probably noone even tried the CAPS EXTERN part. Good luck ;) Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
