Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On 29.02.2012 08:17, Steffen Barszus wrote: On Wed, 29 Feb 2012 05:38:06 +0100 Gerogeronimo...@gmx.de wrote: On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote: 28.02.2012 12:24, Gero kirjoitti: On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote: I'll keep this in mind for after version 2.0. Why so far? Because 1.6.0 was released a long time ago, and we want a new stable version soon? :) Sure! - But next stable version would be 1.8 - wouldn't it? Next stable will be 2.0 AFAIK ... Yes, the next stable version will be 2.0. Version 1.0 was the SD version, and version 2.0 shall be the HD version ;-). I'll see to make client/server a priority after that. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On 29.02.2012 08:24, Dave wrote: And the Linux distributions will generally only package 'stable' versions. For Debian I'm already packaging 1.7.x, because 1.6 became pretty much useless nowadays. Wheezy is going to freeze in June and I hope that VDR becomes stable until then. Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Patch suggestion: Force CAM reset before upcoming recording
I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back online. Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard channel not available message. This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only. Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel? -- Heikki M ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patch suggestion: Force CAM reset before upcoming recording
On 29.02.2012 12:13, Heikki Manninen wrote: I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back online. Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard channel not available message. This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only. Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel? Wouldn't it be better to fix the actual problem and prevent the CAM from disappearing? Greetings Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patch suggestion: Force CAM reset before upcoming recording
On 29.2.2012, at 13.18, Klaus Schmidinger wrote: On 29.02.2012 12:13, Heikki Manninen wrote: I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back online. Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard channel not available message. This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only. Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel? Wouldn't it be better to fix the actual problem and prevent the CAM from disappearing? Of course as always. But we don't live in a perfect world ;) I'm not too happy about the idea to start testing different DVB card/CI combos on my own expense to find one that works. Especially nowadays when finding non-USB/Linux supported tuners for cable reception is next to impossible. -- Heikki M ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patch suggestion: Force CAM reset before upcoming recording
On 29.02.2012 12:22, Heikki Manninen wrote: On 29.2.2012, at 13.18, Klaus Schmidinger wrote: On 29.02.2012 12:13, Heikki Manninen wrote: I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back online. Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard channel not available message. This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only. Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel? Wouldn't it be better to fix the actual problem and prevent the CAM from disappearing? Of course as always. But we don't live in a perfect world ;) I'm not too happy about the idea to start testing different DVB card/CI combos on my own expense to find one that works. Especially nowadays when finding non-USB/Linux supported tuners for cable reception is next to impossible. I wasn't suggesting that you get some new hardware. What I meant was to fix the driver, which I would assume is causing the problems. Of course, there might as well be a problem in VDR's own CAM handling code. However, I've looked through that several times and didn't find anything that looks fishy. But if somebody can point out a bug in there, I'd be happy to accept a fix. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patch suggestion: Force CAM reset before upcoming recording
Hi list, my CAM drops out every once in a while, too. It's rather annoying, but I don't know how to fix the problem, so I decided to work around it. Whenever my CAM fails, the kernel/DVB driver seems to notice, and the debug ringbuffer contents reflect this. An error message like dvb_ca adapter 0: DVB CAM link initialisation failed :( also makes its way into syslog that way (because rsyslog retrieves messages from /dev/kmsg). I wrote a simple Python program that monitors a given logfile for the appearance of this message, and then tries to trigger the appropriate SVDRP HITK sequence via a plain and simple socket connection. So far, it works quite well (no manual CAM resets had to be performed by my parents for the last four weeks this way). If anyone happens to know a more reliable way to externally trigger a CAM reset via VDR/SVDRP, please let me know - right now, everything depends on the unchanged ordering of main menu entries, which is kind of annoying. @OP: If your drivers produce a similar message to mine when your CAM flakes out, I could provide my (inelegant, but tiny and apparently working) script to you. Let me know if you want to try it :) -- with best regards: - Johannes Truschnigg ( johan...@truschnigg.info ) www: http://johannes.truschnigg.info/ phone: +43 650 2 17 xmpp: johan...@truschnigg.info Please do not bother me with HTML-eMail or attachments. Thank you. signature.asc Description: Digital signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patch suggestion: Force CAM reset before upcoming recording
On 29.02.2012 12:29, Johannes Truschnigg wrote: Hi list, my CAM drops out every once in a while, too. It's rather annoying, but I don't know how to fix the problem, so I decided to work around it. Whenever my CAM fails, the kernel/DVB driver seems to notice, and the debug ringbuffer contents reflect this. An error message like dvb_ca adapter 0: DVB CAM link initialisation failed :( also makes its way into syslog that way (because rsyslog retrieves messages from /dev/kmsg). I wrote a simple Python program that monitors a given logfile for the appearance of this message, and then tries to trigger the appropriate SVDRP HITK sequence via a plain and simple socket connection. So far, it works quite well (no manual CAM resets had to be performed by my parents for the last four weeks this way). If anyone happens to know a more reliable way to externally trigger a CAM reset via VDR/SVDRP, please let me know - right now, everything depends on the unchanged ordering of main menu entries, which is kind of annoying. I also see this message in my log file from time to time. So this means that the driver apparently recognizes a CAM failure. Now the question is: why doesn't the driver report this fact to the application (VDR)? If VDR would receive this information, it could automatically do a reset. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patch suggestion: Force CAM reset before upcoming recording
On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote:
On 29.02.2012 12:13, Heikki Manninen wrote:
I have a number of different Conax CAM modules from different manufacturers
and all of them disappear from VDR after a couple of days running. Hitting
CAM reset on the CI menu will bring it back online. Naturally all Conax
channel recordings will fail silently as a result of this until the CAM has
been brought back up. Switching to an encrypted channel just gives the
standard channel not available message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From what I
understand, this seems to be a common problem though I'm not sure whether it
is limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is trying
to start recording non-FTA channel?
Wouldn't it be better to fix the actual problem and prevent
the CAM from disappearing?
Hola,
For me this seems to be driver issue, not VDRs fault. CI poll ioctl write seems
to fail sometimes with my KNC One (saa7146) budget cards . Following patch
seems to help in my case:
--- dvbci.c 2007-01-04 14:49:10.0 +0200
+++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300
@@ -62,8 +62,10 @@
void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length)
{
if (Buffer Length 0) {
- if (safe_write(fd, Buffer, Length) != Length)
+if (safe_write(fd, Buffer, Length) != Length) {
esyslog(ERROR: can't write to CI adapter on device %d: %m, device-De
viceNumber());
+ Reset(device-DeviceNumber());
+}
}
}
--
Kende
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patch suggestion: Force CAM reset before upcoming recording
On 29.2.2012, at 13.29, Johannes Truschnigg wrote: Hi list, my CAM drops out every once in a while, too. It's rather annoying, but I don't know how to fix the problem, so I decided to work around it. Whenever my CAM fails, the kernel/DVB driver seems to notice, and the debug ringbuffer contents reflect this. An error message like dvb_ca adapter 0: DVB CAM link initialisation failed :( Ok, that seems to be case for me as well: [ 28.712154] dvb_ca adapter 0: DVB CAM detected and initialised successfully [229405.488050] dvb_ca adapter 0: CAM tried to send a buffer larger than the ecount size! [229405.488063] dvb_ca adapter 0: DVB CAM link initialisation failed :( [344470.637483] budget_av: cam inserted A [344471.426622] dvb_ca adapter 0: DVB CAM detected and initialised successfully [352268.360055] dvb_ca adapter 0: CAM tried to send a buffer larger than the ecount size! [352268.360068] dvb_ca adapter 0: DVB CAM link initialisation failed :( Some scripting to try then.. -- Heikki M ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] DVB subtitke colors vary
Hi Lately I have been noticing that the fg color of the DVB subtitles changes irregularly between white, grey and black. If there is more than one line the lines may have different colors but the whole line is the same color. This is seen in Finnish YLE channels. Is there some setting for this? I was in the impression that color mapping should come with the subtitles but it would seem strange if they would change the color irregularly. Is this a broadcast issue or a VDR issue? I'm running Ubuntu 10.04.4 LTS. I've installed all from yavdr-stable repository and these are the installed components vdr (1.7.20/1.7.20) vompserver (0.3.1-3) femon (1.7.10) osdteletext (0.9.1) epgsearch (1.0.0) burn (0.2.0-beta7) pvrinput (2011-08-18) wirbelscan (0.0.7-pre01) vdrrip (0.3.0) conflictcheckonly (0.0.1) quickepgsearch (0.0.1) undelete (0.0.6) streamdev-server (0.5.1-git) webvideo (0.4.4) xineliboutput (1.0.90-cvs) dvd (0.3.6-b03) epgsearchonly (0.0.1) skinsoppalusikka (1.7.2) ttxtsubs (0.2.3) Player is vdr-sxfe 1.0.90-cvs also from yavdr repo. \\Karsta ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB subtitke colors vary
On 29.02.2012 14:52, Kartsa wrote: Hi Lately I have been noticing that the fg color of the DVB subtitles changes irregularly between white, grey and black. If there is more than one line the lines may have different colors but the whole line is the same color. This is seen in Finnish YLE channels. Is there some setting for this? I was in the impression that color mapping should come with the subtitles but it would seem strange if they would change the color irregularly. Is this a broadcast issue or a VDR issue? ... It's a known issue in VDR and will be fixed in version 1.7.25. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB subtitke colors vary
Hi There is an issue in the VDR's subtitle antialiasing. Finnish www.linuxtv.fi site can be found the patch, which fixed the problem in my VDR configuration. Link to patch - http://www.linuxtv.fi/viewtopic.php?f=12t=4618start=30 Jarkko On 29.2.2012 15:52, Kartsa wrote: Hi Lately I have been noticing that the fg color of the DVB subtitles changes irregularly between white, grey and black. If there is more than one line the lines may have different colors but the whole line is the same color. This is seen in Finnish YLE channels. Is there some setting for this? I was in the impression that color mapping should come with the subtitles but it would seem strange if they would change the color irregularly. Is this a broadcast issue or a VDR issue? I'm running Ubuntu 10.04.4 LTS. I've installed all from yavdr-stable repository and these are the installed components vdr (1.7.20/1.7.20) vompserver (0.3.1-3) femon (1.7.10) osdteletext (0.9.1) epgsearch (1.0.0) burn (0.2.0-beta7) pvrinput (2011-08-18) wirbelscan (0.0.7-pre01) vdrrip (0.3.0) conflictcheckonly (0.0.1) quickepgsearch (0.0.1) undelete (0.0.6) streamdev-server (0.5.1-git) webvideo (0.4.4) xineliboutput (1.0.90-cvs) dvd (0.3.6-b03) epgsearchonly (0.0.1) skinsoppalusikka (1.7.2) ttxtsubs (0.2.3) Player is vdr-sxfe 1.0.90-cvs also from yavdr repo. \\Karsta ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patch suggestion: Force CAM reset before upcoming recording
On 29.02.2012 12:44, Kende wrote:
On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote:
On 29.02.2012 12:13, Heikki Manninen wrote:
I have a number of different Conax CAM modules from different manufacturers and all of them
disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it
back online. Naturally all Conax channel recordings will fail silently as a result of
this until the CAM has been brought back up. Switching to an encrypted channel just gives the
standard channel not available message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From what I
understand, this seems to be a common problem though I'm not sure whether it is
limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is trying to
start recording non-FTA channel?
Wouldn't it be better to fix the actual problem and prevent
the CAM from disappearing?
Hola,
For me this seems to be driver issue, not VDRs fault. CI poll ioctl write seems
to fail sometimes with my KNC One (saa7146) budget cards . Following patch
seems to help in my case:
--- dvbci.c 2007-01-04 14:49:10.0 +0200
+++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300
@@ -62,8 +62,10 @@
void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length)
{
if (Buffer Length 0) {
- if (safe_write(fd, Buffer, Length) != Length)
+if (safe_write(fd, Buffer, Length) != Length) {
esyslog(ERROR: can't write to CI adapter on device %d: %m,
device-De
viceNumber());
+ Reset(device-DeviceNumber());
+}
}
}
I tried this, but I'm afraid it doesn't help.
The Reset() call was never triggered, even though my CAM went from normal
operation to the CAM ready state, and not even an explicit reset via
the Setup/CAM menu brought it to life again. Only after reloading the
driver and restarting VDR did it work again.
My theory is that switching channels is what's causing the problem.
When I trigger an EPG scan, the problem typically occurs after a while.
Maybe it's caused by tuning to channels that are no longer available,
so the frontend times out. However, there's no reason why a frontend
timeout should lead to a CAM freeze...
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Klaus Schmidinger wrote: Yes, the next stable version will be 2.0. Version 1.0 was the SD version, and version 2.0 shall be the HD version ;-). I'll see to make client/server a priority after that. What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, like the other built-in plugins. Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On 29.02.2012 16:48, Manuel Reimer wrote: Klaus Schmidinger wrote: Yes, the next stable version will be 2.0. Version 1.0 was the SD version, and version 2.0 shall be the HD version ;-). I'll see to make client/server a priority after that. What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, like the other built-in plugins. I'll cross that bridge when I get there ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB subtitke colors vary
Ok, thanks for the info. But I have to wait for the fix from Klaus since I am notcompiling anything my self. All must be in repos :) I have a couple of friends whose vdr box I maintain so I want to keep all as simple as possible. \\Kartsa 29.02.2012 16:16, Jarkko Kangas kirjoitti: Hi There is an issue in the VDR's subtitle antialiasing. Finnish www.linuxtv.fi site can be found the patch, which fixed the problem in my VDR configuration. Link to patch - http://www.linuxtv.fi/viewtopic.php?f=12t=4618start=30 Jarkko On 29.2.2012 15:52, Kartsa wrote: Hi Lately I have been noticing that the fg color of the DVB subtitles changes irregularly between white, grey and black. If there is more than one line the lines may have different colors but the whole line is the same color. This is seen in Finnish YLE channels. Is there some setting for this? I was in the impression that color mapping should come with the subtitles but it would seem strange if they would change the color irregularly. Is this a broadcast issue or a VDR issue? I'm running Ubuntu 10.04.4 LTS. I've installed all from yavdr-stable repository and these are the installed components vdr (1.7.20/1.7.20) vompserver (0.3.1-3) femon (1.7.10) osdteletext (0.9.1) epgsearch (1.0.0) burn (0.2.0-beta7) pvrinput (2011-08-18) wirbelscan (0.0.7-pre01) vdrrip (0.3.0) conflictcheckonly (0.0.1) quickepgsearch (0.0.1) undelete (0.0.6) streamdev-server (0.5.1-git) webvideo (0.4.4) xineliboutput (1.0.90-cvs) dvd (0.3.6-b03) epgsearchonly (0.0.1) skinsoppalusikka (1.7.2) ttxtsubs (0.2.3) Player is vdr-sxfe 1.0.90-cvs also from yavdr repo. \\Karsta ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wed, 29 Feb 2012 16:17:07 +0100, Klaus Schmidinger wrote Even though VDR itself doesn't have the necessity for remote receivers (yet), I see the problem for streamdev. I have therefore reconsidered this matter and will make the following changes for the next developer version: - Revised priority handling to allow receivers with a priority that is lower than that of live viewing (with suggestions from Frank Schmirler): + An idle device (one that is not used for live viewing and has no receiver attached to it) now has priority IDLEPRIORITY (-100). + An unused CAM slot now has priority IDLEPRIORITY. + The default priority of a cReceiver is now MINPRIORITY (-99). + A device that is used only for live viewing (no matter whether it's in Transfer Mode or real live mode) now has priority TRANSFERPRIORITY (-1). + The function cDevice::Receiving() now returns true if there is any receiver attached to the device. Its boolean parameter has no meaning any more. + The default value for the Priority parameter of the function cDevice::ProvidesChannel() has been changed to IDLEPRIORITY. When searching for a device for live viewing, VDR uses priority 0 for the search (thus avoiding any devices that are serving actual timer recordings), and - if going into Transfer Mode - gives the cReceiver a priority of -1. That way the next search for a live device will be able to use the one that is currently serving the Transfer Mode, because the search has a higher priority (this is pretty much the same as it was before). Now a remote transfer mode (which I assume is what streamdev and the like implement) can use a search priority of, say, -10, and a transfer priority of -11. That way the remote mechanism will also be able to reuse devices, just like local Transfer Mode. And local live mode can override remotely used devices due to its higher priority. I'm currently testing these changes in my own production VDR (local live and transfer mode only) and will release them in version 1.7.25 shortly. Let me know then if this works for you. Wow - this is good news. Thanks for reconsidering! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wed, 29 Feb 2012 16:48:33 +0100 Manuel Reimer manuel.rei...@gmx.de wrote: Klaus Schmidinger wrote: Yes, the next stable version will be 2.0. Version 1.0 was the SD version, and version 2.0 shall be the HD version ;-). I'll see to make client/server a priority after that. What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, like the other built-in plugins. I don't think a plugin is enough. For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Patch suggestion: Force CAM reset before upcoming recording
On Wed, Feb 29, 2012 at 7:39 AM, Klaus Schmidinger
klaus.schmidin...@tvdr.de wrote:
On 29.02.2012 12:44, Kende wrote:
On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote:
On 29.02.2012 12:13, Heikki Manninen wrote:
I have a number of different Conax CAM modules from different
manufacturers and all of them disappear from VDR after a couple of days
running. Hitting CAM reset on the CI menu will bring it back online.
Naturally all Conax channel recordings will fail silently as a result of
this until the CAM has been brought back up. Switching to an encrypted
channel just gives the standard channel not available message.
This happens (for me) with Satelco DVB-C card with Satelco CI. From
what I understand, this seems to be a common problem though I'm not sure
whether it is limited to Satelco devices only.
Would it be possible to force CAM reset on all CI slots when VDR is
trying to start recording non-FTA channel?
Wouldn't it be better to fix the actual problem and prevent
the CAM from disappearing?
Hola,
For me this seems to be driver issue, not VDRs fault. CI poll ioctl write
seems to fail sometimes with my KNC One (saa7146) budget cards . Following
patch seems to help in my case:
--- dvbci.c 2007-01-04 14:49:10.0 +0200
+++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300
@@ -62,8 +62,10 @@
void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length)
{
if (Buffer Length 0) {
- if (safe_write(fd, Buffer, Length) != Length)
+if (safe_write(fd, Buffer, Length) != Length) {
esyslog(ERROR: can't write to CI adapter on device %d: %m,
device-De
viceNumber());
+ Reset(device-DeviceNumber());
+}
}
}
I tried this, but I'm afraid it doesn't help.
The Reset() call was never triggered, even though my CAM went from normal
operation to the CAM ready state, and not even an explicit reset via
the Setup/CAM menu brought it to life again. Only after reloading the
driver and restarting VDR did it work again.
My theory is that switching channels is what's causing the problem.
When I trigger an EPG scan, the problem typically occurs after a while.
Maybe it's caused by tuning to channels that are no longer available,
so the frontend times out. However, there's no reason why a frontend
timeout should lead to a CAM freeze...
I've had this problem for years on my TT-2300-C-FF and TT-1501-C cards with
Alphacrypt Multicam. Updating the CAM has no effect, same experience with
multiple versions of VDR. Most of the time the CAM can be brought back to
Ready by doing a CAM Reset from the VDR menus multiple times. On rare
occasions the CAM will still be Ready but I still get Channel not
available, until I do a CAM reset a few times.
I have a crude script which looks for ERROR: can't write to CI adapter on
device in the syslog which notifies me so I can do the CAM reset (often
multiple times) from the VDR menus.
This appears to be either a bug in the dvb code - which has never been
fixed. To be honest - it's nice to hear other people have had the problem!!
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wed, Feb 29, 2012 at 12:20 AM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: Yes, the next stable version will be 2.0. Version 1.0 was the SD version, and version 2.0 shall be the HD version ;-). Sounds good! :) I'll see to make client/server a priority after that. I honestly had to read this a couple times to make sure I wasn't misunderstanding some how. This is a huge announcement and I think everyone will agree a big step in the right direction to suit modern needs. Since it sounds like true server/client will really happen for VDR now, maybe it would be a wise idea to start a dedicated thread to it for collecting information on identifying the needs/wants, and ways they can be met. This is a great opportunity to thoroughly think things through so the actual server/client design integration addresses all the necessary considerations. ...What an awesome way to start off the day! You're my hero Klaus! :D ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wednesday 29 February 2012 - 17:50:27, Tony Houghton wrote: On Wed, 29 Feb 2012 16:48:33 +0100 Manuel Reimer manuel.rei...@gmx.de wrote: Klaus Schmidinger wrote: Yes, the next stable version will be 2.0. Version 1.0 was the SD version, and version 2.0 shall be the HD version ;-). I'll see to make client/server a priority after that. What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, like the other built-in plugins. I don't think a plugin is enough. I agree. I think, it is evident not confuse plugin-networking with client/server networking. OK, currently the client/server support works only through plugins, as there is no vdr-frontend - but Klaus should not care about plugin- networking on designing client/server functionality. C/S-communication should be completely private to vdr - just like internal communication. Plugins may keep on doing their networking, i.e. to connect other frontends like xine or whatever - but that's not the internal communication, vdr relies on. For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously. Yeah, that would be very nice :) kind regards Gero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 29.02.2012 17:50, schrieb Tony Houghton: On Wed, 29 Feb 2012 16:48:33 +0100 Manuel Reimer manuel.rei...@gmx.de wrote: What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, like the other built-in plugins. I don't think a plugin is enough. For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously. Not necessarily. I think the key solution is to modularize VDR's internal structures, with well defined interfaces between them. A receiving module that provides stream sources, a recording module that does all the timer work, a frontend module that can display, a storage module that can store and provide videos, for example. A timer menu that belongs to a recording backend, a recording menu that displays content of storage modules, several frontends that can connect to one recording backend or several storage modules, and all can connect to different sources. With defined and pluggable structures between them, its easy to have them either locally connected or linked over network. Whether that's done by a plugin or VDR internally doesn't matter. In any case this would be the biggest rewrite of major parts of VDR ever, with lots of breakage, total loss of plugin compatibility and very long development cycle. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 29.02.2012 16:17, schrieb Klaus Schmidinger: + The function cDevice::Receiving() now returns true if there is any receiver attached to the device. Its boolean parameter has no meaning any more. Please remember to drop the following line from PLUGINS.html, as it is now finally completely void: (any negative value will allow a cReceiver to be detached from its cDevice at any time.) This was handled via Receiving(true). This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug. What about having yet another plugin callback that fires before switching a live channel? Currently, plugins get notified after channel change, and thats too late to disconnect receivers early. And since receiving at -1 doesn't have any special meaning any more, there's no way to get receivers out of way early enough. Roughly, the callback should be at the places where these two get called: DELETENULL(liveSubtitle); DELETENULL(dvbSubtitleConverter); (Thats how VDR's own receivers get out of way.) That way, GetDevice(ch, 0, true) will still have the weired behavior of returning different devices before and after initiating the live view channel switch, but at least after disconnecting all live related receivers, the correct device will be returned. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wednesday 29 February 2012 - 20:45:54, Udo Richter wrote: Am 29.02.2012 17:50, schrieb Tony Houghton: For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously. Not necessarily. I think the key solution is to modularize VDR's internal structures, with well defined interfaces between them. Well, that task is overdue, but not necessary to provide real a C/S app. But I think, the C/S task is easier to workout after a complete redesign and modularization. Additionally the modules should be grouped by layers, which makes design cleaner. A timer menu that belongs to a recording backend, a recording menu that displays content of storage modules, several frontends that can connect to one recording backend or several storage modules, ... I think, here is already the first shortcoming in design. May be cause you're thinking with today plugins in mind? If several independent clients open a timer menu, they should not interfere each other. If the menu is tied to the recording module (which should be a singleton), timer-menu would be like a singleton and a keystroke of one client changes the menu of all other clients too. That's not desired. Therefore menu representation should be decoupled from menu data, so i.e. the recording module (as all backend modules) provides their data (the timer-list) as list or tree structure only. The vdr provides a menu for each client, which is based on the same (singleton) list of timers. This way, each client can operate independently and if one client changes a timer, every other client will see the change - but no client is disturbed by the actions of other clients. So from my point of view, future design will have different types of plugins, like backend- and frontend-plugin (or name the plugin templates by the layer they belong to). They might have the same interface, but I think, it is better to differ the interfaces, so a plugin cannot be misused by accident. So backend-plugin (like nowadays dvdswitch) will only be allowed to provide a list of items, which will be used by OSD-Providers, that will create a menu different for each client and of cause, each menu can have different/independent state. For configuration a backend module may only say, I need an integer value called value, ranged from 0 to 5 with default of 2 - and it is up to the OSD- painter (skin), whether to use a slider or an input field, or what ever ... The backend module should not be allowed to care about user input elements. Thinking about configuration, the backend should be able to configure the number of possible clients and so the open ports. When a client connects, the vdr looks for a free input-module, that serves life-stream. Having multiple independent clients, the command to change the channel should not have any side-effect to other clients, nor disturb an active recording. Additionally it should be possible to configure the preferred input device used by this client for life-view. Other devices may be configured as fallback, in case the preferred device is not available. For FF-clients it is evident to have a preferred input device without any fallback. I think, this way no further distinction between FF-client and other clients is necessary. With defined and pluggable structures between them, its easy to have them either locally connected or linked over network. Whether that's done by a plugin or VDR internally doesn't matter. Oh - I think it does matter! As I already wrote, from my point of view, plugins may continue do networking, but the connection between backend- and frontend-part of vdr should not be public nor affected by any plugin. And the connection does not have to be tied to networking. Networking is just one implementation of internal communication, which could easily replaced by a communication, that uses shared memory or pipes or what ever - if backend and frontend reside at the same machine. So modules of internal connection may be interchangeable, but they should be considered private to vdr-core. Don't know, whether it makes sense to look a existing C/S protocols. If I got it right, there's no standard for it and each plugin uses its own protocol. C/S networking needs one channel for streaming from server to client and one channel for commands from client to server. This 2-channel networking is standard for any networking, so I don't see, where networking is a challenge. It might be the smallest and easiest part of the redesign. Real challenge is the break down and distribution of responsibility. In any case this would be the biggest rewrite of major parts of VDR ever, with lots of breakage, total loss of plugin compatibility and very long development cycle. :) so the earlier this task starts, the earlier it may finish :) kind regards Gero ___ vdr mailing list vdr@linuxtv.org
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wed, Feb 29, 2012 at 11:45 AM, Udo Richter udo_rich...@gmx.de wrote: In any case this would be the biggest rewrite of major parts of VDR ever, with lots of breakage, total loss of plugin compatibility and very long development cycle. It's not a small task, but I believe the end product will be well worth the effort. VDR has the benefit of having coder support. If people are willing (as I think they would be), one option to spread the workload could be Klaus assigning different portions to different contributors that would like to work on it. If Klaus is clear about what he wants and is in good communication with other coders, perhaps it could become more of a team effort with Klaus as team captain.. It's a lot of work but there's no reason it should take years to complete either. Especially if the design is well-thought out ahead of time. As far as plugin breakage.. I would expect there to be some growing pains and plugin maintainers needing to fix/add support for this is just a necessary part of the progression. Keep in mind, people have been wishing for VDR to go this route for quite a while so even if it means extra work fixing plugins, I think you'll find more people welcoming this change than not. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
