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
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] perfect vdr remote?
On Wed, 27 Jul 2011 09:16:17 +1000, Torgeir Veimo wrote > On 27 July 2011 01:49, VDR User wrote: > > On Tue, Jul 26, 2011 at 7:39 AM, Torgeir Veimo > > 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
[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] 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] 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
[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] 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
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
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Sat, 25 Feb 2012 15:39:17 +0100, Klaus Schmidinger wrote > There was also apparently some misunderstanding about what > PrimaryLimit was supposed to do. It was *never* meant to allow > "Channel switching can cancel timers with priority <= > Setup.PrimaryLimit" (as noted at the bottom of http://projects.vdr- > developer.org/issues/show/10). Its sole purpose was to not use the > primary device for recording low priority timers and leave the user > with a black screen. Those days are long gone, and PrimaryLimit is > obsolete and causing nothing but trouble. > > A recording shall *always* have priority over live viewing. I would be fine with that with respect to recordings, but this shouldn't be generally true for cReceivers. What I'm hoping to get is the possiblity to attach a cReceiver with a lower priority than live TV but without the "cReceivers with negative priority do not count". > Since cReceivers can have priorities between -99 and 99, the priority > for an unused device has been changed from -1 to -100. Udo Richter's patch basically turned "PrimaryLimit" into a configurable "LiveTV priority". A "LiveTV priority" > 0 gains you cReceivers with a priority less than live TV but still non-negative. To fix the "Transfer mode receiver device has priority -1" problem, he introduced "volatile". 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". 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. 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 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
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 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 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
[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
[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] 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.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
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
Re: [vdr] [Announce] streamdev-0.6.1
Hi Morfsta, On Fri, 29 Nov 2013 14:35:03 +, Morfsta wrote > I have been using the VDR Samsung SmartTV VDR plugin which relies on > streamdev for transfer of live channels over the network and it uses > its own proprietary implementation for the transfer of recordings. I > have tried using it over wifi as well as powerline. The recordings > (SD and HD) play flawlessly over the network, however the streaming > of live channels using streamdev results in regular buffering (SD > and HD) and eventually the TV just gives up playing them. Is there > any buffer options or other configurable settings within streamdev > that might alleviate this problem? I can't seem to find much that > would help. Maybe you suffer from some sort of network congestion. Currently there's no buffering option. Streamdev starts streaming as soon as possible. Try adding a short delay at the beginning of void cStreamdevWriter::Action(void) in file server/streamer.c, e.g. cCondWait::SleepMs(500); Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Announce] streamdev-0.6.1
Hi, On Sat, 30 Nov 2013 16:36:14 -0800, VDR User wrote > If his recordings stream fine and the problem is only with live tv, > how could that possibly be network congestion? I should have written "temporary network congestion". When streaming a recording, the client can pre-buffer data to prevent buffer underruns. With live TV this is not possible as data becomes available just in time. So fluctuations in the available network bandwidth could have an impact. The fact that streamdev uses TCP to transmit the stream might be an additional problem here as packet loss leads to retransmission. As Morfsta is able to view HD recordings while he seems to get problems even with SD live TV, bandwith alone surely isn't the problem. But temporary congestion or high packet loss due to e.g. interference sound reasonable to me. Regards, Frank ___ 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
[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
[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
Re: [vdr] [ANNOUNCE] New patch: MainMenuHooks
On Mon, 26 Feb 2007 21:41:28 +0100, Udo Richter wrote > The service functions are meant to be a solution for plugin-to- > plugin communication, since in that case there's no access to the > other's symbol space. In this case however, the VDR headers can > easily be extended, so there's enough room to do a normal interface. Right, we've been discussing that but opted against an API change. With just an interim solution in mind we've been looking for the least invasive way to get what we want. And no need to recompile all plugins. > For the menu hooks, I would suggest to implement a common base class, > that a plugin must derive a copy of, to register a new handler. > Basically, the same way it already works for cStatus, or other > things like devices and skins. That would be the cleanest solution. But IMHO a little bit oversized if it were only about replacing the four mainmenu entries. A new API should rather give plugins a chance to modify both, contents and behaviour of the standard menus. That way even multiple plugins could modify the contents of the same (original) menu, something a dumb "replace whole submenu" feature would not support. My upcoming remotetimers plugin should give an excellent example. Currently it's a copy of the original timers and schedule menu code with some lines added here and there just to fill in the remote entries. With an appropriate new API I could simply append the remote timers to the original timers list and my additional options to cMenuEditTimer. In the schedules menu, I need to tag remote timer matches and catch the add timer actions. If there were some well defined hooks, that would not keep anyone from using one of the alternative schedule implementations. Finally on a pure streaming client it would be nice to redirect instant recordings to the server by overriding the red button action in the main menu. However as it should also be informed whenever the record key is pressed this is rather a candidate for an other API. I stop cherishing my illusions here. Such an API would require thorough analysis of the current plugins and major rewrites of VDR and plugins. Still in the end it won't suit everyone. But maybe Klaus could share his opinion with us? Perhaps it's worth a try. > Basically, I think its worth considering such an interface to allow > to replace standard dialogs. However, the user should always have > the choice whether he wants to keep the originals or use the replacements. Agreed. That's why in the patch instructions we ask plugin developers to provide a setup option for this which defaults to "off". Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] svdrpservice-0.0.3
Hi there, svdrpservice is a helper plugin which makes it easy for other plugins to send SVDRP commands to an other VDR. Homepage: http://vdr.schmirler.de. Most important changes in 0.0.3: No longer using a fixed buffer size. Users of the epgsync plugin might appreciate this when using external EPG sources with e.g. tvmovie2vdr. The amount of data provided there was often too large for the old buffer. The plugin has its own setup menu now. You can specify default values for the server IP and port, so these values no longer have to be entered in each and every plugin using svdrpservice. If a plugin requests a connection to the special IP 0.0.0.0 or the IP is missing completely (empty string), the default value from the svdrpservice setup will be used. Likewise port number 0 will be replaced. Note that yet it's not possible to enter port number 0 in the plugins which use svdrpservice. Future versions will fix this. A silent change of the service specification came along with the new setup options: Server IP and port are now in/out parameters. After the service call for a new connection these parameter contain the actual values for IP and port, i.e. the svdrpservice default values are returned if they have been used. Note that the service version has not been increased as the modification does not break compatibility. Changelog: - Dynamic buffer size - New setup options: default server IP and port - Silent change of service interface: serverIP and serverPort are now in/out params - Connection handle was not reset to -1 when disconnecting a shared connection which is still in use - Non-blocking connect Enjoy, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] remoteosd-0.0.2
Hi, another new version this week: remoteosd-0.0.2 is out. The remoteosd plugin allows a (client) VDR to operate the menu of a remote (server) VDR. Remoteosd requires the svdrpservice plugin, so make sure both plugins get installed on the client. The svdrpext plugin is required on the server. All three plugins are available on http://vdr.schmirler.de. Most important changes in version 0.0.2: New option "Tune server channel". When opening the remote OSD, the plugin tries to tune the server to the same channel the client is viewing. So when entering e.g. the remote schedules menu, the expected channel will be highlighted. Usually this option makes sense only if you are running a headless server. In this case I recommend to install the dummydevice plugin on the server, too. Otherwise, in some situations the server might not be able to switch channels as expected. Support for MainMenuHooks patch. With this patch a plugin can replace the VDR mainmenus "Schedule", "Channels", "Timers" or "Recordings" (read http://www.linuxtv.org/pipermail/vdr/2007-February/012309.html for more information). Remoteosd allow you to replace "Schedule" and/or "Timers" by the corresponding remote menu. Note that you have to apply the patch before compiling remoteosd, otherwise the setup options won't show up. The MainMenuHooks patch is included in the patches directory of the remoteosd sources. See the patch file for further information and instructions. Changelog: - New option: tune channel on server - Support for MainMenuHooks patch. Plugin may replace the VDR mainmenus Schedule and Timers - Close remote menu when the local menu has been closed by menu key - OSD message if server is not reachable - Support for svdrpservice-0.0.3 default IP/port - Code cleanup Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] New plugin remotetimers-0.0.1
Hi, the successor of streamdev's former remote timers feature is finally there. You can get the new remotetimers plugin at http://vdr.schmirler.de. Features: - Add, edit and delete timers on the local (client) VDR and a remote (server) VDR - Move timers between client and server - Assign user IDs to timers. Filter the timer list by user ID. - Support for MainMenuHooks patch. Replace the VDR mainmenus "Schedule" and "Timer" by remotetimers' counterparts. In addition, the plugin comes with its own "Schedule" menu. Adding timers without EPG is not very convenient, is it? All menus are more or less copies of VDR's originals. That should help to keep up with changes in VDR. Credits to Klaus and everyone who contributed to those parts of the code I copied. Remotetimers requires the svdrpservice plugin. So make sure, both plugins are installed. Differences between the original VDR menus and their remotetimers counterparts: The edit timer menu has two additional options: Location determins if the timer is stored on the local or the remote machine. Use this setting to move the timer from client to server or vice versa. Note that you cannot move a running timer. You will have to stop it first. You can assign a user ID to each timer. Every user or client can use its own ID or maybe you want to distinguish timers by genre? Whatever you prefer. You can then filter the timer list by ID. The special ID "0" actually means "no ID". A corresponding timer will always be visible. In the plugin setup you can determine the default values for location and user ID. In the timer list you will see a letter in front of the channel number. "L" indicates a local timer, "R" a remote timer. Use the number keys to filter the list. Press "0" to see all timers. Any other digit will show only timer with a matching ID and timers with ID "0". The menu title shows the current filter setting. In the plugin setup you can configure the default filter. There's nothing special about the schedule menus, of course except for the fact that remote timer matches are marked with "T", too. Note that there's no user ID filter. You will always see all timer matches. Warning: This is the very first release of the plugin. Even though it works perfectly for me, it may not in your environment. Keep this in mind when testing and maybe doublecheck the timer list on the remote VDR. Enjoy, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Streamdev and subtitles and HD
On Tue, 20 Mar 2007 22:18:31 +0200, Pasi Juppo wrote > Hi, > > Is there any plans to have subtitle support for streamdev plugin? Or > is there by any chance a patch that provides it? AFAIC no plans for that at the moment - sorry. > And are there any plans for streamdev to support HDTV (h.264 or > similar)? AFAIK mpeg2 based HDTV works right out of the box. I will probably start working on H.264 if all of the following conditions are met: - Linux and VDR support for DVB-S2 and H.264 - H.264 FTA channels on Astra which are halfway worth the effort - Affordable way to decode it in hardware without generating to much noise - Component output of HDTV not threatened by broadcast flag / DRM Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] remotetimers plugin
On Fri, 27 Apr 2007 01:38:56 +0100 (BST), Simon Baxter wrote > I can't get this plugin to work - I get a "remote timers" and "remote > schedule" unavailable message on the 'client'. This is a known issue with version 0.0.1. Please make sure that plugin svdrpservice is loaded before remotetimers (i.e. "vdr -Psvdrpservice -Premotetimers") or apply remotetimers-svdrpservice.diff which is available on http://vdr.schmirler.de/. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] remotetimers plugin
On Fri, 27 Apr 2007 11:23:38 +0200, Matthias Fechner wrote > oh good to know, maybe you should correct your website: > > Known issue: > > * Make sure that remotetimers is loaded before svdrpservice or apply > remotetimers-svdrpservice.diff. Will be fixed in the next release. Oops - fixed. Thanks! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr in client-server configuration?
On Tue, 12 Jun 2007 18:02:29 +0200, Oliver Joa wrote > i use vdr since a long time, i still use version 1.3.23 on 3 Computers. > The last months/years i did not follow the development. Is there already > a solution for the client-server Problem? I wonder if it is possible > to have 1 server recording and streaming to 2 client. And the > clients possible to start recordings on the server. Maybe the > possibility to see the osd of the server on the clients... If you are looking for a solution with streamdev, then check http://streamdev.vdr-developer.org for a current version. Additional client-server plugins are available from http://vdr.schmirler.de (e.g. access to server osd). Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Fix Pid not available error in the streamdev plugin VDR-VDR connection
On Sat, 15 Dec 2007 15:48:21 +0100, Jose Alberto Reguero wrote > This patch fix the error "Pid xxx not available" in the streamdev > plugin with VDR-VDR connection, that cause not tunning to the > channel. The problem is that sometimes, when cConnectionVTP::CmdADDP > is called, m_LiveStreamer is NULL, and then return an errorr. > m_LiveStreamer became null in cConnectionVTP::CmdABRT that is called > from cStreamdevDevice::CloseDvrInt called from cStreamdevDevice::CloseDvr. Guess you refer to this problem: http://www.vdr-developer.org/mantisbt/view.php?id=255 I finally commited a workaround to CVS last week. The problem is caused by VDR 1.5.x clients, so I'd rather see this fixed on the client side. But thanks for your efforts nevertheless! I added a reference to your posting in the bugreport. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Using a local FF card for recording on streamdev client
On Wed, 23 Jan 2008 10:50:45 +0100, Malte Forkel wrote > sometimes I would like to use the FF card of my client for recording > (to the common video directory shared via NFS). The client seems to > automatically prefer its streamdev device though, i.e. it uses one > of the server's cards if available. Is there a way to tell vdr to > "stay local", preferably without editing channels.conf? Two possible solutions come into my mind 1. Patch (or rather bugfix) for streamdev: When you disable streamdev-client in its setup, it remains active until you restart vdr. It would make more senste to make streamdev-client stop offering channels once it is disabled. You would have to temporarily disable streamdev every time you want to make sure the recording uses the local FF card. 2. Extend VDR's device selection algorithm: See cDevice::GetDevice(...) in VDR's device.c. Timers usually have a high priority, so it's easy to identify calls to GetDevice caused by a timer. Whenever GetDevice is called with a high priority and the device's card index indicates a non-DVB card device like streamdev-client, give that a maximum impact, so it should be avoided. By checking for a particular priority range only (e.g. >= 30), you could even use the timer priority to control whether streamdev or the FF card will finally take the recording. Patches for both solutions attached - feedback welcome! Note that both patches are entirely untested. DISCLAIMER: Fiddling around in cDevice::GetDevice() could have unexpected side effects ;-) Cheers, Frank streamdev-disabled.diff Description: Binary data vdr-avoid-streamdev-recording.diff Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] remotetimers-0.0.2
Hi, remotetimers-0.0.2 is available from http://vdr.schmirler.de/. The plugin lets you add/edit/delete timers on the local (client) VDR and a remote (server) VDR. Changes: - Updated the menu parts copied from VDR to 1.6.0 - Gettext support for VDR 1.5.7+ Credits to Udo Richter for his po218n.pl backward compatibility script - API change for VDR 1.5.3+ (thanks to [EMAIL PROTECTED]) - Svdrpservice no longer needs to be loaded before remotetimers - Ignore recording flag when verifying that a timer hasn't been modified - Removed duplicate check when deleting timer - Italian translations (thanks to Gringo) Have fun! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] vdr-streamdev-0.3.4 and CVS branch
Hi there, streamdev-0.3.4 is finally available from http://streamdev.vdr-developer.org. It marks the end of the 0.3.x series. As such, it still contains lots of unused and legacy code. There has been a major cleanup in the meantime. Watch out for the upcoming releases 0.4.0 (for VDR 1.4.0 - 1.5.8) and 0.5.0 (for VDR > 1.5.9). Most of it has already been commited to CVS. Note that a branch has been opened for the 0.4 series. Special thanks go to: - Sascha Volkenandt, the original author of streamdev - Rolf Ahrenberg for many suggestions, patches and for helping a lot to prepare the upcoming releases - Petri Hintukainen for contributing the section streaming parts. Great work! - all the others on the CONTRIBUTORS list ;) Please check http://streamdev.vdr-developer.org for information on new features. Additional information can be found in the README file and the HISTORY log. Enjoy, 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
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
[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] 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] 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] 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=1777&page=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 -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
Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
On Wed, 05 Nov 2008 13:02:22 +0100, Helge Lenz wrote > The TS from the streamdev is not recognized by the PCH (neither SD > nor HD). I tried to remux SD through vlc and this works quite well. > I assume that the PCH only supports a certain "flavour" of TS > packets because if you remux HD material with a TS-Remuxer for the > PCH (see http://www.hdd-player.de/syabas/showthread.php?tid=2285 or > http://www.hdd-player.de/syabas/showthread.php?tid=3353 ) it works. > Maybe it would be a solution to patch the streamdev plugin in a way > that it generates a TS valid for the PCH. TS-Doctor seems to log what it had to fix. Did it give you a hint? 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 Sat, 8 Nov 2008 00:12:47 +0100, jori.hamalainen wrote > > TS-Doctor seems to log what it had to fix. Did it give you a hint? > > Actually I started fixing it what was analyzed on my previous mail, > log starts with: - Transfering this back to PCH is out to todays > tuning time so I need to test later if this fixed file works.. > > Starting at packet 1 00:00:00.000 > ERROR: For video PID 0202 00E2: Wrong PSCPrefix (...) > ERROR: For audio PID 0289 2002: Wrong PSCPrefix It seems that those messages refer to the very beginning of the stream only. I assume PSCPrefix is the PES PACKET_START_CODE_PREFIX. Maybe the PSCPrefix message is logged for incomplete PES packets at the beginning of the stream. > --- PMT 0 --- > Packet : 2347 Apparently TS packet 2347 is the first with the PMT. So it might also be possible that TS-doctor complains about PES packets of yet "unknown" PIDs, as no PMT has been transmitted yet. > --- 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? Otherwise I don't see any major difference from the output of TS-doctor. Sorry, I'm a little bit lost here. > What I can tell this just deletes two subtitle PIDS (swe and fin) Maybe streamdevs cStreamdevPatFilter::GetPid() filtered too much. Could you recompile streamdev with debug output enabled: cd STREAMDEV_SRC_DIR; make clean; DEBUG=1 make all Plese post the debug output (sent to stderr) as well as the messages from the log. 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, 12 Nov 2008 15:23:40 +0100, jori.hamalainen wrote > >> So could streamdev be easily modified to provide PMT at stream start? > > > 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. > > Thanks - I patched my streamdev with that patch and I'll test it > after I get access to my PCH.. > > I hope when PCH finds PAT has some patience to read stream for particular > PMT. Revised the patch in the bugtracker. It guarantees that the first packet is PAT, second is PMT. Untested however. 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 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=1696&pid=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 Thu, 13 Nov 2008 09:39:18 +0100, dplu wrote > There was also something strange on streaming, even if I choose the > audio track with the plus argument, the both audio track are > available from popcorn. It should not if I understand well how > streamdev push the stream .. isn't it ? In HTTP TS streaming mode current streamdev will always stream all PIDs according to PMT regardless of the selected audio track. The audio track selection would only apply to input devices which do not provide sections. Regards, 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 13:32:14 +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. Glad to here that :) > Note - some errors on stream now.. Is this because streams (PIDs) > are recognized because PAT/PMT is ok, and the first data is received > starting in the middle of GOP? Definitely. In TS mode streamdev simply forward all TS packets without looking into them (except for PAT/PMT of course). So there will be incomplete PES packets in the beginning and video will usually start right in the middle of a GOP. 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 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 Fri, 14 Nov 2008 11:12:38 +0100, jori.hamalainen wrote > > A hexdump of the first few packets from both, the original and the fixed > stream, would be fine. > > Ok, here is plain hexdump. If dvbsnoop is needed, just ask.. :) The PMT was broken. Uploaded patch v4. 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 Fri, 14 Nov 2008 14:42:10 +0100, jori.hamalainen wrote > > The PMT was broken. Uploaded patch v4. > > I updated the patch - and here is output via mplayer (3 fails to > stream - one success). I changed this to HTML format so I can > highlight some lines.. So almost with every run the streamdev is > returning different PAT/PMT or whatever.. These are ran in a line, > no pause after SIGINT (^C) was given. Maybe PAT/PMT still isn't correct. Output of TS-Doctor plus hexdump of original and fixed stream would be better. Sorry - I cannot test myself here. 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] vdr-1.7.1 video stream format
On Mon, 24 Nov 2008 17:42:28 +0100, Stefan Lucke wrote
> On Monday 24 November 2008, Frank Schmirler wrote:
> > 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.
>
> Thanks,
>
> but things went worse with that on my system:
> audio disappeared and nothing more to dump in PlayVideo() :-( .
Problem seems to be that my patch fixes the generator, but the same mistake is
made while parsing the TS packet. I attached an extended patch which fixes
parsing, too.
According to the dumps you sent me (thanks!), vdr-1.7.1 cPatPmtGenerator *is*
broken.
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;
--- remux.h.orig 2008-11-25 09:48:58.0 +0100
+++ remux.h 2008-11-25 10:05:41.0 +0100
@@ -114,7 +114,8 @@
inline int TsPayloadOffset(const uchar *p)
{
- return (p[3] & TS_ADAPT_FIELD_EXISTS) ? p[4] + 5 : 4;
+ int o = (p[3] & TS_ADAPT_FIELD_EXISTS) ? p[4] + 5 : 4;
+ return TsPayloadStart(p) ? o + p[o] + 1 : o;
}
inline int TsGetPayload(const uchar **p)
___
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=thread&topic_id=33621&forum=10&post_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] xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !
On Tue, 25 Nov 2008 20:30:59 +0200, Ville Skyttä wrote > On Tuesday 25 November 2008, Frank Schmirler wrote: > > > 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. > > Hmm, any particular reason why you need to do that? Recent em8300 > driver versions should be able to load the microcode on demand, and > vdr-dxr3 tries to load it at startup and in various other scenarios > "manually" anyway. Yes, you're right. The manual upload was necessary when I started back in 2005. In the meantime the firmware is loaded automatically along with the dxr3 module. But anyway: it takes a few seconds until the dxr3 is ready. It's a pitty that the dxr3 doesn't survive suspending. 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 Wed, 26 Nov 2008 00:00:27 +0200 (EET), Mika Laitio wrote > >> 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. > > Nice... > > Are you using just a normal distro like rhat or ubuntu for > getting this fast resume and does the system survive from multiple > suspend/resumes without need for the coldboot? My production VDR client is a busybox system living on a 32 MB CF card, EPIA 6000. Kernel, busybox and VDR are selfmade, other binaries are from Debian (distro on my server). No need for reboots, no matter how often it is suspended/resumed. My new HD extension client uses the same base, but this time PXE booting and on an EPIA 1. Unfortunately I haven't been able to resurrect the HD extension after suspend/resume yet, but apart from that everything is fine. Multiple no problem with multiple suspend/resumes, no problem with PXE booting after setting the via_rhine module parameter. I'm going to switch my DXR3 client to PXE booting, soon, but I'll keep the CF card. My server isn't running 24/7 - would be idle most of the time - so my clients needs to be able to wake it up with WOL. This is no problem when I resume a client. But after a power failure, the client obviously cannot PXE boot without the server. In this case the client is going to boot off the CF card, wake up the server and reboot - now PXE is available. 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] VDR with S2API (update)
On Sun, 14 Dec 2008 09:42:40 +0100, Clemens Kirchgatterer wrote > Seppo Ingalsuo wrote: > > > > vdr in a massive client server configuration is a giant hack with > > > many pieces each with its own little problems summing up. > > > > Not giant system, but some experiences: I have one server running > > three instances of vdr. Vdr #2 and #3 are connected by streamdev to > > vdr #1 that owns dvb hardware. Timersync plugin syncronizes timers to > > vdr #1. > > yes, intelligent timer migration between vdr instances is a not trivial > task. when a timer is to be fired, you have to ask all vdr instances > its timer list and move the timer to the most suitable instance. > taking into account recordings on the same transponder to not waste > dvb devices. the same gues for finding a free dvb device for life-view. You're no longer talking about client-server here. What you have in mind is peer-to-peer. Streamdev et al. haven't been designed for this. I never looked at videgor, but AFAIK it was a peer-to-peer aproach. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
On Sun, 14 Dec 2008 16:42:21 +0100, Udo Richter 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. Remember 4 years ago: Remotetimers feature was part of streamdev by that time. The menu classes in VDR 1.3 started to change frequently and noone kept up with the necessary changes to streamdev. Personally I never missed a channel sync feature. The major channels rarely ever change. Futhermore streamdev and related plugins all use the channel ID, so no need to have the same channel numbers on client and server. Also channel updates and link channels work right out of the box. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
On Sat, 13 Dec 2008 18:52:52 +0200, Seppo Ingalsuo wrote > - The biggest annoyance: Possible to pause live TV only in vdr #1 Have you tried with the VDR patch from remotetimers-0.1.0? I never took the time to test it with timersync-plugin, but I'd be interested to see if instant recordings and pause live TV works with it, too. Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
On Sat, 13 Dec 2008 12:31:05 +0100, Udo Richter wrote > Agreed. Solutions like RemoteOSD and RemoteTiemrs are merely > workarounds. A nice solution to this integrated into VDR would > improve things a lot here. Just curious: What are you missing? > Another parameter for every timer would be a nice > solution: "Record locally" or "Record remotely" - VDR would have to > connect to a remote VDR via SVDRP to read and write these timers. Isn't that exactly what remotetimers-plugin already provides? Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
On Mon, 15 Dec 2008 21:50:45 +0200, Seppo Ingalsuo wrote > I wonder if it solves the problems when the channels are not > perfectly in sync? I have a manually sorted DVB-T channels section > but my autosort handled huge amount of DVB-S channels are usually > bit different in vdr instances due to frequent updates. I think > timersync works only when the channel numbers match. A quick glance at the timersync code reveals that indeed it uses channel numbers and not channel ids. I don't know if this is on purpose or not. If you want to give it a try: Edit timersync.c and simply replace every occurrence of "ToText()" by "ToText(true)" (about 14 times). 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] [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] [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] 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] 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
[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] 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: ... 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] 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 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
Re: [vdr] Streaming recordings
Hi, On Tue, 14 Apr 2009 18:49:06 +0100, scott wrote > Hi, I was thinking of hacking in some more support to streamdev to support > playback of recordings. Early days though. VTP seems easiest to get some > playback with the PORT and PROV commands, although SVDRP has some support > with the LSTR. Dont want to step on anyones toes, but any > thoughts/suggestions? There already is some work in progress as part of the VDR integration with XBMC (http://www.xbmc.org/trac/ticket/5595). Their streamdev patch adds a lot of VTP commands, including playback using some code taken from VOMP. Note that the patch is only for streamdev-server, the client is XBMC. If VTP based playback with streamdev-client is what you have in mind, I'm not convinced. For a full-fledged client side replay there's a lot to do: implement fast motion / trick speed and setting / moving marks to name just a few. And the server recordings will show up in a separate Recordings menu (i.e. streamdev-clients menu), or you will need to patch/replace the original VDR menu. Now compare all this to simply mounting a network share with the server side recordings... However what makes perfect sense is adding playback support to streamdev HTTP. If playback works over VTP it should be easy to get it via HTTP, too. 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] 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
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
[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] 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] [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] [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-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] 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
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
