headers
Issa Gorissen | 1 Mar 2011 13:25
Picon

Handling independent CI devices

Hello,

Support for the CI on Digital Devices under linux is put on hold because no
solution has been aggreed on as of 17/01/2001. This is about independent CI
devices handling.

www.mail-archive.com/linux-media <at> vger.kernel.org/msg22196.html
www.mail-archive.com/linuxtv-commits <at> linuxtv.org/msg09640.html

As the needed changes will have an impact on softwares like
MythtTV/VDR/TVHeadend, I would like to know your opinions/views about how you
see this implemented and what are your expectations.

Thx
--
Issa

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Permalink | Reply | 0 comments |
headers
Frank Schmirler | 1 Mar 2011 17:32
Picon

[ANNOUNCE] remotetimers-0.1.4

Hi,

I just released a new version of the remotetimers plugin on
http://vdr.schmirler.de

The new version includes some minor bugfixes plus the following new features:

* By renaming a recording, it may now also be moved to a different filesystem
by a background task. You can limit the bandwidth used for copying in the
plugin setup. 
* The plugin offers several service calls to other plugins which are already
used by "yaepghd-0.0.3-ce"
(http://vdrportal.de/board/thread.php?postid=949924#post949924)

Changelog:
- Improved German translations
- Updated Italian translations (thanks to Diego Pierotto)
- Default server port is now 0, i.e. taken from svdrpservice
- Fixed missing timer markers when opening the Schedule for the first time
- Implemented moving recording to a different filesystem with optional
  bandwidth throttle
- Cutting from menu failed for PES recordings since VDR 1.7.3 due to missing
  parameters to cMarks::Load
- Moving recordings into folders named ' ' failed or caused unexpected
  results as VDR's text input control strips trailing whitespace. Now 
  folder ' ' is assumed when renaming a recording and the name ends with
  the folder delimiter character
- Don't rename a recording if the user completely wiped out the name
- Added service interface for operating on timers
- Updated MainMenuHooks patch to v1.0.1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Houghton | 1 Mar 2011 21:23
Picon

Two problems with vdr 1.7.16-1devel2

I'm currently experiencing two problems with vdr 1.7.16-1devel2.

The first problem is that if I fast forward or rewind, when I return to
normal playback the stream resumes from wherever I started the ff/rew
instead of where I stopped it. That's with vdr-sxfe on remote clients,
I'm not sure whether it does the same if the client is on the same PC as
vdr.

The second problem is a memory leak. It's not too bad, but I have to
restart VDR about twice a week to make sure there's no swapping and
plenty of memory free for caching on a 2GB x86_64 system.

As well as xineliboutput I'm also using the eepg and remote plugins. All
from Tobias Grimm's debian repository.

Are these known problems, perhaps fixed in a later release of "upstream"
VDR?

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Permalink | Reply | 0 comments |
headers
Gerald Dachs | 2 Mar 2011 21:41
Picon

Messages from Lirc have to be longer than 21 chars, why?

Hi,

during my tests with eventlircd I noticed that the up key of my remote
didn't work with vdr, but with xbmc. I debugged vdr and stumbled above
the line lirc.c:89 (not vanilla sources):

         if (ready && ret > 21) {

Lirc sends this to vdr: 

	"67 0 KEY_UP devinput"

So this key gets ignored, all other key have longer names and are
working. Solution seems to be easy. Instead of 21 I could use 19, but
with inputlircd I get this string for the same key: 

	"67 0 KEY_UP event7"

It would get ignored again.

What is the intention for this condition: 

	ret > 21? 

Is it to make sure to not get garbage from lirc? But why 21 chars? What
would be a better length, or a better check?

Gerald

_______________________________________________
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andreas Brachold | 5 Mar 2011 10:21
Picon
Favicon

[announcement] Release 0.2.0 of vdr-plugin-dvdswitch

Hello,

A new release of vdr-plugin-dvdswitch

http://projects.vdr-developer.org/attachments/download/534/vdr-dvdswitch-0.2.0.tgz

Changes: http://projects.vdr-developer.org/versions/show/169

* Read name of volume to prefill OSD-Entry with filename
  Fill OSD-field with capitalize volume name
* Improve menu to read images
* Rename image was'nt possible
* used posix functions to parse commandline, 
  create symbolic links, parse mountpoint
* Improve handle of error messages
* Update translations
  Add italian translation (Support #490)
* refactoring MenuSetup
  Allow localized character at title of image menu
* remove some unused code, typecast ...

What's it 
---------
The dvdswitch plugin functions as a kind of a DVD changer. This plugin
make it possible to select images and play them with the DVD plugin.

But it's need too dvd-plugin

See included file README for more details.
http://projects.vdr-developer.org/projects/plg-dvdswitch/wiki
(Continue reading)

Permalink | Reply | 0 comments |
headers
Klaus Schmidinger | 6 Mar 2011 15:49
Picon
Favicon

Re: Messages from Lirc have to be longer than 21 chars, why?

On 02.03.2011 21:41, Gerald Dachs wrote:
> Hi,
> 
> during my tests with eventlircd I noticed that the up key of my remote
> didn't work with vdr, but with xbmc. I debugged vdr and stumbled above
> the line lirc.c:89 (not vanilla sources):
> 
>          if (ready && ret > 21) {
> 
> Lirc sends this to vdr: 
> 
> 	"67 0 KEY_UP devinput"
> 
> So this key gets ignored, all other key have longer names and are
> working. Solution seems to be easy. Instead of 21 I could use 19, but
> with inputlircd I get this string for the same key: 
> 
> 	"67 0 KEY_UP event7"
> 
> It would get ignored again.
> 
> What is the intention for this condition: 
> 
> 	ret > 21? 
> 
> Is it to make sure to not get garbage from lirc? But why 21 chars? What
> would be a better length, or a better check?

The check for 21 characters has been in there from the very start.
Note that there is also another explicit number in
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ville Skyttä | 6 Mar 2011 16:33
Picon
Picon
Favicon

Re: Messages from Lirc have to be longer than 21 chars, why?

On 03/06/2011 04:49 PM, Klaus Schmidinger wrote:

> I guess what we need first is a specification of the strings
> LIRC provides. Then we can adapt the VDR code accordingly.
> I quickly searched the web, but couldn't find that information.
>
> Anybody?

Maybe it has been discussed before, but I wonder why VDR has a LIRC 
implementation of its own instead of using liblirc_client?

http://www.lirc.org/html/technical.html#library

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Permalink | Reply | 2 comments |
headers
Steffen Barszus | 6 Mar 2011 16:56
Gravatar

Re: Messages from Lirc have to be longer than 21 chars, why?

On Sun, 06 Mar 2011 17:33:39 +0200
Ville Skyttä <ville.skytta <at> iki.fi> wrote:

> On 03/06/2011 04:49 PM, Klaus Schmidinger wrote:
> 
> > I guess what we need first is a specification of the strings
> > LIRC provides. Then we can adapt the VDR code accordingly.
> > I quickly searched the web, but couldn't find that information.
> >
> > Anybody?
> 
> Maybe it has been discussed before, but I wonder why VDR has a LIRC 
> implementation of its own instead of using liblirc_client?
> 
> http://www.lirc.org/html/technical.html#library

You need a lircrc file for that to use, i think that is just adding
another layer. Instead of learning the keys, you would need
to create what is in remote.conf in the .lircrc and have fixed keywords
in VDR. At least this is my understanding, correct me if i'm wrong. 

The format is described there as well. 

XBMC seems for instance just to read a line 

while (fgets(m_buf, sizeof(m_buf), m_file) != NULL)
...
    char scanCode[128];
    char buttonName[128];
    char repeatStr[4];
(Continue reading)

Permalink | Reply | 1 comment |
headers
Klaus Schmidinger | 6 Mar 2011 17:15
Picon
Favicon

Re: [Bug] VPS Recording not starting as long as another recording (with lower priority) is running

On 26.02.2011 15:24, Markus Ehrnsperger wrote:
> Hi,
> 
> I created two timers:
> 
> 5:S19.2E-1-1101-28106:2011-02-26:1330:1500:50:99:Das Traumhotel - Afrika:
> 9:S19.2E-1-1079-28006:2011-02-26:1300:1500:10:99:Wintersport:
> 
> The second timer was recorded for the complete time. The first Timer
> was ignored, in spite of the higher priority.
> This is related to VPS: A VPS timer seems to be ignored as long as
> other recorings block the devices. In this logic, the priority of the
> recoring is ignored.
> 
> Note: For this test, I started VDR with --device=0 so only one device
> is used. I used no patch (plain 1.7.16) and only one plugin
> (dvbsddevice).

The problem is that the VPS code in vdr.c avoids devices that are
currently recording. And since this is a rather complex area,
I'm not sure if it's too good an idea to change this ;-)

If you feel like it, you may want to take a look at the code under

  // Find a device that provides the required transponder:

in vdr.c. Maybe you can come up with a better solution...

Klaus
(Continue reading)

Permalink | Reply | 10 comments |
headers
Frank Schmirler | 7 Mar 2011 13:23
Picon

Re: [Bug] VPS Recording not starting as long as another recording (with lower priority) is running

Hi,

On Sun, 06 Mar 2011 17:15:44 +0100, Klaus Schmidinger wrote
> The problem is that the VPS code in vdr.c avoids devices that are
> currently recording. And since this is a rather complex area,
> I'm not sure if it's too good an idea to change this ;-)
> 
> If you feel like it, you may want to take a look at the code under
> 
>   // Find a device that provides the required transponder:
> 
> in vdr.c. Maybe you can come up with a better solution...

Unless I've missed something, that code does not only ignore priorities but
also the availability of CAMs. How about using cDevice::GetDevice(const
cChannel*, int, bool) to find out which device will do the job? After all
that's what cRecordControls::Start(...) uses later when looking for the device
to actually start recording from.

Streamdev-server already uses this method for quite a while to find out if a
device is available. The only change required in cDevice::GetDevice would be
that it needs to become a query only method again like it was before VDR
1.5.0. Currently it may detach receivers of the device it returns. Adding a
"query only" flag to the method should do. Streamdev currently includes a copy
of cDevice::GetDevice without the detach receivers part to get that "query
only" behaviour. Would be happy if I could get rid of that.

OT but related: Any chance to see Udo Richter's patch related to proper
priorities on the transfer mode receiver device in VDR? This patch eliminates
some more inconsistencies related to priorities. References:
(Continue reading)

Permalink | Reply | 9 comments |

Gmane