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] 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] 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
[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] 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
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] 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] 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 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)
///Store the current position in a satellite position with the given
Number
///and recalculate all other positions relative to this one
Oh, and there's a DisableLimits but there's no corresponding EnableLimits
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] [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] 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] 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] 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 l...@ventoso.org 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] 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] 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] 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] [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] [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 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 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] will VDR run on this?
Al 01/08/11 10:04, En/na Steffen Barszus ha escrit: 2011/8/1 Gerald Dachs v...@dachsweb.de: 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] rotor-ng in development [was [ANNOUNCE] vdr-actuator-1.2.0 plugin]
Al 20/03/11 22:20, En/na Morfsta ha escrit: I'd like to release it at some point when I've tidied it up (perhaps as rotor-ng or something), but one issue I have is with DVB-S2 signal tuning and scanning on my Hauppauge Nova HD-S2 card - does anyone have this functionality working either with this card or another card with the actuator plugin's scanner? Since I don't have an S2 card I never tested that functionality. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to vdr
Al 23/01/11 09:56, En/na Arthur Konovalov ha escrit: On 22.01.2011 20:31, Timothy D. Lenz wrote: VDR being a euro program where FTA sat is far more common should have really good support built in. I agree and awaiting too native rotor support in the vdr core. What I'd like to see is that core vdr is more friendly to steerable dishes (be they implemented natively or via a plugin): vdr currently doesn't know that the dish is not pointing at the correct satellite, and that leads to some problems - the channels can be wrongly updated (NIT/PAT/PMT of the wrong satellite), I currently workaround that by setting Setup.UpdateChannels at 0 while the dish is moving, but it's ugly and it's not a complete solution (I think it shouldn't be processing section filters at all while the dish is moving). - when the position is reached, sometimes vdr doesn't show anything until I switch to a different transponder. Or if it does it doesn't find the dvb subtitles (until I switch to a different transponder). - unattended recordings are problematic since while the dish is moving obviously there's no data. I have a patch that sets a bigger timeout for the first packet, but, again, that's not a perfect solution. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to vdr
Al 22/01/11 19:31, En/na Timothy D. Lenz ha escrit: I know about that plugin. Won't really help with a rotor. Different setup. Actuators are for BUD's, Dishes over 1.2m though they have come out with small dish systems. Yes, my dish is 1.2m, but I fitted it for an analog receiver, long before DISEqC existed, so an actuator was the only option, even for small dishes. When I had to switch from analog to digital, I found about vdr and decided to write the plugin to avoid aligning a new dish ;-) Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new OSD system
Al 16/01/11 12:09, En/na Gero ha escrit: Currently when I forget to switch to a SD channel on the xineliboutput frontend before stopping that frontend, the vdr is not operable for the FF- user. There's no way to recover. I had the same issue with vdr-xine and the dxr3 plugin. Maybe the ff output should do something similar to what I did with the dxr3 plugin: if the stream is hd (actually h264), instead of sending it to the dxr3 (and crashing it), just show a message that the video stream is not supported. Everything else (audio, osd), still works fine. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Meridian
Al 11/01/11 19:24, En/na Tony Houghton ha escrit: Since my upgrade from VDR 1.6.0 to 1.7.16 I can't view my local ITV1 region (ITV1 Mer South) on Freesat. The EPG appears normal, but there's no picture or sound. ITV1 is OK on Freeview, as is the London version on Freesat. The log says: Jan 11 18:07:57 htpc vdr: [10023] switching to channel 103 Jan 11 18:07:57 htpc vdr: [10023] setstatus 0 Jan 11 18:08:06 htpc vdr: [10027] frontend 0/0 timed out while tuning to channel+ 103, tp 110891 ^^ The channels.conf entry (which I've checked is up-to-date) is: ITV1 Mer South;BSkyB:10891:hC56:S28.2E:22000:3336=2:3337=...@4:2344:0:10140:2:20+53:0 ^ 110891 is not the same as 10891. BTW, this is my entry for it ITV1 Meridian S;BSkyB:10891:HC56M2O0S0:S28.2E:22000:3336=2:3337=...@4:2344:0:10140:2:2053:0 I just checked and I can see and hear it, and I have one full week of epg (with the eepg plugin). My VDR versions are now: * vdr 1.7.16-1devel2 from Tobias Grimm's Debian sid repository. * vdr-plugin-eepg 0.0.3-28yavdr1 built from yavdr's vdr-unstable deb source I'm also using vdr-1.7.16 and eepg-0.0.3 (both self compiled). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Meridian
Al 11/01/11 21:50, En/na Tony Houghton ha escrit: BTW, this is my entry for it ITV1 Meridian S;BSkyB:10891:HC56M2O0S0:S28.2E:22000:3336=2:3337=...@4:2344:0:10140:2:2053:0 Essentially the same as mine I think. Well, yours is missing some of the parameters (i.e. it's missing the M2O0S0), and the TID seems wrong (20+53 instead of 2053), so I doubt that your entry has been auto updated by vdr. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to extract HD dvb subtitles (and possibly convert to srt)?
Al 04/01/11 10:01, En/na Luca Olivetti ha escrit: En/na Luca Olivetti ha escrit: Yesterday I noticed that the timing offset is not fixed but depends on the recording (e.g, with my previous experiments I hardcoded a 4 seconds delay for the bbc channels, while yesterday I needed a 2 minutes delay). I don't know the cause of this offset (ProjectX or the crappy media player of my tv) but the problem can be easily solved with Subtitles: I now know the cause of the offset, but I don't know how to (easily) fix it: Project-X for some reason (maybe a wrong option I gave?) doesn't extract the pts from the video stream, so it doesn't synchronize the subtitles to the video but it simply assumes the time starts with the first subtitle. If, e.g., the first subtitle appears 3 minutes into the recording, it will get a timestamp of 0 seconds so it will show 3 minutes early. These are the options I'm giving to Project-X (via its ini file): Ok, I found there's an option to enable hd video demuxing (OptionPanel.enableHDDemux), *but* ProjectX crashes with it enabled, so I changed the script to use dvbsnoop to obtain the first pts of the video track and of the subtitles track, and use the difference as a time offset. BTW: am I the only one needing this and/or wrestling with ProjectX to manipulate vdr recordings? I wasn't exactly overwhelmed with the replies... Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to extract HD dvb subtitles (and possibly convert to srt)?
En/na Luca Olivetti ha escrit: Yesterday I noticed that the timing offset is not fixed but depends on the recording (e.g, with my previous experiments I hardcoded a 4 seconds delay for the bbc channels, while yesterday I needed a 2 minutes delay). I don't know the cause of this offset (ProjectX or the crappy media player of my tv) but the problem can be easily solved with Subtitles: I now know the cause of the offset, but I don't know how to (easily) fix it: Project-X for some reason (maybe a wrong option I gave?) doesn't extract the pts from the video stream, so it doesn't synchronize the subtitles to the video but it simply assumes the time starts with the first subtitle. If, e.g., the first subtitle appears 3 minutes into the recording, it will get a timestamp of 0 seconds so it will show 3 minutes early. These are the options I'm giving to Project-X (via its ini file): # Application Application.Agreement=1 Application.OutputDirectory=/temporary/word/directory # CollectionPanel CollectionPanel.CutMode=0 # SubtitlePanel SubtitlePanel.SubpictureColorModel=UkFreeview(mc) SubtitlePanel.enableHDSub=1 SubtitlePanel.exportAsVobSub=1 ExportPanel.Streamtype.MpgAudio=0 ExportPanel.Streamtype.Ac3Audio=0 ExportPanel.Streamtype.PcmAudio=0 ExportPanel.Streamtype.Teletext=0 ExportPanel.Streamtype.Subpicture=1 ExportPanel.Streamtype.Vbi=0 Any hint on what option I could try to get the video pts (but only the pts, I don't want to extract the video stream)? Or simply Project-X cannot do it with h264 streams? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to extract HD dvb subtitles (and possibly convert to srt)?
Al 01/01/11 18:09, En/na Luca Olivetti ha escrit: I found a simpler (i.e scriptable) way: I wrote a simple python script that uses ProjectX (cvs version) to extract the subtitles from the ts file, BDSup2Sub to convert the subtitles to png images, ImageMagick's convert to improve the resulting images and finally gocr to convert the images to text. It seems to work acceptably with recordings from the bbchd/bbcone-hd. It's available here: http://ventoso.org/luca/vdr/vdrsubrip/ Both ProjectX and BDSup2Sub will spit a million warnings, but the final result is ok. As always YMMV. Yesterday I noticed that the timing offset is not fixed but depends on the recording (e.g, with my previous experiments I hardcoded a 4 seconds delay for the bbc channels, while yesterday I needed a 2 minutes delay). I don't know the cause of this offset (ProjectX or the crappy media player of my tv) but the problem can be easily solved with Subtitles: http://karasik.eu.org/software/ Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to extract HD dvb subtitles (and possibly convert to srt)?
Al 18/12/10 12:57, En/na Luca Olivetti ha escrit: Al 15/12/10 18:28, En/na Luca Olivetti ha escrit: I've a media player that only understand srt subtitles, so I'm looking for a way to extract the dvb subtitles from a vdr ts recording, and then use some kind of ocr to convert it to srt. I asked google and I came empty handed (many people asking the same question with no working answer). [...] I found how to do it but it's way too cumbersom: the cvs version of ProjectX supports HD subtitles, *but* the sup exported subtitles aren't readable neither by suprip (not subrip!) nor by BDSup2Sub, so I additionally export to sub format and use BDSup2Sub to convert it to a valid sup, that can then be processed by suprip. Both ProjectX and BDSup2Sup, being java programs, work under Linux, but suprip is windows only. Projectx: http://sourceforge.net/projects/project-x/ BDSup2Sub http://forum.doom9.org/showthread.php?t=145277 SupRip http://exar.ch/suprip/ I found a simpler (i.e scriptable) way: I wrote a simple python script that uses ProjectX (cvs version) to extract the subtitles from the ts file, BDSup2Sub to convert the subtitles to png images, ImageMagick's convert to improve the resulting images and finally gocr to convert the images to text. It seems to work acceptably with recordings from the bbchd/bbcone-hd. It's available here: http://ventoso.org/luca/vdr/vdrsubrip/ Both ProjectX and BDSup2Sub will spit a million warnings, but the final result is ok. As always YMMV. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to extract HD dvb subtitles (and possibly convert to srt)?
Al 15/12/10 18:28, En/na Luca Olivetti ha escrit: I've a media player that only understand srt subtitles, so I'm looking for a way to extract the dvb subtitles from a vdr ts recording, and then use some kind of ocr to convert it to srt. I asked google and I came empty handed (many people asking the same question with no working answer). What I tried so far: - ProjectX (fails because it doesn't like hd pixel coordinates) - avidemux (it has a ts-srt option but it only allows pids up to to 255, and the lucky few that managed to make it work say that it doesn't work with hd) - mencoder -vobsubout (it just produces garbage instead of good pictures, at least according to subrip) Any other option? I found how to do it but it's way too cumbersom: the cvs version of ProjectX supports HD subtitles, *but* the sup exported subtitles aren't readable neither by suprip (not subrip!) nor by BDSup2Sub, so I additionally export to sub format and use BDSup2Sub to convert it to a valid sup, that can then be processed by suprip. Both ProjectX and BDSup2Sup, being java programs, work under Linux, but suprip is windows only. Projectx: http://sourceforge.net/projects/project-x/ BDSup2Sub http://forum.doom9.org/showthread.php?t=145277 SupRip http://exar.ch/suprip/ Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
Al 15/12/10 00:19, En/na VDR User ha escrit: On Tue, Dec 14, 2010 at 12:56 PM, Luca Olivettil...@ventoso.org wrote: Instead of speculating I actually tried. I created a test database with the contents of my channels.conf (only containing the number, name, frequency, source, symbol rate and the vpid, I don't think adding all the fields would change the result considerably). Why would you do a test and intentionally discard necessary data fields? If you're not going to run tests using _all_ the actual data, don't bother. Because, without indexes, sqlite will do a linear scan, so, e.g., doubling the data per record, will roughly double the time, and the double of imperceptible is too little to notice. But that anyway would be offset by using indexes and optimizing the data types (e.g. in my query I used strings for parameters and source, and those are very inefficient, intentionally so, just to show that sqlite wouldn't be a bottleneck). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
Al 15/12/10 20:35, En/na VDR User ha escrit: On Wed, Dec 15, 2010 at 9:21 AM, Luca Olivettil...@ventoso.org wrote: Instead of speculating I actually tried. I created a test database with the contents of my channels.conf (only containing the number, name, frequency, source, symbol rate and the vpid, I don't think adding all the fields would change the result considerably). Why would you do a test and intentionally discard necessary data fields? If you're not going to run tests using _all_ the actual data, don't bother. Because, without indexes, sqlite will do a linear scan, so, e.g., doubling the data per record, will roughly double the time, and the double of imperceptible is too little to notice. But that anyway would be offset by using indexes and optimizing the data types (e.g. in my query I used strings for parameters and source, and those are very inefficient, intentionally so, just to show that sqlite wouldn't be a bottleneck). Then you create indexes, not discard a big portion of necessary data. Ok I created an index create index transp on channels (freq, params, source, sr); Now the reply to the query is immediate. Since I don't have time to create a proper table, I added a dummy column in order that each row has at least three times the amount of necessary data. The reply is still immediate. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
Al 15/12/10 20:57, En/na Jouni Karvo ha escrit: I don't understand what would be easy in using SQL. Since the channels.conf-code is already there, and pretty stable, then obviously rewriting that to SQL is not easy, but instead additional work. Justifying additional work needs some reason. Well, I don't actually care either way. Using sql has advantages and disadvantages, using channels.conf has another set of advantages and disadvantages. I just don't like the spreading of FUD. I think adding dependencies to outside packages is a burden that should be avoided. I assure you that sqlite wouldn't be a burden. It's no more of an external dependency than, say, libc. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
Al 13/12/10 11:34, En/na Steffen Barszus ha escrit: That was my point in the beginning. Then: I want to see sqlite3 being less efficient on insert and fetch or memory consumption. I can not imagine it (prove me wrong! ;)). Last but not least i don't think any user would even notice any difference in behaviour. I think the low end would be PIII 700 (SMT7020s/S100) or ARMv5(sheeva/dockstar) recently. I'd say that the performance would be better. Right now I have a recording going on. If I press the up channel past the last channel on the same transponder, vdr is unresponsive for ~30 seconds. I guess that sqlite, with a well formulated query and the right indexes, would take a fraction of a second to realize that there are no more channels in the same transponder. Bye. -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
Al 14/12/10 21:20, En/na Luca Olivetti ha escrit: Al 13/12/10 11:34, En/na Steffen Barszus ha escrit: That was my point in the beginning. Then: I want to see sqlite3 being less efficient on insert and fetch or memory consumption. I can not imagine it (prove me wrong! ;)). Last but not least i don't think any user would even notice any difference in behaviour. I think the low end would be PIII 700 (SMT7020s/S100) or ARMv5(sheeva/dockstar) recently. I'd say that the performance would be better. Right now I have a recording going on. If I press the up channel past the last channel on the same transponder, vdr is unresponsive for ~30 seconds. I guess that sqlite, with a well formulated query and the right indexes, would take a fraction of a second to realize that there are no more channels in the same transponder. Instead of speculating I actually tried. I created a test database with the contents of my channels.conf (only containing the number, name, frequency, source, symbol rate and the vpid, I don't think adding all the fields would change the result considerably). With no indexes, the time to get the result to the following query (which is meant to find the next channel in the same transponder) is too short to measure: select * from channels where nr13 and freq=10992 and params='VC23M2O0S0' and source='S13.0E' and sr=27500 and vpid0 order by nr limit 1; (note that the machine was running vdr while performing the query). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
En/na Klaus Schmidinger ha escrit: Of course, but they are *simple* databases ;-) I don't want VDR to become dependent on some particular database software. And I like the fact that these files are plain readable text files. text files, yes, plain readable, no (with all special symbols, special cases, etc.). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cSdtFIlter and LinkChannels
Al 12/11/10 16:24, En/na Klaus Schmidinger ha escrit: I also see that cSdtFilter starts processing with the first section, and that shouldn't really be necessary as long as one processes all sections. Personally I'm not interested in that whole NVOD stuff, therefore Me neither, but that question was for normal sdt scanning, not related to NVOD. Meanwhile I took the faster approach: whichever section comes first it gets processed. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] UK users - multiple BBC One/Two/News in channels list
Al 03/11/10 21:31, En/na Alasdair Campbell ha escrit: Hi, Been a while since I've used VDR. Have it setup after scanning using the scan program, however something is strange. There are multiple versions of some channels, such as BBC One/Two/News, Channel 4 etc. Some of these either have video and no EPG, have video and EPG, or have EPG and no video... Obviously what I'm looking for is the video the EPG - this works for BBC One, but when I tune to the BBC Two which has the EPG visible, I receive no signal found message. Terrestrial or satellite? I'm not really sure, but the issue should be the same in both cases: the service id should be sufficient to identify a channel, regardless of the transponder, but since some broadcasters reuse the same id in more than one transponder, vdr uses both the transponder and the service id to differentiate channels. The result is that when a channel changes transponder (like the uk channels recently did), vdr would probably find a new channel instead of replacing the tuning data of the existing one. If any UK users have a cluestick on how to fix this, please let me know. Well, I think there should be a better way, but the only current option is to let vdr update all channels and manually delete the old, non working ones. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reelchannelscan not working with empty channels.conf!
En/na Halim Sahin ha escrit: Hi, On Thu, Oct 21, 2010 at 10:03:05PM +0400, Goga777 wrote: have a look on actuator plugin from Luca http://www.ventoso.org/luca/vdr/ I read only about dvb-s/s2 support in the announcement. Unfortunately in need also dvb-t and maybe later dvb-c (I am looking for dvb-c hw currently :-(). Yes, unfortunately it only supports dvb-s/s2 (don't forget it's meant to work as an actuator, channel tuning/scanning is just an aid to point the dish). It also currently work with only one card (the card connected to the motor), so it'll probably fail in multiple cards setups. I don't think I can easily adapt it to dvb-t/dvb-c :-( Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reelchannelscan not working with empty channels.conf!
Al 21/10/10 20:03, En/na Goga777 ha escrit: I tested reelchannelscan on my vdr-1.7.15 and had problems with it. It crashs when using it with empty channels.conf, because it need a tuned channel before scanning. When started with an empty channels.conf there is no channel tuned and the plugin gets no valid initial channel data. Do we have a fix for that issue? Who does maintain an oficial (vdr) compatible version of the plugin? imho - nobody have a look on actuator plugin from Luca http://www.ventoso.org/luca/vdr/ it can scan dvb-s2 channels (see the discussion in vdr list about this plugin) Though I don't have the hardware to test dvb-s2 and I never tried with an empty channels.conf. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
Al 12/10/10 18:13, En/na Hannu Tirkkonen ha escrit: On 11.10.2010 22.22, Vesa wrote: eHD card has now days working plugin for vdr, more info about that here: http://www.vdr-portal.de/board/thread.php?threadid=98019 eHD is stable with latest card firmwares, also for ts playback. Only issue is still that somehow VDR is not compatible with eHD on replay mode. With live tv DVB subtile timing is correct. During replay subtitles still comes 6-7s too early here in Finland. Last real discussion about this bug is from Sat Sep 5 15:09:30 CEST 2009. And still no any real solutions. Hi! This is really annoying problem and basically all of the recordings containing dvb subtitles are pretty much useless. The problem exists also on recordings having teletext subtitling, but the teletext plugin have an option for delaying the subtitling. I don't know if it's related, but I have the same problem with a dxr3. I modified pts management in the dxr3 plugin so that it correctly fast forwards (without the modification it would appear to fast forward but, once the ff mode stops, replay would continue from where the ff began), but then dvb subtitles in recordings appear too early. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-actuator-1.2.0 plugin
Al 10/10/10 13:39, En/na Gregoire Favre ha escrit: On Sun, Oct 10, 2010 at 12:39:24AM +0200, Luca Olivetti wrote: Oh, I know what happened :-( Try the attached patch. Thanks, that's it :-) Ok, I'll push a new release. Now i just discovered that my vdr-xine don't seems to work (even without actuator)... At least it's not my fault this time ;-) Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-actuator-1.2.0 plugin
Al 10/10/10 14:06, En/na Goga777 ha escrit: From this version it is also possible to use the plugin without an actuator, i.e. as a channel scanner only. does it mean, that with your plugin no need to use reelchannelscan plugin for creating/updating channels.conf ? Yes, but I could only test it with plain dvb-s, no dvb-s2. Also, it doesn't to a blind scan, it needs a transponder.ini file for each satellite that you want to scan. does the sources of scaner based on reelchanellscan plugin ? No. The original implementation was the work of Thomas Bergwinkl, which adapted pat.c and sdt.c to give a faster result (pat.c and sdt.c aren't intended as a fast channel scanner, just as a background scan of the current transponder). The reelchannelscan plugin was in turn based on this implementation. Since I wasn't satisfied with the results, I completely rewrote the scanner, using the approach of the scan utility but using the code in in pat.c/sdt.c to add the channels to vdr channels list Why don't release the scaner as separete plugin ? Well, because the functionality matches what I wanted to do with my actuator: move the dish to hunt for a satellite, quickly check a transponder to see if it's the correct one, then do a satellite or transponder scan. But since now it works even without an actuator, I don't see the reason to write a separate plugin. However the plugin is gpl, so anybody is free to take scanner.c and use it to write another plugin. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-actuator-1.2.0 plugin
Al 10/10/10 13:54, En/na Luca Olivetti ha escrit: Al 10/10/10 13:39, En/na Gregoire Favre ha escrit: On Sun, Oct 10, 2010 at 12:39:24AM +0200, Luca Olivetti wrote: Oh, I know what happened :-( Try the attached patch. Thanks, that's it :-) Ok, I'll push a new release. I released version 1.2.1 with this change. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-actuator-1.2.0 plugin
Al 10/10/10 16:39, En/na Luis Fernandes ha escrit:
hello,
just to say that in scanner.c
must contain this patch if relevant:
- Int Atypes [MAXDPIDS + 1] = {0};
+ Int Atypes [MAXAPIDS + 1] = {0};
and also
Dpids [NumDpids] = esPid;
+ Dtypes [NumDpids] = SI:: AC3DescriptorTag;
strn0cpy (DLangs [NumDpids], lang, MAXLANGCODE1);
and for cosmetic reasons I think this change should also contain in
both vdr, as in the plugin:
- Case 0x0F: / / ISO / IEC 13818-7 Audio with ADTS transport sytax
+ Case 0x0F: / / ISO / IEC 13818-7 Audio with ADTS transport syntax
if relevant.
Thank you, I took the relevant code from vdr-1.7.15 and didn't notice
the change in 1.7.16.
I'll try to keep the code in sync from now on, but I don't think I'll
make a release just for these changes.
Bye
--
Luca
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-actuator-1.2.0 plugin
Al 10/10/10 17:04, En/na Luca Olivetti ha escrit:
Al 10/10/10 16:39, En/na Luis Fernandes ha escrit:
hello,
just to say that in scanner.c
must contain this patch if relevant:
- Int Atypes [MAXDPIDS + 1] = {0};
+ Int Atypes [MAXAPIDS + 1] = {0};
and also
Dpids [NumDpids] = esPid;
+ Dtypes [NumDpids] = SI:: AC3DescriptorTag;
strn0cpy (DLangs [NumDpids], lang, MAXLANGCODE1);
and for cosmetic reasons I think this change should also contain in
both vdr, as in the plugin:
- Case 0x0F: / / ISO / IEC 13818-7 Audio with ADTS transport sytax
+ Case 0x0F: / / ISO / IEC 13818-7 Audio with ADTS transport syntax
if relevant.
Thank you, I took the relevant code from vdr-1.7.15 and didn't notice
the change in 1.7.16.
I'll try to keep the code in sync from now on, but I don't think I'll
make a release just for these changes.
Here is the patch.
Bye
--
Luca
diff -r 0ab3596d2708 -r f2e86b9ea741 scanner.c
--- a/scanner.c Sun Oct 10 17:05:54 2010 +0200
+++ b/scanner.c Sun Oct 10 17:07:12 2010 +0200
@@ -347,7 +347,7 @@ bool cChannelScanner::ParsePmt(const uns
int Ppid = pmt.getPCRPid();
int Vtype = 0;
int Apids[MAXAPIDS + 1] = { 0 }; // these lists are zero-terminated
-int Atypes[MAXDPIDS + 1] = { 0 };
+int Atypes[MAXAPIDS + 1] = { 0 };
int Dpids[MAXDPIDS + 1] = { 0 };
int Dtypes[MAXDPIDS + 1] = { 0 };
int Spids[MAXSPIDS + 1] = { 0 };
@@ -375,7 +375,7 @@ bool cChannelScanner::ParsePmt(const uns
break;
case 3: // STREAMTYPE_11172_AUDIO
case 4: // STREAMTYPE_13818_AUDIO
- case 0x0F: // ISO/IEC 13818-7 Audio with ADTS transport sytax
+ case 0x0F: // ISO/IEC 13818-7 Audio with ADTS transport syntax
case 0x11: // ISO/IEC 14496-3 Audio with LATM transport syntax
{
if (NumApids MAXAPIDS) {
@@ -488,6 +488,7 @@ bool cChannelScanner::ParsePmt(const uns
}
if (NumDpids MAXDPIDS) {
Dpids[NumDpids] = esPid;
+Dtypes[NumDpids] = SI::AC3DescriptorTag;
strn0cpy(DLangs[NumDpids], lang, MAXLANGCODE1);
NumDpids++;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-actuator-1.2.0 plugin
Hello, I'm releasing version 1.2.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. From this version it is also possible to use the plugin without an actuator, i.e. as a channel scanner only. Note that it only compiles with the current development version of vdr. The changes: - Version for current development version of vdr (= 1.7.15) - DVB-S2 support (untested, I don't have DVB-S2 hardware) - Experimental seractuator module (uses a serial port instead of a parallel port) - Complete rewrite of the channel scanner - The plugin can now work without an actuator (i.e. as a channel scanner only) with the command line option -s or --scanonly Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-actuator-1.2.0 plugin
Al 09/10/10 22:03, En/na Goga777 ha escrit: From this version it is also possible to use the plugin without an actuator, i.e. as a channel scanner only. does it mean, that with your plugin no need to use reelchannelscan plugin for creating/updating channels.conf ? Yes, but I could only test it with plain dvb-s, no dvb-s2. Also, it doesn't to a blind scan, it needs a transponder.ini file for each satellite that you want to scan. You can download those file, e.g, from http://www.fastsatfinder.com/transponders.html#transponders-sorted Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-actuator-1.2.0 plugin
Al 09/10/10 23:23, En/na Gregoire Favre ha escrit: On Sat, Oct 09, 2010 at 10:43:10PM +0200, Luca Olivetti wrote: Yes, but I could only test it with plain dvb-s, no dvb-s2. Also, it doesn't to a blind scan, it needs a transponder.ini file for each satellite that you want to scan. You can download those file, e.g, from http://www.fastsatfinder.com/transponders.html#transponders-sorted Strange, I tried to start it with : ./vdr -c /etc/vdr -w 90 -l 3 -s 'sudo /usr/local/bin/vdrpoweroff.sh' -P'xine -r' -P'actuator -s' But nothing happen (and no vdr runs) : isn't that the right way to start it ? Anything in the logs? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-actuator-1.2.0 plugin
Al 10/10/10 00:25, En/na Luca Olivetti ha escrit:
Al 09/10/10 23:23, En/na Gregoire Favre ha escrit:
On Sat, Oct 09, 2010 at 10:43:10PM +0200, Luca Olivetti wrote:
Yes, but I could only test it with plain dvb-s, no dvb-s2.
Also, it doesn't to a blind scan, it needs a transponder.ini file for
each satellite that you want to scan.
You can download those file, e.g, from
http://www.fastsatfinder.com/transponders.html#transponders-sorted
Strange, I tried to start it with :
./vdr -c /etc/vdr -w 90 -l 3 -s 'sudo /usr/local/bin/vdrpoweroff.sh'
-P'xine -r' -P'actuator -s'
But nothing happen (and no vdr runs) : isn't that the right way to start
it ?
Anything in the logs?
Oh, I know what happened :-(
Try the attached patch.
Bye
--
Luca
diff -r 3ba203b62f5d actuator.c
--- a/actuator.cSat Oct 09 17:31:56 2010 +0200
+++ b/actuator.cSun Oct 10 00:38:08 2010 +0200
@@ -1738,13 +1738,6 @@ cPluginActuator::cPluginActuator(void)
// VDR OBJECTS TO EXIST OR PRODUCE ANY OUTPUT!
statusMonitor = NULL;
PosTracker = NULL;
- if (!ScanOnly) {
-fd_actuator = open(/dev/actuator,0);
-if (fd_actuator0) {
- esyslog(cannot open /dev/actuator);
- exit(1);
-}
- }
cThemes::Save(actuator, Theme);
}
@@ -1805,8 +1798,14 @@ bool cPluginActuator::Initialize(void)
bool cPluginActuator::Initialize(void)
{
// Initialize any background activities the plugin shall perform.
- if (!ScanOnly)
+ if (!ScanOnly) {
+fd_actuator = open(/dev/actuator,0);
+if (fd_actuator0) {
+ esyslog(cannot open /dev/actuator);
+ return false;
+}
PosTracker=new cPosTracker();
+ }
return true;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 08/10/10 00:37, En/na Mika Laitio ha escrit: with vdr 1.7.16 and reelbox plugin (eHD) this channels are ok in live tv (even with some BER with my dish, Warszawa seemed to be weaker, i also got UNC's there but no real problems, only a small picture distortion some times) And Reinhard also sees them ok with vdr-xine, while I still have problems both with vdr-xine and the dxr3 :-/ I have used to have problems for watching some pretty weak signal DVB-T channels also which seemed always lost the log after 5 minute usage, until vdr killed and restarted itself. The problem went away for me after I changed from the vdr settings the EPG scan mode to newer or something like that. (I am not near to my vdr at the moment, so I can not check the exact location and text for this menu in the vdr.) Can you test, whether the same thing could help also you? No need, I already determined that the problem is due to my skystar2: it only has 6 hw pid filters, and when userspace needs more it switches to full-ts streaming, however those transponders exceed the capacity of the skystar2. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Why won't my DVB-S work?
En/na Simon Baxter ha escrit: My setup.conf for the LNB has: LnbFrequHi = 11300 LnbFrequLo = 10750 LnbSLOF = 12500 If that's an universal lnb the correct settings are LnbFrequHi = 10600 LnbFrequLo = 9750 LnbSLOF = 11700 Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
En/na Newsy Paper ha escrit: which DVB card and which driver version do you use? I also had those problems with an old skystar 2. Nr of pid filters was too low and datarate of the stream was to high to transport it completely I was told. The card is indeed a skystar 2, but these are fairly low bitrate channels, and dvbstream has no problem with them (hence excluding an issue with the card or the signal). It's true that dvbstream is only streaming the audio and video pids, while vdr is also using filters for eit/pmt/sdt, but I don't really think that's a problem, otherwise I'd see it with other, more demanding, channels, that actually work fine. I have no problem with various hd channels and also have no problem recording/watching several channels at once (on the same transponder), so that also should exclude a problem with the available amount of pid filters. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
En/na Luca Olivetti ha escrit: En/na Newsy Paper ha escrit: which DVB card and which driver version do you use? I also had those problems with an old skystar 2. Nr of pid filters was too low and datarate of the stream was to high to transport it completely I was told. The card is indeed a skystar 2, but these are fairly low bitrate channels, and dvbstream has no problem with them (hence excluding an issue with the card or the signal). It's true that dvbstream is only streaming the audio and video pids, while vdr is also using filters for eit/pmt/sdt, but I don't really think that's a problem, otherwise I'd see it with other, more demanding, channels, that actually work fine. I have no problem with various hd channels and also have no problem recording/watching several channels at once (on the same transponder), so that also should exclude a problem with the available amount of pid filters. Ah, I see, you refer to the global bandwidth of the transponder and that it could exceed the capacity of the skystar2 if more than 6 pid filters are needed and it switches to full ts streaming. That could indeed be the case, I'll check when I'm at home. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 06/10/10 10:11, En/na Luca Olivetti ha escrit: En/na Luca Olivetti ha escrit: En/na Newsy Paper ha escrit: which DVB card and which driver version do you use? I also had those problems with an old skystar 2. Nr of pid filters was too low and datarate of the stream was to high to transport it completely I was told. The card is indeed a skystar 2, but these are fairly low bitrate channels, and dvbstream has no problem with them (hence excluding an issue with the card or the signal). ... Ah, I see, you refer to the global bandwidth of the transponder and that it could exceed the capacity of the skystar2 if more than 6 pid filters are needed and it switches to full ts streaming. That could indeed be the case, I'll check when I'm at home. That's it: I temporarily removed from device.c the extra filters and I can see those channels perfectly. Is there a workaround (apart from removing the eit/pat/nit scan or changing the card)? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 04/10/10 21:07, En/na Luca Olivetti ha escrit: Al 04/10/10 20:55, En/na Luca Olivetti ha escrit: Al 04/10/10 20:10, En/na Luca Olivetti ha escrit: Al 04/10/10 19:36, En/na Luca Olivetti ha escrit: Now I tried with a clean vdr (1.7.16), no patches (though my patches didn't modify the signal path at all), only the vdr-xine plugin and the problem is still there. BTW, the same xine I'm using with the plugin, has no problem playing the stream from dvbstream. If I start a recording and try to play the ts file with, say, mplayer, it has the same problems, with a lot of messages in the console: FWIW, if I set the audio pid to 0, the video is perfect. With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture). The reverse is also true: if I set the video pid to 0, the audio is fine. Any hint on how to debug this? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 05/10/10 20:49, En/na Reinhard Nissl ha escrit: FWIW, if I set the audio pid to 0, the video is perfect. With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture). The reverse is also true: if I set the video pid to 0, the audio is fine. Any hint on how to debug this? Do you use this patch with vdr-xine? http://www.mail-archive.com/vdr@linuxtv.org/msg11991.html Yes. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 05/10/10 21:27, En/na Reinhard Nissl ha escrit: Hi, Am 05.10.2010 21:00, schrieb Luca Olivetti: Al 05/10/10 20:49, En/na Reinhard Nissl ha escrit: FWIW, if I set the audio pid to 0, the video is perfect. With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture). The reverse is also true: if I set the video pid to 0, the audio is fine. Any hint on how to debug this? Do you use this patch with vdr-xine? http://www.mail-archive.com/vdr@linuxtv.org/msg11991.html Yes. Does this happen with 1.7.15 too? I'm still at 1.7.15 -- didn't find time to update yet. Yes, I just tried 1.7.16 to see if if was automagically solved. I also tried with vdr-1.7.9 (a random version I used since I had the tarball around) and it does the same. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 05/10/10 21:50, En/na Luca Olivetti ha escrit: Does this happen with 1.7.15 too? I'm still at 1.7.15 -- didn't find time to update yet. Yes, I just tried 1.7.16 to see if if was automagically solved. I also tried with vdr-1.7.9 (a random version I used since I had the tarball around) and it does the same. I tried vdr 1.6.0 and it does the same *but* setting the video pid and/or the audio pids to 0 doesn't seem to fix it. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 04/10/10 18:40, En/na Lars Bläser ha escrit: Well, I'm pretty sure the ber and the unc are right: I tried to stream those channels with dvbstream and they play perfectly, so the signal is ok. hi, to see if unc and ber are working you should provoke those errors by weakening the signal and only if you see a change you know that it is working, if you allway see a 0 you can'n be shure if its working the way you expect it imho there is no difference in femon between is not provided by driver and 0 Hey, I know the signal is ok: dvbstream streams those channels perfectly, no artefacts, no strange sound, no jumps, and that would be impossible if the signal were not good. Now I tried with a clean vdr (1.7.16), no patches (though my patches didn't modify the signal path at all), only the vdr-xine plugin and the problem is still there. BTW, the same xine I'm using with the plugin, has no problem playing the stream from dvbstream. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 04/10/10 19:36, En/na Luca Olivetti ha escrit: Now I tried with a clean vdr (1.7.16), no patches (though my patches didn't modify the signal path at all), only the vdr-xine plugin and the problem is still there. BTW, the same xine I'm using with the plugin, has no problem playing the stream from dvbstream. If I start a recording and try to play the ts file with, say, mplayer, it has the same problems, with a lot of messages in the console: mpeg2video @ 0x8902640]ac-tex damaged at 10 1 [mpeg2video @ 0x8902640]skipped MB in I frame at 28 6 [mpeg2video @ 0x8902640]ac-tex damaged at 10 9 [mpeg2video @ 0x8902640]ac-tex damaged at 23 17 [mpeg2video @ 0x8902640]ac-tex damaged at 24 18 [mpeg2video @ 0x8902640]Warning MVs not available [mpeg2video @ 0x8902640]concealing 220 DC, 220 AC, 220 MV errors [mpeg2video @ 0x8902640]concealing 220 DC, 220 AC, 220 MV errors [mpeg2video @ 0x8902640]concealing 220 DC, 220 AC, 220 MV errors [mpeg2video @ 0x8902640]mb incr damaged [mpeg2video @ 0x8902640]ac-tex damaged at 0 32 [mpeg2video @ 0x8902640]mb incr damaged [mpeg2video @ 0x8902640]invalid cbp at 23 4 [mpeg2video @ 0x8902640]ac-tex damaged at 10 5 [mpeg2video @ 0x8902640]slice mismatch [mpeg2video @ 0x8902640]ac-tex damaged at 17 7 [mpeg2video @ 0x8902640]invalid mb type in P Frame at 4 9 [mpeg2video @ 0x8902640]slice mismatch [mpeg2video @ 0x8902640]ac-tex damaged at 24 11 [mpeg2video @ 0x8902640]invalid cbp at 16 12 [mpeg2video @ 0x8902640]slice mismatch [mpeg2video @ 0x8902640]ac-tex damaged at 9 14 [mpeg2video @ 0x8902640]ac-tex damaged at 9 15 [mpeg2video @ 0x8902640]ac-tex damaged at 4 16 [mpeg2video @ 0x8902640]mb incr damaged [mpeg2video @ 0x8902640]ac-tex damaged at 16 18 [mpeg2video @ 0x8902640]ac-tex damaged at 9 19 [mpeg2video @ 0x8902640]mb incr damaged [mpeg2video @ 0x8902640]ac-tex damaged at 4 21 [mpeg2video @ 0x8902640]ac-tex damaged at 16 22 [mpeg2video @ 0x8902640]slice mismatch [mpeg2video @ 0x8902640]invalid mb type in P Frame at 7 24 [mpeg2video @ 0x8902640]invalid mb type in P Frame at 3 25 [mpeg2video @ 0x8902640]mb incr damaged [mpeg2video @ 0x8902640]mb incr damaged [mpeg2video @ 0x8902640]invalid cbp at 16 28 [mpeg2video @ 0x8902640]ac-tex damaged at 28 29 [mpeg2video @ 0x8902640]invalid mb type in P Frame at 13 30 [mpeg2video @ 0x8902640]ac-tex damaged at 12 31 [mpeg2video @ 0x8902640]slice mismatch [mpeg2video @ 0x8902640]invalid cbp at 24 33 [mpeg2video @ 0x8902640]ac-tex damaged at 37 34 [mpeg2video @ 0x8902640]invalid cbp at 3 35 [mpeg2video @ 0x8902640]Warning MVs not available etc. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 04/10/10 20:10, En/na Luca Olivetti ha escrit: Al 04/10/10 19:36, En/na Luca Olivetti ha escrit: Now I tried with a clean vdr (1.7.16), no patches (though my patches didn't modify the signal path at all), only the vdr-xine plugin and the problem is still there. BTW, the same xine I'm using with the plugin, has no problem playing the stream from dvbstream. If I start a recording and try to play the ts file with, say, mplayer, it has the same problems, with a lot of messages in the console: FWIW, if I set the audio pid to 0, the video is perfect. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 04/10/10 20:55, En/na Luca Olivetti ha escrit: Al 04/10/10 20:10, En/na Luca Olivetti ha escrit: Al 04/10/10 19:36, En/na Luca Olivetti ha escrit: Now I tried with a clean vdr (1.7.16), no patches (though my patches didn't modify the signal path at all), only the vdr-xine plugin and the problem is still there. BTW, the same xine I'm using with the plugin, has no problem playing the stream from dvbstream. If I start a recording and try to play the ts file with, say, mplayer, it has the same problems, with a lot of messages in the console: FWIW, if I set the audio pid to 0, the video is perfect. With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture). Bye. -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 04/10/10 21:41, En/na Reinhard Nissl ha escrit: Hi, Am 04.10.2010 21:07, schrieb Luca Olivetti: Al 04/10/10 20:55, En/na Luca Olivetti ha escrit: Al 04/10/10 20:10, En/na Luca Olivetti ha escrit: Al 04/10/10 19:36, En/na Luca Olivetti ha escrit: Now I tried with a clean vdr (1.7.16), no patches (though my patches didn't modify the signal path at all), only the vdr-xine plugin and the problem is still there. BTW, the same xine I'm using with the plugin, has no problem playing the stream from dvbstream. If I start a recording and try to play the ts file with, say, mplayer, it has the same problems, with a lot of messages in the console: FWIW, if I set the audio pid to 0, the video is perfect. With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture). Please have a look at http://sourceforge.net/mailarchive/forum.php?thread_name=4C93BD03.80702%40gmx.deforum_name=xine-devel and try changing buffer sizes. Just a guess. I tried setting video buffers to 5000 and audio buffers to 500, but it didn't change anything. Unsurprising, since with the default settings I have no problem with HD and these channels are SD and at a fairly low bitrate. Besides, the same xine with the same configuration had no problem playing the stream from dvbstream, and the fact that all output plugins are doing the same points to a lower level problem. The dxr3 plugin still uses pes video, so I first suspected cTsToPes, but the recording test made me think of something else. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 04/10/10 22:21, En/na Luca Olivetti ha escrit: Besides, the same xine with the same configuration had no problem playing the stream from dvbstream, and the fact that all output plugins are doing the same points to a lower level problem. The dxr3 plugin still uses pes video, so I first suspected cTsToPes, but the recording test made me think of something else. I took a look at the log and I see a lot of TS continuity errors: Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] receiver on device 1 thread started (pid=8337, tid=8404) Oct 4 22:30:21 vdr.ventoso.local vdr: [8405] TS buffer on device 1 thread started (pid=8337, tid=8405) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (1) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (12) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (3) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (13) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (0) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (3) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (7) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (8) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (15) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] cVideoRepacker: switching to MPEG1/2 mode Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] cVideoRepacker: operating in MPEG1/2 mode Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (1) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (5) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] PES packet shortened to 798 bytes (expected: 1166 bytes) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] cAudioRepacker(0xC0): skipped 104 bytes to sync on next audio frame Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (11) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (4) . Oct 4 22:30:22 vdr.ventoso.local vdr: [8404] TS continuity error (6) Oct 4 22:30:22 vdr.ventoso.local vdr: [8404] PES packet shortened to 1104 bytes (expected: 1166 bytes) Oct 4 22:30:22 vdr.ventoso.local vdr: [8404] TS continuity error (12) .Oct 4 22:30:22 vdr.ventoso.local vdr: [8404] TS continuity error (9) Oct 4 22:30:22 vdr.ventoso.local vdr: [8404] PES packet shortened to 982 bytes (expected: 1166 bytes) Oct 4 22:30:22 vdr.ventoso.local vdr: [8404] TS continuity error (15) As soon as I set the audio pid to 0 there are no errors at all. I also don't get those messages with the dxr3 plugin, but it gets confused by spurious and continuous audio parameters change: Oct 4 22:36:51 vdr.ventoso.local vdr: [8412] dxr3: audiodecoder: sample rate=44100 Oct 4 22:36:51 vdr.ventoso.local vdr: [8412] dxr3: audiodecoder: unexpected parameter change Oct 4 22:36:51 vdr.ventoso.local vdr: [8412] dxr3: audiodecoder: skipping 288 broken data bytes Oct 4 22:36:51 vdr.ventoso.local vdr: [8412] dxr3: audiodecoder: sample rate=48000 Oct 4 22:36:51 vdr.ventoso.local vdr: [8412] dxr3: audiodecoder: channels=1 Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 04/10/10 22:38, En/na Luca Olivetti ha escrit: Al 04/10/10 22:21, En/na Luca Olivetti ha escrit: Besides, the same xine with the same configuration had no problem playing the stream from dvbstream, and the fact that all output plugins are doing the same points to a lower level problem. The dxr3 plugin still uses pes video, so I first suspected cTsToPes, but the recording test made me think of something else. I took a look at the log and I see a lot of TS continuity errors: I see that those TS continuity messages are generated in vdr-xine... Oct 4 22:36:51 vdr.ventoso.local vdr: [8412] dxr3: audiodecoder: sample rate=44100 Oct 4 22:36:51 vdr.ventoso.local vdr: [8412] dxr3: audiodecoder: unexpected parameter change ..as those are generated in the dxr3. Somehow both of them (and streamdev too) are getting the data wrong. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvb-s2 missing modulation values
Al 03/10/10 14:53, En/na Luca Olivetti ha escrit: Hello, I cannot currently receive dvb-s2 channels, but I'd like to update my plugin to work more or less correctly with it (even if I only have a couple of users). The wikipedia page http://en.wikipedia.org/wiki/DVB-S2 says that dvb-s2 has 4 possible modulations: QPSK, 8PSK, 16APSK and 32APSK. Those are defined in s2api, frontend.h, as QPSK, PSK_8, APSK_16 and APSK_32. There's also a DQPSK, which I suppose is for directv? (see below). But in vdr's dvbdevice.c, ModulationValues only maps to strings QPSK, PSK_8 and APSK_16. APSK_32 and DQPSK are missing. I read transponder information from ini files downloadable from http://www.fastsatfinder.com/transponders.html#transponders-sorted I examined all files there, and for S2 transponders I found these definitions: QPSK (this is easy) 8PSK (supposedly maps to PSK_8) 16APSK (supposedly maps to APSK_16) DIRECTV (supposedly maps to DQPSK) so maybe APSK_32 isn't really needed? To complicate matters further, if I try to edit a channel, vdr offers me the following modulations: QAM16, QAM32, QAM64, QAM128, QAM256, QPSK, 8PSK, 16APSK, VSB8, VSB16, QAMAUTO, QAM modes aren't only for cable? What are VSB for? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Hello, this has been bugging me for a while, but since it happens on channels I don't usually watch, I didn't ask before. There are some channels that are completely unwatchable: even with a perfect signal (at least according to femon) I can only see blocking artefacts and chirping sound. I tried vdr-xine, the dxr3 or vlc/mplayer through streamdev, the result is always the same. Here are some of the channels where this is happening right now: Mirabelle TV;EUTELSAT:10972:VC78M2O0S0:S5.0W:29950:1061=2:10...@3:0:0:4134:1375:20600:0 Normandie TV;EUTELSAT:11096:VC78M2O0S0:S5.0W:29950:851=2:852=...@3:0:0:405:1375:20400:0 TV8 MONT BLANC;EUTELSAT:11096:VC78M2O0S0:S5.0W:29950:881=2:882=...@3,883=...@3:0:0:408:1375:20400:0 TVN Warszawa;TVN:11508:VC56M2O0S0:S13.0E:27500:512=2:650=...@4:572:0:15801:318:1600:0 TVP Kultura;CYFRA +:11488:HC56M2O0S0:S13.0E:27500:172=2:128=...@4:513:0:5113:318:1500:0 PULS;CYFRA +:11488:HC56M2O0S0:S13.0E:27500:171=2:124=...@4:0:0:5112:318:1500:0 TRACE TV;CYFRA +:11488:HC56M2O0S0:S13.0E:27500:164=2:96=...@4,97=...@4:0:0:5105:318:1500:0 (in fact all polish channels on this transponder do the same) RTV;Harmonic:11471:VM2O0S0:S13.0E:27500:611=2:6...@3:0:0:10622:318:1400:0 and many more. Any idea? -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 03/10/10 23:10, En/na VDR User ha escrit: On Sun, Oct 3, 2010 at 12:23 PM, Luca Olivettil...@ventoso.org wrote: Hello, this has been bugging me for a while, but since it happens on channels I don't usually watch, I didn't ask before. There are some channels that are completely unwatchable: even with a perfect signal (at least according to femon) I can only see blocking artefacts and chirping sound. That sounds like the symptoms of a bad signal. Are you sure the driver you're using is reporting the correct statistics to femon? Several drivers don't. Yes, it seems like a bad signal, but femon is reporting a ber and unc of 0 (I really don't trust snr and strength, but ber and unc should be just about right). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer)
Al 04/10/10 00:20, En/na VDR User ha escrit: On Sun, Oct 3, 2010 at 3:06 PM, Luca Olivettil...@ventoso.org wrote: Yes, it seems like a bad signal, but femon is reporting a ber and unc of 0 (I really don't trust snr and strength, but ber and unc should be just about right). The point I was trying to make is that you can't rely on femon to give you accurate statistics unless the dvb driver provides accurate statistics, which very many don't. Try plugging an analog signal meter into that cable and you'll likely see a different result then what you see in femon. Well, I'm pretty sure the ber and the unc are right: I tried to stream those channels with dvbstream and they play perfectly, so the signal is ok. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with VDR 1.7.15 and dxr3plugin 0.2.10
Al 02/10/10 09:51, En/na Teemu Suikki ha escrit: It's annoying to have two almost working versions. :) git version is fine except for the audio and subtitles, and 0.2.11 is fine except for the OSD. Mmh, strange, my osd is working (with the usual problems but mostly working). Note that my version is not exactly the same as the cvs one, but there should be no differences wrt the osd. So now we just need to combine the working features of both versions. :) They diverged too much, that's why I first tried the git version then I went back to the cvs one. Bye. -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cSdtFIlter and LinkChannels
Al 02/10/10 12:19, En/na Goga777 ha escrit: I'm trying to understand cSdtFilter in order to write a channel scanner. will it the plugin for vdr with possibility to scan dvb-s2 channels ? Hi, no, it's integrated in the actuator plugin. It should work with s2 channels, but I've no means to check it (currently using dvb-s and there are no interesting channels for me in s2). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] cSdtFIlter and LinkChannels
Hello, I'm trying to understand cSdtFilter in order to write a channel scanner. I see that when it finds a SI::NVODReferenceDescriptorTag it will add it to the previously found channel with channel-SetLinkChannels, but it only does if it is in the current section (channel is a local variable) while the sdt could span several sections. From the specifications here http://neuron2.net/library/mpeg2/iso13818-1.pdf and here http://www.dvb.org/technology/standards/a005r5.tm1324r13.tr101211.v1.10.1.pdf I don't understand if this mechanism is correct, shouldn't the time_shifted_services link to the NVOD_reference? Besides, I don't see that the relation between a channels and its linkchannels is preserved in channels.conf (though I don't really care). I also see that cSdtFilter starts processing with the first section, and that shouldn't really be necessary as long as one processes all sections. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Trouble with picture Lost lock/regained lock
Al 05/09/10 22:54, En/na Scott Waye ha escrit: In particular the lost lock/regained lock looks strange. Searching through the archives suggests this could be due to a weak signal. I ran femon and got this: FE: Conexant CX24116/CX24118 (DVBS) status SCVYL | signal d840 | snr d800 | ber | unc | FE_HAS_LOCK status SCVYL | signal d8c0 | snr d999 | ber | unc | FE_HAS_LOCK status SCVYL | signal d840 | snr d666 | ber | unc | FE_HAS_LOCK status SCVYL | signal d840 | snr d999 | ber 3e71 | unc 00a6 | FE_HAS_LOCK status SCVYL | signal d840 | snr d999 | ber 3e71 | unc 00a6 | FE_HAS_LOCK status SCVYL | signal d8c0 | snr db33 | ber 3e71 | unc 00a6 | FE_HAS_LOCK status SCVYL | signal d8c0 | snr d800 | ber 0081 | unc | FE_HAS_LOCK status SCVYL | signal d840 | snr db33 | ber | unc | FE_HAS_LOCK Which looks ok, the snr value seems high enough, so any other reason why the lock would be lost. No, there are 3 lines where the unc is not 0. Those indicate that the demodulator couldn't correct some of the data, so that's probably the cause of your problems. As an aside, every card reports those values in a different way, mine for example shows unc at 0 even with a much higher ber, and the unc is supposed to be cumulative, not instantaneous. I don't trust neither the signal strength nor the snr, partially trust the ber, but definitely the only value that means something is the unc (provided you decipher if your frontend give a cumulative value - i.e. ever increasing- or instantaneous -i.e it goes back to 0). Bye -- Lua ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video audio, etc.
En/na Goga777 ha escrit: Provided that I disable Force Full GPU Scaling, the tv reports a 50Hz signal. if you disabled full gpu scaling , how upscaling will work really ? what and how will upscale SD video to 1080p ? According to the help text, that option is only useful if the display resolution is different than the output resolution, so since both are 1920x1080 the option has no effect whatsoever (other than forcing the refresh rate at 60Hz). So even with that option disabled it will upscale SD video to 1080p. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video audio, etc.
En/na JJussi ha escrit: I had (up till today) problem with my NVidia, what ever I described in xorg.conf, output was 60Hz.. Command what fixed everything: Option FlatPanelProperties Scaling=Native in Section Screen That's the same as disabling Force full gpu scaling in nvidia-settings. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video audio, etc.
En/na Goga777 ha escrit: if you disabled full gpu scaling , how upscaling will work really ? what and how will upscale SD video to 1080p ? This setting is only useful if your display device can't scale on its own or the scaling is worse quality. If you enable it the card will always output native resolution at native refresh. If disabled the gpu will not touch the mode and output whatever you tell it to, in which case the display itself will have to scale the mode as needed. let's have a look on the following situation. I have full HD TV set, which of course can upscale. TV My xorg.conf has default mode - 1080p can be 2 situation With vdr and vdr-xine I'm watching SD 576i channels and after that I switch to HD 1080i channel. Does graphic card do upscale in first variant (with SD channel) ? Yes (I thought I already told you that). And in the second case it will deinterlace. Afaik vdr-xine cannot switch the display resolution/frequency to match the input signal. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Advice on new motherboard, xineliboutput, vdpau, hdmi video audio, etc.
Al 26/08/10 10:33, En/na Thomas Hilber ha escrit: to verify. Even the Xorg.0.log lies about the fact that 50Hz are active but in reality it uses 60Hz. Maybe nVidia has fixed that in the meantime. To watch HD broadcasts I use the hdmi output on my laptop. It isn't configured in xorg but I just configure it on the fly with nvidia-settings in twin-view mode (the laptop panel at 60Hz and the hdmi port at 50Hz). Provided that I disable Force Full GPU Scaling, the tv reports a 50Hz signal. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with VDR 1.7.15 and dxr3plugin 0.2.10
En/na Teemu Suikki ha escrit: OSD is working 100% except for the subtitles. To me it looks like it is the subtitle font rendering that is bugged, sometimes you can see unfilled letters where there's only the white outline and inside is transparent.. This might be VDR bug actually, I have no idea where the rendering takes place? You could try the cvs version from sourceforge (though I don't know if Ville committed the latest changes I made, which, IIRC, showed a message for h264 encoded channels). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] frequent xine crashes with vdr
Al 17/08/10 18:40, En/na VDR User ha escrit: On Tue, Aug 17, 2010 at 12:45 AM, martinezmarti...@embl.de wrote: Unfortunately I can not reproduce it anymore, because in the meantimeI installed a newer version of xine-lib and the problem disappeared. What I notice is that using vdpau, on 28e BBC HD for example drops many frames (unwatchable, although cpu load remains low), whereas using xv the same channels plays perfectly (although ITV1 HD even using xv drops some frames) So for me it is xv for now as vdpau does not seem quite mature I read a lot of complaints about BBC HD. That surely appears to be a problem channel. However, vdpau is working great for many users, hopefully soon you'll be able to join us. ;) BBCHD works perfectly with vdpau here, they changed the codec around last June, but the vdpau developers fixed it. Make sure you're using the hg repository for xine 1.2 http://hg.debian.org/hg/xine-lib/xine-lib-1.2 (though I last updated it last June). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor integration to vdr
Al 23/06/10 23:04, En/na Timothy D. Lenz ha escrit: I also looked at the Actuator plugin because I am interested in getting something going with c-band and thought maybe it included rotor commands. Don't it does, doesn't look like it's been updated since vdr-1.6.0, Hi, I didn't update the released version (it seems there are only two users of the plugin), but I'm using it with vdr 1.7.15 (with the transponder tuning and channel scanning commented out, I don't have much time or need to work on that). and requires a custom kernel module. I don't mind building custom electronics and was planing to anyway. But I don't want to have to hack code into the kernel. It's a really simple out of tree module, you don't need to hack the kernel, just to compile the module and insmod it. It hasn't caused me any problem in the many years I have used it. BTW, the module uses a parallel port, and since these are becoming difficult to find, I wrote another, unreleased, one that uses a serial port (even an usb to serial adapter should work). Of course I'm not (still) using it in production, so it's not as tested as the one using the parallel port. I think they have boxes that provide actuator control from rotor diseqc commands anyway which brings us back to including it. Well, yes, but I'm cheap and I preferred to spend 5€ in components tucked inside the computer instead of buying a 100€ v-box, have another box laying around and having less control over the whole positioning process. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor integration to vdr
Al 24/06/10 20:18, En/na Timothy D. Lenz ha escrit: On 6/24/2010 1:37 AM, Luca Olivetti wrote: It's a really simple out of tree module, you don't need to hack the kernel, just to compile the module and insmod it. It hasn't caused me any problem in the many years I have used it. BTW, the module uses a parallel port, and since these are becoming difficult to find, I wrote another, unreleased, one that uses a serial port (even an usb to serial adapter should work). Of course I'm not (still) using it in production, so it's not as tested as the one using the parallel port. I looked on mine and while it doesn't have a port on the back, it does have a header on the board. If intel had their way, there'd be not floppy, parallel or serial ports on any new board :(. With a serial port, the data stream could be brought out to parallel giving you 8 pins. My implementation doesn't use the data stream, it just uses the control pins of the serial port (RTS as rotate west output, DTR as rotate east output and CTS as the pulse counter input). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr xine-lib eac3
Al 25/03/10 16:08, En/na Jose Alberto Reguero ha escrit: Patch for xine-lib that don't need to patch remux.c to work. Today I applied this patch (strange it isn't in xine-lib-1.2 yet) but there's still no sound on tvehd (vdr 1.7.15, vdr-xine and playing the ts directly through xine). Do I need some special options to configure xine-lib for this patch to take effect? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xine - VDpau config help
Al 12/06/10 17:23, En/na Jouni Karvo ha escrit: My current settings in .xine/config (which I found by reading the source code - is there any documentation anywhere?): I cannot help with the apparent lack of deinterlacing[*], but those options are available in the xine gui in the video tab, once you set the level to Master of the known universe. [*]maybe your card cannot manage temporal-spatial, or maybe the broadcaster is flagging the frames as progressive when they're interlaced. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr and aac support
Al 16/05/10 14:28, En/na Klaus Schmidinger ha escrit: Ok, here's a complete patch that attempts to handle audio types. It is untested, so please use it with care. Please let me know whether this works with your audio types in live mode and with replaying recordings. As of yesterday I can tune to a dvb-t hd channel where vdr doesn't pick the audio pid, my tv picks it and identifies it as dolby digital plus. I tried this patch but vdr still doesn't pick the audio pid. If I disable channel updating and manually introduce the pid, I cannot decode the audio with xine. vlc (through streamdev) doesn't decode it either but it tells me that it's of type eac3. This is the output of dvbsnoop: $ dvbsnoop -adapter 1 0 dvbsnoop V1.4.00 -- http://dvbsnoop.sourceforge.net/ SECT-Packet: 0001 PID: 0 (0x), Length: 36 (0x0024) Time received: Tue 2010-05-18 21:17:20.758 : 00 b0 21 9c 40 cd 00 00 00 00 e0 10 9c 41 e3 e8 @a.. 0010: 9c 42 e7 d0 9c 43 eb b8 9c 45 e7 e4 9c 46 eb cc .B...C...E...F.. 0020: 9e 44 56 b1.DV. PID: 0 (0x) [= assigned for: ISO 13818-1 Program Association Table (PAT)] Guess table from table id... PAT-decoding Table_ID: 0 (0x00) [= Program Association Table (PAT)] section_syntax_indicator: 1 (0x01) (fixed): 0 (0x00) reserved_1: 3 (0x03) Section_length: 33 (0x0021) Transport_Stream_ID: 4 (0x9c40) reserved_2: 3 (0x03) Version_number: 6 (0x06) current_next_indicator: 1 (0x01) [= valid now] Section_number: 0 (0x00) Last_Section_number: 0 (0x00) Program_number: 0 (0x) reserved: 7 (0x07) Network_PID: 16 (0x0010) Program_number: 40001 (0x9c41) reserved: 7 (0x07) Program_map_PID: 1000 (0x03e8) Program_number: 40002 (0x9c42) reserved: 7 (0x07) Program_map_PID: 2000 (0x07d0) Program_number: 40003 (0x9c43) reserved: 7 (0x07) Program_map_PID: 3000 (0x0bb8) Program_number: 40005 (0x9c45) reserved: 7 (0x07) Program_map_PID: 2020 (0x07e4) Program_number: 40006 (0x9c46) reserved: 7 (0x07) Program_map_PID: 3020 (0x0bcc) CRC: 2655278769 (0x9e4456b1) == The channel is the one with pmt pid 1000 $ dvbsnoop -adapter 1 1000 dvbsnoop V1.4.00 -- http://dvbsnoop.sourceforge.net/ SECT-Packet: 0001 PID: 1000 (0x03e8), Length: 46 (0x002e) Time received: Tue 2010-05-18 21:18:11.126 : 02 b0 2b 9c 41 d7 00 00 e3 e9 f0 00 1b e3 e9 f0 ..+.A... 0010: 0a 28 04 64 00 28 3f 2a 02 fe ef 06 e4 4c f0 0a .(.d.(?*.L.. 0020: 7a 02 80 c2 0a 04 73 70 61 00 e4 8e 54 ed z.spa...T. PID: 1000 (0x03e8) Guess table from table id... PMT-decoding Table_ID: 2 (0x02) [= Program Map Table (PMT)] section_syntax_indicator: 1 (0x01) (fixed '0'): 0 (0x00) reserved_1: 3 (0x03) Section_length: 43 (0x002b) Program_number: 40001 (0x9c41) reserved_2: 3 (0x03) Version_number: 11 (0x0b) current_next_indicator: 1 (0x01) [= valid now] Section_number: 0 (0x00) Last_Section_number: 0 (0x00) reserved_3: 7 (0x07) PCR PID: 1001 (0x03e9) reserved_4: 15 (0x0f) Program_info_length: 0 (0x) Stream_type loop: Stream_type: 27 (0x1b) [= AVC video stream as defined in ITU-T Rec. H.264 | ISO/IEC 14496-10 Video] reserved_1: 7 (0x07) Elementary_PID: 1001 (0x03e9) reserved_2: 15 (0x0f) ES_info_length: 10 (0x000a) MPEG-DescriptorTag: 40 (0x28) [= AVC_video_descriptor] Descriptor_length: 4 (0x04) : 64 00 28 3f d.(? MPEG-DescriptorTag: 42 (0x2a) [= AVC_timing_and_HRD_descriptor] Descriptor_length: 2 (0x02) : fe ef .. Stream_type: 6 (0x06) [= ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data] reserved_1: 7 (0x07) Elementary_PID: 1100 (0x044c) reserved_2: 15 (0x0f) ES_info_length: 10 (0x000a) DVB-DescriptorTag: 122 (0x7a) [= reserved_descriptor] Descriptor_length: 2 (0x02) ERROR: unimplemented descriptor (dvb context), Report! Descriptor-data: : 80 c2 .. MPEG-DescriptorTag: 10 (0x0a) [= ISO_639_language_descriptor] Descriptor_length: 4 (0x04) ISO639_language_code: spa Audio_type: 0 (0x00) [= undefined] CRC: 3834533101 (0xe48e54ed) == Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr and aac support
Al 18/05/10 21:20, En/na Luca Olivetti ha escrit:
Al 16/05/10 14:28, En/na Klaus Schmidinger ha escrit:
Ok, here's a complete patch that attempts to handle audio types.
It is untested, so please use it with care.
Please let me know whether this works with your audio types in
live mode and with replaying recordings.
As of yesterday I can tune to a dvb-t hd channel where vdr doesn't pick
the audio pid, my tv picks it and identifies it as dolby digital plus.
I tried this patch but vdr still doesn't pick the audio pid.
Unsurprising, since in pat.c it doesn't check for
SI::EnhancedAC3DescriptorTag while it should according to your patch
posted on 14-05-2010:
--- pat.c 2010/03/27 15:17:46 2.9
+++ pat.c 2010/05/14 14:12:31
@@ -401,6 +401,7 @@
switch (d-getDescriptorTag()) {
case SI::AC3DescriptorTag:
case SI::EnhancedAC3DescriptorTag:
+case SI::AACDescriptorTag:
dpid = esPid;
ProcessCaDescriptors = true;
break;
(i.e. it only adds SI::AACDescriptorTag)
I must have missed some patch along the way :-/
Bye
--
Luca
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr and aac support
Al 18/05/10 21:43, En/na Luca Olivetti ha escrit: (i.e. it only adds SI::AACDescriptorTag) I must have missed some patch along the way :-/ Ok, they were in the Recording DVB-T HD infrance (sic). It appears that spain is using the same standard. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
