Re: [vdr] will VDR run on this?
Al 01/08/11 10:04, En/na Steffen Barszus ha escrit: > 2011/8/1 Gerald Dachs : >>> http://www.geek.com/articles/chips/raspberry-pi-25-pc-goes-into-alpha-production-20110728/ >>> >>> Any thoughts? >> >> VDR runs just fine on a seagate dockstar, so I see no reason why it >> shouldn't run on this device, but I don't believe that it has enough power >> show the TV signal via hdmi. > > Not so sure, depending on driver availability: > http://www.mikrocontroller.net/topic/224132#2254607 > > OpenGL ES 2.0 > 1080p30 H.264 high-profile decode > > Well lets see, when it apears, if it will be available to normal > people AND if the required driver will be there too. It's broadcom, so I doubt it: the wolf may lose his teeth but never his nature. At most (if anything) we'll get a binary blob tied to a specific kernel version with no possible upgrade path. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] UK FreeviewHD and VDR
Al 12/08/11 00:09, En/na Chris Rankin ha escrit: > Could someone tell me what the "recommended" approach is for parsing a > Huffman-compressed EPG with VDR please? I suspect that I can integrate this > patch into VDR manually, but this isn't a viable long-term solution. You can use the eepg plug-in: http://linuxtv.org/vdrwiki/index.php/Eepg-plugin Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.21
Al 04/09/11 15:42, En/na Klaus Schmidinger ha escrit: > - The subtitle PIDs are now stored in the channels.conf file as an extension > to the > TPID field (thanks to Rolf Ahrenberg). When I start a recording on a satellite that's not the one the dish is pointing at, when it finally reaches the position the recording will have no subtitles. It also happens in live view, but then I can switch transponder and switch it back to get the subtitles. Does this modification fix the issue? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.21
Al 04/09/11 16:41, En/na Klaus Schmidinger ha escrit: >> Does this modification fix the issue? > > It might - there's one way to find out ;-) Well, I'm getting old, so I try the "latest and greatest" only if it's strictly necessary :-D Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.21
Al 04/09/11 17:22, En/na Luca Olivetti ha escrit: > Al 04/09/11 16:41, En/na Klaus Schmidinger ha escrit: > >>> Does this modification fix the issue? >> >> It might - there's one way to find out ;-) > > Well, I'm getting old, so I try the "latest and greatest" only if > it's strictly necessary :-D Ok, I couldn't resist and I tried. I don't know if it solves the issue because now the subtitles are "whacky": they only appear from time to time and they're in the middle of the screen, both with my trusty dxr3 and with the xine plugin (in the latter case it happens both with sd and hd channels). Oh well, back to vdr-1.7.16 until I can investigate what's wrong :-( Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.21
Al 04/09/11 23:05, En/na Klaus Schmidinger ha escrit: >> Ok, I couldn't resist and I tried. I don't know if it solves the issue >> because now the subtitles are "whacky": they only appear from time to >> time and they're in the middle of the screen, both with my trusty dxr3 and >> with the xine plugin (in the latter case it happens both with sd and hd >> channels). >> Oh well, back to vdr-1.7.16 until I can investigate what's wrong :-( > > I tested this with several old recordings and also live (in HD) > and the subtitles always worked just fine. > I'm using a TT-S2 6400 as output device, if that matters. Well, I disabled the scaling/offset (in cDvbSubtitleConverter::SetOsdData) and the subtitles now work fine, both with the dxr3 and xine, in sd and hd (of course the latter only with xine). I have to say that with this version of vdr the subtitles are recorded even if the dish is not positioned at the start of the recording. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.21
Al 04/09/11 23:53, En/na Luca Olivetti ha escrit: > Al 04/09/11 23:05, En/na Klaus Schmidinger ha escrit: > >>> Ok, I couldn't resist and I tried. I don't know if it solves the issue >>> because now the subtitles are "whacky": they only appear from time to >>> time and they're in the middle of the screen, both with my trusty dxr3 and >>> with the xine plugin (in the latter case it happens both with sd and hd >>> channels). >>> Oh well, back to vdr-1.7.16 until I can investigate what's wrong :-( >> >> I tested this with several old recordings and also live (in HD) >> and the subtitles always worked just fine. >> I'm using a TT-S2 6400 as output device, if that matters. > > Well, I disabled the scaling/offset (in cDvbSubtitleConverter::SetOsdData) It still works better with the above "fix", but maybe there's a typo in there: shouldn't osdFactorX = VideoAspect * OsdHeight / displayWidth; be instead osdFactorX = VideoAspect * OsdHeight / displayHeight; ? -- Bye ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.21
Al 05/09/11 18:15, En/na Klaus Schmidinger ha escrit: > On 05.09.2011 00:08, Luca Olivetti wrote: >> Al 04/09/11 23:53, En/na Luca Olivetti ha escrit: >>> Al 04/09/11 23:05, En/na Klaus Schmidinger ha escrit: >>> >>>>> Ok, I couldn't resist and I tried. I don't know if it solves the issue >>>>> because now the subtitles are "whacky": they only appear from time to >>>>> time and they're in the middle of the screen, both with my trusty dxr3 and >>>>> with the xine plugin (in the latter case it happens both with sd and hd >>>>> channels). >>>>> Oh well, back to vdr-1.7.16 until I can investigate what's wrong :-( >>>> >>>> I tested this with several old recordings and also live (in HD) >>>> and the subtitles always worked just fine. >>>> I'm using a TT-S2 6400 as output device, if that matters. >>> >>> Well, I disabled the scaling/offset (in cDvbSubtitleConverter::SetOsdData) >> >> It still works better with the above "fix", but maybe there's a typo in >> there: >> >> shouldn't >> >> osdFactorX = VideoAspect * OsdHeight / displayWidth; >> >> be instead >> >> osdFactorX = VideoAspect * OsdHeight / displayHeight; > > I don't think so. > > 'VideoAspect * OsdHeight' is the width of a full screen subtitle display, > using the entire OSD height, according to the aspect ratio of the video > material. Dividing this by displayWidth (i.e. the actual width of the > subtitle display) results in the osdFactorX, which is used to convert > coordinates in the subtitle display to the OSD coordinate system. Ok, I got confused, but why do you use VideoAspect * OsdHeight instead of OsdWidth? Most probably the problem is caused because the dxr3 plugin doesn't implement the GetOsdSize and GetVideoSize method, but the xine plugin does implement them. Anyway, since the cDevice::GetVideoSize returns 0 if not overridden, I put a check VideoWidth == 0 in SetOsdData. > Can you provide me with some sample recording that demonstrates the > problem you are seeing? I think you can check by yourself: I tested with the bbc channels at 28.2E. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.21
Al 05/09/11 19:43, En/na Luca Olivetti ha escrit: > Ok, I got confused, but why do you use VideoAspect * OsdHeight instead of > OsdWidth? > Most probably the problem is caused because the dxr3 plugin doesn't implement > the GetOsdSize and GetVideoSize method, but the xine plugin does implement > them. Ok, I had to setup the osd extents in xine to 1920x1080 to fix the issue. > Anyway, since the cDevice::GetVideoSize returns 0 if not overridden, I put a > check > VideoWidth == 0 in SetOsdData. I think this is still needed for output plugins that don't implement the method, so that they should at least work as before this modification. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.21
Al 09/09/11 16:54, En/na Klaus Schmidinger ha escrit:
>> I think this is still needed for output plugins that don't implement the
>> method,
>> so that they should at least work as before this modification.
>
> Can you please point out exactly which modificaton you are
> referring to?
I'm referring to the modification that changed GetVideoSize
from being purely informational to being used for something.
In case you're interested, with the patch below, output plugins that
don't implement GetVideoSize will have the subtitles working as
before. I know that the proper fix is to implement GetVideoSize
and GetOsdSize (I actually did afterwards), but at least it doesn't
break what was working before.
--- dvbsubtitle.c.orig 2011-09-04 19:11:12.426133000 +0200
+++ dvbsubtitle.c 2011-09-09 19:27:46.064725000 +0200
@@ -887,7 +887,7 @@
double VideoAspect;
cDevice::PrimaryDevice()->GetOsdSize(OsdWidth, OsdHeight, OsdAspect);
cDevice::PrimaryDevice()->GetVideoSize(VideoWidth, VideoHeight, VideoAspect);
- if (OsdWidth == displayWidth && OsdHeight == displayHeight) {
+ if ((OsdWidth == displayWidth && OsdHeight == displayHeight) || VideoWidth
== 0) {
osdFactorX = osdFactorY = 1.0;
osdDeltaX = osdDeltaY = 0;
}
Bye
--
Luca
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.21
Al 09/09/11 21:19, En/na Reinhard Nissl ha escrit: > No matter which OSD size I setup in vdr-xine (e. g. 720x576, 1280x720 or > 1920x1080), the subtitles are never positioned correctly and vdr-xine > complains very often like that: > > vdr-xine: new OSD(-152, 0) requested with coordinates out of range Reinhard, I'm using vdr-xine-0.9.3, and after setting the osd to 1920x1080, the subtitles are positioned correctly, at least on the bbc channels on 28.2E, both hd and sd. Previously I had the osd set to 640x480 (IIRC) and either the subtitles didn't show or they were at the left of the screen, vertically in the middle. The "normal" osd on 4:3 channels is compressed horizontally (it still covers the whole width of the screen but the characters are narrow), but the subtitles are fine. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Undetected channels on transponders switching from DVB-S to DVB-S2
Al 11/09/11 13:49, En/na Udo Richter ha escrit: > Am 11.09.2011 11:37, schrieb Henning Pingel: >> And this tackles another small problem: I think that VDR doesn't delete >> any channels from the channels.conf in any case. So outdated channels >> have to be removed manually. Has there been an attempt to offer a >> functionality that VDR makes a note of those channels that get the line >> "frontend timed out while tuning to channel X" in the syslog and offers >> those channels for manual deletion via the OSD in a special OSD page >> called "Outdated channels"? > > > There's currently no 'official' method to track down channels that are no > longer announced. There's a trick however: Modify your channels.conf so that > all channel names start with [outdated], then start VDR and wait for a full > transponder scan to finish. All existing channels will be renamed back to > their proper names, and all remaining [outdated] channels can be dropped > after some grace period. My actuator plugin has menu options to mark, unmark and delete marked channels. The idea is, you mark the channels, do a complete satellite scan, then delete the (still) marked channels. Even if I wrote that specifically to get rid of obsolete channels, I never use it, because there are some channels that are not advertised in the nit. As a result I now have a channel.conf with more that 7000 channels and most of the entries are rubbish. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Undetected channels on transponders switching from DVB-S to DVB-S2
Al 13/09/11 11:09, En/na Henning Pingel ha escrit: > Can actuator be used by people without a "motor" behind their dish? Yes, with the -s option it will just offer the channel scanning functionality. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] IS there a working UPnP-AV/DLNA support for VDR?
Al 10/02/12 18:07, En/na Pim Zandbergen ha escrit: > I suppose you could use mediatomb with vdrnfofs to share your recordings. Or hack the TV to simply nfs mount the directory with the recordings Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Updating actuator plugin
Al 26/03/12 18:56, En/na YUP ha escrit: > Luca, > It is just to remind you that vdr is updated (1.7.27 is now), and that > impossible to compile actuator plugin against new vdr. I do like your plugin, > it very useful for channel's scanning. It is better than other scanner > pluging I tried. Pls, find some time! ;-) I'm really sorry, but I have even less time now :-( I think I won't have time to touch this at least until summer. Bye > Regards, > > Yarema > > 17 січня 2012 р. 13:28 Luca Olivetti <mailto:l...@ventoso.org>> написав: > > Al 17/01/12 00:39, En/na YUP ha escrit: > > Hi Luca, > > > > Maybe it is a right time to update your actuator plugin. There are some > changes in vdr-1.7.23, it is enough to change SystemValues to > SystemValuesSat to compile vdr-actuator against the last vdr-1.7.23, or > simply: > > sed -i -e "s/SystemValues/SystemValuesSat/" actuator.c > > I'm still using 1.7.21, not much time to upgrade vdr right now. > > Bye > -- > Luca > > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Updating actuator plugin
Al 27/03/2012 15:29, En/na YUP ha escrit: I managed to build actuator plugin. As it was stated by Klaus, "Any plugins that implement cStatus::ChannelSwitch() need to add the parameter 'bool LiveView' to that function." So it is enough to add "bool LiveView" , for details please see my PKGBUILD https://aur.archlinux.org/packages.php?ID=42711. Cool!, I hope to remember it when I'll have the time to update the plugin. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Updating actuator plugin
Al 27/03/12 16:35, En/na Dominic Evans ha escrit: > Ah I realise now that someone sent me the rotorng sources rather than > the actuator plugin. > > Which is the superior of these two? They're different: "actuator" controls an "old style" 36V actuator, using a relay board connected to the parallel port, while "rotor" drives a diseqc motor. "actuator" can also be used as a stand-alone channel scanner (with no motor at all), I think that "rotorng" can do the same. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFE: Make VDR more friendly when using combinations of DVB-S, DVB-T and DVB-C
Al 17/06/12 12:50, En/na Klaus Schmidinger ha escrit: > Well, first of all: there will be no SQL dependency in the core VDR ;-) That's a pity, because channels.conf would be a perfect candidate for being an sqlite table. (Note that I said "sqlite", not "sql", but since sqlite uses sql it would allow for the more adventurous to substitute it for an heavy-weight database like postgresql or mysql). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Al 30/12/12 01:08, En/na Christopher Reimer ha escrit: > > I don't consider the mailinglist as "central spot of developement". > Here I'm forced to speak English. Almost all VDR Users are German. And > in VDR-Portal I reach the critical mass. With the addition that I am > allowed to speak my native language. Oh, if vdr is only intended for german speaking users, is there a good alternative for the rest of us? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Call for translations for VDR version 2.0.0: one more string needed
Al 04/03/13 15:30, En/na Klaus Schmidinger ha escrit: > While implementing an option to turn on/off sorting folders first in the > Recordings > menu, one more string was necessary and needs to be translated: > > "Always sort folders first" es_ES "Siempre ordenar primero carpetas" ca_ES "Sempre ordenar primer carpetes" Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 21/04/13 14:54, En/na Klaus Schmidinger ha escrit: > I'm currently implementing support for steerable dishes, loosely based > on https://linuxtv.org/patch/12911. In doing so, I'm defining a virtual > base class cPositioner, which defines all the functions necessary to > control the positioner. Is there a preview of the API to comment on? At the very least it should have a "GotoSource" method an "IsPositionedAt" method and something to give visual feedback while the dish is moving, but then my views may be biased by my own implementation. > The question I have now is: will it be enough to have *one* single > positioner > in any given setup, or are there actually users who have more than one > positioner? > Supporting only a single positioner (as is done in the aforementioned > patch) > of course simplifies things quite a bit. So I wouldn't want to add this > level of complexity unless there is a real need for it. Personally I have just one positioner, so my plugin only allows one instance (even worse, my kernel driver only allows one device). I think there are no more than 3 users of the plugin (including myself), so that's not a statistically relevant sample, sorry. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 21/04/13 15:52, En/na Klaus Schmidinger ha escrit: > > Any visual feedback will be done via the channel display of the skin, by > comparing > CurrentLongitude() to TargetLongitude(). And of course any section > filtering will > start only after the target position has been reached. Mmh, how will the system decide between "GotoAngle" and "GotoPosition"? I have a linear actuator and I can only work with pulses. While in theory calculating the angle is possible, it'd be difficult to do and it will vary based on the geometry of the mount. Also, I don't like the use of "Number" in StorePosition, mainly because I've been using Source up until now, but I guess I can live with that. >From the complete interface it seems that everything regarding positioning will be managed by vdr itself, so the main screen of my plugin[*] will be made redundant (good! I'm lazy), one thing I see missing is some way to show error conditions (I have "Limit reached" and "Motor error", which means the motor isn't moving even if it should). [*] http://ventoso.org/luca/vdr/screenshot.jpg Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 21/04/13 20:17, En/na Luca Olivetti ha escrit: > Al 21/04/13 15:52, En/na Klaus Schmidinger ha escrit: > >> >> Any visual feedback will be done via the channel display of the skin, by >> comparing >> CurrentLongitude() to TargetLongitude(). And of course any section >> filtering will >> start only after the target position has been reached. > > Mmh, how will the system decide between "GotoAngle" and "GotoPosition"? > I have a linear actuator and I can only work with pulses. While in > theory calculating the angle is possible, it'd be difficult to do and it > will vary based on the geometry of the mount. > Also, I don't like the use of "Number" in StorePosition, mainly because > I've been using Source up until now, but I guess I can live with that. > From the complete interface it seems that everything regarding > positioning will be managed by vdr itself, so the main screen of my > plugin[*] will be made redundant (good! I'm lazy), one thing I see > missing is some way to show error conditions (I have "Limit reached" and > "Motor error", which means the motor isn't moving even if it should). FYI, I use these states in the driver, shown here with the corresponding message in the plugin: ACM_IDLE (no message since it's doing nothing) ACM_WEST, ACM_EAST "Dish target %d, position %d" ACM_REACHED "Position reached" ACM_STOPPED, ACM_CHANGE "Motor wait" ACM_ERROR "Motor error" Limit control is not done by the driver but by the plugin, and the messages are "Dish at limits" (in manual mode) "Position outside limits" (in positioning mode) There's also a "Position not set" if the new channel is in it's in a source that's not been memorized (I'm currently implementing a cStatus to detect channel switch). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 21/04/13 15:52, En/na Klaus Schmidinger ha escrit:
One more observation
> virtual void StepEast(void) {}
> ///< Move the dish one step to the east.
> virtual void StepWest(void) {}
> ///< Move the dish one step to the west.
I'd suggest a parameter with the number of steps to move (and for "step"
I mean a "pulse", not the next/previous stored satellite position).
Bye
--
Luca
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 21/04/13 20:36, En/na Luca Olivetti ha escrit:
> Al 21/04/13 15:52, En/na Klaus Schmidinger ha escrit:
>
> One more observation
>
>> virtual void StepEast(void) {}
>> ///< Move the dish one step to the east.
>> virtual void StepWest(void) {}
>> ///< Move the dish one step to the west.
>
> I'd suggest a parameter with the number of steps to move (and for "step"
> I mean a "pulse", not the next/previous stored satellite position).
And, I hope, the last one:
virtual void Recalc(int Number)
///http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 22/04/13 11:12, En/na Klaus Schmidinger ha escrit: >> virtual void Recalc(int Number) >>///> Number >>/// > What would this actually be good for? Imagine that the dish moved but the counter didn't work, or simply there's some slack accumulated, so the actual position and the registered position differ. Without this method you should store each of the already stored position, with a Recalc method, positioning to one know good satellite would be enough, since the relatives positions would still be good. Actually, the description is wrong, as the effect would be "You, positioner, now are at this position", so it would be something like "Set as your current position the position specified by Number" (or longitude if you prefer) So maybe it should be better called "SetCurrentPosition" Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 22/04/13 11:11, En/na Klaus Schmidinger ha escrit: >> I'd suggest a parameter with the number of steps to move (and for "step" >> I mean a "pulse", not the next/previous stored satellite position). > > I don't see the need for a "number of steps". Well, I use it from time to time. Say I move step by step to the west and, after e.g. 5 steps, I discover the signal is getting worse. Instead of hitting 5 times StepEast, I position over the "x steps east" soft button, push 5 on the remote, push ok and I'm at the starting position. Better yet, I move 10 steps east at once to try if going to the other side improves things or not. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 22/04/13 14:28, En/na Klaus Schmidinger ha escrit:
> So what do you folks think?
I don't have any preference wrt Left/Right East/West.
My last (and only) set top box with integrated positioner was analogue
and used East/West, but I don't remember if it had any provision for the
southern hemisphere (I suppose you could just reverse the polarity of
the motor). Hey, it also had skew control :-)
But..
> virtual void Drive(bool Left) {}// true = left, false = right
> virtual void Step(int Steps) {} // <0 = left, >0 = right
> virtual void SetLimit(bool Left) {} // true = left, false = right
I do like this one (less cluttered interface)
Bye
--
Luca
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 23/04/13 12:41, En/na Klaus Schmidinger ha escrit: >> >> So maybe it should be better called "SetCurrentPosition" > > The specs on the 0x6F command are a little vague. > What do you suggest should be sent to a DiSEqC rotor? > Something like > > 6F nn 00 00 > > where 'nn' is the number of the satellite position the dish currently > actually points to? I have no idea about DiSEqC rotors, sorry, I just drive a couple of relays and count the pulses myself (well, actually my device driver/plugin) but it seems such a basic functionality to me that I'd be surprised if it isn't there. A google search found this http://www.dvbviewer.tv/forum/topic/46086-positioner-console-re-calculate-command/ Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Which DVB-S / DVB-S2 cards are recommended?
El 12/08/15 a les 09:28, jori.hamalai...@teliasonera.com ha escrit: I abandoned VDR after 11 years of running it for Duo2+OpenVix. Sorry for the off-topic, but my google-fu is failing: where could I find instructions on how to build openvix from sources? I see they're on github, but they have several repositories and I could not find instructions, and I'd need to modify something in the enigma c++ files to support my positioner (probably I just need to compile the enigma binary, but I'm not sure yet). The various boxes running openvix (and other enigma images) seem to be very cheap and convenient (small size, low power, etc.), if they also have good tuners they could be a good replacement for my ageing vdr computer. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Which DVB-S / DVB-S2 cards are recommended?
El 02/10/15 a les 02:14, Ralph Metzler ha escrit: Yes, build instructions are hard to find. After some trial and error I am doing it like this: git clone https://github.com/oe-alliance/build-enviroment.git cd build-enviroment make MACHINE=vuduo2 DISTRO=openvix DISTRO_TYPE=release make image Thank you! I suppose that will build a (more or less) "official" image. Is there a mailing list (not a shady web forum) where one can ask questions about it and how to incorporate custom changes/patches/etc.? I don't want to abuse this list too much ;-) Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] diseqc usals communication protocol
Hello, In cDiseqcPositioner the last nibble (corresponding to the first decimal) of the angle is calculated as a % 10 * 16 / 10 With, e.g. angle -123 (-12.3) the resulting diseqc command would be 6e e0 c4 (i.e. the last nibble is 4 to represent 0.3). OTOH the enigma2 implementation uses a lookup table for the decimal digit: .0 -> 0x00 .1 -> 0x02 .2 -> 0x03 .3 -> 0x05 .4 -> 0x06 .5 -> 0x08 .6 -> 0x0A .7 -> 0x0B .8 -> 0x0D .9 -> 0x0E https://github.com/OpenViX/enigma2/blob/master/lib/dvb/sec.cpp#L526 so for the same angle -12.3 it would send 6e e0 c5 (at least looking at the code, I don't have an enigma 2 receiver). Since I'm implementing the receiving side and the only "reliable" documentation is either the enigma2 code or vdr, I wonder which one is correct. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] diseqc usals communication protocol
El 13/12/15 a les 17:24, sergiogo...@tostado.com.ar ha escrit: Hi Luca. Check documents from http://www.eutelsat.com/en/support/technical-support/diseqc.html Maybe you find there what you want. Thank you. I read those documents so many times but I managed to not see the table on page 12 of the "Positioner application notes" one. Duh Bye Regards El 2015-12-12 17:37, Luca Olivetti escribió: Hello, In cDiseqcPositioner the last nibble (corresponding to the first decimal) of the angle is calculated as a % 10 * 16 / 10 With, e.g. angle -123 (-12.3) the resulting diseqc command would be 6e e0 c4 (i.e. the last nibble is 4 to represent 0.3). OTOH the enigma2 implementation uses a lookup table for the decimal digit: .0 -> 0x00 .1 -> 0x02 .2 -> 0x03 .3 -> 0x05 .4 -> 0x06 .5 -> 0x08 .6 -> 0x0A .7 -> 0x0B .8 -> 0x0D .9 -> 0x0E https://github.com/OpenViX/enigma2/blob/master/lib/dvb/sec.cpp#L526 so for the same angle -12.3 it would send 6e e0 c5 (at least looking at the code, I don't have an enigma 2 receiver). Since I'm implementing the receiving side and the only "reliable" documentation is either the enigma2 code or vdr, I wonder which one is correct. Bye ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] playing VDR-recordings on Samsung Smart TV with subtitles
El 13/01/16 a les 12:00, Peter Münster ha escrit: Hi, Is is possible to play VDR-recordings on Samsung Smart TV with subtitles, and if yes, how please? It seems, that the Samsung Smart needs 2 files: an mp4 and an srt file. I've tried: "ffmpeg -i 1.ts -vn -an -codec:s:0 srt 1.srt" But no 1.srt is created... TIA for any hints, Usually the subtitles that are broadcast and recorded are images, while the srt is a text file. Since I had the same need, a long time ago I wrote a script to extract the images and apply an ocr to them in order to create the srt file http://ventoso.org/luca/vdr/vdrsubrip/ and there's a derived (and possibly better) version here https://github.com/philhansen/dvbsubrip Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Questions about good hardware to view VDR 4K
El 8/5/19 a les 19:25, Karl-Heinz Volk ha escrit: I just purchased an Amazon FireTV 4k stick and this is amazing. It is working until 2160p60 consuming 1..2 Watt using an USB power supply. Why is there no VDR for Android using network DVB sources? You can buy an android tv box and put libreelec/coreeelec/armbian on it. I have a mecool ki pro, it cost me ~60€, it has an integrated S2/T2/C tuner (though its linux driver is not as good as the android one) and I'm using it with libreelec. It's small, can decode 4k (though my display is just 1080p) and it consumes very little. Unfortunately I had to switch to tvheadend: while vdr is supplied by libreelec and it works, it has a problem with encrypted channels. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Handling of temporarily encrypted channels
En/na Ondrej Wisniewski ha escrit: I am using VDR 1.4.5 with the integrated auto pid feature and without any CAM. When tuning to an encrypted channel, the CA value gets set accordingly and "channel not available" is displayed. So far so good. However there are channels that encrypt only certain programs and are free the rest of the time. When tuning to this "free" channel while the program is encrypted, the CA value will be set and "channel not available" shown. But when tuning to the same channel again when it is not encrypted any more it seems that VDR just checks the CA value and displays "channel not available" instead of checking the currently broadcast CA value. So the channel cannot be watched even if it is free in the moment. This is quite annoying and decreases the WAF a lot :-/ Is there an easy way to fix this? Edit the file dvbdevice.c, insert a line "return true;" at the beginning of the method cDvbDevice::ProvidesCa. With this modification you can tune to encoded channels, however you'll never see a "channel not available", you'll just see a black screen. This, btw, also solves the problem of channels that declare they're scrambled when they aren't. Bye -- Luca A: Because it destroys the flow of the conversation Q: Why is it bad? A: No, it's bad. Q: Should I top post in replies to mailing lists? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Understanding how vdr's tuning algo works.
En/na Stone ha escrit: 3) Does vdr care or know anything about a rotor setup where the channel isn't always present the moment the diseqc commands are sent? Well, vdr isn't aware the dish is moving, so it doesn't wait for it. This isn't a big problem for live view, but it is a potential problem for recordings (it could cause an emergency shutdown). My stopgag measure has been to increase the timeout but only at the beginning of a recording: http://ventoso.org/luca/vdr/patches/steerable-vdr-1.3.32.diff The ideal solution would be for vdr to wait for the dish, maybe querying the plugin(s) responsible for moving it. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: Freezes with Reiserfs
En/na Patrick Cernko ha escrit: I'm using SGI's XFS for any kind of data filesystem and only use ext3 for / . So far, no problems at all. I also use XFS exclusively, but I have the "random zeroed files" when the system crashes/power goes off unexpectedly. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR: Mantis bug tracking and a forum
En/na Pasi Juppo ha escrit: Same actually goes for this mailing list. Proper forum is much more convenient than mailing list because of proper threading etc. features. Could someone be able to set up the forum and most importantly would this discussion move to the forum? I hate forums, since I have to chase messages on them, at most they send me an email message when there's a new message, and then I have to go to the forum. OTOH, with a mailing list everything is neatly ordered in my vdr folder (server side filtering takes care of that, but client side filtering can do that too) and readily available, I just have to press "N" or the "Next" button to see unread messages. As per the proper threading, any decent mail client can do it, thunderbird surely does. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr and 28.2E EPG ?
En/na kafifi ha escrit: > Hi all, > > I've just tuned my second dish on 28.2E, viewing many FTA channels. > Curiously, vdr doesn't display any EPG (just now & next information). > > Is there any special transponder I must tune to download EPG, > or SKY uses a non standard EPG ? In this case, could you give me a link ? Look at the getskyepg.pl script in the sky plugin (that comes standard with vdr) Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] anybody using the dxr3 plugin with vdr 1.5.3?
Hello, I wanted to try the development version of vdr (1.5.3) to see what's new and to keep my actuator plugin up to date. I think that the new vdr is doing funky things with the osd, since the menu is unwatchable (a lot of "dxr3: colormanager: bummer, too many sections (14), reusing last one"). OTOH the menu of my plugin displays just fine. I did not try any skin plugin yet, I loaded the bare minimum (dxr3, actuator and savechannel), so I just tested the 2 skins included in vdr (being the classic one the worst). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] anybody using the dxr3 plugin with vdr 1.5.3?
En/na Luca Olivetti ha escrit: > Hello, > I wanted to try the development version of vdr (1.5.3) to see what's new > and to keep my actuator plugin up to date. > I think that the new vdr is doing funky things with the osd, since the > menu is unwatchable (a lot of "dxr3: colormanager: bummer, too many > sections (14), reusing last one"). > OTOH the menu of my plugin displays just fine. > I did not try any skin plugin yet, I loaded the bare minimum (dxr3, > actuator and savechannel), so I just tested the 2 skins included in vdr > (being the classic one the worst). Tried skinsoppalusikka now and it seems to work fine Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] anybody using the dxr3 plugin with vdr 1.5.3?
En/na Luca Olivetti ha escrit: > En/na Luca Olivetti ha escrit: >> Hello, >> I wanted to try the development version of vdr (1.5.3) to see what's new >> and to keep my actuator plugin up to date. >> I think that the new vdr is doing funky things with the osd, since the >> menu is unwatchable (a lot of "dxr3: colormanager: bummer, too many >> sections (14), reusing last one"). >> OTOH the menu of my plugin displays just fine. >> I did not try any skin plugin yet, I loaded the bare minimum (dxr3, >> actuator and savechannel), so I just tested the 2 skins included in vdr >> (being the classic one the worst). > > Tried skinsoppalusikka now and it seems to work fine Ok, solved: disabling the antialiasing classic and sttng:panels work ok with a dxr3. Probaly antialiasing produces too many colours for the dxr3 to handle. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] anybody using the dxr3 plugin with vdr 1.5.3?
En/na Klaus Schmidinger ha escrit:
anels work ok
>> with a dxr3.
>> Probaly antialiasing produces too many colours for the dxr3 to handle.
>
> VDR's skins first check whether the OSD in use can handle 8bpp, and
> only then uses a single 256 color bitmap (with font anti-aliasing).
>
> Maybe the dxr3 plugin claims to be able to handle 8bpp, but in fact can't?
IIRC (it's been a while since I touched the dxr3 plugin) it can only
handle 2bpp, but it can also use various regions ("highlights") each
with a different palette. The plugin uses this as a trick to obtain more
apparent bpp, so it accepts 8bpp, though the number of regions depends
on the distribution of the colours, and with too many regions the dxr3
misbehaves or even completely hangs.
To simplify: it can handle 8bpp but only when there aren't too many
colours in a single line
Bye
--
Luca
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.5.4: cannot tune a transponder with actuator plugin
[sorry if this turns out to be long]
In the actuator plugin main menu, I offer the possibility to tune to a
transponder "on the fly", to either quickly see what's there or to
trigger a transponder scan.
To do that I have this piece of code that worked find under 1.4.x but
stopped working under 1.5.4:
void cMainMenuActuator::Tune(bool live)
{
int Apids[MAXAPIDS + 1] = { 0 };
int Dpids[MAXDPIDS + 1] = { 0 };
char ALangs[MAXAPIDS+1][MAXLANGCODE2]={ "" };
char DLangs[MAXDPIDS+1][MAXLANGCODE2]={ "" };
Apids[0]=menuvalue[MI_APID];
SChannel->SetPids(menuvalue[MI_VPID],0,Apids,ALangs,Dpids,DLangs,0);
SChannel->cChannel::SetSatTransponderData(curSource->Code(),menuvalue[MI_FREQUENCY],Pol,menuvalue[MI_SYMBOLRATE],FEC_AUTO);
cDevice *myDevice=cDevice::GetDevice(DvbKarte);
if (myDevice==cDevice::ActualDevice()) HasSwitched=true;
if (HasSwitched && live) {
if (cDevice::GetDevice(SChannel,0,true)==myDevice) {
cDevice::PrimaryDevice()->SwitchChannel(SChannel, HasSwitched);
return;
}
}
myDevice->SwitchChannel(SChannel, HasSwitched);
}
I.e., it creates a dummy channel with the transponder data currently on
screen and tries to tune it with the card connected to the motor,
cDevice::GetDevice(DvbKarte).
Since I don't have a full-featured card, it's not the primary card, so
the line that's executed is the last one.
Putting some printf here and there, it seems that's ultimately calling
cDevice::SetChannelDevice instead of cDvbDevice::SetChannelDevice, and I
don't understand why, since DvbKarte is 0 (the first and only card,
which should be a cDvbDevice).
What should I do to adapt to the new vdr?
(BTW, I noticed that also the LoadEpg plugin stopped working, for a
similar, but not exactly the same, reason: it switches for a split
second to the channel with the epg data, then goes back to the previous
one, so it doesn't get any data).
I suppose that I could just use
cDevice::PrimaryDevice()->SwitchChannel[*], but then I couldn't be sure
that the transponder will be definitely tuned by the desired card (it
would be in my case, but it wouldn't when there's more than a dvb-s card).
[*]actually, I tried, but then my pat and sdt filters didn't work, but
that's a different matter ;-)
Bye
--
Luca
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.5.4: cannot tune a transponder with actuator plugin
En/na Klaus Schmidinger ha escrit: >> Putting some printf here and there, it seems that's ultimately calling >> cDevice::SetChannelDevice instead of cDvbDevice::SetChannelDevice, and I >> don't understand why, since DvbKarte is 0 (the first and only card, >> which should be a cDvbDevice). > > Are you sure that your DVB card is device number 0? > Maybe the device you use for replaying (a software player?) > is device 0? Well, it turns out you're right, the primary (dxr3) device is 0, the dvb card is 1 and another software player (xine-plugin) is 2. I though that dvb devices always cought the lowest numbers, then the plugins would start from there. If I use CardIndex does it always correspond to the dvb device number? i.e. /dev/dvb/adapter0 -> CardIndex =0 ? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-actuator-1.0.4 plugin
Hello, I'm releasing version 1.0.4 of the "actuator" plugin available at http://www.ventoso.org/luca/vdr/ This plugin controls a linear actuator (or an horizon to horizon one) through the parallel port with a simple circuit. CHANGES: - check the CardIndex to identify the selected card in the main menu instead of relying on cDevice::GetDevice(index) - added a note in README to clarify that if you select card 1 it corresponds to /dev/dvb/adapter0, 2 to /dev/dvb/adapter1 and so on - adapted for the experimental version of vdr (1.5.X) Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.5: segfault in fontconfig
En/na Stefan Huelswitt ha escrit: > Hi, > trying to upgrade to 1.5.5 I'm facing the problem that VDR > segfaults right on startup (no plugins envolved). First step is to check if you have some tt font installed. Then check /etc/fonts/fonts.conf (and subdirectories in /etc/fonts) to see if "Sans Serif" points to an existing font (it usually point to Vera Sans or DejaVu, so you should have that font installed). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-actuator-1.0.4 plugin
En/na Luca Olivetti ha escrit: > Hello, > > I'm releasing version 1.0.4 of the "actuator" plugin available at > > http://www.ventoso.org/luca/vdr/ I realized that, since I upgraded my kernel, I inadvertently released the tarball with module.c already patched with the "apply_for_kernel_2.6.15.patch", so if you run an older kernel you should patch it with -r (then eventually apply "apply_for_kernel_2.6.13.patch"), while if you're running a kernel >= 2.6.15 just user module.c as is. Sorry for any inconvenience this may have caused. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-actuator-1.0.4 plugin
En/na Luca Olivetti ha escrit: > I realized that, since I upgraded my kernel, I inadvertently released > the tarball with module.c already patched with the > "apply_for_kernel_2.6.15.patch", so if you run an older kernel you > should patch it with -r (then eventually apply > "apply_for_kernel_2.6.13.patch"), while if you're running a kernel >= > 2.6.15 just user module.c as is. > Sorry for any inconvenience this may have caused. Not my day, that should be "-R" not "-r". Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-ttxtsubs in vdr developer versions?
En/na Magnus Andersson ha escrit: > ttxtsubsdisplay.c: In member function ‘void cTtxtSubsDisplay::ShowOSD()’: > ttxtsubsdisplay.c:415: error: ‘SetCode’ is not a member of ‘cFont’ > ttxtsubsdisplay.c:415: error: ‘I18nCharSets’ was not declared in this scope > ttxtsubsdisplay.c:438: error: ‘SetCode’ is not a member of ‘cFont’ > ttxtsubsdisplay.c:463: error: ‘SetCode’ is not a member of ‘cFont’ I just commented out these lines and it seems to work (though lately I'm not using it very much). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Premiere UTF-8 fix for VDR 1.5.1+
En/na Klaus Schmidinger ha escrit: > Well, this might cause problems on channels that do adhere to the > standard and actually broadcast their EPG data in ISO6937. > > Maybe somebody should call Premiere and complain to them. After all, > it's them who are not following the standard ;-) Unfortunately they're not the only one :-( Bye ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] No signal - Dish seems fine - femon output follow
En/na Peer Oliver Schmidt ha escrit: > Hello, > > after my vacation I no longer have any reception. [...] Just a wild guess, but if you usually leave your vdr pc switched on, leaving it off for a while could make it not work right when turned back on (usually capacitors are to blame). Maybe a capacitor in the power supply or the mainboard is faulty and it doesn't give enough juice to your cards to supply the lnbs. I repeat that's just a guess, so it may be totally unrelated to your actual problem. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] No signal - Dish seems fine - femon output follow
En/na VDR User ha escrit: > On 7/5/07, Luca Olivetti <[EMAIL PROTECTED]> wrote: >> Just a wild guess, but if you usually leave your vdr pc switched on, >> leaving it off for a while could make it not work right when turned back >> on (usually capacitors are to blame). > > Where did you hear this? 100% incorrect. It actually happened to me, twice: an old pace mss1000, unplugged while on holiday, didn't turn on when I came back, I had to recap the power supply. One year later the same happened to the tv (this time it was just one capacitor in the power supply). Oh, and bad capacitors is a known a plague in many motherboards (yes, I have one that failed due to bad capacitors, you can see those for the leaked electrolyte or the bulged top, and even my current vdr machine needed a replacement capacitor). Bye. -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] No signal - Dish seems fine - femon output follow
En/na VDR User ha escrit: > Yeah, I know how to tell if a capacitor is bad, went to college for > electronic engineering. In all my years of working with electronics I > have never seen a capacitor blow because a device was left on for a > long period of time and then turned off. Yes, those were two unrelated problem, and, no, a capacitor won't blow, but as it degrades (due to excessive heat, bad quality or simply a borderline design), it will go on working while the equipment is switched on, but if you turn it off it won't work when you switch it back on. >I'd recommend buying better > equipment if you're having a problem with (cheap) parts failing. Well, usually you don't have a choice on the components used, only on the final product, and the problem with bad capacitors in motherboards is spread among many top tier vendors, so it's not a problem of cheap components. Besides, there are no-name capacitors sold as brand name ones. And even expensive products eventually fail. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbtextsubs 0.2
En/na listnisse ha escrit: > Hi all, > > > > I have searched the internet (including archive.org) for > dvbtextsubs-0.2.tar.gz but haven’t found it. I would really appreciate > if some friendly soul on this list would like to send me the file or > point me to a location. maybe you're looking for ttxtsubs? http://www.linuxtv.org/vdrwiki/index.php/Ttxtsubs-plugin (the "patches" link is really needed). or subtitles? http://www.linuxtv.org/vdrwiki/index.php/Subtitles-plugin Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.6
En/na Klaus Schmidinger ha escrit: > VDR developer version 1.5.6 is now available at With this version display of national character broke here, e.g. "WDR münster" changed to "WDR mnster" (not only in the channels name, also in the epg for wdr, zdf, das erste ). I reverted these two fixes in tools.c: > - Fixed a buffer overflow in initializing the system character table (thanks > to Marco Schlüßler). [...] > - Fixed handling single byte characters >0x7F in Utf8ToArray() (thanks to Udo > Richter). with no result. Not that I understand german anyway, but I don't like the look of the channel list with all those squares ;-) Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Announce LoadEPG 0.1.11
En/na lukkinosat ha escrit:
Hello
On site http://www.kikko77.altervista.org/ in the
section download, is available the new version of
LoadEPG.
History:
2007-07-26: Version 0.1.11
- Fixed for new format epg of Digital+ (S19.2E Spain)
Since vdr 1.5.x changed the numbering of the cards if there are
softdevices, I changed it to look for the card using the CardIndex
(patch attached, in case you want to take a look), but it doesn't work
anyway: it switches to the transponder with the epg, then it switches
back instantly to the previous one, so it obviously doesn't get any data.
If I change the function cLoadepgOsd::SwitchToEpgChannel (and only that
function) to use cDevice::PrimaryDevice() to do the switching then
everything works as expected (well, special characters show up as little
squares in accents in the epg, but I'll look into that).
Bye
--
Luca
diff --unified --recursive --exclude='*.o' --exclude='*~' loadepg-0.1.11.orig/loadepg.c loadepg-0.1.11/loadepg.c
--- loadepg-0.1.11.orig/loadepg.c 2007-07-26 18:32:05.0 +0200
+++ loadepg-0.1.11/loadepg.c 2007-07-26 19:55:16.36301 +0200
@@ -936,6 +936,10 @@
Timeout = 0;
LoadepgConfig.OldUpdateChannels = Setup.UpdateChannels;
Setup.UpdateChannels = 0;
+EpgDevice=NULL;
+for (int i=0; iCardIndex()==LoadepgConfig.DeviceNumber -1)
+EpgDevice=cDevice::GetDevice(i);
}
cLoadepgOsd::~cLoadepgOsd( void )
@@ -947,7 +951,7 @@
Setup.UpdateChannels = LoadepgConfig.OldUpdateChannels;
if( Filter )
{
-cDevice::GetDevice( LoadepgConfig.DeviceNumber - 1 )->Detach( Filter );
+EpgDevice->Detach( Filter );
delete Filter;
}
if( Osd )
@@ -967,7 +971,7 @@
if( SwitchToEpgChannel() )
{
Filter = new cLoadepgFilter();
- cDevice::GetDevice( LoadepgConfig.DeviceNumber - 1 )->AttachFilter( Filter );
+ EpgDevice->AttachFilter( Filter );
}
else
{
@@ -1009,6 +1013,7 @@
void cLoadepgOsd::Show( void )
{
+if ( EpgDevice == NULL) return;
Osd = cOsdProvider::NewOsd( 160, 88 );
if( Osd )
{
@@ -1026,7 +1031,8 @@
bool cLoadepgOsd::SaveOldChannel( void )
{
-OldChannel = Channels.GetByNumber( cDevice::GetDevice( LoadepgConfig.DeviceNumber - 1 )->CurrentChannel() );
+if (EpgDevice == NULL) return false;
+OldChannel = Channels.GetByNumber( EpgDevice->CurrentChannel() );
if( OldChannel )
{
return true;
@@ -1038,7 +1044,7 @@
{
if( OldChannel )
{
- cDevice::GetDevice( LoadepgConfig.DeviceNumber - 1 )->SwitchChannel( OldChannel, true );
+ EpgDevice->SwitchChannel( OldChannel, true );
}
}
@@ -1055,9 +1061,9 @@
*EpgChannel = *OldChannel;
sscanf( EpgProviderValue1[MenuItem], "%[^:]:%[^:]:%[^:]:%[^:]:%[^:]", ProviderName, Frequency, Polarization, SourceName, SymbolRate );
EpgChannel->cChannel::SetSatTransponderData( cSource::FromString( SourceName ), atoi( Frequency ), Polarization[0], atoi( SymbolRate ), FEC_AUTO );
- cDevice::GetDevice( LoadepgConfig.DeviceNumber - 1 )->SwitchChannel( EpgChannel, true );
+ EpgDevice->SwitchChannel( EpgChannel, true );
usleep( 200 );
- if( cDevice::GetDevice( LoadepgConfig.DeviceNumber - 1 )->HasLock() )
+ if( EpgDevice->HasLock() )
{
return true;
}
@@ -1071,6 +1077,10 @@
eOSState cLoadepgOsd::ProcessKey( eKeys Key )
{
+if (EpgDevice == NULL ) {
+ Skins.Message(mtError,tr("Card not available"));
+ return osEnd;
+}
eOSState state = cOsdObject::ProcessKey( Key );
StatusKey = 0;
if( state == osUnknown )
diff --unified --recursive --exclude='*.o' --exclude='*~' loadepg-0.1.11.orig/loadepg.h loadepg-0.1.11/loadepg.h
--- loadepg-0.1.11.orig/loadepg.h 2007-07-26 18:32:23.0 +0200
+++ loadepg-0.1.11/loadepg.h 2007-07-26 19:41:09.43301 +0200
@@ -380,6 +380,7 @@
cLoadepgFilter *Filter;
cChannel *OldChannel;
cChannel *EpgChannel;
+ cDevice *EpgDevice;
int Margin;
int StatusKey;
int Padding;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Announce LoadEPG 0.1.11
En/na Luca Olivetti ha escrit:
> If I change the function cLoadepgOsd::SwitchToEpgChannel (and only that
> function) to use cDevice::PrimaryDevice() to do the switching then
> everything works as expected (well, special characters show up as little
> squares in accents in the epg, but I'll look into that).
I made a crude hack: I assume that the epg is in ISO-8859-15, so if
SystemCharacterTable is different than iso-8859-15, I call iconv to
convert the file in cLoadepgOsd::SaveEpg, just before the LoadFile label:
fclose( File );
const char *syschar=cCharSetConv::SystemCharacterTable();
if (syschar==NULL || !strcasestr(syschar, "ISO-8859-15")) {
char *cmd;
asprintf(&cmd, "iconv -f ISO-8859-15 -t %s -o
\"%s.converted\" \"%s\"", syschar ? syschar : "UTF-8",FileName,FileName);
SystemExec(cmd);
free(cmd);
asprintf(&cmd, "mv \"%s.converted\" \"%s\"",
FileName,FileName);
SystemExec(cmd);
free(cmd);
}
}
LoadFile:;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Announce LoadEPG 0.1.11
En/na lukkinosat ha escrit: > --- Luca Olivetti <[EMAIL PROTECTED]> ha scritto: >> I made a crude hack: I assume that the epg is in >> ISO-8859-15, so if >> SystemCharacterTable is different than iso-8859-15, >> I call iconv to >> convert the file in cLoadepgOsd::SaveEpg, just >> before the LoadFile label: > [CUT] > > Hi > > The epg is ISO-8859-15. I must still try with vdr > version 1.5.x. Well, with the previous patch, the iconv hack and using cDevice::PrimaryDevice() to tune to the epg channel, everything is working fine here. For a more general solution I suppose I'll have to do the same I did in my actuator plugin (use cDevice::PrimaryDevice() only if the selected device is ActualDevice and provides the needed channel). I'll look into it and post a revised patch. > As soon as I can I make you to know :-) > > Do you speak italian? Yes, I do Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Announce LoadEPG 0.1.11
En/na Luca Olivetti ha escrit:
En/na lukkinosat ha escrit:
--- Luca Olivetti <[EMAIL PROTECTED]> ha scritto:
I made a crude hack: I assume that the epg is in
ISO-8859-15, so if
SystemCharacterTable is different than iso-8859-15,
I call iconv to
convert the file in cLoadepgOsd::SaveEpg, just
before the LoadFile label:
[CUT]
Hi
The epg is ISO-8859-15. I must still try with vdr
version 1.5.x.
Well, with the previous patch, the iconv hack and using
cDevice::PrimaryDevice() to tune to the epg channel, everything is
working fine here.
For a more general solution I suppose I'll have to do the same I did in
my actuator plugin (use cDevice::PrimaryDevice() only if the selected
device is ActualDevice and provides the needed channel).
I'll look into it and post a revised patch.
Here it is. It should work for 1.4.x as well as for 1.5.x (but I only
tested it with 1.5.6 and a single dvb card, so YMMV).
Bye
--
Luca
Només a loadepg-0.1.11: .dependencies
diff --unified --recursive --exclude '*.o' --exclude '*.so' loadepg-0.1.11.orig/loadepg.c loadepg-0.1.11/loadepg.c
--- loadepg-0.1.11.orig/loadepg.c 2007-07-26 18:32:05.0 +0200
+++ loadepg-0.1.11/loadepg.c 2007-07-30 14:54:09.468527000 +0200
@@ -936,6 +936,10 @@
Timeout = 0;
LoadepgConfig.OldUpdateChannels = Setup.UpdateChannels;
Setup.UpdateChannels = 0;
+EpgDevice=NULL;
+for (int i=0; iCardIndex()==LoadepgConfig.DeviceNumber -1)
+EpgDevice=cDevice::GetDevice(i);
}
cLoadepgOsd::~cLoadepgOsd( void )
@@ -947,7 +951,7 @@
Setup.UpdateChannels = LoadepgConfig.OldUpdateChannels;
if( Filter )
{
-cDevice::GetDevice( LoadepgConfig.DeviceNumber - 1 )->Detach( Filter );
+EpgDevice->Detach( Filter );
delete Filter;
}
if( Osd )
@@ -967,7 +971,7 @@
if( SwitchToEpgChannel() )
{
Filter = new cLoadepgFilter();
- cDevice::GetDevice( LoadepgConfig.DeviceNumber - 1 )->AttachFilter( Filter );
+ EpgDevice->AttachFilter( Filter );
}
else
{
@@ -1009,6 +1013,7 @@
void cLoadepgOsd::Show( void )
{
+if ( EpgDevice == NULL) return;
Osd = cOsdProvider::NewOsd( 160, 88 );
if( Osd )
{
@@ -1026,7 +1031,8 @@
bool cLoadepgOsd::SaveOldChannel( void )
{
-OldChannel = Channels.GetByNumber( cDevice::GetDevice( LoadepgConfig.DeviceNumber - 1 )->CurrentChannel() );
+if (EpgDevice == NULL) return false;
+OldChannel = Channels.GetByNumber( EpgDevice->CurrentChannel() );
if( OldChannel )
{
return true;
@@ -1038,7 +1044,8 @@
{
if( OldChannel )
{
- cDevice::GetDevice( LoadepgConfig.DeviceNumber - 1 )->SwitchChannel( OldChannel, true );
+ if (UsingPrimaryDevice) cDevice::PrimaryDevice()->SwitchChannel( OldChannel, true);
+ else EpgDevice->SwitchChannel( OldChannel, false );
}
}
@@ -1055,9 +1062,19 @@
*EpgChannel = *OldChannel;
sscanf( EpgProviderValue1[MenuItem], "%[^:]:%[^:]:%[^:]:%[^:]:%[^:]", ProviderName, Frequency, Polarization, SourceName, SymbolRate );
EpgChannel->cChannel::SetSatTransponderData( cSource::FromString( SourceName ), atoi( Frequency ), Polarization[0], atoi( SymbolRate ), FEC_AUTO );
- cDevice::GetDevice( LoadepgConfig.DeviceNumber - 1 )->SwitchChannel( EpgChannel, true );
+ if (EpgDevice==cDevice::ActualDevice() && cDevice::GetDevice(EpgChannel,0
+ #if APIVERSNUM >= 10500
+ ,true
+ #endif
+ ) == EpgDevice) {
+ cDevice::PrimaryDevice()->SwitchChannel( EpgChannel, true );
+ UsingPrimaryDevice = true;
+} else {
+ EpgDevice->SwitchChannel( EpgChannel, false );
+ UsingPrimaryDevice = false;
+}
usleep( 200 );
- if( cDevice::GetDevice( LoadepgConfig.DeviceNumber - 1 )->HasLock() )
+ if( EpgDevice->HasLock() )
{
return true;
}
@@ -1071,6 +1088,10 @@
eOSState cLoadepgOsd::ProcessKey( eKeys Key )
{
+if (EpgDevice == NULL ) {
+ Skins.Message(mtError,tr("Card not available"));
+ return osEnd;
+}
eOSState state = cOsdObject::ProcessKey( Key );
StatusKey = 0;
if( state == osUnknown )
@@ -1259,6 +1280,18 @@
BeginProgramId = BeginProgramId + ListEpgPrograms[ChannelId+1];
}
fclose( File );
+#if APIVERSNUM >= 10500
+const char *syschar=cCharSetConv::SystemCharacterTable();
+if (syschar==NULL || !strcasestr(syschar, "ISO-8859-15")) {
+char *cmd;
+asprintf(&cmd, "iconv -f ISO-8859-15 -t %s -o \"%s.converted\" \"%s\"", syschar ? syschar : "UTF-8",FileName,FileName);
+SystemExec(cmd);
+free(cmd);
+asprintf(&cmd, "mv \"%s.converted\" \"%s\&quo
[vdr] [ANNOUNCE] vdr-actuator-1.0.5 plugin
Hello, I'm releasing version 1.0.5 of the "actuator" plugin available at http://www.ventoso.org/luca/vdr/ This plugin controls a linear actuator (or an horizon to horizon one) through the parallel port with a simple circuit. CHANGES: - Updated russian translation from Vladimir Monchenko - Compatibility defines in module.c and remove patches I'm releasing it before the necessary conversion of the translations for vdr-1.5.7, so I think this is the last release supporting stable vdr (1.4.x). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
En/na Klaus Schmidinger ha escrit: > - The parameter OSDLanguage in 'setup.conf' is now a string and holds the > locale > code of the selected OSD language (e.g. en_US). If Setup.OSDLanguage is not > set to a particular locale that is found in VDR's locale directory, the > locale as defined in the system environment is used by default. My system locale is set as ca_ES: [EMAIL PROTECTED] vdr]$ locale LANG=ca_ES.UTF-8 LC_CTYPE=ca_ES.UTF-8 LC_NUMERIC=ca_ES.UTF-8 LC_TIME=ca_ES.UTF-8 LC_COLLATE=ca_ES.UTF-8 LC_MONETARY=ca_ES.UTF-8 LC_MESSAGES=ca_ES.UTF-8 LC_PAPER=ca_ES.UTF-8 LC_NAME=ca_ES.UTF-8 LC_ADDRESS=ca_ES.UTF-8 LC_TELEPHONE=ca_ES.UTF-8 LC_MEASUREMENT=ca_ES.UTF-8 LC_IDENTIFICATION=ca_ES.UTF-8 LC_ALL= If I leave OSDLanguage empty, the menus are in spanish. If I go to the setup menu I can only select English and Spanish, all other languages show the three letter code and are not selected. If I select "Spanish" OSDLanguage is set to ca_ES and the menus are in spanish. I set the LOCDIR in Make.config (to /home/vdr/vdr/locale, maybe is this the problem?) and in that directory I have the ca_ES subdirectory (as well as all other languages). In the log I see this: vdr: [6184] VDR version 1.5.7 started vdr: [6184] codeset is 'UTF-8' - known vdr: [6184] found 21 locales in /home/vdr/vdr/locale vdr: [6184] no locale for language code 'deu,ger' vdr: [6184] no locale for language code 'slv,slo' vdr: [6184] no locale for language code 'ita' vdr: [6184] no locale for language code 'dut,nla,nld' vdr: [6184] no locale for language code 'por' vdr: [6184] no locale for language code 'fra,fre' vdr: [6184] no locale for language code 'nor' vdr: [6184] no locale for language code 'fin,smi' vdr: [6184] no locale for language code 'pol' vdr: [6184] no locale for language code 'ell,gre' vdr: [6184] no locale for language code 'sve,swe' vdr: [6184] no locale for language code 'rom,rum' vdr: [6184] no locale for language code 'hun' vdr: [6184] no locale for language code 'cat,cln' vdr: [6184] no locale for language code 'rus' vdr: [6184] no locale for language code 'hrv' vdr: [6184] no locale for language code 'est' vdr: [6184] no locale for language code 'dan' vdr: [6184] no locale for language code 'cze,ces' vdr: [6184] no locale for language code 'tur' Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
En/na Luca Olivetti ha escrit: > En/na Klaus Schmidinger ha escrit: > >> - The parameter OSDLanguage in 'setup.conf' is now a string and holds the >> locale >> code of the selected OSD language (e.g. en_US). If Setup.OSDLanguage is not >> set to a particular locale that is found in VDR's locale directory, the >> locale as defined in the system environment is used by default. > > My system locale is set as ca_ES: > > [EMAIL PROTECTED] vdr]$ locale > LANG=ca_ES.UTF-8 > LC_CTYPE=ca_ES.UTF-8 > LC_NUMERIC=ca_ES.UTF-8 > LC_TIME=ca_ES.UTF-8 > LC_COLLATE=ca_ES.UTF-8 > LC_MONETARY=ca_ES.UTF-8 > LC_MESSAGES=ca_ES.UTF-8 > LC_PAPER=ca_ES.UTF-8 > LC_NAME=ca_ES.UTF-8 > LC_ADDRESS=ca_ES.UTF-8 > LC_TELEPHONE=ca_ES.UTF-8 > LC_MEASUREMENT=ca_ES.UTF-8 > LC_IDENTIFICATION=ca_ES.UTF-8 > LC_ALL= > > If I leave OSDLanguage empty, the menus are in spanish. If I go to the > setup menu I can only select English and Spanish, all other languages > show the three letter code and are not selected. > If I select "Spanish" OSDLanguage is set to ca_ES and the menus are in > spanish. > > I set the LOCDIR in Make.config (to /home/vdr/vdr/locale, maybe is this > the problem?) and in that directory I have the ca_ES subdirectory (as > well as all other languages). > > In the log I see this: > vdr: [6184] VDR version 1.5.7 started > vdr: [6184] codeset is 'UTF-8' - known > vdr: [6184] found 21 locales in /home/vdr/vdr/locale > vdr: [6184] no locale for language code 'deu,ger' > vdr: [6184] no locale for language code 'slv,slo' > vdr: [6184] no locale for language code 'ita' > vdr: [6184] no locale for language code 'dut,nla,nld' > vdr: [6184] no locale for language code 'por' > vdr: [6184] no locale for language code 'fra,fre' > vdr: [6184] no locale for language code 'nor' > vdr: [6184] no locale for language code 'fin,smi' > vdr: [6184] no locale for language code 'pol' > vdr: [6184] no locale for language code 'ell,gre' > vdr: [6184] no locale for language code 'sve,swe' > vdr: [6184] no locale for language code 'rom,rum' > vdr: [6184] no locale for language code 'hun' > vdr: [6184] no locale for language code 'cat,cln' > vdr: [6184] no locale for language code 'rus' > vdr: [6184] no locale for language code 'hrv' > vdr: [6184] no locale for language code 'est' > vdr: [6184] no locale for language code 'dan' > vdr: [6184] no locale for language code 'cze,ces' > vdr: [6184] no locale for language code 'tur' it appears that, even if the setlocale call succeeds, gettext doesn't find the correct translation for LanguageCode (it always returns esl, very strange since ca_ES is the first one tried). If I leave just the ca_ES directory, LanguageCode is untranslated. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
En/na Luca Olivetti ha escrit: > it appears that, even if the setlocale call succeeds, gettext doesn't > find the correct translation for LanguageCode (it always returns esl, > very strange since ca_ES is the first one tried). > If I leave just the ca_ES directory, LanguageCode is untranslated. Well, it seems that if the LANGUAGE variable is set, the second argument to setlocale is ignored, and since I had LANGUAGE=ca:es_ES:es it looked in ca (which doesn't exist) and then es_ES (found) and stopped there. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
En/na Klaus Schmidinger ha escrit: > On 08/12/07 22:01, Luca Olivetti wrote: >> En/na Luca Olivetti ha escrit: >> >>> it appears that, even if the setlocale call succeeds, gettext doesn't >>> find the correct translation for LanguageCode (it always returns esl, >>> very strange since ca_ES is the first one tried). >>> If I leave just the ca_ES directory, LanguageCode is untranslated. >> Well, it seems that if the LANGUAGE variable is set, the second argument >> to setlocale is ignored, and since I had LANGUAGE=ca:es_ES:es it looked >> in ca (which doesn't exist) and then es_ES (found) and stopped there. > > So what exactly doesn this mean? that the man page of setlocale is incorrect ;-) > Should something be changed in VDR, or do you just not set the > LANGUAGE variable? I'm just unsetting LANGUAGE before launching vdr. Maybe someone else will be bitten by this problem and he'll have to unset LANGUAGE too. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
En/na Klaus Schmidinger ha escrit: >> I'm just unsetting LANGUAGE before launching vdr. Maybe someone else >> will be bitten by this problem and he'll have to unset LANGUAGE too. > > Wouldn't that be problem for other applications, too? > Could VDR do something to make this work better? I don't know, I think most applications just use the locale environment variables and don't allow switching language at runtime. Maybe it's just my version of glibc that's flawed, or my settings for LANGUAGE. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
En/na Klaus Schmidinger ha escrit: > Isn't there perhaps a way to tell gettext *explicitly* which files > to use, completely bypassing this whole broken setlocale stuff? > In that case VDR could collect it's list of *.mo files and decide > by itself which one to use. freepascal bypasses gettext altogether by using an own implementation that reads mo files directly. Though it's in pascal, the implementation seems simple enough for a C++ wizard like you to replicate it with half the effort you'd need to workaround the issues we've seen so far. Here's the documentation of the class: http://community.freepascal.org:1/docs-html/fcl/gettext/tmofile.html and here's the implementation: http://svn.freepascal.org/svn/fpc/trunk/packages/fcl-base/src/inc/gettext.pp (just ignore the "Resourcestring translation procedures" that hooks into the native resourcestring mechanism of pascal). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
En/na Anssi Hannula ha escrit: > Note that KDE does provide the user a list of languages, but it does not > use gettext, but instead uses its own glibc-derived implementation for > translation, with file format being the same. [...] >> Isn't there perhaps a way to tell gettext *explicitly* which files >> to use, completely bypassing this whole broken setlocale stuff? >> In that case VDR could collect it's list of *.mo files and decide >> by itself which one to use. > > I'm not aware of such a way. I think that in your message there's the solution: do *not* use gettext but use an own implementation. Maybe borrowing kde implementation (which is already C++) it's easier than translating the pascal class I proposed before (or maybe not ;-). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
En/na Klaus Schmidinger ha escrit: >> >> It seems that it *does* work, i.e. LANGUAGE=de, LANGUAGE=fr, LANGUAGE=fi >> will work even if there is no such locale at all. >> >> I copied a .mo file into /usr/share/locale/testtest/LC_MESSAGES/, which >> certainly is not a valid locale, and using LANGUAGE=testtest it was >> correctly used! :) > > Looks good. However, after some tests it would appear as if only the > very first setenv() call actually changes anything. Subsequent calls > have no further effect, and gettext() always returns the language > that was selected in the very first call to setenv(). Did you try calling bindtextdomain again after calling setenv? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
En/na Klaus Schmidinger ha escrit: > Please test the attached patch. It scans the LOCDIR directory as before, > but checks for the existence of a vdr.mo file and then uses setenv() > instead of setlocale(). > > This should work for VDR itself. For plugins I need to do more work. > But first let's see whether others can confirm that this works for VDR. With this patch it shows all the language names, but then it ignores the selection (i.e. the osd is always in the system selected locale), regardless if the selected language has a locale installed or not. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.5.7-1.5.8.diff problems?
The diff fails on all po files, it's only me or does it happens to others? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
En/na Klaus Schmidinger ha escrit: > On 08/19/07 16:54, Luca Olivetti wrote: >> The diff fails on all po files, it's only me or does it happens to others? > > You need to add '-p1' to the patch command. Yes, I know that, it doesn't prompt me for the filename, but it just FAILS to patch (and stores the rejects). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
En/na Luca Olivetti ha escrit: > En/na Klaus Schmidinger ha escrit: >> On 08/19/07 16:54, Luca Olivetti wrote: >>> The diff fails on all po files, it's only me or does it happens to others? >> You need to add '-p1' to the patch command. > > Yes, I know that, it doesn't prompt me for the filename, but it just > FAILS to patch (and stores the rejects). The strange thing is that the context of the rejected hunks seems fine in the original file?!? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
En/na Klaus Schmidinger ha escrit: > On 08/19/07 17:12, Luca Olivetti wrote: >> En/na Klaus Schmidinger ha escrit: >>> On 08/19/07 16:54, Luca Olivetti wrote: >>>> The diff fails on all po files, it's only me or does it happens to others? >>> You need to add '-p1' to the patch command. >> Yes, I know that, it doesn't prompt me for the filename, but it just >> FAILS to patch (and stores the rejects). > > I explicitly tried it with the original 1.5.7, and it went through > just fine. you're right, I tried the patch from 1.5.6->1.5.7->1.5.7 (since the last tarball I used was 1.5.3) and it worked. Oh, well, I'll just copy over the files. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
En/na Klaus Schmidinger ha escrit: > Please try version 1.5.8, which I have just uploaded. yes, 1.5.8 works. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
En/na Udo Richter ha escrit: > Luca Olivetti wrote: >> The diff fails on all po files, it's only me or does it happens to others? > > po files are a pain for diff-patches because they have lists of source > code line numbers in the comments. If you've applied any other patch to > the VDR sources, and did a recompile, then all your po files will have > lots of changed line numbers. Ah, ok, that's surely it. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-actuator-1.1.0 plugin
Hello, I'm releasing version 1.1.0 of the "actuator" plugin available at http://www.ventoso.org/luca/vdr/ This plugin controls a linear actuator (or an horizon to horizon one) through the parallel port with a simple circuit. The only change is the adaptation to the new translation method, so it only works with vdr 1.5.8 (not 1.5.7 since the name of the mo file has changed) Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to set German OSD in VDR 1.5.8
En/na Udo Richter ha escrit: > Matthias Fechner wrote: >>> cp Make.config.template Make.config >>> edit it and set LOCDIR=./locale >> ok I changed it, now VDR says at startup: >> Aug 20 14:53:36 localhost vdr: [23028] found 21 locales in ./locale >> Aug 20 14:53:36 localhost vdr: [23028] no locale for language code 'deu,ger' >> [..] >> But in the OSD I can select between several LanguageName$English and >> English but no german translation. > > Post the output of locale -a. You may need to install missing locales, > check your distribution on how to. That shouldn't be necessary with 1.5.8: I only have 3 locales installed but I can select all languages from the osd setup menu (and see the corresponding translations). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.9
En/na Klaus Schmidinger ha escrit: > Note that the "multiple OSD" change currently has no visible effect yet, > but it is a necessary preparation for displaying subtitles, which will > be addressed in the next developer version. dvb or teletext? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.9
En/na Klaus Schmidinger ha escrit: > On 08/26/07 21:51, Luca Olivetti wrote: >> En/na Klaus Schmidinger ha escrit: >> >>> Note that the "multiple OSD" change currently has no visible effect yet, >>> but it is a necessary preparation for displaying subtitles, which will >>> be addressed in the next developer version. >> dvb or teletext? > > DVB for now. :-( (as in: all channels I have an use for subtitles only sport teletext subtitles, and the ttxtsubs plugins+patch is getting cruftier every day). Is there any english/french fta channel with dvb subtitles (just to test the dvb subtitles plugin and the forthcoming vdr feature)? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.5.9 and ttxtsubs patch/plugin
Hello, I downloaded the patch for both vdr and the ttxtsubs plugin from Rolf's page, but the subtitles aren't showing. With a quick look (and I remark "quick" so I may be wrong) it seems that the patches now don't change anymore the osd but use the new osd level in vdr-1.5.9. I'd like to know if the new patch is supposed to be working, or the cause the subtitles aren't showing is my hurriedly patched dxr3 and xine plugins. If the latter, do you have any hint on how to correctly implement osd level in said plugins? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.9 and ttxtsubs patch/plugin
En/na Rolf Ahrenberg ha escrit:
On Thu, 30 Aug 2007, Luca Olivetti wrote:
With a quick look (and I remark "quick" so I may be wrong) it seems that
the patches now don't change anymore the osd but use the new osd level
in vdr-1.5.9.
Yes. I've set subtitles to use level 10 and ttxtsubs to 20.
I'd like to know if the new patch is supposed to be working, or the
cause the subtitles aren't showing is my hurriedly patched dxr3 and xine
plugins.
DVB subtitles are working nicely in my FF setup and someone reported
that ttxtsubs are working with xineliboutput.
I somewhat doubt it, since I had to bypass the "IsOpen" test to make it
work with a properly (I think) patched dxr3 plugin.
Patch attached.
Bye
--
Luca
--- ttxtsubsdisplay.c.orig 2007-09-02 13:38:44.621547000 +0200
+++ ttxtsubsdisplay.c 2007-09-02 15:07:14.774866000 +0200
@@ -413,12 +413,12 @@
delete tmp;
}
+#if defined(APIVERSNUM) && APIVERSNUM < 10509
if (cOsd::IsOpen()) {
//dprint("NOT displaying subtitles because of other OSD activities!\n");
return;
}
else {
-#if defined(APIVERSNUM) && APIVERSNUM < 10509
mOsd = cOsdProvider::NewOsd(SCREENLEFT, SCREENTOP);
#else
mOsd = cOsdProvider::NewOsd(SCREENLEFT, SCREENTOP, 20); // level 20
@@ -427,7 +427,9 @@
//dprint("Error: cOsdProvider::NewOsd() returned NULL!\n");
return;
}
+#if defined(APIVERSNUM) && APIVERSNUM < 10509
}
+#endif
#if defined(APIVERSNUM) && APIVERSNUM < 10503
cFont::SetCode(I18nCharSets()[globals.i18nLanguage()]);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.9 and ttxtsubs patch/plugin
En/na Petri Helin ha escrit: > Luca Olivetti wrote: >> En/na Rolf Ahrenberg ha escrit: >>> DVB subtitles are working nicely in my FF setup and someone reported >>> that ttxtsubs are working with xineliboutput. >> I somewhat doubt it, since I had to bypass the "IsOpen" test to make it >> work with a properly (I think) patched dxr3 plugin. > > There is nothing to doubt about. Ttxtsubs do work with xineliboutput and > VDR-1.5.9. Or was it something else you had doubts about? You're right, I've re-checked without my patch and it works (though with the osd level the "IsOpen" check is not really necessary). -- Bye ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.9 and ttxtsubs patch/plugin
En/na Luca Olivetti ha escrit:
En/na Petri Helin ha escrit:
Luca Olivetti wrote:
En/na Rolf Ahrenberg ha escrit:
DVB subtitles are working nicely in my FF setup and someone reported
that ttxtsubs are working with xineliboutput.
I somewhat doubt it, since I had to bypass the "IsOpen" test to make it
work with a properly (I think) patched dxr3 plugin.
There is nothing to doubt about. Ttxtsubs do work with xineliboutput and
VDR-1.5.9. Or was it something else you had doubts about?
You're right, I've re-checked without my patch and it works (though with
the osd level the "IsOpen" check is not really necessary).
though the attached patch is IMO needed (otherwise the plugin doesn't
take into account the "volatile" main menu setting but only the setup
menu setting in order to decide whether do display the subtitles or not).
Bye
--
Luca
--- ttxtsubsdisplay.c~ 2007-09-02 15:40:57.90173 +0200
+++ ttxtsubsdisplay.c 2007-09-02 15:40:57.91173 +0200
@@ -386,7 +386,7 @@
cOSDSelfMemoryLock selfmem(&gSelfMem);
cMutexLock lock(&mOsdLock);
- if(!globals.mDoDisplay) {
+ if(!globals.mRealDoDisplay) {
//dprint("NOT displaying subtitles because disabled!\n");
return;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.9 and ttxtsubs patch/plugin
En/na Rolf Ahrenberg ha escrit: > On Sun, 2 Sep 2007, Luca Olivetti wrote: > >> You're right, I've re-checked without my patch and it works (though with >> the osd level the "IsOpen" check is not really necessary). > > Well, you're right too and it was a bummer in my patch - somehow forgot > to check those IsOpen calls when re-patching the ttxtsubs. I also > integrated your mRealDoDisplay fix. Considering that 1) The last released version of the plugin is 3 and a half years old 2) Neither me nor google haven't seen the author here or anywhere else since 3 and a half years ago 3) The (compressed) patch size is about half the (compressed) plugin source 4) You've been almost the only one that took care of the plugin (ok, I did some very minor things, and probably there have been other contributors, but you did the rest) why don't you take maintainership of the plugin, release a full tarball, and be done with it? Bonus points if you release a "stable" (or if you prefer "dead" ;-) version for "stable" vdr and a bleeding edge version (without the #if APIVERSION madness!) for the development version ;-) If Ragnar is alive and listening, please speak up. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.9 and ttxtsubs patch/plugin
En/na Rolf Ahrenberg ha escrit: > On Mon, 3 Sep 2007, Luca Olivetti wrote: > >> why don't you take maintainership of the plugin, release a full tarball, >> and be done with it? > > Because I don't want it. The plugin needs a complete rewrite and there's > no point to do it before Klaus has integrated necessary parts into VDR's > core (OSD handling, subtitles menu/key, ..) ...subtitles recording... > that's hopefully next sunday > :) I don't even had any ttxtsubs channels available for years and been > just maintaining the plugin for my friends by doing as little as it > requires... and besides, I've been getting those damn bug reports > already, but been able to reject them by saying I'm not the maintainer! fair enough > I'd like to see the ttxtsubs (and closed captions) integrated into core > VDR before the next stable release as they are IMO essential features > that should work out-of-box. I hope Klaus is listening ;-) Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.9 and ttxtsubs patch/plugin
En/na Klaus Schmidinger ha escrit: > I haven't looked into the code of the ttxt subtitle plugin, yet, but > currently my idea is to convert the ttxt subtitles into DVB subtitles, > so that VDR only needs to handle one type of subtitiles for recording > and live viewing. Aren't dvb subtitles just bitmaps? If so, converting the text to a bitmap for recording doesn't seem a good idea to me. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.0 plugin
En/na Reinhard Nissl ha escrit: > Hi, > > I'm pleased to announce the long awaited release 0.8.0, which integrates > the vdr-xine-network patch. You can find it on my homepage: I finally upgraded to this version (from 0.7.6 + network patches, I think I tried some other version but with similar problems as this one), but using it from the network (I cannot try it locally, so I don't know if it applies), live tv stutters (i.e. plays smooth for around a second, stops or slows down for a moment, plays for a second, stops, and so on). Recordings are not affected by this problem (or so it seems). The same version of xine (20070829224000, downloaded from your page, with the patches in vd-xine) on the client against streamdev-server plays smoothly. -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.0 plugin
En/na Luca Olivetti ha escrit: > En/na Reinhard Nissl ha escrit: >> Hi, >> >> I'm pleased to announce the long awaited release 0.8.0, which integrates >> the vdr-xine-network patch. You can find it on my homepage: > > I finally upgraded to this version (from 0.7.6 + network patches, I > think I tried some other version but with similar problems as this one), > but using it from the network (I cannot try it locally, so I don't know > if it applies), live tv stutters (i.e. plays smooth for around a second, > stops or slows down for a moment, plays for a second, stops, and so on). > Recordings are not affected by this problem (or so it seems). > The same version of xine (20070829224000, downloaded from your page, > with the patches in vd-xine) on the client against streamdev-server > plays smoothly. Mmmh, I usually use wifi, now I tried with a wired connection and it seems to work fine. 0.7.6 worked fine with wifi though (even with marginal reception, with at least 5Mbps available as reported by kwifimonitor), and where I usually need it there's no wired connection available. Is it possible that newer version generate more traffic/are more sensible to network latencies? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.0 plugin
En/na Reinhard Nissl ha escrit: > Hi, > > Luca Olivetti schrieb: > >> Is it possible that newer version generate more traffic/are more >> sensible to network latencies? > > Yes, at least in the buffer monitoring phase, which was introduced with > 0.7.7. Try to set it to 0 in vdr-xine's setup menu. That was it! Thank you. Incidentally, that was the only parameter I didn't touch ;-) Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.0 plugin
En/na Graziano Pavone ha escrit: > I'm currently using xineliboutput for my other client (on a standard > PC), so this would be my first choice, but I've no problem to switch > back to vdr-xine (which I used in the past - with the network patch... I > moved to xineliboutput just because I don't want to patch xine-lib > everytime anymore..) Note that 0.8.0 has network support built-in. A nice feature that vdr-xine has over xineliboutput, is that it automatically sets itself as the primary device when a connection comes, and when the connection is closed it restores the previous primary device. This way I can either watch locally with the dxr3-plugin or remotely with vdr-xine. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 and 1.5.11 antialiasing
En/na Jan Willies ha escrit: > After upgrading from 1.5.2 to 1.5.11 I ran into some problems with my > dxr3 card. The first one was solved by setting AntiAlias = 0 in > setup.conf. But after that, VDR won't even start: > > vdr: [3936] ERROR: FreeType: error during FT_Render_Glyph 32, 3 > vdr: [3936] ERROR: FreeType: error during FT_Render_Glyph 32, 3 > vdr: [3936] ERROR: FreeType: error during FT_Render_Glyph 32, 3 > Speicherzugriffsfehler > > Apparently the AntiAlias fix worked for Luca Olivetti Yes, and it is working now, with vdr-1.5.11 (though dvbsubtitles.c have to be patched since it seems it doesn't honour the AntiAlias setting, and the dxr3 osd is too funky to give the right answer to CanHandleAreas, but this is not your problem) > (http://article.gmane.org/gmane.linux.vdr/33161/).So is this a freetype > problem? wrong font? More infos needed? > > libfreetype6 2.3.5-1+b1 > libfreetype6-dev 2.3.5-1+b1 FWIW I have 2.3.1 (the version that came with mandriva 2007.1). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 and 1.5.11 antialiasing
El Wed, 14 Nov 2007 14:38:39 +0100 Jan Willies <[EMAIL PROTECTED]> escribió: > Luca Olivetti wrote: > > FWIW I have 2.3.1 (the version that came with mandriva 2007.1). > > Seems that debian only has Version: 2.3.5-1+b1 and Version: > 2.2.1-5+etch1. Unfortunately, 2.2.1 seems pretty old when trying to > downgrade: Hey, I just told you my version for information, I doubt that the version of freetype is the problem (or maybe it is, I cannot say). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dxr3 compiling and 1.5.11
El Thu, 15 Nov 2007 19:58:43 +0100 YUP <[EMAIL PROTECTED]> escribió: > I successfully compiled dxr3 plugin from cvs (stable at it was > described here http://www.linuxtv.org/vdrwiki/index.php/Dxr3-plugin), > but still no luck - vdr crashes with segmentation fault. This happened to me with the first version of vdr using truetype fonts: since my vdr machine is headless, has no X and consequently no kde/gnome desktop, I had no truetype font installed. Installing TT fonts and configuring vdr to use the installed fonts solved my problem. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 & subtitling problems
En/na Reinhard Nissl ha escrit: > BTW: the patch is almost untested as there are currently no subtitles > running. FYI, if you can see astra 2d I just found that at least CBeebies and BBC4 broadcast dvb subtitles. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DXR3?
En/na Rob Davis ha escrit: > I have a couple of SkyStar cards on a VDR server, running xineliboutput > on an NVidia card using a VGA cable to my HDTV. I am seeing lagging, > tearing and noticeable interlacing. > > Is it worth buying a DXR3 on ebay? A dxr3 only decodes mpeg at standard resolution, it does it very well and with good quality, but it's of no use for HD. It also has many stability problems with the osd (it was designed to display dvd menus and subtitles, not a full-fledged, full-screen, full-color osd, so the vdr plugin pushes it to its limits and beyond). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbsubtitle issue
En/na Stefan Lucke ha escrit: > > Excat :-( > > Stefan Lucke In case it could help you: the dxr3-plugin had a similar issue, the solution was to clear the osd each time SetAreas is called. http://dxr3plugin.cvs.sourceforge.net/dxr3plugin/dxr3/dxr3osd_subpicture.c?r1=1.1.2.17&r2=1.1.2.18 Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbsubtitle issue
En/na Klaus Schmidinger ha escrit: > On 01/19/08 18:47, Luca Olivetti wrote: >> En/na Stefan Lucke ha escrit: >> >>> Excat :-( >>> >>> Stefan Lucke >> In case it could help you: the dxr3-plugin had a similar issue, the >> solution was to clear the osd each time SetAreas is called. >> >> http://dxr3plugin.cvs.sourceforge.net/dxr3plugin/dxr3/dxr3osd_subpicture.c?r1=1.1.2.17&r2=1.1.2.18 > > cDvbOsd also clears the OSD whenever SetAreas() is called: Well, yes, that's how I found the error in the dxr3-plugin, by looking at cDvbOsd code ;-) I just wanted to save Stefan some time (if indeed softdevice has the same problem, if it's a different one he'll have to find it by himself). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD-TV hardware decoding on motherboard instead of waitingfor FF DVB-S2 card
En/na Igor ha escrit: >>> So I was wondering if it would be possible to use the on board video >>> decoder chips of the VIA EPIA boards like the VIA EPIA EX15000G >>> http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboa >>> rd_id=450 >>> >>> This board mounts a CX700M2 chipset which features MPEG2/4 hardware >>> decoding. It has DVI and Y/Pb/Pr video output as well as analog and >>> SPDIF audio (coaxial and optical). So that's everything we need, isn't >>> it. > > for hdtv - no. > I don't see the h.264 hardware decoding. mpeg4 is not h.264. Maybe this thing can be hacked to run vdr or to be used as a front-end: http://www.popcornhour.com/ Supposedly it runs Linux, but you know these companies (like, e.g., broadcom) that only take but never give back Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
