vdr

vdr@linuxtv.org

6731 discussions

backports from 1.4.6-1 to dev
by Stone 01 May '07

01 May '07

Hi, Klaus, I wasnt sure if you were going to release another version of 1.5.x, so I just wanted to toss these out there for testing. The NIT fixes in vdr-1.4.6-1 are not attached to this mail because they have already been posted to the list. Best Regards

2 3

[ANNOUNCE] VDR maintenance patch 1.4.6-1
by Klaus Schmidinger 01 May '07

01 May '07

VDR maintenance patch 1.4.6-1 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.6-1.diff This is a 'diff' against version 1.4.6. Small fixes to the officially released VDR versions will be first made available as "maintenance patches" in the Developer directory, so that they can be reviewed and tested before a new official release is published. So please apply the above patch and report whether it works (or if it causes any new problems). This version is binary compatible to the previous one, so plugins don't need to be recompiled. The changes since version 1.4.6: - Fixed a busy loop in fast forward if the next video data file is missing (thanks to Reinhard Nissl). - Fixed handling frequencies in NitFilter::Process() (thanks to Anssi Hannula). - Fixed handling ChannelUp/Down keys if there is currently a replay running (thanks to Marco Schlüßler). - Increased the maximum number of CA system ids to cope with the AlphaCrypt CAM's version 3.11 firmware. Have fun! Klaus

1 0

OT: "Pop around the clock" concerts all day on 3sat
by Lucian Muresan 01 May '07

01 May '07

Hello folks, did some of you, which can receive "3sat" also forgot, like me, they're broadcasting lots of good concerts today, all day? Well, I just remembered during the Chris Rea concert and started to record, I guess I'll schedule all of the remaining ones. They're listed in order of broadcasting here: http://www.3sat.de/3sat.php?http://www.3sat.de/poparoundtheclock_index.html right now "Cyndi Lauper & Friends" is recording... Now, is it legal or not, to exchange records which where broadcasted FTA and everyone COULD record? Anyone recorded the ones in the morning? Is this all some matter for VIDEGOR (haven't used it, but I guess I could set it up after finishing...)?

1 0

[Announce] epgsearch-0.9.21
by Christian Wieninger 01 May '07

01 May '07

Hi, here's the next release of epgsearch. 2007-04-29: Version 0.9.21 new: - support for the new MainMenuHooksPatch. This replaces the vdr-replace-schedulemenu patch. The new patch is used by other plugins too, so from now on only one patch is needed. The old patch is still supported, but this will be removed in the next releases. - announcements of broadcasts via OSD have been completely redesigned. Instead of displaying them event by event, you get now "x new broadcast(s) found! Show them?". Pressing 'Ok' shows a menu of all events with the usual functions as in other EPG menus. With "Edit" you can modify the announce settings (like "announce again: yes/no" or announce again after day x). - timer conflict notifications via OSD can now be supressed while replaying. Nevertheless, if a conflict comes up within the next 2 hours the message gets still displayed. - all addon plugins (epgsearchonly, quickepgsearch, conflictcheckonly) now have a setup option to toggle the main menu entry on/off, thanks to Tobias Grimm for providing a patch. - channel name in aux info of manual timers, thanks to Rolf Ahrenberg for providing a patch. - new script undoneepgsearch.sh to undo a timer within the recordings menu, more info at: http://www.vdr-portal.de/board/thread.php?postid=574109#post574109 Thanks to the author Christian Jacobsen - update for french translation, thanks to Patrice Staudt - update for finnish translation, thanks to Rolf Ahrenberg - menu 'timer conflicts details' now also shows the date of the conflict in menu title, suggested by Rusk@vdrportal. - the password for mail authentication is now hidden in the OSD, i.e. represented with '***...' - the setup for mail notifications now also has a "Send to" address, because some providers don't allow the same address for sender and recipient. If "Send to" is not set, epgsearch automatically uses the sender address as recipient. - when testing for repeats (with feature 'Avoid repeats') epgsearch now only compares the alphanumeric portions of title and episode and ignores the case too. Suggested by chello@vdrportal. - thanks to Rolf Ahrenberg for finnish translation update - added '&' to the set of valid chars for search terms fixes: - the tags stored in the aux info of the timers created with search timers conform now to correct XML syntax (no capitals, no blanks). E.g. "Search timer" will be changed to "searchtimer". So don't wonder if the first search timer update will modify all existent timers created with search timers. Thanks to Rolf Ahrenberg for reporting. - update of recordingdone.sh because of the previous changes, thanks to Mike Constabel for providing a patch - fixed a segfault in the case of misconfigured extended EPG categories. - scrolling text items now works again, if your skin supports this. Thanks to ufauser@vdrportal for reporting. - setup option "Use search timers" now always gets automatically enabled, if one toggles a search to 'active' or manually starts a search timer update. - fixed handling of double quotes in title/episode when passed to userdefined EPG commands, thanks to Mike Constabel for reporting. - fixed menu handling in search timer templates menu, thanks to wombel@vdrportal for reporting. Description and download: http://people.freenet.de/cwieninger/html/vdr-epg-search__english_.html wget: http://people.freenet.de/cwieninger/vdr-epgsearch-0.9.21.tgz Have fun! Christian

2 3

Logs filling up
by Rob Davis 30 Apr '07

30 Apr '07

How do I stop my logs filling up with: i2c_adapter i2c-1: master_xfer[1] R, addr=0x68, len=1 I am using a SkyStar2 card on gentoo x86. Dunno if it's a kernel module somewhere or something I can do to syslog. Thanks..

1 0

Can't write to CI adapter on device 0
by Simon Baxter 30 Apr '07

30 Apr '07

Hi. Lots of posts recently - many of which I've resolved! The latest - I've added an Irdeto CI adapter to my TT-1500 Budget card. But I can't decrypt channels, and get the following errors: In /var/log/messages: Apr 30 19:31:26 media1 vdr: [2774] CAM 1: module present Apr 30 19:31:28 media1 kernel: dvb_ca adapter 0: DVB CAM detected and initialised successfully Apr 30 19:31:28 media1 vdr: [2774] CAM 1: module ready Apr 30 19:31:29 media1 vdr: [2774] ERROR: can't write to CI adapter on device 0: Input/output error In dmesg: dvb_ca adapter 0: DVB CAM detected and initialised successfully dvb_ca adapter 0: DVB CAM detected and initialised successfully dvb_ca adapter 0: DVB CAM detected and initialised successfully and in the CAM menu on VDR: 1 CAM present 1 CAM ready 1 CAM present 1 CAM ready (etc) vdr-1.5.2, v4l-dvb hg snapshot from yesterday. Any ideas??

2 3

DVB-C scan with non-standard symbol rate
by Simon Baxter 30 Apr '07

30 Apr '07

Can anyone suggest a method to scan for channels with a non-standard symbol rate? My provider does not use 6900 or 6875. Thanks Simon

2 3

remote plugin ignoring some keys
by Artur Skawina 29 Apr '07

29 Apr '07

A while ago the remote plugins "telnet" server started acting strangely here; it would sometimes ignore all cursor and function keys, yet other keys would work perfectly. I'm not sure when exactly this began, most likely a newer kernel triggered this. It does not happen always, but when it does it makes navigating the OSD practically impossible. Turns out the remote plugin gets confused when a read() call returns not a full escape sequence, but just the first \0x27 byte and the next read() receives the remaining two or three bytes. And this is exactly what happens (the client for some reason actually sends two tcp packets containing just eg "\0x1b" and "\0x5b\0x43"). This quick patch made the remote osd usable again; it isn't perfect as keys can still be lost (see comments), but it's a huge improvement - only some key repeats are dropped, not all multibyte sequences. artur diff -urNp remote-0.3.9.org/remote.c remote-0.3.9/remote.c --- remote-0.3.9.org/remote.c 2006-12-03 14:46:55.000000000 +0000 +++ remote-0.3.9/remote.c 2007-04-29 20:45:13.000000000 +0000 @@ -517,6 +517,27 @@ uint64_t cRemoteDevTty::getKey(void) uint64_t code = 0; n = read(fh, &code, sizeof code); + + if (code==27 && n==1) + { + // Ugh. What happened: user pressed a key that generates an escape + // sequence (eg up/down) and we got only the first '\e'; now we have + // to fetch the remaining bytes as otherwise we end up ignoring almost + // every such key press and navigating the osd becomes impossible. + // We try to read more bytes and hope that the result makes sense; + // this often works, but not always. When eg holding down a key we + // can receive several (repeated) sequences and these are then ignored. + // Dropping a few key presses (mostly repeats) is still much better + // than dropping nearly _all_ of them... + // (Unfortunately the sequences do differ in length, hence either + // parsing them or matching them w/ the expected ones would be needed + // to avoid loosing sync here) + int m = read(fh, ((char*)&code)+1, sizeof code-1); + if (m > 0) + n += m; + } + //dsyslog("cRemoteDevTty::getKey: %d %lld", n, code); + return (n > 0) ? code : INVALID_KEY; }

1 0

[BUG] check terminal access
by s.huelswitt＠gmx.de 29 Apr '07

29 Apr '07

Hi, I think there is a bug in the RW access check for a terminal given with commandline option -t. The check is performed before VDR actualy switches his uid, so if the user which starts VDR has access rights and the effective vdr user doesn't have, the check is useless. In addition VDR should check the return value of freopen() when claiming the terminal later on. The current code segfaults on the first terminal access (e.g. printf), if the effective vdr user doesn't have sufficient rights. Regards. -- Stefan Huelswitt s.huelswitt(a)gmx.de | http://www.muempf.de/

3 3

[PATCH] re-use devices in transfer mode
by Anssi Hannula 29 Apr '07

29 Apr '07

Hi! Consider the scenario: - 2 devices, 1 used in transfer mode on transponder A - a new recording / streamdev session starts on transponder A Now, IMO the correct thing to do is start the new receiver in the transfer-moded device, so that the second device is left free. However, the usual "use-already-tuned-devices" check in GetDevice() only checks for device->Receiving(), which does not report transfer-moded device, resulting in the new receiver being started on second device, thus both devices being reserved for receiving data from the same transponder. Attached is a patch for GetDevice() to check for transfer-moded devices as well. -- Anssi Hannula

4 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr