Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

[Marko Mäkelä]

On Wed, Jan 31, 2007 at 09:02:58AM +0200, Rolf Ahrenberg wrote:
> >I would rather write "käynnistyy" instead of the foreign "aktivoituu".
> 
> But VDR starts ("käynnistää") all plugins already at the beginning and 
> depending on the plugins behaviour it's activated on main menu action, 
> external trigger, ... So, using the "käynnistää" as activate confuses me 
> a bit and I'd avoid using it here, but I can live with it.

I didn't think of that.  If the verb is already used in some translation
string, it might be good to avoid using the verb in another context.
What about "Laajennos herää" (Plugin wakes up)?

> Does VDR really shut _itself_ off ("VDR sammuu")? I've always think that 
> it just listens signals from OS that can be generated via the external 
> shutdown script.

When VDR invokes the external shutdown script, I would say that it
indeed does shut itself off, or at least attempts to.  But it might be
a little funny to write "VDR attempts to shut down in %ld minutes"
or "VDR yrittää sammua %ld minuutin päästä".  That would make sense if
the vdr-shutdown script could deny the operation because some other
application on the VDR box is being used.

Marko

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

[vdr] Problem with two cards

[Teemu Suikki]

Hi,

I have been using VDR for about two years now, without any big problems.
:)

Now I built a new system with two cards. One is my old hauppaude nova-t,
other is technotrend nova-t with CI..

With only one card installed, both cards work fine. If I install both
cards, only one the newer card works! Older card is found by VDR and can
tune channels, but there is no picture..

Any ideas?

It could be some hardware issue, if there is some conflict with two
cards.. But I have tried both cards in all PCI slots, no difference there.
:)

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


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

Re: [vdr] SetPlayMode() on radio channels

[Thiemo]

Am Freitag, 26. Januar 2007 15:32 schrieb Klaus Schmidinger:
> Thiemo wrote:
> > Hi,
> >
> > is there a special reason that SetPlayMode() is always called with
> > "pmAudioVideo" even on radio channels instead of pmAudioOnly or
> > pmAudioOnlyBlack? It would make things much easier if it would do so (for
> > displaying a background image).
> > Can you give me a hint where I could change this?
>
> "pmAudioVideo" is the default play mode for VDR, and by itself VDR
> doesn't use anything else. This was introduced in case a plugin
> wants to implement a player that needs a different play mode.
>
> When replaying a recording, VDR sets up a cDvbPlayerControl in
maybe you got me wrong - i don't want this for replaying a recording but for 
live-broadcasts. (although replaying is an issue i did not think about yet).

currently its realy a pain finding out if a stream is audio-only or not in the 
mpeg-player (where it does not belong imho).

t.

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

Re: [vdr] Problem with two cards

[Andre . Weidemann]

Teemu Suikki wrote:

With only one card installed, both cards work fine.  ...


This sounds like an interesting solution... Can you post a link to 
picture showing this particular setup? :-P scnr



It could be some hardware issue, if there is some conflict with two
cards.. But I have tried both cards in all PCI slots, no difference there.


With both cards installed, load the budget and the budget-ci modules and 
then take a look at the dmesg output and see what it says.
Look into /proc/interrupts and see if both cards may be using the same 
interrupt.

What happens if you append "acpi=off" and/or "noapic" to the kernel?

Let us know what you found out.

 André


PS: Please start a new message when posting to a list and do not reply 
to an older message by replacing the subject.


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

Re: [vdr] SetPlayMode() on radio channels

[Laz]

On Wednesday 31 January 2007 14:13, Thiemo wrote:
> Am Freitag, 26. Januar 2007 15:32 schrieb Klaus Schmidinger:
> > Thiemo wrote:
> > > Hi,
> > >
> > > is there a special reason that SetPlayMode() is always called with
> > > "pmAudioVideo" even on radio channels instead of pmAudioOnly or
> > > pmAudioOnlyBlack? It would make things much easier if it would do
> > > so (for displaying a background image).
> > > Can you give me a hint where I could change this?
> >
> > "pmAudioVideo" is the default play mode for VDR, and by itself VDR
> > doesn't use anything else. This was introduced in case a plugin
> > wants to implement a player that needs a different play mode.
> >
> > When replaying a recording, VDR sets up a cDvbPlayerControl in
>
> maybe you got me wrong - i don't want this for replaying a recording
> but for live-broadcasts. (although replaying is an issue i did not
> think about yet).
>
> currently its realy a pain finding out if a stream is audio-only or not
> in the mpeg-player (where it does not belong imho).


What would be nice is something like bool cRecording::IsRadio(). I was 
going to have a go at incorporating the code posted on this thread the 
other day by Reinhard Nissl but haven't got round to it yet.

This could then also be used when determining recording lengths, skipping, 
etc. rather than treating all timings as video.

Having said that, I tried to record a couple of sample bits of a radio 
channel the other day and they were pretty broken.

:(

Do radio recordings still work for other people or have I managed to break 
something?! I used to make quite a few but haven't done so in a while. 
This is vdr-1.5.0 and softdevice cvs.

Cheers,

Laz

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

[vdr] FF card AV sync problems, possible fix to VDR

[Ville Rannikko]

Hi!

The newest firmware for FF cards did not completely fix the AV desync problems 
for me. According to information from Werner the problem happens when small 
video frames fill the decoder buffer with over 2 seconds of data. So I made 
this patch for dvbplayer.c to stop it from uploading more PES frames to decoder 
when STC/PTS difference is more than 2 seconds. This seems to fix the remaining 
problems for me, but I have not tested it much. The PTS/STC-code has been 
mostly taken from the dvb-subtitles plugin. Comments, please


Ville

--- dvbplayer.c.orig2007-01-31 18:21:42.0 +0200
+++ dvbplayer.c 2007-01-31 18:35:36.0 +0200
@@ -495,6 +495,51 @@
  }
   }
   if (p) {
+ if(playMode == pmPlay && pc > 13)
+   {
+ int64_t stc = -1;
+ int64_t pts = -1;
+
+ if ( p[0] == 0x00 && p[1] == 0x00 && p[2] == 0x01)
+   {
+ if(p[7] & 0x80)
+   {
+ switch( p[3] )
+   {
+   case 0xE0 ... 0xEF: // video
+   case 0xC0 ... 0xDF: // audio
+ pts  = (int64_t) (p[ 9] & 0x0E) << 29 ;
+ pts |= (int64_t)  p[ 10] << 22 ;
+ pts |= (int64_t) (p[ 11] & 0xFE) << 14 ;
+ pts |= (int64_t)  p[ 12] <<  7 ;
+ pts |= (int64_t) (p[ 13] & 0xFE) >>  1 ;
+   }
+   }
+   }
+ if(pts != -1)
+   {
+ cDevice *pd = cDevice::PrimaryDevice();
+ if(pd)
+   {
+ stc = pd->GetSTC();
+ if(stc != 0)
+   {
+ if(pts & (int64_t)1<<32)
+   {
+ stc |= (int64_t)1<<32;
+   }
+ int64_t timeDiff = (pts-stc);
+ if (pts 2000)
+  cCondWait::SleepMs(timeDiff - 2000);
+   }
+  }
+  }
+  }
   int w = PlayPes(p, pc, playMode != pmPlay);
   if (w > 0) {
  p += w;

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

Re: [vdr] VDR-on-Mac patches

[Martin Wache]

Hi Tero,

Tero Siironen schrieb:
> Thank you, that was it. Next thing I'll try to do is get it to run on
> MacBook Pro also.
> 

Great! Keep us up to date on your progress ;-)
I'm not sure if the configure script correctly detects the Intel Mac, so
you may have to modify the configure to get MMX acceleration. Also, in
audio-macos.c I've set the audio format to

inDesc.mFormatFlags |= kAudioFormatFlagIsBigEndian;

I would guess that you have to change that on Intel processors, but I
can't try it. And there may be problems with the OSD colors, but you
will see ;-)

Bye,
Martin

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

Re: [vdr] SetPlayMode() on radio channels

[Thiemo]

Am Mittwoch, 31. Januar 2007 17:05 schrieb Laz:
> > currently its realy a pain finding out if a stream is audio-only or not
> > in the mpeg-player (where it does not belong imho).
>
> What would be nice is something like bool cRecording::IsRadio().
Why reinventing the wheel if pmAudioOnly is already there?

Even more, one could already either set pmAudioOnly or pmAudioOnlyBlack 
depending if the mpeg-player should or should not show a background picture 
(i.e. for the mp3 pi which shows its own backgrounds)
this won't be possible with the bool solution...

t.

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

Re: [vdr] FF card AV sync problems, possible fix to VDR

[Klaus Schmidinger]

Ville Rannikko wrote:
> Hi!
> 
> The newest firmware for FF cards did not completely fix the AV desync
> problems for me. According to information from Werner the problem
> happens when small video frames fill the decoder buffer with over 2
> seconds of data. So I made this patch for dvbplayer.c to stop it from
> uploading more PES frames to decoder when STC/PTS difference is more
> than 2 seconds. This seems to fix the remaining problems for me, but I
> have not tested it much. The PTS/STC-code has been mostly taken from the
> dvb-subtitles plugin. Comments, please

While this may actually help in your case, I'm not particularly fond
of this. The cDvbPlayer shouldn't have to worry about this. It takes care
that data is sent to the player device fast enough to avoid underruns,
but that's all it should have to care about. It's the device's (driver
and firmware) job to play the data correctly.

Klaus

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

Re: [vdr] Problem with two cards

[Teemu Suikki]

On Wed, 31 Jan 2007 [EMAIL PROTECTED] wrote:

> Teemu Suikki wrote:
> > With only one card installed, both cards work fine.  ...
>
> This sounds like an interesting solution... Can you post a link to
> picture showing this particular setup? :-P scnr

Bah. :)

> > It could be some hardware issue, if there is some conflict with two
> > cards.. But I have tried both cards in all PCI slots, no difference there.
>
> With both cards installed, load the budget and the budget-ci modules and
> then take a look at the dmesg output and see what it says.

Actually both cards use budget-ci, the other card just doesn't have the
physical connector although it has a place for it in the PCB. The cards
look very similar, but newer card has tda10046 and older tda10045
frontend.. Both have saa7146 pci chip.

Here's dmesg output, looks ok to me:

saa7146: register extension 'budget_ci dvb'.
PCI: Found IRQ 11 for device :02:05.0
PCI: Sharing IRQ 11 with :00:0d.0
saa7146: found saa7146 @ mem e0974c00 (revision 1, irq 11) (0x13c2,0x1012).
saa7146 (0): dma buffer size 192512
DVB: registering new adapter (TT-Budget-T-CI PCI).
adapter has MAC addr = 00:d0:5c:04:43:33
input: Budget-CI dvb ir receiver saa7146 (0) as /class/input/input1
budget_ci: CI interface initialised
DVB: registering frontend 0 (Philips TDA10046H DVB-T)...
dvb_ca adapter 0: DVB CAM detected and initialised successfully

PCI: Found IRQ 3 for device :02:08.0
saa7146: found saa7146 @ mem e0976800 (revision 1, irq 3) (0x13c2,0x1011).
saa7146 (1): dma buffer size 192512
DVB: registering new adapter (TT-Budget/WinTV-NOVA-T PCI).
adapter has MAC addr = 00:d0:5c:22:27:8a
input: Budget-CI dvb ir receiver saa7146 (1) as /class/input/input2
DVB: registering frontend 1 (Philips TDA10045H DVB-T)...


> Look into /proc/interrupts and see if both cards may be using the same
> interrupt.

Nope..

3:64681  XT-PIC  saa7146 (1)
11:3565  XT-PIC  saa7146 (0), eth0

Adapter 0 is the one that is working, so it doesn't matter that it shares
interrupt with eth0. Adapter 1 seems to generate a lot of interrupts for
some reason..

> What happens if you append "acpi=off" and/or "noapic" to the kernel? >

No difference..

One thing I noticed is that after a reboot, working card always
has valid firmware, but non-working card's firmware must always be
re-uploaded.. So the firmware gets corrupted somehow?

Also I tried to tune channels with "tzap". It "works" for both cards, but
the other card never reports FE_HAS_LOCK and "ber" is very high. Looks
pretty much the same as if the antenna was unplugged.. (it's not..) :)

Perhaps there is some problem having tda10045 and tda10046 in same system?
After all, both are handled by the same tda1004x module..

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


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

Re: [vdr] FF card AV sync problems, possible fix to VDR

[VDR User]

On 1/31/07, Klaus Schmidinger <[EMAIL PROTECTED]> wrote:


Ville Rannikko wrote:
> Hi!
>
> The newest firmware for FF cards did not completely fix the AV desync
> problems for me. According to information from Werner the problem
> happens when small video frames fill the decoder buffer with over 2
> seconds of data. So I made this patch for dvbplayer.c to stop it from
> uploading more PES frames to decoder when STC/PTS difference is more
> than 2 seconds. This seems to fix the remaining problems for me, but I
> have not tested it much. The PTS/STC-code has been mostly taken from the
> dvb-subtitles plugin. Comments, please

While this may actually help in your case, I'm not particularly fond
of this. The cDvbPlayer shouldn't have to worry about this. It takes care
that data is sent to the player device fast enough to avoid underruns,
but that's all it should have to care about. It's the device's (driver
and firmware) job to play the data correctly.




From what he's saying, the problem is buffer overrun's, not underrun's.  Too

much data is being sent and the device isn't able to keep up.  If that's the
case then it would make sense for vdr to have a user setting to limit how
many seconds (or milliseconds perhaps?) worth of data is sent to the
buffer.  I can't think of any reason not to add such a feature if it means
better usability for the end-user.

That's my opinion anyways.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

[Rolf Ahrenberg]

On Wed, 31 Jan 2007, Marko Mäkelä wrote:


I didn't think of that.  If the verb is already used in some translation
string, it might be good to avoid using the verb in another context.
What about "Laajennos herää" (Plugin wakes up)?


That sounds ok.


When VDR invokes the external shutdown script, I would say that it
indeed does shut itself off, or at least attempts to.  But it might be
a little funny to write "VDR attempts to shut down in %ld minutes"
or "VDR yrittää sammua %ld minuutin päästä".  That would make sense if
the vdr-shutdown script could deny the operation because some other
application on the VDR box is being used.


Well, I wouldn't try to translate that one too literally (no need to 
tell about trying) - it's enough to inform user that VDR will shut down 
in a few minutes. If it fails due to any plugin activity that could be 
informed later on.


These (sometimes rather annoying!) OSD messages should be as short and 
simple as possible.


BR
--
rofa

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

Re: [vdr] FF card AV sync problems, possible fix to VDR

[Klaus Schmidinger]

VDR User wrote:
> On 1/31/07, *Klaus Schmidinger* <[EMAIL PROTECTED]
> > wrote:
> 
> Ville Rannikko wrote:
> > Hi!
> >
> > The newest firmware for FF cards did not completely fix the AV desync
> > problems for me. According to information from Werner the problem
> > happens when small video frames fill the decoder buffer with over 2
> > seconds of data. So I made this patch for dvbplayer.c to stop it from
> > uploading more PES frames to decoder when STC/PTS difference is more
> > than 2 seconds. This seems to fix the remaining problems for me,
> but I
> > have not tested it much. The PTS/STC-code has been mostly taken
> from the
> > dvb-subtitles plugin. Comments, please
> 
> While this may actually help in your case, I'm not particularly fond
> of this. The cDvbPlayer shouldn't have to worry about this. It takes
> care
> that data is sent to the player device fast enough to avoid underruns,
> but that's all it should have to care about. It's the device's (driver
> and firmware) job to play the data correctly.
> 
> 
> From what he's saying, the problem is buffer overrun's, not underrun's. 
> Too much data is being sent and the device isn't able to keep up.  If
> that's the case then it would make sense for vdr to have a user setting
> to limit how many seconds (or milliseconds perhaps?) worth of data is
> sent to the buffer.  I can't think of any reason not to add such a
> feature if it means better usability for the end-user.

If the device can't take any more data, it should just refuse to
accept it and return from the write() call without anything written.

Klaus

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

[vdr] multiple video formats with fbxine

[h . h . braun]

I am using fbxine with the xine-plugin.
How can I browse a directory structure and and open the video-file
and use lirc to control the presentation and return to the vdr menu

Cheers 
H.Braun

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

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x - Finnish translations

[Marko Mäkelä]

I believe that we have reached consensus on the Finnish translation.

On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote:
> - i18n strings:
>   "VDR will shut down later. Press power to force."

"VDR sammuu myöhemmin - pakota virtakytkimellä"

>   "VDR will shut down in %s minutes"

"VDR sammuu %s minuutin kuluttua"
(consider replacing the %s with %ld)

>   "Replaying - shut down anyway?"

"Toisto kesken - sammutetaanko?"

>   "Cutting - shut down anyway?"

"Leikkaus kesken - sammutetaanko?"

>   "Plugin activity in %ld minutes, shut down anyway?"

"Laajennos herää %ld minuutin kuluttua - sammutetaanko?"

better:

>   "Plugin %s wakes up in %ld minutes, shut down anyway?"
"Laajennos %s herää %ld minuutin kuluttua - sammutetaanko?"

Marko

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

Re: [vdr] FF card AV sync problems, possible fix to VDR

[VDR User]

On 1/31/07, Klaus Schmidinger <[EMAIL PROTECTED]> wrote:


VDR User wrote:
> From what he's saying, the problem is buffer overrun's, not underrun's.
> Too much data is being sent and the device isn't able to keep up.  If
> that's the case then it would make sense for vdr to have a user setting
> to limit how many seconds (or milliseconds perhaps?) worth of data is
> sent to the buffer.  I can't think of any reason not to add such a
> feature if it means better usability for the end-user.

If the device can't take any more data, it should just refuse to
accept it and return from the write() call without anything written.



I disagree.  Simply returning from write() implies the data was written and
the device is ready for more.  If this is not true then you risk making the
sync even worse.  I consulted with people familiar with this type of stuff
and it was suggested the problem could (and should) be fixed at the driver
level so I'm following up on that now.  Hopefully we'll find a good (or at
least resonable) solution to this last little bit of a/v sync frustration.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr diseqc equivalence of szap diseqc n ?

[Reinhard Nissl]

Hi,

Gregoire Favre wrote:

> since a few days, I try to configure my diseqc.conf for VDR without much
> success...
> 
> Kaffeine and scan work out of the box.
> For szap I have made simultaneously :
> dvbscan -a 0 -s 0 -x 0 /usr/share/dvb/dvb-s/Astra-19.2E > diseqc-0
> dvbscan -a 1 -s 1 -x 0 /usr/share/dvb/dvb-s/Hotbird-13.0E > diseqc-1
> dvbscan -a 2 -s 2 -x 0 /usr/share/dvb/dvb-s/Astra-28.2E > diseqc-2
> 
> The first try on -a 1 -s 1 failed, I had to restart it, which worked
> immediatly.
> 
> The VDR version I try is a vanilla 1.4.5-1 with only one plugin : xine.
> 
> If a timer is running and I don't start xine plugin, vdr initiate the
> same emergency exit.
> 
> Could someone tells me how to have the same diseqc setup in vdr as in
> scan ?

Hhm, I had a look into szap.c and dvbsec_api.c and do not see anything
different than in kaffeine.

Tomorrow, I'll have a look into VDR and add some debug output. So, stay
tuned ;-)

> One card in vdr works great (-D 0 or -D 1 or -D 2) but I can't use
> more...
> 
> Thank you very much,

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]

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

Re: [vdr] DVD plugin - sound jerky??

[thomas]

On Wed, Jul 26, 2006 at 09:30:44AM -0700, Simon Baxter wrote:
> I've had this problem for ages and never found any resolution to it as it's 
> really only a problem with DVDs that have a lot of chapters.
> 
> When it get towards the end of a chapter, the sound disappears.  The video 
> is still fine, but the sound stops.
> 
> Are there any debugs I can run to get more info out of dvd-plugin? 

I also had this problem until a applied the following workaround.
It seems the call to 'm_xineLib.execFuncResetAudio();' causes a
short audio dropout. But it appears the call is not neccessary anyway.
At least I noticed no bad sideeffects yet after skipping the call.

-
--- ../../vdr.org/VDR/PLUGINS/src/xine-0.7.9/xineDevice.c   2006-04-17 
20:36:01.0 +0200
+++ xine-0.7.9/xineDevice.c 2006-08-26 07:27:39.0 +0200
@@ -2969,7 +2969,11 @@
 //  np = true;
 }
 
+#if 0
 m_xineLib.execFuncResetAudio();
+#else
+xfprintf(stderr, "skipping execFuncResetAudio()\n");
+#endif
 
 if (f)
 m_xineLib.execFuncSetSpeed(0.0);
-


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

Re: [vdr] vdr diseqc equivalence of szap diseqc n ?

[Gregoire Favre]

On Wed, Jan 31, 2007 at 10:07:38PM +0100, Reinhard Nissl wrote:

Hello :)

> Hhm, I had a look into szap.c and dvbsec_api.c and do not see anything
> different than in kaffeine.

Strange :)

> Tomorrow, I'll have a look into VDR and add some debug output. So, stay
> tuned ;-)

With my previous diseqc/lnb, vdr-1.0.4 worked perfectly also...

I might try it again, but it could be a little hard to compil it against
recent kernels ;)

Thank you very much for taking a look at VDR diseqc commands sequence :)
-- 
Grégoire FAVRE  http://gregoire.favre.googlepages.com  http://www.gnupg.org

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

Re: [vdr] FF card AV sync problems, possible fix to VDR

[Klaus Schmidinger]

VDR User wrote:
> On 1/31/07, *Klaus Schmidinger* <[EMAIL PROTECTED]
> > wrote:
> 
> VDR User wrote:
> > From what he's saying, the problem is buffer overrun's, not
> underrun's.
> > Too much data is being sent and the device isn't able to keep up.  If
> > that's the case then it would make sense for vdr to have a user
> setting
> > to limit how many seconds (or milliseconds perhaps?) worth of data is
> > sent to the buffer.  I can't think of any reason not to add such a
> > feature if it means better usability for the end-user.
> 
> If the device can't take any more data, it should just refuse to
> accept it and return from the write() call without anything written.
> 
> 
> I disagree.  Simply returning from write() implies the data was written
> and the device is ready for more.

The write() function returns the number of bytes actually written,
which is not necessarily the same as the number of bytes the caller
wanted to write. So the device can chose not to accept all of the data.
If the device is currently unable to accept any data (and the file handle
is in O_NONBLOCK mode) it shall return EAGAIN to inform the caller that
it is currently busy and that the caller should try again later.

>  If this is not true then you risk
> making the sync even worse.  I consulted with people familiar with this
> type of stuff and it was suggested the problem could (and should) be
> fixed at the driver level so I'm following up on that now.

Well, that's exactly what I was suggesting. The write() function has
everything it takes to block data from coming into the device if its
buffer is full. No need for the caller to do any funny estimates here.

Klaus

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

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

[Udo Richter]

Marko Mäkelä wrote:

First, and more important: Can you please suspend the playback of
recordings when Shutdown.IsUserInactive() holds?  Here is the relevant
hunk from my vdr-suspend patch:


This would break the other interesting feature, shut down VDR as soon as 
the playback ends. Also, this would require a long and visible warning 
that VDR will soon stop playback because of inactivity, so the user wont 
be confused by the sudden stop of the playback.



Alternatively, could you suggest how to fix this in softdevice?


Maybe not switching off display while doing playback? It doesn't make 
much sense anyway to run playback invisible.



Second request: Consider modifying cDevice::Action() so that
non-recording tuners will not be read during user inactivity.
The kernel would then be able to turn off unnecessary tuners.


We had this discussion before, and since the majority of VDRs continues 
to display live video, I don't think that this should be part of VDR 
itself, and I don't really want to extend this patch into the deeper 
parts of cDevice.


To de-tune live devices, a plugin could display a still, like 
streamdev-server does, to free up devices.




Actually, it'd be nice to turn off any unneeded tuners, also
during interactive use (multi-tuner setups, or watching recordings).


Unneeded tuners get de-tuned. Provide there are unneeded tuners. (I know 
that my primary FF card tuner gets de-tuned if I play back a recording.)



Cheers,

Udo


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

[vdr] xine-plugin fbxine and mplayer and lirc

[h . h . braun]

Can those 4 components work together so that I can open a video from the menu 
and play it or can I use fbxine also for this

Cheers 
H.Braun

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

[vdr] Blocking the playback of recordings in plugins

[Marko Mäkelä]

On Wed, Jan 31, 2007 at 08:38:29PM +0100, Klaus Schmidinger wrote:
> > From what he's saying, the problem is buffer overrun's, not underrun's. 
> > Too much data is being sent and the device isn't able to keep up.  If
> > that's the case then it would make sense for vdr to have a user setting
> > to limit how many seconds (or milliseconds perhaps?) worth of data is
> > sent to the buffer.  I can't think of any reason not to add such a
> > feature if it means better usability for the end-user.
> 
> If the device can't take any more data, it should just refuse to
> accept it and return from the write() call without anything written.

I gather that in plugin-based playback, cDevice::PlayAudio() and
cDevice::PlayVideo() are overridden and may return 0 to indicate
that nothing was written.

I modified PlayAudio and PlayVideo in softdevice.c so that they return 0
when softdevice is in suspended state.  That is, I replaced
  if (! packetMode)
with
  if (!packetMode && !setupStore.shouldSuspend)
in both methods, so that they would return 0.

This seemed to work for recordings, but I am not sure if it worked for video.
If I suspended the playback for only a short while, it looked like the
playback resumed from where it was stopped, and maybe some frames were
dropped every now and then to reduce the lag.  I'd prefer the live
playback to resume without any lag, that is, to drop all live PES packets
during the time the playback was suspended in the plugin.  However,
the PES packets from recordings should be blocked.

I believe that the easy fix would be to have these methods return 0 only
when playing a recording.  Can the plugin detect this somehow?

Marko

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

[vdr] ERROR: plugin mldkgui doesn't honor APIVERSION - not compiled!

[h . h . braun]

When I try to compile the mldkgui I get the following message:
ERROR: plugin mldkgui doesn't honor APIVERSION - not compiled!


Cheers 
H.Braun

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

Re: [vdr] ERROR: plugin mldkgui doesn't honor APIVERSION - not compiled!

[Halim Sahin]

Hi,

Open plugins Makefile 
Search and replace VDRVERSION
with APIVERSION.

On Mi, Jan 31, 2007 at 11:26:20 +0100, [EMAIL PROTECTED] wrote:
> When I try to compile the mldkgui I get the following message:
> ERROR: plugin mldkgui doesn't honor APIVERSION - not compiled!
> 
> 
> Cheers 
> H.Braun
> 
> ___
> 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] xine-plugin fbxine and image

[h . h . braun]

When I start runvdr with -P'image I get :
Unable to open MRL "vdr:.

Cheers 
H.Braun

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

Aw: Re: [vdr] ERROR: plugin mldkgui doesn't honor APIVERSION - not compiled!

[h . h . braun]

 


- Original Nachricht 
Von: Halim Sahin <[EMAIL PROTECTED]>
An:  VDR Mailing List 
Datum:   31.01.2007 23:32
Betreff: Re: [vdr] ERROR: plugin mldkgui doesn't honor APIVERSION - not
compiled!

> Hi,
> 
> Open plugins Makefile 
> Search and replace VDRVERSION
> with APIVERSION.
This gives the Error :
MLdkGUIStart.cpp: In member function 'virtual eOSState 
MLdkGUIStart::ProcessKey(eKeys)':
MLdkGUIStart.cpp:106: error: invalid lvalue in assignment
make[1]: *** [MLdkGUIStart.o] Fehler 1

> 
> On Mi, Jan 31, 2007 at 11:26:20 +0100, [EMAIL PROTECTED] wrote:
> > When I try to compile the mldkgui I get the following message:
> > ERROR: plugin mldkgui doesn't honor APIVERSION - not compiled!
> > 
> > 
> > Cheers 
> > H.Braun
> > 
> > ___
> > 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
> 

Cheers 
H.Braun

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

Re: [vdr] multiple video formats with fbxine

[Tony Houghton]

In <[EMAIL PROTECTED]>, you wrote:

> I am using fbxine with the xine-plugin.
> How can I browse a directory structure and and open the video-file
> and use lirc to control the presentation and return to the vdr menu

If your remote control supports /dev/input events, which I think is
standard for the ones that are connected to DVB cards, you can do a
similar thing to this with boxstar . But
you have to use xine only for VDR, and use MPlayer for other videos.
This is because if xine has an equivalent to mplayer's -slave option I
haven't found it. You need it to get most of the control while watching
videos, but while watching VDR the only control you really need over
xine is to be able to stop and start it; everything else is controlled
by VDR.

If you really have to use xine you could probably do this by using a
wrapper script to stop and start lirc.

-- 
TH * http://www.realh.co.uk

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

Re: [vdr] FF card AV sync problems, possible fix to VDR

[Oliver Endriss]

Klaus Schmidinger wrote:
> VDR User wrote:
> > On 1/31/07, *Klaus Schmidinger* <[EMAIL PROTECTED]
> > > wrote:
> > 
> > VDR User wrote:
> > > From what he's saying, the problem is buffer overrun's, not
> > underrun's.

Afaics this is just a guess. We need a sample recording and track down
what happens in the driver/firmware.

> > > Too much data is being sent and the device isn't able to keep up.  If
> > > that's the case then it would make sense for vdr to have a user
> > setting
> > > to limit how many seconds (or milliseconds perhaps?) worth of data is
> > > sent to the buffer.  I can't think of any reason not to add such a
> > > feature if it means better usability for the end-user.
> > 
> > If the device can't take any more data, it should just refuse to
> > accept it and return from the write() call without anything written.

Code from the driver:
|...
|if (nonblock && !FREE_COND)
|return -EWOULDBLOCK;
|
|while (todo > 0) {
|if (!FREE_COND) {
|if (nonblock)
|return count - todo;
|if (wait_event_interruptible(av7110->avout.queue,
| FREE_COND))
|return count - todo;
|}
| ...

Looks ok to me. The driver does not accept more data than it can handle.

> > I disagree.  Simply returning from write() implies the data was written
> > and the device is ready for more.
> 
> The write() function returns the number of bytes actually written,
> which is not necessarily the same as the number of bytes the caller
> wanted to write. So the device can chose not to accept all of the data.
> If the device is currently unable to accept any data (and the file handle
> is in O_NONBLOCK mode) it shall return EAGAIN to inform the caller that
> it is currently busy and that the caller should try again later.
> 
> >  If this is not true then you risk
> > making the sync even worse.  I consulted with people familiar with this
> > type of stuff and it was suggested the problem could (and should) be
> > fixed at the driver level so I'm following up on that now.
> 
> Well, that's exactly what I was suggesting. The write() function has
> everything it takes to block data from coming into the device if its
> buffer is full. No need for the caller to do any funny estimates here.

Fullack. There is no reason to add workarounds like this to VDR.

@all:
Don't panic. Provide samples. :-)

Oliver

-- 

VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] FF card AV sync problems, possible fix to VDR

[Oliver Endriss]

Ville Rannikko wrote:
> Hi!
> 
> The newest firmware for FF cards did not completely fix the AV desync 
> problems 
> for me.

Can you provide a sample recording where A/V sync fails with the current
firmware?

> According to information from Werner the problem happens when small  
> video frames fill the decoder buffer with over 2 seconds of data. So I made  
> this patch for dvbplayer.c to stop it from uploading more PES frames to 
> decoder 
> when STC/PTS difference is more than 2 seconds. This seems to fix the 
> remaining 
> problems for me, but I have not tested it much. The PTS/STC-code has been 
> mostly taken from the dvb-subtitles plugin. Comments, please

The driver accepts as much data as the driver buffers can hold:
- max. 192 KByte video
- max.  64 KByte audio

The firmware requests data from the driver. The driver does not push
data to the firmware without request from the firmware.

Until now I do not understand how there could be any over/underflows
during normal operation.

> --- dvbplayer.c.orig  2007-01-31 18:21:42.0 +0200
> +++ dvbplayer.c   2007-01-31 18:35:36.0 +0200
> @@ -495,6 +495,51 @@
>}
> }
> if (p) {
> + if(playMode == pmPlay && pc > 13)
> +   {
> + int64_t stc = -1;
> + int64_t pts = -1;
> +
> + if ( p[0] == 0x00 && p[1] == 0x00 && p[2] == 0x01)
> +   {
> + if(p[7] & 0x80)
> +   {
> + switch( p[3] )
> +   {
> +   case 0xE0 ... 0xEF: // video
> +   case 0xC0 ... 0xDF: // audio
> + pts  = (int64_t) (p[ 9] & 0x0E) << 29 ;
> + pts |= (int64_t)  p[ 10] << 22 ;
> + pts |= (int64_t) (p[ 11] & 0xFE) << 14 ;
> + pts |= (int64_t)  p[ 12] <<  7 ;
> + pts |= (int64_t) (p[ 13] & 0xFE) >>  1 ;
> +   }
> +   }
> +   }
> + if(pts != -1)
> +   {
> + cDevice *pd = cDevice::PrimaryDevice();
> + if(pd)
> +   {
> + stc = pd->GetSTC();
> + if(stc != 0)
> +   {
> + if(pts & (int64_t)1<<32)
> +   {
> + stc |= (int64_t)1<<32;
> +   }
> + int64_t timeDiff = (pts-stc);
> + if (pts +   {
> + timeDiff += (int64_t)1<<33;
> +   }
> + timeDiff /= 90;
> + if(timeDiff > 2000)
> +cCondWait::SleepMs(timeDiff - 2000);
> +   }
> +}
> +}
> +}
> int w = PlayPes(p, pc, playMode != pmPlay);
> if (w > 0) {
>p += w;

Hm, that patch does not look like a real bug fix to me. ;-)
It is a workaround which limits the total buffer capacity to max 2s.
I guess this works because it somehow triggers a resync in the firmware.

Anyway, fixes must be applied to the firmware or driver, not to VDR.

But let's analyse the problem first. We need a sample recording...

Oliver

-- 

VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/



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

[vdr] FF card AV sync problems, possible fix to VDR (fwd)

[Ville Rannikko]

>  Hi!
> 
> The newest firmware for FF cards did not completely fix the AV desync 
> problems

>  for me.
Can you provide a sample recording where A/V sync fails with the current
firmware?


Oh, well. Turns out that I had somehow failed to install the new firmware 
properly. My test patch is possibly not needed at all.


Ville

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