Re: [vdr] Freeview Playback
On Tuesday 12 Jun 2007, Alex Stansfield wrote: > Hi, > > with the launch of Freeview Playback in the UK, I was wondering if > anyone here knew how the series links were sent to the dvb box. > > Freeview Playback is a system by which series link information is sent > to the dvb box, allowing someone to select to record a whole series. > Some sort of link information is sent, I guess in the epg, about each > episode so that the dvb box can be sure it's always recording unique > episodes of a series. > > I thought that support for Freeview Playback would be an excellent > addition to plugins like epgsearch. > > 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. The EPG format is covered by this document (which I think is the latest issue) http://webapp.etsi.org/action/OP/OP20060428/en_300468v010701o.pdf so presumably the data fits in to the specification somehow. I looked through this and also checked the broadcast data with dvbsnoop last weekend but couldn't see anything obvious. Maybe no-one is broadcasting the links yet. It would certainly be an excellent addition to VDR. 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
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 Monday 18 Jun 2007, Alex Stansfield wrote: > I've been finding my way around the vdr source code as the idea of > support for this series link has me interested in seeing if it's > something I might be able to do or help with. > > I guess we'd need to store the series link information in the epg.data > file. The question is where? I figured the two options were to put it on > the end of the event line (the one that starts with E and hold the event > ID, start time, duration, etc) or to create a new line specifically for > it. > > Also I was wondering about the amount of support to be put into vdr. To > have vdr support series recording would, imo, be quite a bit of work > when there are plugins that cover that sort of thing. So I was thinking > that it might be best to start with just adding support for finding the > series link, storing it in the epg and adding the property to the Event > class. > > I haven't figured out how plugins interact with vdr to grab Event > information but it would need to be able to pass the Series Link ID to a > plugin if it asks for it. An example would be epgsearch, when I select > an event in the EPG and hit '4' it creates a search from the event. It > would be nice if when i do that it checks to see if the Event has a > series link and if it does offers to create a search based on the Series > Link. > > Anyway that was just a few thoughts I had. If i'm going off on the wrong > track please let me know, I've never done any work on VDR itself before. One issue is whether this is a global standard (in which case perhaps vdr ought to support it) or a UK-only scheme (where a plug-in might be more appropriate). Do other countries / broadcast systems implement "Freeview Playback" aka "TV-Anytime" (ETSI TS 102 323)? -- 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] EPG: Events with same on different channels?
On Monday 16 Jul 2007, Friedhelm Büscher wrote: > Hi everybody. > > I wonder, if (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 of 4711 for "ard" and a 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] vdr-1.5.7-1.5.8.diff problems?
On Sunday 19 Aug 2007, Luca Olivetti wrote: > The diff fails on all po files, it's only me or does it happens to > others? The diff applies fine for me. -- 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
[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] 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] 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] 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
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: 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] 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
[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] 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
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] 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] 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] 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
[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] [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
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
[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
