Re: [vdr] Epia MII questions
2010/11/21 Rene : > 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??
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] [PATCH] Improved pause handling
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 ||
Re: [vdr] [PATCH] Improved pause handling
> > 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
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
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
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
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
