DXR3 and subtitles in 1.5.x

  Hi Luca!

2008/3/6, Luca Olivetti <luca@ventoso.org>:
> En/na Luca Olivetti ha escrit:
>
>
>  >> ... and this went away when I changed the cDxr3SubpictureOsd constructor
>  >> to call the cOsd with proper level. Unless I'm missing something - and I
>  >> bet I am - the system seems to be working smoothly now.
>  >
>  > Mmh, it should be already doing it, look at line 39
>  >
>  > http://dxr3plugin.cvs.sourceforge.net/dxr3plugin/dxr3/dxr3osd_subpicture.c?revision=1.1.2.18&view=markup&pathrev=vdr-dxr3-0-2
>
>
> (slaps on head), ok, that's calling it with 0, in my local copy I'm
>  calling it with Level (probably the problem was introduced when I made
>  the patch for the cvs version supporting older vdr releases).
>  Sorry for all the trouble.
>
>  Ville, are you listening? ;-)

If you meant me then yes I am =) I made the change locally here too
and now it works correctly! Has been bugging me a long time but I've
lived with it ;)

Sami, I believe you already have it almost in order. I've been using
the development VDR all the time, and the only problem has been that
the OSD hijacked the OSD (and is now gone thanks to the osdlevel
patch). Though, if you get the problem that the OSD doesn't clear
between subtitles, then see the 2. patch I'm attaching for vdr-dxr3
plugin (though it could be in the CVS now, I'm using a tarball of the
CVS that is somewhat aged now).

For reference I'm attaching here all the patches I need to apply to
VDR (1.5.15 but probably works with older ones too) and dxr3-vdr
plugin on my setup to get it working properly. Are the Gentoo overlay
guys listening? These could go into the overlay (but the VDR patch
should of course only activate if the dxr3 use flag is set).


 -  Ville
  

El Thu, 6 Mar 2008 19:52:49 +0200

> >  Ville, are you listening? ;-)
> 
> If you meant me then yes I am =)

No, I meant Ville Skyttä, the plugin maintainer, there are many
Ville here :-)

[...]

>Though, if you get the problem that the OSD doesn't clear
> between subtitles, then see the 2. patch I'm attaching for vdr-dxr3
> plugin (though it could be in the CVS now, I'm using a tarball of the
> CVS that is somewhat aged now).

Yes, it should be in cvs, the only thing missing is calling the cOsd
constructor with Level instead of 0

Bye
  

On Thursday 06 March 2008, Luca Olivetti wrote:

> Yes, it should be in cvs, the only thing missing is calling the cOsd
> constructor with Level instead of 0

That's right - all patches posted for the DXR3 plugin are now in CVS, thanks 
again to everyone involved.

However, Luca and Ville A, you seem to be using different patches to VDR's 
dvbsubtitle.c - looks like Luca's contains all the changes in Ville A's, but 
comments those out and uses something else instead.

Unless a better fix emerges, I'm quite interested in including one of these in 
the upcoming VDR 1.6.x package for Fedora and also ship it in the DXR3 plugin 
tarball (possibly modified so that it's only enabled if the primary device is 
a DXR3 if possible), but I don't quite follow which would be the preferred 
one.

Could you compare and comment (off-list is fine, this may be getting a bit off 
topic for the general VDR public)?

http://article.gmane.org/gmane.linux.vdr/35860
http://article.gmane.org/gmane.linux.vdr/35881
  

Ville Skyttä wrote:
> On Thursday 06 March 2008, Luca Olivetti wrote:
> 
>> Yes, it should be in cvs, the only thing missing is calling the cOsd
>> constructor with Level instead of 0
> 
> That's right - all patches posted for the DXR3 plugin are now in CVS, thanks 
> again to everyone involved.
> 
> However, Luca and Ville A, you seem to be using different patches to VDR's 
> dvbsubtitle.c - looks like Luca's contains all the changes in Ville A's, but 
> comments those out and uses something else instead.
> 
> Unless a better fix emerges, I'm quite interested in including one of these in 
> the upcoming VDR 1.6.x package for Fedora and also ship it in the DXR3 plugin 
> tarball (possibly modified so that it's only enabled if the primary device is 
> a DXR3 if possible), but I don't quite follow which would be the preferred 
> one.
> 
> Could you compare and comment (off-list is fine, this may be getting a bit off 
> topic for the general VDR public)?

Preferably on-list, as I'm planning a similar conditional patch for
Mandriva VDR 1.6.x packages. That is, unless something better emerges.

> http://article.gmane.org/gmane.linux.vdr/35860
> http://article.gmane.org/gmane.linux.vdr/35881
  

En/na Anssi Hannula ha escrit:

> Preferably on-list, as I'm planning a similar conditional patch for
> Mandriva VDR 1.6.x packages. That is, unless something better emerges.

Keep in mind that the patch could be detrimental if you have something 
other than a dxr3 with a better osd (though I'm using it with either the 
dxr3 or a xine frontend and in both cases I can read the subtitles just 
fine, in fact with xine I cannot tell the difference with or without the 
patch).

Bye
  

On Thu, Mar 06, 2008 at 08:42:30PM +0200, Ville Skyttä wrote:

> Unless a better fix emerges, I'm quite interested in including one of
> these in the upcoming VDR 1.6.x package for Fedora and also ship it in
> the DXR3 plugin tarball (possibly modified so that it's only enabled
> if the primary device is a DXR3 if possible), but I don't quite follow
> which would be the preferred one.

Both amount to same thing - setting bpp for each area to 2 - but Luca's
patch does it in cleaner way, so that's what I would use.
  

On Thu, Mar 06, 2008 at 07:52:49PM +0200, Ville Aakko wrote:

> Sami, I believe you already have it almost in order. I've been using
> the development VDR all the time, and the only problem has been that
> the OSD hijacked the OSD (and is now gone thanks to the osdlevel
> patch). Though, if you get the problem that the OSD doesn't clear
> between subtitles, then see the 2. patch I'm attaching for vdr-dxr3
> plugin (though it could be in the CVS now, I'm using a tarball of the
> CVS that is somewhat aged now).

Yep, I seem to have the second patch, so it's looking good now, thanks.

I'm having some stability problems, though - every once in a while
changing the channel or doing some fast moves with OSD freezes the
screen. Don't know what the problem is, yet. Possibly related to this is
that the subtitles have gone missing a couple of times. I haven't been
able to pinpoint what exactly happens here, but my guess is it's got
something to do with DXR3 :P
  

2008/3/9, Sami Sundell <sami.sundell@kotikone.fi>:
>
>  I'm having some stability problems, though - every once in a while
>  changing the channel or doing some fast moves with OSD freezes the
>  screen. Don't know what the problem is, yet. Possibly related to this is
>  that the subtitles have gone missing a couple of times. I haven't been
>  able to pinpoint what exactly happens here, but my guess is it's got
>  something to do with DXR3 :P

What skin are you using? I've noticed that the only skins that are
usable (i.e. stable enough to use them) are those of text2skin plugin
- more specifically, I use enElchi. Some other were stable, too.
Anything else (including skinsoppalusikka, which is identical in
appearance to enElchi but standalone) and I just can't use my VDR
without losing my nerves.

I still get OSD freezes, but only very rarely (i.e. maybe once in
every 12 hours of active use; i.e. watching recordings and such).

  - Ville
  

On Sun, 9 Mar 2008, Ville Aakko wrote:

> What skin are you using? I've noticed that the only skins that are
> usable (i.e. stable enough to use them) are those of text2skin plugin
> - more specifically, I use enElchi. Some other were stable, too.
> Anything else (including skinsoppalusikka, which is identical in
> appearance to enElchi but standalone) and I just can't use my VDR
> without losing my nerves.

You could try the latest soppalusikka as there were some osd update 
tweaks. At least with xineliboutput the cpu load was reduced ~20% on a 
core2duo+nvidia setup, so the skin is nowadays less demanding for the 
hardware...

BR,
--
rofa
  

En/na Rolf Ahrenberg ha escrit:
> On Sun, 9 Mar 2008, Ville Aakko wrote:
> 
>> What skin are you using? I've noticed that the only skins that are
>> usable (i.e. stable enough to use them) are those of text2skin plugin
>> - more specifically, I use enElchi. Some other were stable, too.
>> Anything else (including skinsoppalusikka, which is identical in
>> appearance to enElchi but standalone) and I just can't use my VDR
>> without losing my nerves.
> 
> You could try the latest soppalusikka as there were some osd update 
> tweaks. At least with xineliboutput the cpu load was reduced ~20% on a 
> core2duo+nvidia setup, so the skin is nowadays less demanding for the 
> hardware...

I'm still using 1.0.4 (and, yes, from time to time I have osd problems 
with the dxr3), but a performance improvement could be actually a bad 
thing for the dxr3 (if it translates to more osd updates).
In fact I think that text2skin works well enough for Ville because it is 
slow (at least it was last time I used it).

Bye
  

On Sun, 9 Mar 2008, Luca Olivetti wrote:

> I'm still using 1.0.4 (and, yes, from time to time I have osd problems
> with the dxr3), but a performance improvement could be actually a bad
> thing for the dxr3 (if it translates to more osd updates).

Well, in this case the performance improvement means less work for the 
osd provider as I've eliminated unnecessary osd accesses. Hence the 
lower CPU load on the xineliboutput setup. I didn't mention about those 
tweaks in HISTORY, but they should be included in version 1.1.5 and a 
few more in the next release.

BR,
--
rofa
  

2008/3/10, Rolf Ahrenberg <rahrenbe@cc.hut.fi>:
> On Sun, 9 Mar 2008, Luca Olivetti wrote:
>
>  > I'm still using 1.0.4 (and, yes, from time to time I have osd problems
>  > with the dxr3), but a performance improvement could be actually a bad
>  > thing for the dxr3 (if it translates to more osd updates).
>
>
> Well, in this case the performance improvement means less work for the
>  osd provider as I've eliminated unnecessary osd accesses. Hence the
>  lower CPU load on the xineliboutput setup. I didn't mention about those
>  tweaks in HISTORY, but they should be included in version 1.1.5 and a
>  few more in the next release.

I tried skinsoppalusikka. It is a bit more stable, but not enough.
Channel surfing and menus seem to be generally more stable. Editing,
(putting marks and moving them), and most notably, jumping to a
certain position via the red button is still PITA with
skinsoppalusikka and DXR3. But the behaviour of the OSD is a bit
different when it starts being buggy; the "flickering" I get is
different and it doesn't hang as often as it used to. So you can feel
something has changed =). I still get more random crashes with
skinsoppalusikka, than with text2skin.

Also, skinsoppalusikka doesn't update the palette of channel logos, if
the OSD isn't closed in between channel changes (this is notable only
when channel surfing, but if you wait a while, let the OSD close
itself, and then change channel, the logo is shown in right colors).

Just for your information (it probably isn't worth the trouble to get
skinsoppalusikka working properly on DXR3, unless you have some ideas
what to try), and also for DXR3 users who are looking for a stable
OSD.

 - Ville
  

On Sun, 30 Mar 2008, Ville Aakko wrote:

> Channel surfing and menus seem to be generally more stable. Editing,
> (putting marks and moving them), and most notably, jumping to a
> certain position via the red button is still PITA with
> skinsoppalusikka and DXR3. But the behaviour of the OSD is a bit

Did you test it with the latest skinsoppalusikka-1.6.0? I added 
similar osd performance tweaks for replay mode into that particular 
version.

> Also, skinsoppalusikka doesn't update the palette of channel logos, if

Well, IMO the skin isn't responsible of palette updates, but the real 
problem might be in the osd implemantation of DXR3 plugin.

BR,
--
rofa
  

En/na Rolf Ahrenberg ha escrit:

>> Also, skinsoppalusikka doesn't update the palette of channel logos, if
> 
> Well, IMO the skin isn't responsible of palette updates, but the real 
> problem might be in the osd implemantation of DXR3 plugin.

channel logo *must* be disabled for the dxr3.

Bye
  

En/na Rolf Ahrenberg ha escrit:

>> Also, skinsoppalusikka doesn't update the palette of channel logos, if
> 
> Well, IMO the skin isn't responsible of palette updates, but the real 
> problem might be in the osd implemantation of DXR3 plugin.

channel logo *must* be disabled for the dxr3.

Bye
  

2008/3/30, Rolf Ahrenberg <rahrenbe@cc.hut.fi>:
> On Sun, 30 Mar 2008, Ville Aakko wrote:
>
>  > Channel surfing and menus seem to be generally more stable. Editing,
>  > (putting marks and moving them), and most notably, jumping to a
>  > certain position via the red button is still PITA with
>  > skinsoppalusikka and DXR3. But the behaviour of the OSD is a bit
>
>
> Did you test it with the latest skinsoppalusikka-1.6.0? I added
>  similar osd performance tweaks for replay mode into that particular
>  version.

No, sorry! I thoiught I was using the latesta, but I wasn't. But after
some quick testing, it still seems unstable in the editing mode,

>  > Also, skinsoppalusikka doesn't update the palette of channel logos, if
>
>
> Well, IMO the skin isn't responsible of palette updates, but the real
>  problem might be in the osd implemantation of DXR3 plugin.

Yes, that is most probably true. I was merely stating what I'm
experiencing with skinsoppaluskka and the logos =)


  - Ville
  

2008/3/31, Luca Olivetti <luca@ventoso.org>:
>
> channel logo *must* be disabled for the dxr3.

But they look neat =)

But, seriously, they work very nicely with text2skin here, and used to
work in and older VDR / skinsoppalusikka, too (providing you use logos
with decreased number of colours, but I really couldn't tell the
difference when I opened both versions of some of the logos in an
editor on my computer). So it IS a small regression (triggered in the
plugin by changes in skinsoppalusikka). But the real problem here was
the stability, into which the logos have no effect. Well, honestly, I
didn't try the 1.6.0 without logos, but I assume this, because 1)
disabling the channel logos didn't have any effect in a previous
skinsoppalusikka, and 2) the instablility occurs in editing mode and
when going trough the menus, i.e. NOT when any logos are shown on the
screen.

The "palette of the logos not updating" is, on the other hand, a very
minor and purely cosmetic problem.

   - Ville
  

Seems that my brain stopped working in the middle of a sentence here :

2008/4/2, Ville Aakko <ville.aakko@gmail.com>:
>
> No, sorry! I thoiught I was using the latesta, but I wasn't. But after
>  some quick testing, it still seems unstable in the editing mode,

 ... , but I need to do some more testing, before I can say if the
1.6.0 is more stable than 1.1.5.


 - Ville
  

On Wed, 2 Apr 2008, Ville Aakko wrote:

>> No, sorry! I thoiught I was using the latesta, but I wasn't. But after
>>  some quick testing, it still seems unstable in the editing mode,
> ... , but I need to do some more testing, before I can say if the
> 1.6.0 is more stable than 1.1.5.

Increasing the "Osd Flush Rate" value in DXR3 plugin setup might make 
things a bit more stable...

BR,
--
rofa
  

On Wed, 2 Apr 2008, Ville Aakko wrote:

> But, seriously, they work very nicely with text2skin here, and used to
> work in and older VDR / skinsoppalusikka, too (providing you use logos
> with decreased number of colours, but I really couldn't tell the

You don't happen to remember when things went broken? An exact version 
number would help a lot...

BR,
--
rofa