Hi,
E-tobi's experimental VDR branch moved to 1.5.x series, so I did too, but I'm running into some problems. Specifically, this one:
Mar 4 21:05:22 dvd vdr: [17719] dxr3: colormanager: bummer, too many sections (14), reusing last one
I digged archives and found out the reason apparently is that DXR3 doesn't completely support 8-bit OSD but claims to do so. Result is OSD that's made illegible by tearing white lines etc.
Ok, so the solution for OSD (and default themes?) seems to be to turn off the anti-aliasing, which then reduces number of colors enough to make it work.
However, there's still the problem of (DVB) subtitles: similar tearing makes the subtitles unusable. On top of that, opening an OSD when there are subtitles seems to make VDR crash and burn.
Has anyone had the same problem and possibly even come up with the solution?
On Tue, Mar 04, 2008 at 10:55:53PM +0200, Sami Sundell wrote:
E-tobi's experimental VDR branch moved to 1.5.x series, so I did too, but I'm running into some problems. Specifically, this one:
... Some version information might be good, too. VDR 1.5.17, dxr3 plugin 0.2.7, em8300 driver 0.16.4. Two DVB-C budget cards (Terratec 1200), but I guess it doesn't matter in this case.
En/na Sami Sundell ha escrit:
On Tue, Mar 04, 2008 at 10:55:53PM +0200, Sami Sundell wrote:
E-tobi's experimental VDR branch moved to 1.5.x series, so I did too, but I'm running into some problems. Specifically, this one:
... Some version information might be good, too. VDR 1.5.17, dxr3 plugin 0.2.7, em8300 driver 0.16.4. Two DVB-C budget cards (Terratec 1200), but I guess it doesn't matter in this case.
Try the cvs version (I don't remember if the changes for dvb subtitles were in 0.2.7 or are posterior, in any case dvb subtitles work fine here).
Bye
Luca Olivetti wrote:
En/na Sami Sundell ha escrit:
On Tue, Mar 04, 2008 at 10:55:53PM +0200, Sami Sundell wrote:
E-tobi's experimental VDR branch moved to 1.5.x series, so I did too, but I'm running into some problems. Specifically, this one:
... Some version information might be good, too. VDR 1.5.17, dxr3 plugin 0.2.7, em8300 driver 0.16.4. Two DVB-C budget cards (Terratec 1200), but I guess it doesn't matter in this case.
Try the cvs version (I don't remember if the changes for dvb subtitles were in 0.2.7 or are posterior, in any case dvb subtitles work fine here).
The dvb subtitle changes are not in 0.2.7, but only in CVS.
On 03/04/08 22:10, Sami Sundell wrote:
On Tue, Mar 04, 2008 at 10:55:53PM +0200, Sami Sundell wrote:
E-tobi's experimental VDR branch moved to 1.5.x series, so I did too, but I'm running into some problems. Specifically, this one:
... Some version information might be good, too. VDR 1.5.17, dxr3 plugin 0.2.7, em8300 driver 0.16.4. Two DVB-C budget cards (Terratec 1200), but I guess it doesn't matter in this case.
Try changing
int Bpp = 8;
(line 986) to
int Bpp = 2;
in dvbsubtitle.c.
Klaus
On Tue, Mar 04, 2008 at 10:34:55PM +0100, Klaus Schmidinger wrote:
On 03/04/08 22:10, Sami Sundell wrote:
Try changing int Bpp = 8;
(line 986) to
int Bpp = 2;
in dvbsubtitle.c.
Hmm, I tried both fixes - that is, this one, and changing to cvs version of the DXR3 plugin.
With this one, I get following logs:
Mar 5 07:30:53 dvd vdr: [2703] buffer usage: 0% (tid=2702) Mar 5 07:30:53 dvd vdr: [2702] dxr3: demux: stillpicture length: 100 Mar 5 07:31:00 dvd last message repeated 160639 times
...
and with the CVS version of the plugin, this kind of messages:
Mar 5 07:14:06 dvd vdr: [30406] clearing transfer buffer to avoid overflows Mar 5 07:14:06 dvd vdr: [30407] buffer usage: 0% (tid=30406) Mar 5 07:14:07 dvd vdr: [30406] ERROR (transfer.c,93): Virheellinen argumentti Mar 5 07:14:09 dvd last message repeated 65080 times
Notice, that I haven't yet had the chance to actually look at the picture, I was doing this remotely :P Anyway, no section errors anymore, but the loads in VDR machine go sky high - enough to make ssh connection almost unusable because of the unresponsiveness...
I'll try to look more into it later.
On Wed, Mar 05, 2008 at 02:02:31PM +0200, Sami Sundell wrote:
Hmm, I tried both fixes - that is, this one, and changing to cvs version of the DXR3 plugin.
... and in addition to the load issue, there's the slight problem that on TV it shows only the OSD. No TV picture, no audio. Well, perhaps a broken still every once in a while. There are logs about PID changes etc. so VDR is receiving signal, it just doesn't show it.
On 03/05/08 17:47, Sami Sundell wrote:
On Wed, Mar 05, 2008 at 02:02:31PM +0200, Sami Sundell wrote:
Hmm, I tried both fixes - that is, this one, and changing to cvs version of the DXR3 plugin.
... and in addition to the load issue, there's the slight problem that on TV it shows only the OSD. No TV picture, no audio. Well, perhaps a broken still every once in a while. There are logs about PID changes etc. so VDR is receiving signal, it just doesn't show it.
I'd say this whole thing is a DXR3 problem, not a core VDR problem. Therefore I'm afraid I can't contribute to the solution...
Klaus
On Wed, Mar 05, 2008 at 05:51:07PM +0100, Klaus Schmidinger wrote:
I'd say this whole thing is a DXR3 problem, not a core VDR problem. Therefore I'm afraid I can't contribute to the solution...
Looks like it, but thanks anyway.
... found the 0.2.x-branch in the dxr3 plugin CVS, which gives me picture but still bleeding subtitles. Now it won't crash if I try to access the OSD, it just stops responding to remote. :P
-- Sami Sundell sami.sundell@kotikone.fi
En/na Sami Sundell ha escrit:
On Wed, Mar 05, 2008 at 05:51:07PM +0100, Klaus Schmidinger wrote:
I'd say this whole thing is a DXR3 problem, not a core VDR problem. Therefore I'm afraid I can't contribute to the solution...
Looks like it, but thanks anyway.
... found the 0.2.x-branch in the dxr3 plugin CVS, which gives me
Yes, that's the "good" one (I don't think anybody is working on the HEAD version).
picture but still bleeding subtitles. Now it won't crash if I try to access the OSD, it just stops responding to remote. :P
Well, I also had to modify dvbsubtitle.c (with some hints from the dxr3-plugin mailing list), and since I go from one vdr version to the next one with the patch, I forgot it. Attached is a diff from the stock dvbsubtitle.c in 1.5.17 and the version I'm using. I don't know if it's a good or bad patch but it works here, no bleeding and the lirc remote is responsive. I also cannot say if any of the other patches I have make a difference.
Bye
On 03/05/08 22:12, Luca Olivetti wrote:
En/na Sami Sundell ha escrit:
On Wed, Mar 05, 2008 at 05:51:07PM +0100, Klaus Schmidinger wrote:
I'd say this whole thing is a DXR3 problem, not a core VDR problem. Therefore I'm afraid I can't contribute to the solution...
Looks like it, but thanks anyway.
... found the 0.2.x-branch in the dxr3 plugin CVS, which gives me
Yes, that's the "good" one (I don't think anybody is working on the HEAD version).
picture but still bleeding subtitles. Now it won't crash if I try to access the OSD, it just stops responding to remote. :P
Well, I also had to modify dvbsubtitle.c (with some hints from the dxr3-plugin mailing list), and since I go from one vdr version to the next one with the patch, I forgot it. Attached is a diff from the stock dvbsubtitle.c in 1.5.17 and the version I'm using. I don't know if it's a good or bad patch but it works here, no bleeding and the lirc remote is responsive. I also cannot say if any of the other patches I have make a difference.
There's one thing I can say: this patch is not going into the official VDR source. The problem is in the DXR3 plugin: the correct way to handle this is for the OSD object to truthfully report whether it can handle the requested areas or not, and if it claims to be able to handle them, then do so
Klaus
En/na Klaus Schmidinger ha escrit:
There's one thing I can say: this patch is not going into the official
Sure, I understand that
VDR source. The problem is in the DXR3 plugin: the correct way to handle this is for the OSD object to truthfully report whether it can handle the requested areas or not, and if it claims to be able to handle them, then do so
Well, it isn't so simple, since color management with the dxr3 uses many tricks. Natively it's only capable of 2bpp, but with a lot of tricks it manages 4bpp for a typical osd. If it reports 2bpp, most everything would work (I think osd teletext wouldn't) but with a very dull osd, if it reports 4bpp everything works as long as there's no antialiasing.
Bye
On Wed, Mar 05, 2008 at 10:12:43PM +0100, Luca Olivetti wrote:
Well, I also had to modify dvbsubtitle.c (with some hints from the dxr3-plugin mailing list), and since I go from one vdr version to the
Thanks for the info and the patch - I've spent this evening looking at the sources and got the feeling that the cvs version of dxr3 won't alone help in getting the subs working. I was just in the middle of modifying the said dvbsubtitle.c - good that I won't have to do that alone :P
The problems with no picture went away once I noticed that generating a new deb package of VDR and installing it also requires installing the headers and rebuilding the dxr3 plugin against them...
I don't know if it's a good or bad patch but it works here, no bleeding and the lirc remote is responsive.
Ok, now the subtitles work, but I still have problems with subtitles and OSD together - remote becomes unresponsive and I get errors:
Mar 5 23:45:42 dvd vdr: [5102] ERROR: attempt to open OSD while it is already open - using dummy OSD!
Closer to goal, though 8)
On Thu, Mar 06, 2008 at 12:35:54AM +0200, Sami Sundell wrote:
Ok, now the subtitles work, but I still have problems with subtitles and OSD together - remote becomes unresponsive and I get errors:
Mar 5 23:45:42 dvd vdr: [5102] ERROR: attempt to open OSD while it is already open - using dummy OSD!
... 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.
Thanks for all!
En/na Sami Sundell ha escrit:
On Thu, Mar 06, 2008 at 12:35:54AM +0200, Sami Sundell wrote:
Ok, now the subtitles work, but I still have problems with subtitles and OSD together - remote becomes unresponsive and I get errors:
Mar 5 23:45:42 dvd vdr: [5102] ERROR: attempt to open OSD while it is already open - using dummy OSD!
... 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?r...
Bye
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?r...
(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? ;-)
Bye
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?r...
(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/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
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
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
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 Thursday 06 March 2008, Luca Olivetti wrote:
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? ;-)
Sure; committed, thanks!
-
Anssi Hannula -
Klaus Schmidinger -
Luca Olivetti -
Rolf Ahrenberg -
Sami Sundell -
Ville Aakko -
Ville Skyttä