[vdr] [ANNOUNCE] VDR developer version 1.7.15
VDR developer version 1.7.15 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.15.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.14-1.7.15.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.14: - Added Macedonian language texts (thanks to Dimitar Petrovski). - Updated the Estonian OSD texts (thanks to Arthur Konovalov). - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Added handling of EnhancedAC3DescriptorTag (thanks to Eric Valette). - The default SVDRP port is now 6419 (registered with ICANN/IANA by Christian Tramnitz). Use '-p 2001' to switch back to the old port if necessary. - Updated the Italian OSD texts (thanks to Diego Pierotto). - cDvbDevice::ProvidesTransponder() now checks the modulation capabilities of the device (as far as the driver allows this). - Fixed cFrameDetector::Analyze() in case part of the data has been processed and there is less than MIN_TS_PACKETS_FOR_FRAME_DETECTOR left (reported by Derek Kelly). - Added a note about not deleting cDeviceHook objects to device.h. - Added user defined key kUser0 (suggested by Ulf Kiener). - Include paths are now added instead of overwriting INCLUDES in the Makefile (thanks to Paul Menzel). - The various modulation types are now taken into account when selecting a device for a recording or live viewing, so that devices that provide more capabilities are spared. - Fixed generating PMT language descriptors for multi language PIDs (thanks to Rolf Ahrenberg). - Transponders that use "8psk turbo fec" (a non-standard mode used by North American providers) are now identified by assuming that all 8psk transponders on DVB-S use "turbo fec". In order to determine whether a certain device can handle "turbo fec", the new driver flag FE_CAN_TURBO_FEC is checked. If your device can handle "turbo fec", and your driver doesn't have that flag, yet, you can apply the patch from ftp://ftp.tvdr.de/vdr/Developer/v4l-dvb-add-FE_CAN_TURBO_FEC.diff. A temporary macro in dvbdevice.c defines the flag for all those who don't need this in the driver, so that they can continue using an unmodified driver. Thanks to Derek Kelly for testing this. - Updated the Ukrainian OSD texts (thanks to Yarema Aka Knedlyk). - Fixed handling "none" color entries in XPM files (thanks to Thomas Gu"nther). - Fixed a crash when creating a new channel if the channel list is empty (reported by Halim Sahin). - Updated the Czech OSD texts (thanks to Radek Stastny). - Fixed a possible out of buffer memory access in case of bad TS data (reported by Rolf Ahrenberg). - Implemented handling of HD resolution subtitles according to v1.3.1 of ETSI EN 300 743, chapter 7.2.1 (thanks to Rolf Ahrenberg). - The EPG data now handles stream components 5 (H.264-video) and 6 (HEAAC-audio). - Fixed a problem with external Dolby Digital processing via the '-a' option in live mode and with TS recordings (reported by Christopher Reimer). - Added handling MPEG audio types "ISO/IEC 14496-3 Audio with LATM transport syntax" and "ISO/IEC 13818-7 Audio with ADTS transport syntax" (suggested by Luis Fernandes). See man vdr(5) on how the APID section of channels has been extended to store this information. - Added detecting channels that use service type 0x16. - Added full handling of the stream types of Dolby Digital pids (thanks to Jose Alberto Reguero). - The new setup option "OSD/Number keys for characters" can be used to control whether the number keys can be used to enter characters in a text input field (suggested by Stefan Huskamp). Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] S2API wrapper + hard link cutter for VDR-1.7.13-15
Hi list, Once again, I'm a bit late with updating my patches. However, here are the new ones: DVB/S2API wrapper patch, to run VDR-1.7 under DVB API V3: New version of the patch for VDR-1.7.13 - VDR-1.7.15 http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper Hard Link Cutter patch, for fast editing of recordings: New version for VDR-1.7.14 - VDR-1.7.15 http://www.udo-richter.de/vdr/patches.en.html#hlcutter Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] S2API wrapper + hard link cutter for VDR-1.7.13-15
Hi Udo > > Once again, I'm a bit late with updating my patches. However, here are > the new ones: > > DVB/S2API wrapper patch, to run VDR-1.7 under DVB API V3: > New version of the patch for VDR-1.7.13 - VDR-1.7.15 > > http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper > > Hard Link Cutter patch, for fast editing of recordings: > New version for VDR-1.7.14 - VDR-1.7.15 > > http://www.udo-richter.de/vdr/patches.en.html#hlcutter > Thanks for the patches ! Just one question: What is the reason for the DVB/S2API wrapper patch ? Why are you using the old DVB drivers ? -- Helmut Auer, hel...@helmutauer.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] S2API wrapper + hard link cutter for VDR-1.7.13-15
Am 06.06.2010 22:17, schrieb Helmut Auer: >> DVB/S2API wrapper patch, to run VDR-1.7 under DVB API V3: >> New version of the patch for VDR-1.7.13 - VDR-1.7.15 > > Thanks for the patches ! > > Just one question: > What is the reason for the DVB/S2API wrapper patch ? > Why are you using the old DVB drivers ? I'm using my vdr binaries on several machines and portable installations, most of them running debian lenny, means 2.6.26 by default, and no S2API. Since I have no hardware that has any advantage using S2API, and some of the machines don't even have DVB hardware at all, I'll keep up the compatibility for now. After the release of etch, and after all systems are up to date again, I'll probably drop the patch finally. But until then, there's a good chance for even more updates: I guess I'll need runtime switching between DVBV3API and S2API before etch is final. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Insufficient hardware PID filters on tuner (Klaus Schmidinger)
Klaus wrote: The question is can the total PID count be reduced when VDR is idle, or is there an assumption that a channel uses fewer than 4 PID's in calculating how many to leave spare for recordings (if that's how it works)? VDR doesn't do any calculations regarding the number of PID filters. It just assumes that there will be enough of them ;-) You might want to try VDR 1.7.14, which saves a few PID filters. Here's what you could try in VDR 1.6.0-2: - in eit.c exchange the code after the line "// --- cEitFilter ---" with that from VDR 1.7.14. You may need to leave out the "disable until" part. That saves two PID filters. - disable setting the system time from the transponder (saves another filter in eit.c) Klaus Great work, thanks Klaus - I patched version 1.6 as you suggest, leaving out the "disable until" bit. The Freecom USB receiver will now do at least 2 channels simultaneously, sometimes 3. When idle, 6 PID's are now in use normally instead of 8 (I wasn't setting system time - using NTP). Are you aware of anywhere the PID capacity of receivers is published - it's not in http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices for example? - it would be good to publish, so buyers can select better hardware cheers Richard ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] S2API wrapper + hard link cutter for VDR-1.7.13-15
Am 06.06.2010 22:40, schrieb Udo Richter: > After the release of etch, and after all systems are up to date again, > I'll probably drop the patch finally. But until then, there's a good > chance for even more updates: I guess I'll need runtime switching > between DVBV3API and S2API before etch is final. s/etch/squeeze/ of course. I'm getting old... Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Insufficient hardware PID filters on tuner (Klaus Schmidinger)
On Monday 07 June 2010 00:19:45 Richard F wrote: > Are you aware of anywhere the PID capacity of receivers is published - > it's not in http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices for > example? > - it would be good to publish, so buyers can select better hardware Since full speed usb devices have a 12Mbps bandwidth limit (on paper anyway, a bit optimistic for real usable data throughput) I'm not exactly convinced it really matters if you could get more pids out of it. You might (sometimes) get away with recording 3 channels on that but I certainly wouldn't count on it. If you get a high speed device it probably doesn't have a forced filter to begin with. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] radio-0.2.5 compile error
Hi Under vdr-1.7.15 I'm getting this compile error: [r...@localhost radio]# make g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"radio"' -I../../../include -I/include radioepg.c radioepg.c: In function 'int epg_premiere(const char*, const char*, time_t, time_t)': radioepg.c:26: error: invalid conversion from 'const char*' to 'char*' radioepg.c:31: error: invalid conversion from 'const char*' to 'char*' radioepg.c:42: error: invalid conversion from 'const char*' to 'char*' radioepg.c:55: error: invalid conversion from 'const char*' to 'char*' radioepg.c:60: error: invalid conversion from 'const char*' to 'char*' radioepg.c:72: error: invalid conversion from 'const char*' to 'char*' radioepg.c:90: error: invalid conversion from 'const char*' to 'char*' radioepg.c: In function 'int epg_kdg(const char*, time_t, time_t)': radioepg.c:157: error: invalid conversion from 'const char*' to 'char*' radioepg.c:168: error: invalid conversion from 'const char*' to 'char*' radioepg.c:179: error: invalid conversion from 'const char*' to 'char*' radioepg.c:190: error: invalid conversion from 'const char*' to 'char*' radioepg.c: In function 'int epg_unitymedia(const char*, const char*, time_t, time_t)': radioepg.c:257: error: invalid conversion from 'const char*' to 'char*' radioepg.c:260: error: invalid conversion from 'const char*' to 'char*' make: *** [radioepg.o] Error 1 Any ideas? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
