Re: [vdr] Epia MII questions

2010-12-01 Thread Teemu Suikki
2010/11/21 Rene linu...@hertell.com:
 Hi all!

 Is there anyone out there who is using the Via Epia MII 1 or 12000
 board with a current kernel and the 1.6.x build of vdr? I would need
 some some up to date-help in getting the onboard mpeg2-chip in use with
 the softdevice-plugin.

 I'm currently running my system with a budget technotrend dvb-t card,
 and a full featured dvb-s card that handles the output of the picture.
 Now i'm moving to an area with a dvb-c network, and for that i got my
 hands on two buget dvb-c cards.

 All documents i find is mainly for old 2.6 kernels (for example 2.6.10),
 and what i understood, the unichrome/cle266 patches for the onboard
 mpeg2 chip is not included in DirectFB or the main kernel itself...

There was an experimental epia softdevice a long time ago, but I don't
think it has been updated lately.. It worked but it was quite
unstable.

I ended up buying an used dxr3 card, they only cost a few bucks and
are well supported by dxr3-plugin..

-- 
Teemu Suikki
http://www.z-power.fi/

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] CAM auto resetting - feature request??

2010-12-01 Thread Halim Sahin
Hi,
On Sun, Dec 06, 2009 at 04:42:02PM +0100, Klaus Schmidinger wrote:
 On 01.09.2009 23:38, Simon Baxter wrote:
  I was afraid that might be the suggestion!
 
  It seems pretty random when the CAM will crash.  It is possible it's
  only on certain channels, and only one of the CAMs - it only happens
  very rarely
 
  So you have 2 identical CAMs (Alphacrypt) (with the same firmware?),
  and exactly one of them sometimes fails, right?
 
  Have you tried swapping the two CAMs?
  This should tell us whether the problem is with the CAM or with
  the CI adapter.
 
  Klaus
  
  I've discovered this happens to both CAMs, so it's either not a hardware
  issue, or both CAMs are affected.
  
  Managed to capture the following logs prior to the CAM dropping from
  AlphaCrypt to CAM Ready (with no decrypting)
  
  Sep  2 08:17:21 freddy vdr: [27702] switching to channel 11
  Sep  2 08:17:21 freddy vdr: [1150] transfer thread ended (pid=27702,
  tid=1150)
  Sep  2 08:17:21 freddy vdr: [27702] buffer stats: 110356 (5%) used
  Sep  2 08:17:21 freddy vdr: [6564] transfer thread started (pid=27702,
  tid=6564)
  Sep  2 08:17:21 freddy vdr: [1152] TS buffer on device 1 thread ended
  (pid=27702, tid=1152)
  Sep  2 08:17:21 freddy vdr: [1151] buffer stats: 75388 (3%) used
  Sep  2 08:17:21 freddy vdr: [1151] receiver on device 1 thread ended
  (pid=27702, tid=1151)
  Sep  2 08:17:21 freddy vdr: [6565] receiver on device 1 thread started
  (pid=27702, tid=6565)
  Sep  2 08:17:21 freddy vdr: [6566] TS buffer on device 1 thread started
  (pid=27702, tid=6566)
  Sep  2 08:17:23 freddy vdr: [6564] setting audio track to 1 (0)
  Sep  2 08:17:34 freddy vdr: [27702] switching to channel 1
  Sep  2 08:17:34 freddy vdr: [6564] transfer thread ended (pid=27702,
  tid=6564)
  Sep  2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS
  continuity errors
  Sep  2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS
  continuity errors
  Sep  2 08:17:34 freddy vdr: [27702] buffer stats: 63544 (3%) used
  Sep  2 08:17:34 freddy vdr: [6567] transfer thread started (pid=27702,
  tid=6567)
  Sep  2 08:17:34 freddy vdr: [6566] TS buffer on device 1 thread ended
  (pid=27702, tid=6566)
  Sep  2 08:17:34 freddy vdr: [6565] buffer stats: 62980 (3%) used
  Sep  2 08:17:34 freddy vdr: [6565] receiver on device 1 thread ended
  (pid=27702, tid=6565)
  Sep  2 08:17:34 freddy vdr: [6568] receiver on device 1 thread started
  (pid=27702, tid=6568)
  Sep  2 08:17:34 freddy vdr: [6569] TS buffer on device 1 thread started
  (pid=27702, tid=6569)
  Sep  2 08:17:38 freddy vdr: [6567] transfer thread ended (pid=27702,
  tid=6567)
  Sep  2 08:17:38 freddy vdr: [6569] TS buffer on device 1 thread 
ended
  (pid=27702, tid=6569)
  Sep  2 08:17:38 freddy vdr: [6568] buffer stats: 193828 (9%) used
  Sep  2 08:17:38 freddy vdr: [6568] receiver on device 1 thread ended
  (pid=27702, tid=6568)
  Sep  2 08:17:39 freddy vdr: [27702] switching to channel 1
  Sep  2 08:17:39 freddy vdr: [27702] buffer stats: 116748 (5%) used
  Sep  2 08:17:39 freddy vdr: [27702] info: Channel not available!
  Sep  2 08:17:41 freddy vdr: [27702] switching to channel 9
  Sep  2 08:17:41 freddy vdr: [6570] transfer thread started (pid=27702,
  tid=6570)
  Sep  2 08:17:41 freddy vdr: [6570] setting audio track to 1 (0)
  Sep  2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on
  device 0: Input/output error
  Sep  2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on
  device 0: Input/output error
  Sep  2 08:17:55 freddy vdr: [27707] ERROR: can't write to CI adapter on
  device 0: Input/output error
  Sep  2 08:17:55 freddy kernel: dvb_ca adapter 0: DVB CAM detected and
  initialised successfully
 
 This looks more like a driver bug to me.

Well maybe but unfortunately responds to my mails in linux-dvb /
linux-media mailinglist for that problem.

@Klaus: 
If that problem happens, a manual reset of the cam under vdr's
menu-settings-ci brings the cam back.

What about trying to reset a cam automatically when it's Status is !=
msReady?

Like this:
diff --git a/device.c b/device.c
index 681049b..7904de2 100644
--- a/device.c
+++ b/device.c
@@ -239,6 +239,8 @@ cDevice *cDevice::GetDevice(const cChannel *Channel, int 
Priority, bool LiveView
   if (Channel-Ca() = CA_ENCRYPTED_MIN) {
  for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = 
CamSlots.Next(CamSlot)) {
  SlotPriority[CamSlot-Index()] = MAXPRIORITY + 1; // assumes it can't 
be used
+ if (CamSlot-ModuleStatus() == msPresent) 
+CamSlot-Reset();
  if (CamSlot-ModuleStatus() == msReady) {
 if (CamSlot-ProvidesCa(Channel-Caids())) {
if (!ChannelCamRelations.CamChecked(Channel-GetChannelID(), 
CamSlot-SlotNumber())) {



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] [PATCH] Improved pause handling

2010-12-01 Thread Matti Lehtimäki

Hi,

Sometimes when you want to pause live video you are already recording 
the current channel. In such case it is not practical to start a new 
instant recording but it would be more practical to start replaying the 
recording already being made, jump to correct position in the recording 
and then pause. So I have implemented this for VDR-1.7.16 as a patch 
which adds two new options to Pause kay handling menu item to enable 
this behavior with or without confirmation.


Any improvements or suggestions are welcome.

--
Matti Lehtimäki
diff -Naur -x PLUGINS -x po vdr-1.7.16_orig/menu.c vdr-1.7.16_pause/menu.c
--- vdr-1.7.16_orig/menu.c	2010-06-06 12:56:16.0 +0300
+++ vdr-1.7.16_pause/menu.c	2010-11-30 21:09:07.0 +0200
@@ -3025,7 +3025,7 @@
 
 class cMenuSetupRecord : public cMenuSetupBase {
 private:
-  const char *pauseKeyHandlingTexts[3];
+  const char *pauseKeyHandlingTexts[5];
   const char *delTimeshiftRecTexts[3];
 public:
   cMenuSetupRecord(void);
@@ -3036,6 +3036,8 @@
   pauseKeyHandlingTexts[0] = tr(do not pause live video);
   pauseKeyHandlingTexts[1] = tr(confirm pause live video);
   pauseKeyHandlingTexts[2] = tr(pause live video);
+  pauseKeyHandlingTexts[3] = tr(confirm pause and switch to replay mode);
+  pauseKeyHandlingTexts[4] = tr(switch to replay mode);
   delTimeshiftRecTexts[0] = tr(no);
   delTimeshiftRecTexts[1] = tr(confirm);
   delTimeshiftRecTexts[2] = tr(yes);
@@ -3045,7 +3047,7 @@
   Add(new cMenuEditIntItem( tr(Setup.Recording$Primary limit), data.PrimaryLimit, 0, MAXPRIORITY));
   Add(new cMenuEditIntItem( tr(Setup.Recording$Default priority),  data.DefaultPriority, 0, MAXPRIORITY));
   Add(new cMenuEditIntItem( tr(Setup.Recording$Default lifetime (d)),  data.DefaultLifetime, 0, MAXLIFETIME));
-  Add(new cMenuEditStraItem(tr(Setup.Recording$Pause key handling),data.PauseKeyHandling, 3, pauseKeyHandlingTexts));
+  Add(new cMenuEditStraItem(tr(Setup.Recording$Pause key handling),data.PauseKeyHandling, 5, pauseKeyHandlingTexts));
   Add(new cMenuEditIntItem( tr(Setup.Recording$Pause priority),data.PausePriority, 0, MAXPRIORITY));
   Add(new cMenuEditIntItem( tr(Setup.Recording$Pause lifetime (d)),data.PauseLifetime, 0, MAXLIFETIME));
   Add(new cMenuEditBoolItem(tr(Setup.Recording$Use episode name),  data.UseSubtitle));
@@ -4207,6 +4209,19 @@
  AssertFreeDiskSpace(Timer-Priority(), !Timer-Pending());
  Timer-SetPending(true);
  }
+  else if (Setup.PauseKeyHandling  2  Pause) { // PauseLiveVideo  do not start recording
+ cChannel *channel = Channels.GetByNumber(cDevice::CurrentChannel());
+ for (cTimer *t = Timers.First(); t; t = Timers.Next(t)) {
+ if ((t-Channel() == channel)  t-Recording()) {
+for (int i = 0; i  MAXRECORDCONTROLS; i++) {
+if (RecordControls[i]  RecordControls[i]-Timer()-Channel() == t-Channel()) {
+   cReplayControl::SetRecording(RecordControls[i]-FileName(), t-File());
+   return true;
+   }
+}
+}
+ }
+ }
   VideoDiskSpace(FreeMB);
   if (FreeMB  MINFREEDISK) {
  if (!Timer || time(NULL) - LastNoDiskSpaceMessage  NODISKSPACEDELTA) {
@@ -4274,11 +4289,23 @@
 {
   Skins.Message(mtStatus, tr(Pausing live video...));
   cReplayControl::SetRecording(NULL, NULL); // make sure the new cRecordControl will set cReplayControl::LastReplayed()
+  cTimer * timer = NULL;
+  if (Setup.PauseKeyHandling  2) {
+for (cTimer *t = Timers.First(); t; t = Timers.Next(t)) { // find timer of current recording
+  if ((t-Channel() == Channels.GetByNumber(cDevice::CurrentChannel()))  t-Recording())
+timer = t;
+}
+}
   if (Start(NULL, true)) {
  sleep(2); // allow recorded file to fill up enough to start replaying
  cReplayControl *rc = new cReplayControl;
  cControl::Launch(rc);
  cControl::Attach();
+ if (timer) { // if already recording current channel before pause jump to correct position of recording
+int Current, Total;
+rc-GetIndex(Current, Total, true);
+rc-Goto(SecondsToFrames((Total / rc-FramesPerSecond())-2), false);
+}
  sleep(1); // allow device to replay some frames, so we have a picture
  Skins.Message(mtStatus, NULL);
  rc-ProcessKey(kPause); // pause, allowing replay mode display
diff -Naur -x PLUGINS -x po vdr-1.7.16_orig/vdr.c vdr-1.7.16_pause/vdr.c
--- vdr-1.7.16_orig/vdr.c	2010-04-05 13:06:16.0 +0300
+++ vdr-1.7.16_pause/vdr.c	2010-11-30 20:00:48.0 +0200
@@ -1074,7 +1074,7 @@
if (!cControl::Control()) {
   DELETE_MENU;
   if (Setup.PauseKeyHandling) {
- if (Setup.PauseKeyHandling  1 || Interface-Confirm(tr(Pause live video?))) {
+ if ((Setup.PauseKeyHandling == 2 || Setup.PauseKeyHandling == 4) || ((Setup.PauseKeyHandling == 1 || 

Re: [vdr] [PATCH] Improved pause handling

2010-12-01 Thread Jan Willies

 Sometimes when you want to pause live video you are already recording the
 current channel. In such case it is not practical to start a new instant
 recording but it would be more practical to start replaying the recording
 already being made, jump to correct position in the recording and then
 pause. So I have implemented this for VDR-1.7.16 as a patch which adds two
 new options to Pause kay handling menu item to enable this behavior with
 or without confirmation.


I've always wondered myself why vdr behaves like that. Thanks for this
patch, hopefully it gets included.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [PATCH] Improved pause handling

2010-12-01 Thread Christopher Reimer
Thanks for this nice small patch.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VGA2SCART and Broadcom Crystal HD

2010-12-01 Thread Niko Mikkilä
On 2010-11-29 at 18:58 +0100, Damien Bally wrote:
 Hello
 
 I plan to buy an D945GSEJT to build my new VDR box and I would give a 
 try to the VGA2SCART (FRC) output. My TV-set is still a good old CRT.
 
 1) Is the quality comparable to a dxr3 card which I am satisfied with ?

If you get FRC working, it's about as good as RGB SCART can possibly be,
which is much better than the SVideo output of a normal Dxr3. I haven't
seen how an RGB-modified Dxr3 compares.


 2) Can it be used with a BCM70015 card in order to play HD channels ?

That should work in principle, but I'm not sure what would be the best
way to use it with VDR. Proper 1080i-576i downconversion may also be a
bit tricky to achive with current solutions. 720p and progressively
coded 1080i broadcasts are easier.

--Niko


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [PATCH] Improved pause handling

2010-12-01 Thread JJussi

On 1.12.2010 17.44, Matti Lehtimäki wrote:

Hi,

Sometimes when you want to pause live video you are already recording 
the current channel. In such case it is not practical to start a new 
instant recording but it would be more practical to start replaying 
the recording already being made, jump to correct position in the 
recording and then pause. So I have implemented this for VDR-1.7.16 as 
a patch which adds two new options to Pause kay handling menu item 
to enable this behavior with or without confirmation.


Any improvements or suggestions are welcome.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Addition to that would be that (in same situation where there is 
recording ongoing) if user presses backward () button or press jump 
backward little (1) or jump backward big (green) it would work as 
expected... Jumping to right place of recording.


--
JJussi

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [PATCH] Improved pause handling

2010-12-01 Thread Udo Richter
Am 01.12.2010 16:44, schrieb Matti Lehtimäki:
 Sometimes when you want to pause live video you are already recording
 the current channel. In such case it is not practical to start a new
 instant recording but it would be more practical to start replaying the
 recording already being made[...]
 
 Any improvements or suggestions are welcome.

Nice idea, however I see one small drawback: Until now, a 'pause'
instant recording lasts 3 hours (or whatever was set up). With your
patch, this time shortens to the time of the recording, which might be
rather short, for example if the timer actually records the previous
show and overlaps for a few minutes.

This, together with the fact that this is probably unexpected by the
user, can lead to disaster: If he's time-shifting later on, he'll be
quite surprised that the recording has stopped minutes ago and the
in-between show is gone.

A probable solution would be to extend the ongoing recording to the
minimum time shift time, eg. Setup.InstantRecordTime.


However, I have no problem with the fact that the same show is recorded
twice. This doesn't cause too much system load, and with today's disk
sizes, it really doesn't hurt.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr