Re: [vdr] shows recording
On 22/05/14 23:21, jacek burghardt wrote: Coming from mythtv I wonder if there is a way to search for new shows of series. Does epgsearch has such fundion I use vdradminp-an I would love to be able to have it search and record new shows If you are using DVB-T in the UK or one of the NORDIG countries, this plugin may help: http://projects.vdr-developer.org/projects/vdrtva Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG not purged if -E- option set
On 31/08/13 14:22, Klaus Schmidinger wrote: Please try the attached patch. This one does compile ;-). Klaus I've confirmed the schedules do now expire with the -E- option set. Many thanks again. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] EPG not purged if -E- option set
I run VDR 2.0.2 on a Raspberry Pi. The device runs continuously, so to avoid wearing out the SD card or needlessly spinning-up the USB disk drive I run VDR with the -E- option to prevent saving the EPG every 10 minutes. Today I created a timer for one programme in a long-running series and was surprised to find that the Series Link plugin had scheduled timers for earlier episodes, some broadcast several weeks ago! These timers were then automatically deleted of course. Looking at the code, it seems that cleaning up the EPG schedules is a side-effect of writing the data file, so the -E- option disables both. Having the EPG grow unbounded is perhaps not desirable on devices such as the Raspberry Pi which have limited memory and CPU. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG not purged if -E- option set
On 31/08/13 14:22, Klaus Schmidinger wrote: Please try the attached patch. This one does compile ;-). Klaus I'll leave the patched version running for a while to check that expiry is working. Many thanks. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Permissions in vdr-1.7.35 tarball
The directories in the vdr-1.7.35 tarball are set to mode 700. If, like me, you run vdr directly from the source tree but under a different user to the one you use for compiling, your plugins will not load. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR on Raspberry Pi
On 30/09/12 23:04, Laurence Abbott wrote: On 30 September 2012 19:50, Davev...@pickles.me.uk wrote: I'm using VOMP on Raspberry Pi as my main output device. The OSD is still work-in-progress but all the VOMP features are working and TV quality is fine (though I haven't used HD yet). Oooo...interesting. I'm currently using an Ion ITX board for my front-end using xineliboutput. It works but the frontend needs restarting many times a day which gets a tad annoying! I@m very tempted to sort something else out and at 25-quid or so, a Raspberry Pi sounds like it could be my next thing to try! You also need to buy a licence code to enable the GPU decoder for MPEG-2 at £2.40 (MPEG-4 is already enabled). I've got a couple of MediaMVPs that I use occasionally with VOMP but I didn't realise much was still being done on the development of it. I can't find much on t'internet about VOMP on the Pi, though, apart form the git repository and the forum. Does VOMP run the same on the Pi as on the MediaMVPs, i.e. totally separate frontend with it's own remote? What remote receivers are supported? It currently uses CEC, ie passthrough from the TV over HDMI, and so uses the TV's remote. Of course not all TV remotes are the same, and different TVs have different ideas about which buttons to pass through... Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR on Raspberry Pi
On 30/09/12 19:03, Morfsta wrote: Hi, Now that Raspberry Pis are quite common, cheap (~£25) and easily acquired (I received my order within 2 days from Farnell) has anyone considered whether it might be feasible to put together an output plugin for VDR for it? It is now possible to play MPEG-2 (with a codec license costing £2.40) as well as 1080p H.264 with hardware acceleration. There is work on VOMP (previously on Hauppauge MediaMVP) to work as a VDR client on the Pi and as far as I can see quite a lot of progress has been made. I'm wondering whether it would be possible to run VDR with HDMI video / audio output on one of these too and given the work done so far on VOMP and XBMC how difficult it would be to create an output plugin? Cheers, Morfsta I'm using VOMP on Raspberry Pi as my main output device. The OSD is still work-in-progress but all the VOMP features are working and TV quality is fine (though I haven't used HD yet). Running VDR directly on the Pi might be more difficult. The savings that were made to keep the cost down mean that USB relies heavily on software, also Ethernet is handled via the USB controller. A USB TV receiver, plus a USB hard disk plus perhaps a remote TV player via ethernet may be too much for the device to handle. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] VDR Series Link plugin version 0.3.0 released
The vdrtva plugin handles Series Link recording for broadcast system which support the TV-Anytime standard (ETSI TS 102 323). Designed for UK Freeview DVB-T, it has been tested on New Zealand DVB-S and should also be compatible with the NORDIG standard used in Nordic countries plus Eire. The new version includes an OSD interface for managing Series Links. http://projects.vdr-developer.org/projects/vdrtva -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR consumes about 60% CPU load
On 09/07/12 00:14, Martin Neuditschko wrote: Hello, I actually recognized that my VDR consumes much CPU load. Has the machine been rebooted since the leap-second on July 1? My VDR machine began to use much more CPU on that date (load average 6 when recording!) but a reboot fixed it. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dtt.me.uk
On Wednesday 02 May 2012 14:04:27 Dominic Evans wrote: Somebody used to run a site back in 2009 at http://dtt.me.uk/ that generated a very handy table showing resolution and average bitrate information for all the DVB-T channels in the UK. It is still available, just frozen in time. Anyone any idea who it was and/or how one might go about generating a similar table? This and much more is available from http://www.bsaoc.com/ Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dtt.me.uk
On Wednesday 02 May 2012 14:23:50 Dominic Evans wrote: On 2 May 2012 14:09, Dave v...@pickles.me.uk wrote: This and much more is available from http://www.bsaoc.com/ Excellent! The only thing that appears to be missing is the channels' broadcast resolutions, which I couldn't seem to be find? Perhaps not as user-friendly as your original site but listed on a per- multiplex basis here: http://www.bsaoc.com/Transport_Streams/index.php Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Repeating Timers
On Saturday 31 March 2012 02:47:39 Richard Scobie wrote: If one sets a daily or weekly timer, does EPG schedule time on the day override any difference between the two? I am thinking of the situation where a weekly timer is set and for whatever reason, the broadcaster reschedules one weeks episode, with the EPG showing the correct time, will vdr check the EPG and adjust accordingly? There is a 'Series Link' plugin for VDR which can cope with varying times for items in a series, see http://projects.vdr-developer.org/projects/vdrtva The plugin was written for the UK 'Freeview' DVB-T service, though it should work with any implementation of the 'TV Anytime' standard ETSI 102 323. Though it seems that the NZ DVB-T service was inspired by the UK one, I'm unsure how similar they are at the technical level. Some documents I've quickly looked at state that the EPG is carried in MHEG-5, others that the TV- Anytime CRIDs are present in the EIT as they are in the UK. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Repeating Timers
On Saturday 31 March 2012 20:23:51 Richard Scobie wrote: Unfortunately I am outside our DVB-T coverage area and am using DVB-S, which uses the 'no frills EPG and VPS is not used here. Some more research suggests that NZ DVB-S uses the standard SI-based EIT, and also that the extensions for Series Link recording are virtually identical to the UK. So there is a very good chance that the vdrtva plugin will work. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wednesday 29 February 2012 05:58:21 Mika Laitio wrote: Because 1.6.0 was released a long time ago, and we want a new stable version soon? :) I agree, 1.7 devel versions have many nice improvements like the support for hvr-4000's multiple frontends in same adapter. Even thought most active users in this mail list very likely uses developer versions, there are probably lot of users still using stable 1.6.0 and would also prefer to run the Next stable once released. And the Linux distributions will generally only package 'stable' versions. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VPS fallback patch
For some time (at least since 2008) Mandriva Linux have been including the
attached patch in the version of vdr shipped with their distribution. It
allows timers to be triggered directly by the Now/Next data in the EIT
provided that a new parameter is set in the config file.
Looking back in the mailing list archives I see the question of including this
feature in vdr is an old one; see for example:
http://www.linuxtv.org/pipermail/vdr/2005-August/003975.html
However I wonder if the time is now right to reconsider? In the UK an accurate
Now Next EIT is provided on DVB-T as part of the Freeview Plus (aka TV-
Anytime) service, with the data being directly derived from the broadcasters'
playout systems. I have been running vdr with this patch for two years and
have never missed a recording due to incorrect information. It was really
useful during the recent Wimbledon tournament when many programmes ran late
due to live coverage of the tennis.
Dave
Index: vdr-1.6.0/config.c
===
--- vdr-1.6.0/config.c
+++ vdr-1.6.0/config.c 2008-04-15 14:48:30.0 +0300
@@ -255,6 +255,7 @@
UseSubtitle = 1;
UseVps = 0;
VpsMargin = 120;
+ RsVpsFallback = 0;
RecordingDirs = 1;
VideoDisplayFormat = 1;
VideoFormat = 0;
Index: vdr-1.6.0/config.h
===
--- vdr-1.6.0/config.h
+++ vdr-1.6.0/config.h 2008-04-15 14:48:30.0 +0300
@@ -237,6 +237,7 @@
int UseSubtitle;
int UseVps;
int VpsMargin;
+ int RsVpsFallback;
int RecordingDirs;
int VideoDisplayFormat;
int VideoFormat;
Index: vdr-1.6.0/menu.c
===
--- vdr-1.6.0/menu.c
+++ vdr-1.6.0/menu.c 2008-04-15 14:48:30.0 +0300
@@ -2753,6 +2753,7 @@
Add(new cMenuEditBoolItem(tr(Setup.Recording$Use episode name), data.UseSubtitle));
Add(new cMenuEditBoolItem(tr(Setup.Recording$Use VPS), data.UseVps));
Add(new cMenuEditIntItem( tr(Setup.Recording$VPS margin (s)),data.VpsMargin, 0));
+ Add(new cMenuEditBoolItem(tr(Setup.Recording$Use running status as VPS fallback), data.RsVpsFallback));
Add(new cMenuEditBoolItem(tr(Setup.Recording$Mark instant recording),data.MarkInstantRecord));
Add(new cMenuEditStrItem( tr(Setup.Recording$Name instant recording), data.NameInstantRecord, sizeof(data.NameInstantRecord)));
Add(new cMenuEditIntItem( tr(Setup.Recording$Instant rec. time (min)), data.InstantRecordTime, 1, MAXINSTANTRECTIME));
Index: vdr-1.6.0/timers.c
===
--- vdr-1.6.0/timers.c
+++ vdr-1.6.0/timers.c 2008-04-15 14:48:30.0 +0300
@@ -412,7 +412,7 @@
}
if (HasFlags(tfActive)) {
- if (HasFlags(tfVps) event event-Vps()) {
+ if (HasFlags(tfVps) event (Setup.RsVpsFallback || event-Vps())) {
if (Margin || !Directly) {
startTime = event-StartTime();
stopTime = event-EndTime();
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VPS fallback patch
On Monday 18 July 2011 13:58:55 Tony Houghton wrote: Does the standard EIT now reflect the actual times? I was under the impression that the EIT still reflected the original schedule and the actual times were somewhere in the TVAnytime extensions. For the UK Freeview+ service, the EIT p/f table is used as the accurate recording information, and the start of a programme is signalled by the event_id appearing in the 'present' event. The alternative (preferred by ETSI TS 102 323) is a TVA_id descriptor (0x75) in the p/f table, but these don't seem to be broadcast in the UK. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VPS fallback patch
On Monday 18 July 2011 13:09:19 Laz wrote: I will have to give your patch a go becuase I've recently missed a few recordings due to tennis and football over-running!! I presume I need to set timers with no margin at the start and with vps enabled for all for this to work? In your setup.conf you should have: UseVps = 1 VpsFallback = 1 VpsMargin = 120 The last one sets the number of seconds before the scheduled start time that VDR begins monitoring the p/f table for the event start. Also whenever you set a new timer you need to set the 'flag' field to 5 - if using vdradmin-am tick the 'use VPS' box in the New Timer window - as well as setting the start time with no margin. Do I also need your tvanytime patch for this to work? I did try it a few days back with vdr-1.7.19 but I kept on gettign seg faults from calls to strcpyrealloc! I was, however, in the process of sorting out some other issues at the time so will have to try it again now that I've fixed the other problems! The TVAnytime patch includes this VPS Fallback patch, but you don't need the rest of it just to do accurate recording. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How can I add custom information to the EPG?
On 14.06.2011 04:25, John Klimek wrote: My provider sends EEPG information containing information such as Original Air Date and Episode ID. I think I can add the neccessary DVB descriptors the code but where should I add this in the epg.data file? Does anybody have any information or advice on this? My goal is to use the epgsearch plugin with this extra data to record new episodes (ie. never before aired), etc. For a 'quick and dirty' solution, take a look at vdrtva: http://projects.vdr-developer.org/projects/vdrtva Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How can I add custom information to the EPG?
On Thursday 16 June 2011 11:12:35 Dominic Evans wrote: Hi Dave, On 16 June 2011 09:06, Dave v...@pickles.me.uk wrote: On 14.06.2011 04:25, John Klimek wrote: My goal is to use the epgsearch plugin with this extra data to record new episodes (ie. never before aired), etc. For a 'quick and dirty' solution, take a look at vdrtva: http://projects.vdr-developer.org/projects/vdrtva Any plans to look at EPGSearch integration? http://projects.vdr-developer.org/issues/314 ? :-) The next step is to rewrite the patch as a module, which will hopefully make it easier to deploy and to integrate with other modules. Klaus has accepted a patch to add support for the necessary descriptors into libsi. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR developer version 1.7.18
On Sunday 17 April 2011 15:50:44 Klaus Schmidinger wrote: VDR developer version 1.7.18 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.18.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17-1.7.18.diff Compiling the new version I get lots of compiler errors in the new dvbhddevice plugin. I don't use this plugin and the rest of vdr seems to be fine. A sample: g++ -g -O3 -Wall -Woverloaded-virtual -Wno-parentheses -march=native -pipe - fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE - D_GNU_SOURCE -DPLUGIN_NAME_I18N='dvbhddevice' -I../../../include hdffcmd.c hdffcmd.c: In member function ‘uint32_t HDFF::cHdffCmdIf::CmdGetFirmwareVersion(char*, uint32_t)’: hdffcmd.c:57: error: ‘osd_raw_cmd_t’ was not declared in this scope hdffcmd.c:57: error: expected ‘;’ before ‘osd_cmd’ hdffcmd.c:59: error: ‘osd_cmd’ was not declared in this scope hdffcmd.c:65: error: ‘OSD_RAW_CMD’ was not declared in this scope hdffcmd.c: In member function ‘uint32_t HDFF::cHdffCmdIf::CmdGetInterfaceVersion(char*, uint32_t)’: hdffcmd.c:83: error: ‘osd_raw_cmd_t’ was not declared in this scope hdffcmd.c:83: error: expected ‘;’ before ‘osd_cmd’ hdffcmd.c:85: error: ‘osd_cmd’ was not declared in this scope hdffcmd.c:91: error: ‘OSD_RAW_CMD’ was not declared in this scope # gcc -v Using built-in specs. Target: x86_64-manbo-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with- slibdir=/lib64 --with-bugurl=https://qa.mandriva.com/ --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable- languages=c,c++,ada,fortran,objc,obj-c++,java --build=x86_64-manbo-linux-gnu --host=x86_64-manbo-linux-gnu --with-cpu=generic --with-system-zlib --enable- threads=posix --enable-shared --enable-objc-gc --enable-long-long --enable- __cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable- java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --with- ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-gtk-cairo --disable-libjava- multilib --enable-ssp --disable-libssp --disable-werror --with-ppl --with- cloog --with-python-dir=/lib/python2.6/site-packages Thread model: posix gcc version 4.4.3 (GCC) Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG corruption
On Monday 10 January 2011 18:44:21 Tony Houghton wrote: I noticed a problem in VDR's EPG today, using vdradmin. The problem programme is Malcolm in the Middle at 18:00-18:25 on Friday 14/01/11 on UK DVB-T (Freeview) channel Fiver. When I click on the link for the programme description I get the details for the following programme, Zoo Days, instead of Malcolm. I've tried deleting epg.data and restarting, but the same thing happened. But when I ran boxstard, which has EIT harvesting, that showed the correct details. Can any other UK VDR users confirm or deny this? I'm using 1.6.0-19.2 from Debian unstable amd64, which is the stock source package of 1.6.0-19.1 to which I've added the Freesat patch. No problem here, the behaviour of both programmes is as expected. I'm using VDR 1.7.16 compiled for 64-bits with the vdrtva patch, and VDRAdmin- AM 3.6.7. Dave ___ 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
On Wednesday 03 November 2010 23:24:54 Alasdair Campbell wrote: On 3 November 2010 23:18, Torgeir Veimo torg...@netenviron.com wrote: From memory, I think the frequencies in channels.conf ends up being 166khz off the actual frequency. I remember having to tweak the channels.conf file manually, then turn off automatic updates. Can you post your file here? After leaving it for a few hours this is what I have, note BBC ONE at the very bottom, the EPG is available here but no video stream, same with BBC TWO elsewhere. channels.conf attached (hope attachments are allowed on this list!) The first instance of 'BBC ONE' uses QAM64 modulation with 8k carriers, the second QAM16 and 2k. Assuming you've gone through DSO the first one is correct. Maybe vdr's channel scanning is getting confused by having two nearly- identical entries in channels.conf. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Live TV problem with 1.7.15
On Tuesday 08 Jun 2010, VDR User wrote: I'm not sure what FE_CAN_QAM_AUTO is supposed to represent exactly so the problem may not be in VDR, but rather your cards driver not accurately reporting it's capabilities. In which case, the driver needs to be fixed of course. The card is a Twinhan DST DVB-T using the bttv driver. I'm not an expert at reading kernel source, but in drivers/media/dvb/bt8xx/dst.c it does seem that FE_CAN_QAM_AUTO is unconditionally set. The card documentation doesn't specify whether the device can in fact handle all possible QAM settings. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.15
On Tuesday 08 Jun 2010, ShorTie wrote: Hello, I tried to upgrade to 1.7.15 and get no video .. :(~ 1.7.14 works fine. Tried patching v4l with the FE_CAN_TURBO_FEC patch and then neither 1.7.14 or 1.7.15 will work. Do I need a fresh pull of v4l or something? I've just noticed that my vdr 1.7.15 will no longer receive live TV, though old recordings play fine. These entries in the log look ominous: Jun 8 16:24:14 sodom vdr: [18819] probing /dev/dvb/adapter0/frontend0 Jun 8 16:24:14 sodom vdr: [18819] creating cDvbDevice Jun 8 16:24:14 sodom vdr: [18819] new device number 1 Jun 8 16:24:14 sodom vdr: [18819] frontend 0/0 provides DVB-T with unknown modulations (DST DVB-T) Jun 8 16:24:14 sodom vdr: [18823] tuner on frontend 0/0 thread started (pid=18819, tid=18823) Jun 8 16:24:14 sodom vdr: [18824] section handler thread started (pid=18819, tid=18824) Jun 8 16:24:14 sodom vdr: [18819] found 1 DVB device Jun 8 16:24:14 sodom vdr: [18819] initializing plugin: vompserver (0.3.0): VDR on MVP plugin by Chris Tallon Jun 8 16:24:14 sodom vdr: [18819] setting primary device to 1 Jun 8 16:24:14 sodom vdr: [18819] device 1 has no MPEG decoder Jun 8 16:24:14 sodom vdr: [18819] assuming manual start of VDR Jun 8 16:24:14 sodom vdr: [18819] SVDRP listening on port 6419 ... Jun 8 16:24:14 sodom vdr: [18819] switching to channel 1 Jun 8 16:24:14 sodom vdr: [18819] info: Channel not available! I'll do some more experiments later. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Live TV problem with 1.7.15
(I'll start a new thread as my problem may not be the same as the one
posted earlier).
VDR 1.7.15 will not record or show live TV from my DVB-T card - 1.7.14 was
fine. On startup I see this message in the log:
Jun 8 16:24:14 vdr: [18819] frontend 0/0 provides DVB-T with unknown
modulations (DST DVB-T)
The problem seems to be in the new code in dvbdevice.c. My card returns
frontendInfo.caps = 0xb0201, ie the FE_CAN_QAM_AUTO bit is set but not any
of the individual QAM bits. Hence the logic in
cDvbDevice::ProvidesTransponder() incorrectly decides that the card cannot
receive any channel.
The simple patch (attached) fixes the problem but I'm not sure that it
doesn't break something else.
Dave
--- dvbdevice.c.orig2010-05-01 10:47:13.0 +0100
+++ dvbdevice.c 2010-06-08 21:17:08.0 +0100
@@ -710,6 +710,7 @@
if (frontendInfo.caps FE_CAN_QAM_64) { numProvidedSystems++; p += sprintf(p, ,%s, MapToUserString(QAM_64, ModulationValues)); }
if (frontendInfo.caps FE_CAN_QAM_128) { numProvidedSystems++; p += sprintf(p, ,%s, MapToUserString(QAM_128, ModulationValues)); }
if (frontendInfo.caps FE_CAN_QAM_256) { numProvidedSystems++; p += sprintf(p, ,%s, MapToUserString(QAM_256, ModulationValues)); }
+if (frontendInfo.caps FE_CAN_QAM_AUTO) { numProvidedSystems++; p += sprintf(p, ,%s, MapToUserString(QAM_AUTO, ModulationValues)); }
if (frontendInfo.caps FE_CAN_8VSB){ numProvidedSystems++; p += sprintf(p, ,%s, MapToUserString(VSB_8, ModulationValues)); }
if (frontendInfo.caps FE_CAN_16VSB) { numProvidedSystems++; p += sprintf(p, ,%s, MapToUserString(VSB_16, ModulationValues)); }
if (frontendInfo.caps FE_CAN_TURBO_FEC){numProvidedSystems++; p += sprintf(p, ,%s, TURBO_FEC); }
@@ -914,11 +915,11 @@
cDvbTransponderParameters dtp(Channel-Parameters());
if (dtp.System() == SYS_DVBS2 frontendType == SYS_DVBS ||
dtp.Modulation() == QPSK !(frontendInfo.caps FE_CAN_QPSK) ||
- dtp.Modulation() == QAM_16!(frontendInfo.caps FE_CAN_QAM_16) ||
- dtp.Modulation() == QAM_32!(frontendInfo.caps FE_CAN_QAM_32) ||
- dtp.Modulation() == QAM_64!(frontendInfo.caps FE_CAN_QAM_64) ||
- dtp.Modulation() == QAM_128 !(frontendInfo.caps FE_CAN_QAM_128) ||
- dtp.Modulation() == QAM_256 !(frontendInfo.caps FE_CAN_QAM_256) ||
+ dtp.Modulation() == QAM_16!(frontendInfo.caps (FE_CAN_QAM_16 | FE_CAN_QAM_AUTO)) ||
+ dtp.Modulation() == QAM_32!(frontendInfo.caps (FE_CAN_QAM_32 | FE_CAN_QAM_AUTO)) ||
+ dtp.Modulation() == QAM_64!(frontendInfo.caps (FE_CAN_QAM_64 | FE_CAN_QAM_AUTO)) ||
+ dtp.Modulation() == QAM_128 !(frontendInfo.caps (FE_CAN_QAM_128 | FE_CAN_QAM_AUTO)) ||
+ dtp.Modulation() == QAM_256 !(frontendInfo.caps (FE_CAN_QAM_256 | FE_CAN_QAM_AUTO)) ||
dtp.Modulation() == QAM_AUTO !(frontendInfo.caps FE_CAN_QAM_AUTO) ||
dtp.Modulation() == VSB_8 !(frontendInfo.caps FE_CAN_8VSB) ||
dtp.Modulation() == VSB_16!(frontendInfo.caps FE_CAN_16VSB) ||
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANN] TVAnytime Patch
My TVAnytime patch has a new home: http://projects.vdr-developer.org/projects/show/vdrtva The patch implements the subset of TVAnytime (ETSI 102 323) broadcast in the UK as Freeview Plus. Also included is a Perl script to provide automatic series link recording. Vdr versions 1.7.12 and 1.6.0-2 are supported. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FRC - RGB/Scart with the Intel 830 driver
In message 20090909185925.ga24...@roja.toh.cx, Thomas Hilber wrote On Tue, Sep 08, 2009 at 11:08:39PM +0100, dave cunningham wrote: Same behaviour with your xorg.conf unfortunately. I've heard there are some buggy intel-DDXes floating around. I don't know which one you use. A possible workaround is do add SubSection Display Virtual3200 1200 EndSubSection to the Screen section. Attached is a further 'xorg.conf' with the workaround included. Please give it a try. I added this section but it didn't make any difference. I have now fixed it though by adding a new monitor for VGA-1 and setting Ignore to true in xorg.conf. Thanks again for the help (wouldn't have found this if I hadn't started looking into Clone as you mentioned earlier in the thread!) -- Dave Cunningham dave at upsilon org uk PGP KEY ID: 0xA78636DC xorg.conf Description: xorg.conf ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FRC - RGB/Scart with the Intel 830 driver
In message 20090908042705.gh6...@roja.toh.cx, Thomas Hilber wrote The desktop's working just fine but I'm having problems with XV. When running in a window xv's fine however when I switch to full screen all I get is a blue screen + audio. probably a xorg.conf configuration issue. Did you use clone mode? That does not work with interlaced timings. Symptoms are like the ones you describe. Attached is a working sample for xorg.conf I use for my D945GCLF2. Same behaviour with your xorg.conf unfortunately. I get the following with xrandr -q Screen 0: minimum 320 x 200, current 1440 x 576, maximum 1600 x 1600 VGA connected 1440x576+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1440x576_50i 25.1*+ 1600x1200_60 59.9 1368x768_6060.0 1280x800 60.0 1280x768 60.0 1024x768 60.0 800x60060.3 800x520_50i25.0 720x576_50i25.0 640x48059.9 VGA-1 connected (normal left inverted right x axis y axis) 1280x800 60.0 1280x768 60.0 1024x768 60.0 800x60060.3 640x48059.9 Bit confused as to where VGA-1 is coming from. Presumably this could be the source of the problem? xrandr --output VGA-1 --off appears to have no affect. -- Dave Cunningham dave at upsilon org uk PGP KEY ID: 0xA78636DC ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FRC - RGB/Scart with the Intel 830 driver
In message lkpgcrborzpkf...@echelon.upsilon.org.uk, dave cunningham wrote Looking for some help again :( I've finally tried to get this up and running with the patched Intel xserver on a D945GCLF2 atom board (I see from your readme that you've tried this configuration so assume it should work). (Note I'm using MPlayer right now and not xine/vdr). The desktop's working just fine but I'm having problems with XV. When running in a window xv's fine however when I switch to full screen all I get is a blue screen + audio. I've done a lot of googling / messing with xserver options / xv overlay ports but I'm no further forward yet! An addendum... When running in non-interlaced mode with my normal monitor (1280*1024) rather than the TV xv works fine in full screen mode. (Incidentally I note the readme for the xserver says that the driver doesn't support interlaced mode though I guess that's what patch changed). -- Dave Cunningham dave at upsilon org uk PGP KEY ID: 0xA78636DC ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FRC - RGB/Scart with the Intel 830 driver
Thomas Hilber wrote: snip The 1440x576i is driven at doubled dot clock. So it effectively represents a regular 720x576i PAL timing too. The reason for 1440x576i is: the FRC gains doubled horizontal timing resolution. As a result variable frame rate can be controlled in finer (twice as much) increments. Do standard CRTs handle this increased resolution/clock? I've never tried driving this signal into my TV. In fact I use the cable from here http://members.optusnet.com.au/eviltim/scart.htm with the cut off circuit so I'd actually have to build a new cable to use this resolution. Not that that's particularly difficult but do you gain any advantage using the higher resolution on the Intel cards vs standard 576i with ATI. If not then I'll probably just save the hassle and buy an ATI card of eBay instead. -- Dave Cunningham PGP KEY ID: 0xA78636DC ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] FRC - RGB/Scart with the Intel 830 driver
Question for Thomas I guess... I'm in the process of setting up a PVR and just came across the FRC project which looks very interesting! One query I have though is the re. the restriction on the resolutions available. If I'm reading the patches correctly it seems that the ATI chips can currently do 720x576 only, where the Intel chips can be configured for 1440x576 and 1600x1200 only. The Intel driver has been patched to allow a 12MHz dot clock - is it in fact capable of supporting 720x576 interlaced? If so is there a hardware limitation preventing the FRC syncing working at this resolution? (I ask as I'm planning to use a Mini-ITX Atom board with a GMA950 to be hooked up to a standard-def TV. It would be good if I could use the onboard video and leave the PCI slot free.) Thanks -- Dave Cunningham PGP KEY ID: 0xA78636DC ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] No EIT for channel Yesterday
On Monday 10 Aug 2009, Tony Houghton wrote: On Sun, 09 Aug 2009 23:01:07 +0200 In fact, it isn't just Yesterday, the entire Freeview network has no EPG in VDR. I can tune to the channels though. The DVB-S EPG is present though. Are you referring to Freeview, the UHF terrestrial DVB-T service in the UK, or Freesat, the free-to-air satellite service? FreeSAT uses a dedicated transponder to carry the EPG for all channels, and the information is carried using a non-standard coding scheme. There is a patch for Freesat at http://www.rst38.org.uk/vdr/ though I have no idea whether it works. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Where do you live and what kind of broadcast do you receive?
Country: UK Transmission: DVB-T Encoding: MPEG-2 for SD (currently 109 TV radio channels) Hardware: DVB-T budget card, Hauppauge MVP with VOMP plug-in. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: VDR for grandparents
On Sunday 26 Oct 2008, Peer Oliver Schmidt wrote: Hello Paul, has anyone on this list any experience in setting up VDR for older people like grandparents? It would be nice, if she/he could share her/his experience or point me to information on the WWW. I have experience with second best thing after grandparents. A totally clueless user. Since I have setup VDR as the backend sitting near the dish, and added a MediaMVP box next to the TV set, she can use it, record stuff, delete recording, everything. We are using the Hauppauge MediaMVP together with the vdr-plugin-vompserver on the VDR system. Another vote for MediaMVP and vompserver. The user interface is IMO easier to operate than commercial PVRs such as the Humax, and the noisy recorder can be kept out of the living room. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview+ aka TV-Anytime Patch (updated)
On Tuesday 07 October 2008, Laz wrote: This is the sort of feature which would be ideal as a plugin, i.e. only those who are interested need to compile and use it. As to whether it is possible to obtain the relevant LCN info from the DVB stream is possible from a plugin or not (I'd have thought a patch would be needed for this but haven't looked yet), or whether it is possible to renumber channels from a plugin. It is possible to capture the LCN from a plugin (it's in the NIT as descriptor id 0x83), though a patch to libsi would be needed to decode the descriptor in the standard way used elsewhere in VDR. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview+ aka TV-Anytime Patch (updated)
On Tuesday 07 October 2008, Klaus Schmidinger wrote: Are these channel numbers broadcast in a way that's covered in the DVB SI standard? If so, I see no reason why VDR shouldn't (optionally) use them when sorting channels. But they sure have no place in channels.conf, in there I would still use :@nnn lines to set the offsets. LCN is not in ETSI 300 168, it uses a descriptor number in the 'private' range. A web search suggests that it is in the E-Book. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview+ aka TV-Anytime Patch (updated)
On Monday 06 October 2008, Laz wrote: On another Freeview specific note, I'd love to have my channels renumbered to their proper Freeview numbers. At the moment, I have to go through and move them about by hand every time something changes! I don't think there is currently any support for assigning channels a specific number within vdr (probably not much point with gazillions of satellite channels but more useful with the handful of terrestrial Freeview ones in the UK). This is Logical Channel Number (LCN), another poorly-documented extension to the SI tables which is only used in the UK. I prefer my channels.conf in alphabetic order ;-) Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Freeview+ aka TV-Anytime Patch (updated)
A few months ago I posted a VDR patch to implement support for Freeview+, the cut-down version of TV-Anytime (ETSI TS 102 323) broadcast in the UK. I've prepared a new version against VDR 1.6.0-2, and included a simple Perl script which automatically creates timers for all of the programmes in a series. Run it overnight as a cron job and never miss your favourite series again! The patch is at http://www.pickles.me.uk/vdrtva-0.0.3.tar.gz -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview+ aka TV-Anytime Patch (updated)
On Sunday 05 October 2008, Gavin Hamill wrote: Interesting stuff :) I don't suppose it's possible to implement this as a plugin rather than a patch to VDR's core? Is there not enough core exposed via the plugin API? I can't see the patch going into VDR core any time because it's focused squarely at UK users only and Klaus would never have a use for it (unlike the Premiere-specific multi-angle support) so I'm worried that a lot of users will be missing out, especially if they use a packaged VDR. I started writing it as a plugin but quickly ran into problems. The patch has to intercept the TVAnytime descriptors out of the EIT. That is certainly possible from a plugin, but would involve duplicating a lot of core code, and I wonder what the performance impact would be on a slow machine. In any event the libsi code would need changing to recognise the new descriptors (though maybe Klaus might accept that). The code then needs to store the CRIDs and Default Authority values, and the existing channels.conf and epg.data files are the obvious places to put them - there is AFAIK no hook to change these files or the data structures behind them. That also allows the SVDRP interface to be used to build high-level applications. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Greener VDR
On Saturday 06 September 2008, [EMAIL PROTECTED] wrote: I don't know how much watt savings could be achieved with this, but on conseptual level it sounds good or do you agree? I hope some 10-20 watts could be saved in 1xFF and 2xbudget environment. And less heat inside the box, on softdevices CPU runs lower power etc.. I've taken measurements of power consumption on my vdr boxes. Both have had a single DVB-T budget card and playback is via the VOMP plugin. The present machine is a 2.3 GHz Athlon X2 64-bit. It idles at 42w, starting and stopping vdr has no measurable effect so I leave it running. The previous one used a 32-bit Athlon mobile CPU in a desktop motherboard. That machine idled at 62w (less efficient power supply and higher-spec graphics card). With vdr running the CPU temperature increased by 1 degree C and power consumption increased about 1 watt. It would be possible to save a few more watts if the DVB card could be completely powered off (my new machine needs only 38w without the card installed) but AFAIK that's not possible for PCI. A better bet for a 'green' vdr is careful choice of components. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr: no signal
On Saturday 26 July 2008, Alex Girchenko wrote: Lauri, I've found only one manual so far: http://www.linuxtv.org/vdrwiki/index.php/VDR_User%27s_Manual. It doesn't contain a word on setup.conf. Also studied the entire wiki, the man page. Could you please provide a link to the exact manual you mean? TIA. The file MANUAL, included in the vdr distribution. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] channels with same pids+channels update
On Thursday 10 Apr 2008, Peter Evertz wrote: ua0lnj schrieb: And other feature, this is deleting absent channels. If provider was deleted channels, you need delete it from channels.conf manually. After this patch, vdr auto deleting channels, which not present on transponder in sdt. Need select delete absent channels in dvb settings menu, but if you selected channels update or transponder update. I am very interested in this feature. My providers (astra/hotbird) are smart enough not to send not to much garbage, but deleting of unused channels is really a pain. I am at 4500 Channels in my channels.conf and I am pretty sure that at least 30 % of them are long gone. Is it possible to have that feature seperated ? @kls ... and include it in the mainline ? Beware... VDRadmin (and maybe other applications) uses the line number in channels.conf to decide whether to display a channel. Deleting defunct channels would mess this up. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR developer version 1.5.15 - compilation warnings
On Tuesday 19 Feb 2008, Klaus Schmidinger wrote: remote.c:124: warning: format %016LX expects type long long unsigned int, but argument 4 has type uint64_t Apparently there are macros for this, like PRId64 and such. But i don't like having to write something like int64_t n = ...; printf(Some number % PRId64 \n, n); It seems to be the POSIX way... Don't know if the gettext mechanisms would be able to handle tr(Some number % PRId64 \n) It would probably be necessary to have multiple translations for the string after macro expansion (negating the whole reason for having the macro in the first place). -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR developer version 1.5.15 - compilation warnings
Compiling the new version on my 64-bit AMD processor produces the warnings below. I think they've probably been there for a while, I don't usually watch VDR compiling... # g++ -v Using built-in specs. Target: x86_64-mandriva-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --host=x86_64-mandriva-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp Thread model: posix gcc version 4.2.2 20071128 (prerelease) (4.2.2-3.1mdv2008.0) --- g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DVDR_USER=\vdr\ -DLIRC_DEVICE=\/dev/lircd\ -DRCU_DEVICE=\/dev/ttyS1\ -D_GNU_SOURCE -DVIDEODIR=\/video/video\ -DCONFDIR=\/video/video\ -DPLUGINDIR=\./PLUGINS/lib\ -DLOCDIR=\./locale\ -I/usr/include/freetype2 dvbsubtitle.c dvbsubtitle.c: In member function ‘int cDvbSubtitleConverter::Convert(const uchar*, int)’: dvbsubtitle.c:709: warning: format ‘%lld’ expects type ‘long long int’, but argument 3 has type ‘int64_t’ dvbsubtitle.c: In member function ‘virtual void cDvbSubtitleConverter::Action()’: dvbsubtitle.c:776: warning: format ‘%lld’ expects type ‘long long int’, but argument 3 has type ‘int64_t’ dvbsubtitle.c:776: warning: format ‘%lld’ expects type ‘long long int’, but argument 4 has type ‘int64_t’ dvbsubtitle.c:776: warning: format ‘%lld’ expects type ‘long long int’, but argument 5 has type ‘int64_t’ dvbsubtitle.c: In member function ‘int cDvbSubtitleConverter::ExtractSegment(const uchar*, int, int64_t)’: dvbsubtitle.c:845: warning: format ‘%lld’ expects type ‘long long int’, but argument 5 has type ‘int64_t’ g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DVDR_USER=\vdr\ -DLIRC_DEVICE=\/dev/lircd\ -DRCU_DEVICE=\/dev/ttyS1\ -D_GNU_SOURCE -DVIDEODIR=\/video/video\ -DCONFDIR=\/video/video\ -DPLUGINDIR=\./PLUGINS/lib\ -DLOCDIR=\./locale\ -I/usr/include/freetype2 remote.c remote.c: In member function ‘bool cRemote::Put(uint64_t, bool, bool)’: remote.c:124: warning: format ‘%016LX’ expects type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ remote.c:124: warning: format ‘%016LX’ expects type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ - Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Straw poll: stable version 1.6.0 now?
On Sunday 03 Feb 2008, Klaus Schmidinger wrote: Should there be a stable version 1.6.0 now, based on what's in version 1.5.14, but without DVB-S2 or even H.264 support? I have no use for HDTV support (the only HDTV available in the UK at present is on the closed $KY system), so freezing the current development version into a stable release sounds a good idea. The distributions which include vdr would probably appreciate a release which worked with their existing kernels. Maybe we'll all meet again at version 2.0... Yes or No? Yes. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Freeview Replay aka TV-Anytime patch
There was a discussion here last year about implementing support for Freeview Replay, the cut-down version of TV-Anytime (ETSI TS 102 323) broadcast in the UK. I've now produced a patch which implements the low-level support needed for Freeview Replay. It captures the series and item CRIDs and stores the information in epg.data and channels.conf. If anyone is interested in taking this forward and building high-level functions to make use of the data, the patch is at http://www.pickles.me.uk/vdrtva-0.0.1.tar.gz The patch was prepared against vdr-1.5.13. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.5.10 and VDR-1.5.11 recording channel with subtitle
On Sunday 04 Nov 2007, NIVAL Michaël wrote: Hi, When I record channel with subtitle, VDR brutally restart. Here is the content of the syslog, just before restarting : Nov 4 20:59:42 vdrbox vdr: [7700] buffer usage: 70% (tid=7706) Nov 4 20:59:43 vdrbox vdr: [7700] buffer usage: 80% (tid=7706) Nov 4 20:59:44 vdrbox vdr: [7700] buffer usage: 90% (tid=7706) Nov 4 20:59:45 vdrbox vdr: [7700] buffer usage: 100% (tid=7706) Nov 4 20:59:45 vdrbox vdr: [7700] ERROR: 1 ring buffer overflow (65 bytes dropped) Nov 4 20:59:51 vdrbox vdr: [7700] ERROR: 18184 ring buffer overflows (3418592 bytes dropped) Nov 4 20:59:57 vdrbox vdr: [7700] ERROR: 19567 ring buffer overflows (3678596 bytes dropped) Nov 4 21:00:03 vdrbox vdr: [7700] ERROR: 19802 ring buffer overflows (3722776 bytes dropped) Nov 4 21:00:07 vdrbox vdr: [7705] ERROR: video data stream broken Nov 4 21:00:07 vdrbox vdr: [7705] initiating emergency exit Nov 4 21:00:07 vdrbox vdr: [7423] emergency exit requested - shutting down I see exactly the same problem, but only when using my old Hauppauge Nova-T card. The newer Twinhan one doesn't generate these messages. Also the problem only seems to occur when recording, not when watching live TV. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG: Events with same event id on different channels?
On Monday 16 Jul 2007, Friedhelm Büscher wrote: Hi everybody. I wonder, if event id (according to vdr.5) must be uniq among *all* events known to vdr or only among the events of the current channel? Is it valid to have a event id of 4711 for ard and a event id of 4711 for zdf? Or will these both events clash? According to ETSI EN 300 468 the event_id is uniquely allocated within a service definition, which I think means that the combination of service_id and event_id is unique. Of course they cannot be globally unique for all time as they are both 16-bit fields, so I presume that there should simply be no re-use within the time interval covered by the EPG. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview Playback
On Tuesday 26 Jun 2007, Alex Stansfield wrote: Andrew Herron wrote: I believe TV-Anytime is a European standard. Wikipedia seems to agree: http://en.wikipedia.org/wiki/TV-Anytime I now have the TVAnytime spec TS 102 323 from www.etsi.org (painless automated registration required) together with a couple of the referenced documents. From first reading it appears that the Freeview product is a cut-down and not-entirely-compatible version of TVA; there seems to be no RNT table broadcast on PID 0x16, and the crid_type field of the Content Identifier Descriptor has the 'user private' bit set. I'll do some more digging. -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview Playback
On Friday 15 Jun 2007, Jonathan McDowell wrote: On 12/06/07, Alex Stansfield [EMAIL PROTECTED] wrote: If anyone knows any more about how the system works or has the DTG specification (can't see it on their website) please let me know. MythTV seems to have added support: http://svn.mythtv.org/trac/ticket/2811 Hmmm. I worked out the scheme using dvbsnoop last night, then decided it couldn't possibly be so simple. Seems I was right after all... The data is transmitted in the EIT. Each entry has zero, 1 or 2 Content Identifier Descriptors, with table ID 0x76. The format of this descriptor seems to be: Descriptor tag, 8 bits (always 0x76) Descriptor length, 8 bits crid_type, 6 bits crid_location, 2 bits (always seems to be 00) crid_len, 8 bits crid_data, crid_len bytes. If crid_type = 0x31 then crid_data contains the program ID, which I think is supposed to uniquely identify the programme irrespective of repeats etc. If crid_type = 0x32 then crid_data contains the series ID, which should be the same across all episodes of a series. The series ID is sometimes omitted if the programme is a one-off. I'm not sure just how unique these identifiers are supposed to be; the series identifiers are generally 5-digit numbers or 6-character alpha strings preceded by /, while the program ID seems to have the episode number appended. On Sandy Heath I only see this data on the BBC, 4 and sky channels, not ITV. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview Playback
On Wednesday 13 Jun 2007, Andrew Herron wrote: Hi, My understanding is that the updated epg data has been transmitted here in the uK across all dvb-t mux's since about March/April. Not all channels may have completely updated there backend systems yet but all the major channels have done so. Clearly launching the Freeview Playback 'brand' and therefore its feature set means the epg data must be broadly available for these new PVR boxes to work as advertised. So the data must be there somewhere ;-) Is Freeview Playback the same as TV-Anytime? The latter is covered by an ETSI specification TS 102 323, though I haven't found a copy online as yet, and the data is carried in the EIT tables. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Freeview Playback
On Thursday 14 Jun 2007, Andrew Herron wrote: The document we need to look at is the one that specifies how to process Event Information (AKA EPG) and is called ETSI EN 300 468. The latest one is found here; http://webapp.etsi.org/action/OP/OP20060428/en_300468v010701o.pdf It looks like section 5.2.4 contains the information we are looking for, this covers the Event Information Table (EIT). This should be possible to decode in a similar way the 'scan' program grabs, extracts and processes the Network Information Table (PID 0x10), except you'd want to work on PID 0x12 instead. OK I've tried looking again. The ITV1 multiplex at least is broadcasting EIT descriptor 0x76 (content identifier descriptor) which is part of the TV-Anytime spec. Oddly, I didn't see that last night. More investigation needed, but the data does seem to be there. Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Mplayer Frontend for xineliboutput?
Is there any way to use Mplayer as the frontend to xineliboutput? This might be a stupid question, but the a/v sync problems are unacceptable with the existing front end vdr-sxfe, unless someone has a way to get xine-lib 1.1.1 to compile with xvmc support (1.1.2++ apparently introduced the a/v sync issues or so I read?) Otherwise xineliboutput works well. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Any DST change problems?
We're coming up to the weekend when Daylight Saving Time ends in Europe. I seem to recall last time I tried this that there were problems with setting timers before the changeover to record programmes after it. Is this still an issue, and if so would restarting VDR after the change help? I see that timers.conf has the events in 'wallclock' time (when setting timers through vdradmin at least). -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] libxineoutput - A/V Sync
Im experiencing a problem with libxineoutput. The video and audio are out of sync. the settings for the plugin correct it good for one channel, but then are out for another channel, so Ive had to put it in the middle so its kinda out of sync equally across all channels, but I find it unacceptable. I also have an A/V sync problem on another machine playing DVD's, where mplayer is fine, so I suspect it to be xine-lib, rather than the plugin, I am just wondering if anyone else has seen this. VDR 1.4.0, CVS libxineoutput. Latest xine-lib 1.1.2-r1 I believe. I shoud note that Im using spdif passthru. the DVD playback on another machine is regular analog. Thanks ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xineliboutput compilation error
I get the following error compiling xineliboutput: (xine-lib 1.1.2 (gentoo packaged), vdr 1.4.0 gcc -O2 -I/usr/include -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='xineliboutput' -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DXINELIBOUTPUT_VERSION='1.0.0pre3' -DYAEGP_PATCH -Wall -I/usr/src/v4l/v4l-dvb/linux/include -I../../../include xine_input_vdr.c xine_input_vdr.c:3181: error: `XINE_EVENT_VDR_INFO' undeclared here (not in a function) xine_input_vdr.c:3181: error: initializer element is not constant xine_input_vdr.c:3181: error: (near initialization for `vdr_keymap[55].event') xine_input_vdr.c:3181: error: initializer element is not constant xine_input_vdr.c:3181: error: (near initialization for `vdr_keymap[55]') xine_input_vdr.c:3183: error: initializer element is not constant xine_input_vdr.c:3183: error: (near initialization for `vdr_keymap[56]') xine_input_vdr.c: In function `track_audio_stream_change': xine_input_vdr.c:3877: error: `BUF_CONTROL_RESET_TRACK_MAP' undeclared (first use in this function) xine_input_vdr.c:3877: error: (Each undeclared identifier is reported only once xine_input_vdr.c:3877: error: for each function it appears in.) make[1]: *** [xine_input_vdr.o] Error 1 make[1]: Leaving directory `/usr/local/src/VDR/vdr-1.4.0/PLUGINS/src/xineliboutput-1.0.0pre3' ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] anyone using Technotrend Premium S2300 (Rev 2.3) modded
Simon Baxter wrote: Hi. I'm looking at getting the following from dvbshop.net Technotrend Remotecontrol SET Technotrend Technotrend Dual Tuner Package (Technotrend Premium S2300 (Rev 2.3) modded) RGB/S-Video J2 Extension for Technotrend Premium (for component/RGB-out) Has anyone got any advice on getting this working with VDR? I've been using VDR with budget cards for a few years with vdr-xine. This will be my first FF with an MPEG decoder - any problems/advice on the quality of the RGB-out? Also, will this card support HD ok??? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr That card works fine, in fact its recommended by many vdr users. Here is the scoop. The card does NOT do HDTV decoding in hardware. It will do it in software assuming the modulation is QPSK, (it does NOT support 8PSK commonly used for HDTV at least here) The card is used like a budget card if you are doing HDTV. The j2 mod on that board is done incorrectly. It does NOT have the proper circuitry to work out of the box, (It does NOT do component, only RGB). It is NOT terminated properly. It does post a risk of damaging the card if things are incorrectly wired. Correctly wired and terminated the RGB out works excellent. Any other questions? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] anyone using Technotrend Premium S2300 (Rev 2.3) modded
Simon Baxter wrote: That card works fine, in fact its recommended by many vdr users. Here is the scoop. The card does NOT do HDTV decoding in hardware. It will do it in software assuming the modulation is QPSK, (it does NOT support 8PSK commonly used for HDTV at least here) The card is used like a budget card if you are doing HDTV. The j2 mod on that board is done incorrectly. It does NOT have the proper circuitry to work out of the box, (It does NOT do component, only RGB). It is NOT terminated properly. It does post a risk of damaging the card if things are incorrectly wired. Correctly wired and terminated the RGB out works excellent. Any other questions? I'm confused. I thought component video was RGB? s-video uses luminance and chrominance, component uses RGB - am I wrong? Component video is color difference, S video is very similar to component, as there is a Y(luminance) but there are 2 color signals instead of one (R and B), the difference between R and B, makes G. RGB contains much more video bandwidth then component video. Svideo cannot handle HDTV, Component and RGB can. The SCART pinout says RED/Chroma pin 15, RED/Chroma GND pin 13, Green pin 11, Green GND pin 9, Blue pin 7, Blue GND pin 5. How do you go about terminating the RBG from J2 properly? What can this be connected to? Usually you need the filters and the termination resistors, and depending on where you live, RGB devices may or may not be common. (Think SCART) So the tuner will tune QPSK HDTV channels, which can be recorded or displayed with vdr-xine or softdevice, but the MPEG decoder won't output them. What's the best setup to use this then? Do you run vdr-xine or softdevice all the time and ignore the FF bit - to support TV and HDTV? Or just start vdr-xine when you tune to an HD channel? What does the MPEG decoder output when tuned to HDTV? Is there a better FF HDTV card with component/s-video MPEG decoder? I have 3 DVB-s cards in one machine, 1 is a FF, the other 2 are budget. I run in softmode using softdevice 100% of the time. Even though I don't receive and HDTV at all, using the output of a VGA card into a LCD projector produces a much better picture. The advantage to the FF card, is that it will work in a slow computer as the card does all the work. Displaying HDTV will need a powerful computer. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with ATSC card -- need help
yea the frontend supports it, but its otherwise useless. Mlists wrote: On Wed, 2006-08-16 at 22:06 -0400, Dave wrote: From what Im reading, the air2pc ATSC card only supports 8VSB, no support for QAM at all. hmm... but this is what I get with dvbsnoop: dvbsnoop -s feinfo -adapter 1 dvbsnoop V1.4.00 -- http://dvbsnoop.sourceforge.net/ - FrontEnd Info... - Device: /dev/dvb/adapter1/frontend0 Basic capabilities: Name: Broadcom BCM3510 VSB/QAM frontend Frontend-type: unkonwn Frequency (min): 54000.000 Frequency (max): 803000.000 Frequency stepsiz: 0.000 Frequency tolerance: 0 Symbol rate (min): 0.00 MSym/s Symbol rate (max): 0.00 MSym/s Symbol rate tolerance: 0 ppm Notifier delay: 0 ms Frontend capabilities: auto inversion FEC 1/2 FEC 2/3 FEC 3/4 FEC 5/6 FEC 7/8 FEC AUTO QAM 16 QAM 64 QAM 128 QAM 256 Current parameters: Error(95): frontend ioctl: Operation not supported Damn, maybe this is only the frontend too -- perhaps I have a card I can't use. Norm ___ 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
