Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?
Hi Derek, Am 02.01.2017 um 17:43 schrieb VDR User: > Andreas: > As I said, no "magic" or "luck" is needed. Apparently you've never > heard of bandstacking. In the case of DVB-S, it's where one side is > carried in 950-1450Mhz and the other is carried in 1650-2150Mhz - full > circular lnb on ..one..single..cable,..no..magic. Bandstacking doesn't > use voltage switching, instead it simply operates at 18v. Power is > supplied either by the tuner or by a powered switch (if present). It's > not new and very commonly used here in NA/SA so whatever looking into > this subject you did, you didn't look very hard. It's reasonable that > you may live in some old crappy apartment with a horrible setup where > you truly are without options. You'll have a hard time finding such a > building here however. For that matter, most apartments have no > problem with tenants setting up dishes of their own with few > restrictions. Then you are lucky in NA/SA. In Europe the full band 950-2100 Mhz is used for TV broadcasting and that is true for low band (10700 - 11700 Mhz) and high band (11700 - 12700 MhZ) and for vertical and horizontal polarization each, 4 complete full bands, so no bandstacking is possible. Best regards, Andreas ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?
Hi Derek, Am 02.01.2017 um 01:46 schrieb VDR User: >> I would like to know which magic switch behind a single cable receiving only >> one polarization/band allows feeding multiple tuners with independent >> signals. ;-) > > There is no "magic", you probably should read up on switches I guess. I did and all satellite switches I know need 4 individual inputs, each providing one combination of polarization and band. So good look using a switch behind a single cable providing one combination of these 4 at one time. Maybe you are referring to signal splitters to provide one cable to multiple tuners, but these limit the received signal to the same combination of polarization and band for all of these tuners. And that is exactly the use case the device bonding is made for to get the most out of this limitation. I know that there are ways (OneCable and such) to provide individual signals to different tuners via one single cable. But this requires special switches in the infrastructure of a building the renter of an apartment is usually not able to change. Best regards, Andreas ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?
Am 01.01.2017 um 18:36 schrieb VDR User: >> they do in vdr-portal.de ... as I already do remember a bunch of users still >> using that function and the reasons why, so no what-if-scenarios. > > Not sure why you didn't mention that earlier but aside of that it > still doesn't answer this part: "I'd like to know why they don't just > use a switch. Simple, cheap, easy, and no complex code required." > > One of the main purposes of a switch is to feed multiple tuners from a > single cable so it's not like device bonding is a vital feature. The > pros don't seem to outweigh the cons but if enough people actually use > it it sounds like Klaus will take it into consideration. > > -Derek Hi Derek, I would like to know which magic switch behind a single cable receiving only one polarization/band allows feeding multiple tuners with independent signals. ;-) And, no I am not using this feature and I guess most people subscribed to this list don't use it, too. But there are much more VDR users out there, so asking here may not be representative. Best regards Andreas ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] TT6400 dvbhddevice ScaleVideo aspect ratio correction
Am 08.04.2013 19:42, schrieb Lucian Muresan: On 08.04.2013 10:36, Klaus Schmidinger wrote: Am I getting this right? cDvbHdFfDevice::ScaleVideo() apparently sets the video window in units of 1/1000 of the OSD width and height, respectively. Since this resolution is less than the possible acual OSD width or height, the rectangle actually used in this function might be different from the one given in the Rect parameter. While this is, of course, allowed, shouldn't the same calculations also be done in cDvbHdFfDevice::CanScaleVideo(), to return the correct rectangle to the skin? I think if the actual cDvbHdFfDevice::CanScaleVideo implementation would have really calculated something, it should have only converted internally to whatever needed (1/1000 in this case), and back to Osd pixel dimensions before returning the value. Since it doesn't (as it just returns the input rectangle, possibly because the device is able to handle any size within the limits, maybe nothing should be changed. Or maybe checking against the limits could be done, changed the size to a reasonable default (like Null for full size) and log an error if the input size wasn't within the Osd limits. Udo's variant looks well, but for all this maybe Andreas Regel should also be consulted. Btw, I sent him a PM on vdr-portal.de, he did not react so far. Hi, I tested the scaling myself using the nopacity skin. I integrated Udo's patch as is a bit clearer and directly points to the main requirement for correct aspect ratio: The width and height values must be equal as they represent percentages. Best regards, Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] TT6400 dvbhddevice ScaleVideo aspect ratio correction
On 08.04.2013 19:42, Lucian Muresan wrote: On 08.04.2013 10:36, Klaus Schmidinger wrote: Am I getting this right? cDvbHdFfDevice::ScaleVideo() apparently sets the video window in units of 1/1000 of the OSD width and height, respectively. Since this resolution is less than the possible acual OSD width or height, the rectangle actually used in this function might be different from the one given in the Rect parameter. While this is, of course, allowed, shouldn't the same calculations also be done in cDvbHdFfDevice::CanScaleVideo(), to return the correct rectangle to the skin? I think if the actual cDvbHdFfDevice::CanScaleVideo implementation would have really calculated something, it should have only converted internally to whatever needed (1/1000 in this case), and back to Osd pixel dimensions before returning the value. Since it doesn't (as it just returns the input rectangle, possibly because the device is able to handle any size within the limits, maybe nothing should be changed. Or maybe checking against the limits could be done, changed the size to a reasonable default (like Null for full size) and log an error if the input size wasn't within the Osd limits. Udo's variant looks well, but for all this maybe Andreas Regel should also be consulted. Btw, I sent him a PM on vdr-portal.de, he did not react so far. Regards, Lucian Hi, I will look into this shortly. Best regards Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T2 tuning
Am 10.10.2011 21:52, schrieb Tony Houghton: On Mon, 10 Oct 2011 17:31:14 +0200 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: I'm not aware of any DVB-T2 specific code in VDR 1.7.x. For DVB-S2 there had to be a special flag and additional tuning parameters. Don't know how this is handled with DVB-T2. This may help: ETSI EN 300 468 still doesn't cover DVB-T2 (but it does cover S2) but by googling for DVB-T2 delivery descriptor I found this PDF: It is part of ETSI EN 300 468 since 1.10.1 (2009-11) but you may have overseen it, as it is in the extended desriptor range, extension descriptor (tag 0x7F), tag extension 0x04. Best regards Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] missing const keywords in cOsd
Hi,
attached is a small patch that adds some missing const keywords in cOsd
class to be able to use Data and GetColor methods on const objects. The
patch is against vdr-1.6.0-1 but should apply cleanly against 1.7.3, too.
Regards
Andreas
diff -uN vdr-1.6.0/osd.c vdr-1.6/osd.c
--- vdr-1.6.0/osd.c 2007-10-12 14:38:36.0 +0200
+++ vdr-1.6/osd.c 2008-12-29 16:56:09.619517549 +0100
@@ -635,7 +635,7 @@
}
}
-const tIndex *cBitmap::Data(int x, int y)
+const tIndex *cBitmap::Data(int x, int y) const
{
return bitmap[y * width + x];
}
diff -uN vdr-1.6.0/osd.h vdr-1.6/osd.h
--- vdr-1.6.0/osd.h 2007-10-12 16:28:44.0 +0200
+++ vdr-1.6/osd.h 2008-12-29 16:51:06.938850671 +0100
@@ -231,9 +231,9 @@
/// 5: vertical, rising, upper
/// 6: vertical, falling, lower
/// 7: vertical, falling, upper
- const tIndex *Data(int x, int y);
+ const tIndex *Data(int x, int y) const;
/// Returns the address of the index byte at the given coordinates.
- tColor GetColor(int x, int y) { return Color(*Data(x, y)); }
+ tColor GetColor(int x, int y) const { return Color(*Data(x, y)); }
/// Returns the color at the given coordinates.
void ReduceBpp(const cPalette Palette);
/// Reduces the color depth of the bitmap to that of the given Palette.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE]: osdpip-0.0.10
Hi, there is a new version 0.0.10 of the osdpip plugin available: http://home.arcor.de/andreas.regel/files/osdpip/vdr-osdpip-0.0.10.tgz Changes since 0.0.9: - support swscale functions of recent FFMPEG versions. Have a look at README to see how to deactivate it for older FFPMEG versions. - support changed header file structure of recent FFMPEG versions. Have a look at README to see how to activate this. - added zapping through PiP channel based on a patch by pinky666 from vdr-portal. You can activate it via the green button. Regards, Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE]: powermate-0.0.5
Hi, there is a new version of the powermate plugin available: http://home.arcor.de/andreas.regel/files/powermate/vdr-powermate-0.0.5.tgz Changes since 0.0.4: - dropped support for VDR versions older than 1.5.8 - added localization support using gettext as introduced in VDR 1.5.7 - added german translations Regards, Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE]: osdpip-0.0.9
Hi, there is a new version of the osdpip plugin available: http://home.arcor.de/andreas.regel/files/vdr-osdpip-0.0.9.tgz Changes since 0.0.8: - dropped support for VDR version older than 1.3.47. - Now using palette replacemen introduced in VDR 1.3.27, so palette setting workaround is not needed any longer. This simplifies code a bit. - added support for VDR 1.6. Now 1.4 and 1.6 are supported (tested with 1.4.7 and 1.6.0) - added gettext localization support introduced with VDR 1.5.7. - Do not decode B frames when dropping them. - Use cCondWait::SleepMs instead of usleep. - Fixed automatic closing of OSD after some minutes. - Fixed showing wrong channel information. - Added missing inclusion of vdr/device.h. - Added new colour reduction mode using 256 dithered colours (thanks to Martin Wache). - Added french translations (thanks to micky979) Regards, Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE]: powermate-0.0.4
Hi, there is a new version of the powermate plugin available: http://home.arcor.de/andreas.regel/files/powermate/vdr-powermate-0.0.4.tgz Changes since 0.0.3: - added support for VDR 1.4 and 1.6 (older versions might work, too) - support APIVERSION introduced with vdr 1.3.47 - replaced uint64 with uint64_t - added keys that were introduced with VDR 1.3.18, 1.3.38, 1.3.47 and 1.5.10 Regards, Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE]: graphlcd-0.1.5
Hi, here is a new release of the GraphLCD base package and plugin for VDR. It fixes bugs and compile errors some people experienced. You can download the packages from the berlios project's file page: http://developer.berlios.de/project/showfiles.php?group_id=3566 Changes since 0.1.4: graphlcd-base changes: - added missing include path definition (thanks to Wolfgang Astleitner) - replaced unsigned long long with uint64_t - added missing includes - increased VER_MAJOR for glcdgraphics library as interface changed in an incompatible way (thanks to Tobias Grimm) - framebuffer driver: Changed type of fbp (framebuffer pointer) to void*. Compare fbp against MAP_FAILED to test for success of mmap. This should fix a x86_64 compile error. - ks0108 driver: Clear data lines after display refresh to fix problems with display contrast that occur under some conditions. vdr-graphlcd changes: - added some missing includes - do LCD initialisation in display thread instead of during plugin initialisation to fix some issues with direct port accesses (thanks to TomJoad from vdr-portal.de) Best regards Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE]: graphlcd-0.2.0-pre1
Hi, this is the first alpha release of the GraphLCD base package and plugin for VDR which finally introduces skinning support. There is still much functionality missing but it is basically working (Take a look into TODO file). There is no documentation yet. The skin format is based on text2skin's format with some simplifications and useful extensions like - global font definitions - variables (numbers and strings), evaluated while loading the skin - arithmetic functions - font functions to query font height, string width, ... - image functions to query image width and height Take a look at the supplied default skin for an example. Installation is as usual: copy the graphlcd subfolder to your VDR config/plugin directory. Start VDR with following example parameters: -P'graphlcd -d your display -s default'. The new parameter -s specifies the skin to use. The default skin shoudl look OK on both 128x64 and 240x128 displays. You can download the packages from the berlios project's file page: http://developer.berlios.de/project/showfiles.php?group_id=356 Regards, Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE]: graphlcd-0.2.0-pre1
Andreas Regel schrieb: Hi, this is the first alpha release of the GraphLCD base package and plugin for VDR which finally introduces skinning support. There is still much functionality missing but it is basically working (Take a look into TODO file). There is no documentation yet. The skin format is based on text2skin's format with some simplifications and useful extensions like - global font definitions - variables (numbers and strings), evaluated while loading the skin - arithmetic functions - font functions to query font height, string width, ... - image functions to query image width and height Take a look at the supplied default skin for an example. Installation is as usual: copy the graphlcd subfolder to your VDR config/plugin directory. Start VDR with following example parameters: -P'graphlcd -d your display -s default'. The new parameter -s specifies the skin to use. The default skin shoudl look OK on both 128x64 and 240x128 displays. You can download the packages from the berlios project's file page: http://developer.berlios.de/project/showfiles.php?group_id=356 I should at that this release requires VDR 1.4.2, tested here with 1.4.3. There will be a 0.1.4 soon with all the bug fixes and driver addtions that were made during 0.2.0 development. This release will still support VDR 1.2.6 and up. Regards Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE]: graphlcd-0.2.0-pre1
Andreas Regel schrieb: Hi, this is the first alpha release of the GraphLCD base package and plugin for VDR which finally introduces skinning support. There is still much functionality missing but it is basically working (Take a look into TODO file). There is no documentation yet. The skin format is based on text2skin's format with some simplifications and useful extensions like - global font definitions - variables (numbers and strings), evaluated while loading the skin - arithmetic functions - font functions to query font height, string width, ... - image functions to query image width and height Take a look at the supplied default skin for an example. Installation is as usual: copy the graphlcd subfolder to your VDR config/plugin directory. Start VDR with following example parameters: -P'graphlcd -d your display -s default'. The new parameter -s specifies the skin to use. The default skin shoudl look OK on both 128x64 and 240x128 displays. You can download the packages from the berlios project's file page: http://developer.berlios.de/project/showfiles.php?group_id=356 here is the correct link http://developer.berlios.de/project/showfiles.php?group_id=3566 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE]: graphlcd-0.1.4
Hi, here is a new release of the GraphLCD base package and plugin for VDR. It introduces new drivers and fixes bugs. There were also some changes to glcdgraphics library that were needed for skinning implementation. You can download the packages from the berlios project's file page: http://developer.berlios.de/project/showfiles.php?group_id=3566 Changes since 0.1.3: graphlcd-base changes: - added missing include of stdint.h in several files - added -fPIC compiler option to library Makefiles - graphlcd.conf: added missing Driver=serdisp in serdisp section (thanks to Jörn Hermann) - graphlcd.conf: changed default value for sleep method to gettimeofday - glcdgraphics library changes: - Added cBitmap::DrawSlope function that draws a slope of the given type - added class for loading and saving PBM (portable bitmap) files - made loading of GLCD files platform independent (hopefully) - added copy constructor to cBitmap class - removed the friend class stuff from cImage, instead added some functions to set members - new class cImageFile that acts as a base class for image format load/save classes like cGLCDFile or cPBMFile - removed const qualifier from cImage::GetBitmap - added added Invert method to cBitmap - added methods to set font parameter (height, ascent, ...) to cFont class - made loading of FNT files platform independent (hopefully) - return false in cGLCDFile::Open and ::Save when opening of file failed - added trim function to cut leading and trailing spaces from strings - added WrapText method to cFont class - fixed missing last line in cFont::WrapText - fixed WrapText when Height is zero - fixed font loading bug for graphlcd's FNT format - fixed missing addition of spaceBetween in cFont::WrapText that caused too long lines with some fonts - fixed loading of GLCD animations (thanks to Malte Schröder) - glcddrivers library changes: - only config.h, driver.h and drivers.h are needed for applications - added driver for g15daemon (thanks to Mike) - added driver for noritake gu126x64D-K610A4 display (thanks to Alexander Rieger) - gu140x32: fix seqfault if fonts.conf missed (thanks to Andreas Brachold) - t6963c: added support for Serial wiring using an industry version with a serial to parallel converter (thanks to Torsten Lang) - avrctl: adapted to changed commands PC - AVR - avrctl: implemented SetBrightness method - avrctl: changed type of some parameters to SetColData to uint16_t - avrctl: allow sizes below 256x128. Buffer sent to controller is still 256x128. - framebuffer: fixed compiler error on 64bit systems (thanks to Malte Schröder) - serdisp: updated serdisplib driver (thanks to Wolfgang Astleitner) - added simple network driver (not complete) that sends the current display content as and hey string to connected clients - link against libpthread - fixed some default values to be consistent with comments in graphlcd.conf - tools changes: - convpic: adapted to changes related to new base class cImageFile - convpic: use classes from glcdgraphics lib for glcd file conversion - convpic: added pbm support - crtfont: use cFont class methods to save in FNT format - genfont: use cFont class methods to load freetype2 supported fonts - genfont: use cFont class methods to save in FNT format - showpic: call SetBrightness method - showpic: changed setting of brightness to use value from config structure - new tool lcdtestpattern to display a test pattern on a LCD (thanks to Alexander Rieger) vdr-graphlcd changes: - support APIVERSION introduced with vdr 1.3.47 - test if ChannelNumber is 0 in cGraphLCDState::SetChannel - Added french translations (thanks to Pierre Briec) - use cPlugin::MainThreadHook method to do periodic querying of replay status. So, patching vdr is no longer needed. - fixed volume handling for vdr 1.4.2 and up - now use cFont::WrapText instead of local one - got rid of global lcd and display objects, they are local variables of the plugin class now. - display thread should be proper canceled now - logonames.alias for VDR 1.3 and up is the default now - increased lineheight in some bitmap fonts to look good with new WrapText function - extra space between menu lines when lineheight is greater than totalheight - replaced uint64 with uint64_t - replaced unsigned long long with uint64_t Best regards Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
