VDR developer version 1.7.11 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.11.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.10-1.7.11.diff
WARNING: ========
This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging.
The changes since version 1.7.10:
- Fixed resetting the file size when regenerating the index file. - The new function cDevice::PatPmtParser() can be used in derived devices to access the PAT/PMT of the currently replayed material. - Updated the Italian OSD texts (thanks to Diego Pierotto). - The PCR pid in generated PMTs is now set to 0x1FFF ("no PCR pid") in cPatPmtGenerator::GeneratePmt(), because VDR doesn't record the PCR pid. - Updated the Estonian OSD texts (thanks to Arthur Konovalov). - The 'sky' plugin is no longer part of the VDR source. - Improved SPU handling on devices with limited OSD capabilities (thanks to Matthieu Castet). - Several code modifications to avoid compiler warnings (thanks to Winfried Ko"hler). - Added stream type 11172 AUDIO to cPatPmtParser::ParsePmt() (thanks to Johann Friedrichs). - Removed debug output of '-' from cTransfer::Receive(). - Added defines for large files to the 'newplugin' script (reported by Udo Richter). - Removed the workaround for short channel names of "Kabel Deutschland", because apparently they now have their data according to the DVB standard (thanks to Johann Friedrichs). - Some fixes to dvbspu.[hc] (thanks to Johann Friedrichs). - Fixed a busy loop when moving editing marks (thanks to Johann Friedrichs). - Updated sources.conf (thanks to Derek Kelly). - Modified cCharSetConv so that it can be used to convert from "whatever VDR uses" to a given code (thanks to Joachim Wilke). - Channel names containing commas are now handled correctly in channels.conf. If a channel's short name contains a comma, it is replaced with a '.'. - cDevice now logs the device number when a new device is created. - Fixed handling STREAMTYPE_11172_AUDIO in cPatPmtParser::ParsePmt(). - cParsePatPmt now has functions to retrieve the audio, dolby and subtitle pids. - cPatFilter::Process() now only stores CA descriptors for video and audio pids (thanks to Francesco Saverio Schiavarelli for reporting a problem with channels that have some encrypted components that VDR doesn't use). - cDevice::AddPid() now stores the stream type of the given pid (thanks to Andreas Regel). - Added cFont::FontName() and cFont::Size() (thanks to Andreas Regel). - cPatPmtParser now also stores the audio stream types. - The support for full featured DVB cards of the TT/FuSi design has been moved into the new plugin 'dvbsddevice'. On systems that use such a card as their primary device, this plugin now needs to be loaded when running VDR in order to view live or recorded video. If the plugin is not loaded, the card will be treated like a budget DVB card, and there will be no OSD or viewing capability. - Fixed handling the "CA PMT" generation (revised a change not mentioned in version 1.7.9's changes, which caused a malfunction with Conax and Viaccess CAMs). - Fixed stopping subtitle display when switching the primary device (thanks to Anssi Hannula). IMPORTANT NOTE TO PLUGIN AUTHORS: a plugin that implements a derived cDevice class that can replay video must now call the MakePrimaryDevice() function of its base class. - Fixed compiler warnings "format not a string literal and no format arguments" in some syslog calls (thanks to Rolf Ahrenberg). - The new command line options --edit and --genindex can be used to edit a recording or generate its index without actually starting the entire VDR (based on a patch from Helmut Auer). - Improved the description of the transponder parameters in vdr.5 (thanks to Winfried Ko"hler). - Avoiding setting the video stream type to 2 if the vpid is 0 (problem reported by Arthur Konovalov). - Implemented handling the "Content Descriptor" (based on a patch from Rolf Ahrenberg). The 'classic', 'sttng' and 'curses' skins display the textual representation of the content descriptors as "genre". The epg.data file stores the genre using the tag character 'G'. - Implemented handling the "Parental Rating Descriptor" (based on a patch from Rolf Ahrenberg). The 'classic', 'sttng' and 'curses' skins display the parental rating (if given) in their event displays. The epg.data file stores the parental rating using the tag character 'R'. IMPORTANT NOTE: if VDR doesn't display a parental rating, this does not necessarily mean that the given programme is suitable for all audiences! - Rearranged cEvent members to minimize memory waste. - After a CLRE command, no further EPG processing is now done for 10 seconds, so that data sent with subsequent PUTE commands doesn't interfere with data from the broadcasters (suggested by Helmut Auer). - Added support for DVB cards with multiple fontends. Note that this only works for DVB cards where each frontend can be used independently of all the others on the same adapter. - Fixed plugin arguments corruption with glibc 2.11 on x86_64 (thanks to Anssi Hannula).
Have fun!
Klaus
[...]
[...] Any chance of using using DVB-T frontend on HVR-4000? This card have 2 separate frontends. And as quoted on http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000:
"Multiple frontends are supported: DVB-S/S2 and DVB-T appear as /dev/dvb/adapterN/frontend0 and /dev/dvb/adapterN/frontend1 respectively.
Due to a hardware limitation, the two frontends cannot be used simultaneously. However they can be used sequentially within the same application. The driver handles the mutual exclusion appropriately."
Regards, Tomasz Bubel
On 06.01.2010 14:22, Tomasz Bubel wrote:
Well, that's still a problem. Is there a defined way (via the LinuxDVB driver API) through which VDR can find out whether the frontends can be used independently?
Klaus
On Wed, Jan 6, 2010 at 5:55 PM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
Some more food for thought ..
There is also one more added problem: Say there are two adapters and two frontends. I will try to convey the thought as simplest as possible by me...
A case in which frontend0 is bound to adapter0 and frontend1 is bound to adapter 1
This would seem like a classical case of having 2 independent adapters. But let's analyze it a bit more deeply. The two adapters A0 and A1 are on the same physical A (adapter) chip and can send you data simultaneously on both the devices. Likewise F0 and F1 can be on the same physical F (frontend) chip and can send you simultaneous data to both A0 and A1.
Now suppose that you are having F0 and F1 operational: The F chip would have a limitation on some parameter, which is based on a combination of F0 and F1. If the sum parameter is exceeded on the whole F chip, the entire F chip would crash and might need a Reset.
Likewise the same holds good for the A chip too ..
Another case is where you have A0, A1 and F0, F1 on the same chip while additionally providing F2 and F3 on virtual A0' and A1'.
But in all cases, the question remains the same. How would the application like to handle a situation, when a certain parameter will be exceed on the next operation on the next 'Fx' interface ? (If the application feels free and does the operation which might cause some parameter to exceed, the chip as a whole would not respond, unless reset again)
Operations like this might be common on cards having dual, quad and hex frontends. The card itself might be able to stream dual, quad and hex simultaneous streams.
Regards, Manu
On 06.01.2010 15:30, Manu Abraham wrote:
From an application's point of view I would distinguish these cases:
1.) An adapter provides one or more frontends that can be used independently. VDR creates one cDvbDevice for each of them and uses them as completely independent devices (this is currently implemented)
2.) An adapter provides several frontends, only one of which can be used at any given time. VDR creates one cDvbDevice for the adapter and needs to handle the selection of the actual frontend inside that device. In order to implement this, we need a way of finding out this situation through the driver API.
Anything else is probably way too complex to handle and might be called "broken by design".
Klaus
Manu Abraham wrote:
Imho limitations or dependencies between different *adapters* are not acceptable. If a driver maps frontends to different adapters, the driver pretends that they can be used independent of each other and without limitations.
If there are limitations, the frontends must be assigned to the same adapter. Anything else does not make any sense to me.
CU Oliver
On Wed, Jan 6, 2010 at 7:52 PM, Oliver Endriss o.endriss@gmx.de wrote:
Ok, I agree to your point. But it all depends on what we define an adapter is:
Is the adapter specified by the I2C interface, or is it by the actual number of DMA interface ?
In the case of the card that which is mentioned in here, a CX88 PCI card, it neither has dual I2C nor dual DMA. It is just a simple software mutex in the driver alone.
But, suppose a device has lets say 13 physical DMA interfaces which can be applied to a total of 18 DMA interfaces, ie at any time the physical chip can do a total of 13 DMA instances at any given point of time.
Now, all the DMA transfer for all the 'n' interfaces will be over a single memory interface, say maybe a Dual ported memory or something that way. Eventually there will exist a memory bandwidth on any physical memory. That bandwidth has to be shared between 13 instances. So in reality there will be a given limitation on the bandwidth in use, ie for example, when at any given point of instance, you might be able to do 2 SD streams, while practically it might be possible to handle only a single HD stream, or maybe a HD + SD stream, but might not be possible to handle 2 HD streams, to mention a specific case.
For any device that we consider, there is a limitation on the bandwidth that each interface or whatever we might call it.
But eventually, I guess maybe it is better for the driver to handle it internally, though it may look rather damned complex, with lot of multiplexing of the DMA and computation of the bandwidth in use.
Regards, Manu
Manu Abraham wrote:
I define an adapter as the entity /dev/dvb/adapterX, as seen by the application software.
An application may assume that devices from adapter X do not interfere with devices from adapterY (X != Y).
It does not matter, whether two adapters reside on the same hardware (PCI card, whatever), if (and only if) the driver can guarantee that they do not interfere.
In this case it is the choice of the driver developer, whether he uses one or more adapters. I prefer one adapter.
Is the adapter specified by the I2C interface, or is it by the actual number of DMA interface ?
No, these are internals of the driver. User space software should not have to care about this stuff.
Imho this driver should better implement *one* frontend, with some kind of mode switching...
In this case the driver should implement 1 adapter and n frontends. ;-)
If some ressource limit will be exceeded, the driver should deny the ioctl request from the application. As all frontends reside on the same adapter, the application might guess that there is a ressource problem. So it will simply try to use a different adapter...
(Basically, application developers do not want to know what is going on in the driver. ;-)
though it may look rather damned complex, with lot of multiplexing of the DMA and computation of the bandwidth in use.
Keep it as simple as possible. If unsure, it is better to refuse a request. If you accept it, you must be sure that you can fulfil it, and ongoing data transfers on other frontends must not be interrupted.
Regards, Oliver
Klaus Schmidinger wrote:
Afaik DVB API does not specify any way to do that.
For now, I suggest that you simply try to open the frontend. If this fails, you may assume some kind of ressource limitation...
CU Oliver
Klaus Schmidinger wrote:
Shouldn't all frontends that are independent show up as completely different adapters in /dev/dvb/, so that VDR can assume only one frontend per adapter is usable simultaneously?
If not, why is that?
On 06.01.2010 19:30, Anssi Hannula wrote:
I would love it if I could assume that with an adapter with several frontends, only *one* of these frontends could be used at any given time, and that, if a DVB hardware provides several frontends that can be used simultaneously, these would appear as separate adapters with one frontend each. That would be a simple, straightforward setup. But apparently things aren't meant to be simple... :-(
Klaus
On 6 Jan 2010, at 13:22, Tomasz Bubel wrote:
Ping.
I have this card and I am aware that the frontends cannot be used simultaneously. I was unaware of the statement regarding "sequential use within the same application". With even just a little thought I can see that this is not at all the same as 'simultaneous.'
It does raise at least the possibility of a VDR setup config to use DVB-T rather than DVB-S, instead of the game of symlinks that I play at the moment (manual, one time choice of DVB-T or DVB-S, not satisfactory and low WAF).
I can imagine that something like this is not a simple addition to implement but if there is currently momentum in this direction then more 'effort' at this stage will be more effective than at a later date.
I have not given this much thought at all and I am yet to explore the potential of the SourceCaps patch. These comments are really an expression of interest in developments of the features of the HVR4000 (that I imagine most VDR/HVR4000 users share).
Enough of my babbling.
Best wishes,
Ian.
There was a patch for HVR-3000 with was make by EDDI: http://tux.dpeddi.com/lr319sta/downloads/vdr_1.4.5_eddi-multiple-frontend_v5... Regards, Tomasz
2010/1/6, Ian Bates ian_and_joanna@talktalk.net:
Am Mittwoch, den 06.01.2010, 13:34 +0100 schrieb Klaus Schmidinger:
VDR developer version 1.7.11 is now available at
...
The changes since version 1.7.10:
...
Believe it or not, I was working on this patch this afternoon. I should have checked my emails earlier. But how about changing all these #defines in enumeration in epg.h? I also changed the names the way, that they fit better to the rest of vdr's source code (patch attached). ARD also sends some kind of user defined Content Descriptor, but unfortunately it's nowhere documented.
Regards,
Joachim
On 06.01.2010 20:31, JW wrote:
Adopted for version 1.7.12. I also changed "mask" to "group", because these values are not really mask values.
Please provide your real name if you care to be mentioned in VDR/CONTRIBUTORS.
ARD also sends some kind of user defined Content Descriptor, but unfortunately it's nowhere documented.
The DVB standard should never have allowed any "user defined" stuff... :-(
Klaus
2010/1/8 Klaus Schmidinger Klaus.Schmidinger@tvdr.de:
Hi Klaus, any plans on including vdr-1.7.9-pluginparam.patch for pvrinput plugin? http://drseltsam.device.name/vdr/pvr/src/pvrinput
This seems to create an input device of Plugin Type. I guess the vdr-iptv plugin also creates something similar.
Theunis
On Mon, Jan 11, 2010 at 11:41 PM, Theunis Potgieter theunis.potgieter@gmail.com wrote:
Hopefully the truecolor osd upgrade is high on the list as well. ;)
-
Anssi Hannula -
Goga777 -
Ian Bates -
JW -
Klaus Schmidinger -
Manu Abraham -
Oliver Endriss -
Petri Helin -
Rolf Ahrenberg -
Theunis Potgieter -
Tomasz Bubel -
VDR User