Menu
▾
▴
dxr3plugin-users
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(41) |
Jun
(15) |
Jul
(36) |
Aug
(39) |
Sep
(33) |
Oct
(17) |
Nov
(10) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(7) |
Feb
(34) |
Mar
(17) |
Apr
(17) |
May
(15) |
Jun
(4) |
Jul
(8) |
Aug
(3) |
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
(11) |
| 2007 |
Jan
(4) |
Feb
(2) |
Mar
(3) |
Apr
(12) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(30) |
Dec
|
| 2008 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
(7) |
Jun
(1) |
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2009 |
Jan
|
Feb
(14) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2010 |
Jan
(5) |
Feb
(1) |
Mar
(19) |
Apr
(24) |
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
(5) |
Nov
|
Dec
(2) |
| 2011 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
|
From: Luca O. <lu...@ve...> - 2015-12-09 12:52:37
|
Hello, is there somebody here still maintaining the project? I'm not been using vdr a lot myself lately, but I just modified the plugin to compile and (apparently) work with vdr-2.3.1. Where should I send the patch? Bye -- Luca |
|
From: Ville S. <vil...@ik...> - 2011-10-21 18:53:10
|
On 10/20/2011 11:24 PM, Luca Olivetti wrote: > IIRC, it was just defining a couple of cDevice methods to return the size of > the OSD. > Here's the relevant diff. You'll note that I first tried to say to vdr that > the OSD was the same size as the video, hoping that vdr itself would scale it. > It turns out that it doesn't, so, atm, it's better to always return 720x576 and > let the plugin do the scaling. > It's possible that these methods have to be ifdefed (I don't know which > vdr version introduced them). Thanks, applied in 0.2-branch in git. Looks like GetVideoSize is VDR >= 1.7.7 and GetOsdSize VDR >= 1.7.8 but the code compiles fine against 1.6.0-2 without any additional #ifdefs so I didn't add any. |
|
From: Luca O. <lu...@ve...> - 2011-10-21 01:14:28
|
Al 20/10/11 19:51, En/na Ville Skyttä ha escrit:
> On 10/18/2011 11:24 PM, Luca Olivetti wrote:
>
>> I'll see if I manage to install git on the vdr machine so I can send you
>> the changes I made.
>
> Cool. If that won't work, feel free to send a no-whitespace diff
> against CVS (e.g. cvs diff -wbB) and I can take a look if I understand
> some of it :)
IIRC, it was just defining a couple of cDevice methods to return the size of
the OSD.
Here's the relevant diff. You'll note that I first tried to say to vdr that
the OSD was the same size as the video, hoping that vdr itself would scale it.
It turns out that it doesn't, so, atm, it's better to always return 720x576 and
let the plugin do the scaling.
It's possible that these methods have to be ifdefed (I don't know which
vdr version introduced them).
I'll see if I can get my version synced to the git one in case there are further
changes.
Index: dxr3device.c
===================================================================
RCS file: /cvsroot/dxr3plugin/dxr3/dxr3device.c,v
retrieving revision 1.2.2.49
diff --unified -r1.2.2.49 dxr3device.c
--- dxr3device.c 24 Aug 2010 15:31:45 -0000 1.2.2.49
+++ dxr3device.c 20 Oct 2011 20:20:35 -0000
@@ -334,6 +334,22 @@
}
// ==================================
+void cDxr3Device::GetVideoSize(int &Width, int &Height, double &VideoAspect)
+{
+ Width = cDxr3Interface::Instance().GetHorizontalSize();
+ Height = cDxr3Interface::Instance().GetVerticalSize();
+ VideoAspect = double(Width) / double(Height);
+}
+
+// ==================================
+void cDxr3Device::GetOsdSize(int &Width, int &Height, double &PixelAspect)
+{
+ Width = OSDWIDTH; // cDxr3Interface::Instance().GetHorizontalSize();
+ Height = OSDHEIGHT; // cDxr3Interface::Instance().GetVerticalSize();
+ PixelAspect = 1.0;
+}
+
+// ==================================
//! sets volume for audio output
void cDxr3Device::SetVolumeDevice(int Volume)
{
Index: dxr3device.h
===================================================================
RCS file: /cvsroot/dxr3plugin/dxr3/dxr3device.h,v
retrieving revision 1.1.2.25
diff --unified -r1.1.2.25 dxr3device.h
--- dxr3device.h 24 Aug 2010 15:31:45 -0000 1.1.2.25
+++ dxr3device.h 20 Oct 2011 20:20:35 -0000
@@ -59,6 +59,8 @@
// additional functions
virtual void SetVideoFormat(bool VideoFormat16_9);
+ virtual void GetVideoSize(int &Width, int &Height, double &VideoAspect);
+ virtual void GetOsdSize(int &WIdth, int &Height, double &PixelAspect);
virtual void SetVolumeDevice(int Volume);
virtual void SetAudioChannelDevice(int AudioChannel);
virtual int GetAudioChannelDevice(void);
Bye
--
Luca
|
|
From: Ville S. <vil...@ik...> - 2011-10-20 17:51:48
|
On 10/18/2011 11:24 PM, Luca Olivetti wrote: > I'll see if I manage to install git on the vdr machine so I can send you > the changes I made. Cool. If that won't work, feel free to send a no-whitespace diff against CVS (e.g. cvs diff -wbB) and I can take a look if I understand some of it :) |
|
From: Luca O. <lu...@ve...> - 2011-10-18 22:53:18
|
Al 18/10/11 20:10, En/na Ville Skyttä ha escrit: > vdr-dxr3 version 0.2.13 is out, noteworthy changes since 0.2.12: Hello, I have some local changes to fix the osd and subtitles with later vdr revision (I don't remember the exact version it broke since I skipped some versions, now I'm at 1.7.21). Unfortunately I'm still using the cvs repository (i.e. I have 0.2.11 plus my local changes that probably ended in 0.2.12) so I don't remember what I did :-( I'll see if I manage to install git on the vdr machine so I can send you the changes I made. Bye -- Luca |
|
From: Ville S. <vil...@ik...> - 2011-10-18 18:25:13
|
vdr-dxr3 version 0.2.13 is out, noteworthy changes since 0.2.12: - Remove old non-Xine OSD scaler - Reduce unnecessary GetSysClock calls - Implement DVB subtitles hack without needing to patch VDR - Include VDR >= 1.7.13's Make.global in Makefile - Use LDFLAGS when linking Downloads are available at: http://sourceforge.net/projects/dxr3plugin/files/dxr3-0.2.x/0.2.13/ http://projects.vdr-developer.org/projects/plg-dxr3/files |
|
From: Ville S. <vil...@ik...> - 2011-02-06 13:52:48
|
vdr-dxr3 version 0.2.12 is out, noteworthy changes since 0.2.11: - Make dist target depend on up to date *.po (Ville Skyttä) - Use pkg-config to locate libavcodec (Ville Skyttä) - Avoid deprecation warnings with libavcodec >= 52.26.0 (Ville Skyttä) - Compiler warning cleanups (Ville Skyttä) - Reintroduce AC3 decoding (Luca Olivetti) - Fix fast forward with VDR 1.7.x (Luca Olivetti) 0.2.x is the "stable" series of the dxr3 plugin, targeted primarily for VDR 1.6.x at the moment, but it should work to some extent also with VDR 1.7.x. More extensive work on the next version is underway at http://projects.vdr-developer.org/projects/show/plg-dxr3 Downloads are available at: http://sourceforge.net/projects/dxr3plugin/files/dxr3-0.2.x/0.2.12/ http://projects.vdr-developer.org/projects/plg-dxr3/files |
|
From: Ville S. <vil...@ik...> - 2010-12-08 20:16:47
|
On Tuesday 26 October 2010, Ville Skyttä wrote: > On Tuesday 19 October 2010, Ville Skyttä wrote: > > On Tuesday 19 October 2010, Luca Olivetti wrote: > > > Al 18/10/10 23:31, En/na Ville Skyttä ha escrit: > > > > But I'm afraid I don't have any AC3 channels/recordings easily > > > > available at the moment; do you happen to have a (VDR 1.6.0-2 > > > > compatible) recording available that has AC3 of which you could > > > > upload a chunk somewhere and link to (private mail is fine) that I > > > > could use for testing? > > > > > > No, which satellites can you tune to? > > > > None, DVB-C only here. > > Anyone else? Either an AC3 recording chunk requested above for testing > with VDR 1.6.0, or testing the patch with 1.6.0 and AC3 recordings and > reporting experiences would be welcome. > > Attached is the exact patch I'm testing with at the moment, over the vdr- > dxr3-0-2 CVS branch - it has some modifications over the one Luca sent > (coding style, plus toning down logging as these changes seem to provoke > more of it in non-AC3 scenarios). Unfortunately nobody has provided any material to test with. But as it doesn't seem to break anything that I was able to test, I've pushed this to the new git repository at sf.net anyway. |
|
From: Ville S. <vil...@ik...> - 2010-12-08 20:13:38
|
Hello, The SourceForge.net dxr3plugin repository has been switched from CVS to Git. For cloning instructions, see http://sourceforge.net/projects/dxr3plugin/develop The only active branch at sf.net, CVS vdr-dxr3-0-2 branch has been renamed to 0.2-branch. Existing VDR_DXR3_X_Y_Z CVS tags have been renamed to vX.Y.Z. To switch to 0.2-branch after cloning per the above instructions, something like this will do the trick: $ git checkout -b 0.2-branch --track origin/0.2-branch |
|
From: Ville S. <vil...@ik...> - 2010-10-25 21:05:00
|
On Tuesday 19 October 2010, Ville Skyttä wrote: > On Tuesday 19 October 2010, Luca Olivetti wrote: > > Al 18/10/10 23:31, En/na Ville Skyttä ha escrit: > > > But I'm afraid I don't have any AC3 channels/recordings easily > > > available at the moment; do you happen to have a (VDR 1.6.0-2 > > > compatible) recording available that has AC3 of which you could upload > > > a chunk somewhere and link to (private mail is fine) that I could use > > > for testing? > > > > No, which satellites can you tune to? > > None, DVB-C only here. Anyone else? Either an AC3 recording chunk requested above for testing with VDR 1.6.0, or testing the patch with 1.6.0 and AC3 recordings and reporting experiences would be welcome. Attached is the exact patch I'm testing with at the moment, over the vdr- dxr3-0-2 CVS branch - it has some modifications over the one Luca sent (coding style, plus toning down logging as these changes seem to provoke more of it in non-AC3 scenarios). |
|
From: Ville S. <vil...@ik...> - 2010-10-19 05:48:21
|
On Tuesday 19 October 2010, Luca Olivetti wrote: > Al 18/10/10 23:31, En/na Ville Skyttä ha escrit: > > But I'm afraid I don't have any AC3 channels/recordings easily available > > at the moment; do you happen to have a (VDR 1.6.0-2 compatible) > > recording available that has AC3 of which you could upload a chunk > > somewhere and link to (private mail is fine) that I could use for > > testing? > > No, which satellites can you tune to? None, DVB-C only here. |
|
From: Luca O. <lu...@ve...> - 2010-10-18 23:02:18
|
Al 18/10/10 23:31, En/na Ville Skyttä ha escrit: > > But I'm afraid I don't have any AC3 channels/recordings easily available at > the moment; do you happen to have a (VDR 1.6.0-2 compatible) recording > available that has AC3 of which you could upload a chunk somewhere and link to > (private mail is fine) that I could use for testing? No, which satellites can you tune to? Bye -- Luca |
|
From: Ville S. <vil...@ik...> - 2010-10-18 21:39:42
|
On Thursday 14 October 2010, Luca Olivetti wrote: > Hello, > > the attached patch, against the vdr-dxr3-0-2 branch, reintroduces ac3 > decoding (for some reason it wasn't integrated in cvs) and fixes fast > forward for vdr-1.7.x. Thanks. I've run 1.6.0-2 with this a bit and haven't noticed any regressions, will keep doing that and commit soon if I don't find problems. Haven't tested playback of recordings with DVB subtitles yet though, but they seem fine in live TV. But I'm afraid I don't have any AC3 channels/recordings easily available at the moment; do you happen to have a (VDR 1.6.0-2 compatible) recording available that has AC3 of which you could upload a chunk somewhere and link to (private mail is fine) that I could use for testing? |
|
From: Luca O. <lu...@ve...> - 2010-10-13 22:47:26
|
Hello, the attached patch, against the vdr-dxr3-0-2 branch, reintroduces ac3 decoding (for some reason it wasn't integrated in cvs) and fixes fast forward for vdr-1.7.x. The problem was that in fast forward mode the demuxer called PlayVideoFrame(const uint8_t* pBuf, int length, int times) directly without passing through the output buffer, and this method doesn't update m_lastSeenPts. I introduced a new method PlayVideoFrame(cDrx3PesFrame *pesFrame, int times) for fast forward that updates m_lastSeenPts. Differently than the approach I used before, this shouldn't cause any additional problem with dvb subtitles. Bye |
|
From: Ville S. <vil...@ik...> - 2010-08-28 20:04:48
|
vdr-dxr3 version 0.2.11 is out, changes since 0.2.10: - OSD, demuxer and audiodecoder fixes for vdr 1.7.14 (Luca Olivetti) - Don't switch to digital AC3 mode if configured to use analog (Luca Olivetti) - Ignore H.264 streams, display notSupported.mpg instead (Luca Olivetti) - Fix build with recent (May 2010) ffmpeg (Ville Skyttä) 0.2.x is the "stable" series of the dxr3 plugin, targeted primarily for VDR 1.6.x at the moment, but it should work to some extent also with VDR 1.7.x. More extensive work on the next version is underway at http://projects.vdr- developer.org/projects/show/plg-dxr3 Downloads are available at: http://projects.vdr-developer.org/projects/list_files/plg-dxr3 and http://sourceforge.net/projects/dxr3plugin/files/ |
|
From: Ville S. <vil...@ik...> - 2010-08-24 18:58:36
|
On Tuesday 24 August 2010, Luca Olivetti wrote: > Al 24/08/10 17:58, En/na Ville Skyttä ha escrit: > > I ended up reverting the PTS related changes and it fixes the subtitles > > timing issue and does not cause any problems with fast forward/rewind > > with VDR 1.6.0-2 (PES only naturally). > > But that's not going to work with ts recordings :-( Yes, that's what I gathered from previous messages in this thread. That's too bad, but this is the "stable" branch of the dxr3 plugin, and its primary target is the current stable VDR. Which in my (strong) opinion means that things added solely for VDR development releases' needs must not come at the expense of regressions (at least this big ones) when used with the current stable VDR. I already had some concerns about missing audio when moving cut marks caused by some portions of this patch, but it also makes things better with some channels with higher than usual bitrates (e.g. SuomiTV was pretty much unwatchable for me before these changes) so I'm willing to accept that tradeoff within 1.6.x functionality. These may be due to different parts of the patch but it's hard to tell given the size of it (and my lack of competence in this area); it should have really been split into different changesets that each do one self-contained thing so it would have been sanely possible to bisect regressions. (BTW patches that bring back audio when moving cut marks are still welcome.) At least now the PTS reversion changeset can be retrieved separately from CVS with cvsps and looking at that it's probably easier for someone who's interested to work on an implementation that fixes things for VDR 1.7.x without causing 1.6.x regressions. |
|
From: Luca O. <lu...@ve...> - 2010-08-24 18:02:41
|
Al 24/08/10 17:58, En/na Ville Skyttä ha escrit: > I ended up reverting the PTS related changes and it fixes the subtitles timing > issue and does not cause any problems with fast forward/rewind with VDR > 1.6.0-2 (PES only naturally). But that's not going to work with ts recordings :-( > By the way, the subtitles appearing too early issue was most prominent for me > when playing back recordings. There was a bit of it also in live TV, but they > were much more off (about a few seconds) when playing back recordings. Yes, I see it too now with some channels. Bye -- Luca |
|
From: Ville S. <vil...@ik...> - 2010-08-24 16:16:35
|
On Saturday 24 April 2010, Luca Olivetti wrote: > Al 24/04/10 21:23, En/na Ville Skyttä ha escrit: > >> I've been using it for a while with VDR 1.6.0-2, and in addition to the > >> issues already discussed/noted (no audio when moving cut marks, A/V > >> tends to go off sync somewhat more than before) I noticed yesterday > >> that DVB subtitles aren't as well synced as they were (they seem to > >> appear too early). It could be that this is an issue just with the one > >> recording I was watching yesterday, I need to try it out with 0.2.10 to > >> be sure. > > > > Just to follow up, I've now confirmed this. Subtitles at least appear > > much too early. > > Well, the only thing that could affect subtitles timing (an issue that I > don't see btw) is the change I made to get/set the pts. > Revert that and fast forward/rewind stop working (with ts recordings, I > don't remember if that's also the case for pes recordings). > Choose your poison ;-) I ended up reverting the PTS related changes and it fixes the subtitles timing issue and does not cause any problems with fast forward/rewind with VDR 1.6.0-2 (PES only naturally). By the way, the subtitles appearing too early issue was most prominent for me when playing back recordings. There was a bit of it also in live TV, but they were much more off (about a few seconds) when playing back recordings. |
|
From: Luca O. <lu...@ve...> - 2010-04-24 20:56:14
|
Al 24/04/10 21:38, En/na Ville Skyttä ha escrit: > ...and make sure the patches do only what's necessary; on a quick look the > previous version seemed to have some no-op whitespace/formatting only changes > for things that would not have needed touching. IIRC only a couple of empty lines. Probably that happened because I had those modifications done for a while and I merged the cvs version today. Anyway I'm not sure I will dedicate more time to the plugin so there won't be more patches coming. Bye -- Luca |
|
From: Luca O. <lu...@ve...> - 2010-04-24 20:53:22
|
Al 24/04/10 21:28, En/na Ville Skyttä ha escrit: > On Saturday 24 April 2010, Luca Olivetti wrote: >> Hello, >> >> the attached patch does two things: > > Could you submit as two patches that each do one thing? Sure > > Do you have a patch for Makefile that installs the notSupported.mpg into a > proper location? Nope > > Also, I'd like to verify that these won't cause regressions with VDR 1.6.0 or > with digital audio output. Do you have recording snippets that have AC3 and > another one that has H.264 that I could test with? If I make recordings with 1.7.14 they won't work with 1.6 Bye -- Luca |
|
From: Luca O. <lu...@ve...> - 2010-04-24 20:49:11
|
Al 24/04/10 21:23, En/na Ville Skyttä ha escrit: >> >> I've been using it for a while with VDR 1.6.0-2, and in addition to the >> issues already discussed/noted (no audio when moving cut marks, A/V tends >> to go off sync somewhat more than before) I noticed yesterday that DVB >> subtitles aren't as well synced as they were (they seem to appear too >> early). It could be that this is an issue just with the one recording I >> was watching yesterday, I need to try it out with 0.2.10 to be sure. > > Just to follow up, I've now confirmed this. Subtitles at least appear much > too early. Well, the only thing that could affect subtitles timing (an issue that I don't see btw) is the change I made to get/set the pts. Revert that and fast forward/rewind stop working (with ts recordings, I don't remember if that's also the case for pes recordings). Choose your poison ;-) Bye -- Luca |
|
From: Ville S. <vil...@ik...> - 2010-04-24 19:38:44
|
On Saturday 24 April 2010, Ville Skyttä wrote: > On Saturday 24 April 2010, Luca Olivetti wrote: > > Hello, > > > the attached patch does two things: > Could you submit as two patches that each do one thing? ...and make sure the patches do only what's necessary; on a quick look the previous version seemed to have some no-op whitespace/formatting only changes for things that would not have needed touching. |
|
From: Ville S. <vil...@ik...> - 2010-04-24 19:28:10
|
On Saturday 24 April 2010, Luca Olivetti wrote: > Hello, > > the attached patch does two things: Could you submit as two patches that each do one thing? Do you have a patch for Makefile that installs the notSupported.mpg into a proper location? Also, I'd like to verify that these won't cause regressions with VDR 1.6.0 or with digital audio output. Do you have recording snippets that have AC3 and another one that has H.264 that I could test with? |
|
From: Ville S. <vil...@ik...> - 2010-04-24 19:23:40
|
On Friday 16 April 2010, Ville Skyttä wrote: > On Saturday 10 April 2010, Luca Olivetti wrote: > > En/na Andreas Mair ha escrit: > > > Another problem I have is that audio doesn't work very well. After > > > doing some tests I'd say that enabling Dolby Digital makes it worse. > > > If DD is disabled audio is sometimes lost and if DD is enabled audio > > > and video is lost on channel switching. > > > > There's definitely a problem with Dolby Digital: the plugin > > unconditionally switches the output on digital ac3 when there's an ac3 > > channel and never switches iy back. > > It should switch it back for a non ac3 channel and don't do anything at > > all if you're using the analogue output. > > This patch and the rest of your work is now merged back to the vdr-dxr3-0-2 > branch. > > I've been using it for a while with VDR 1.6.0-2, and in addition to the > issues already discussed/noted (no audio when moving cut marks, A/V tends > to go off sync somewhat more than before) I noticed yesterday that DVB > subtitles aren't as well synced as they were (they seem to appear too > early). It could be that this is an issue just with the one recording I > was watching yesterday, I need to try it out with 0.2.10 to be sure. Just to follow up, I've now confirmed this. Subtitles at least appear much too early. |
|
From: Christian G. <chr...@gm...> - 2010-04-24 15:48:27
|
Hi Luca, thanks for your patch. I will have a look at them and I hope to get it fully or a parts of it into my buffer-and-sync-rewrite branch. Thanks -- Christian Gmeiner, MSc 2010/4/24 Luca Olivetti <lu...@ve...>: > Hello, > > the attached patch does two things: > > 1) downmixes ac3 into stereo analogue output > > It isn't extremely useful but if you enable dolby digital in vdr and use the > analogue output of the dxr3 you still get sound: I alternate between the > dxr3 and vdr-xine, bbchd has only ac3 audio (there's also mpeg audio but > with audio description) so I have to enable dolby digital even if I cannot > really use it. > I couldn't find good ffmpeg documentation, so I suppose that setting the > channel count to 2 does the right thing. > > 3) ignores h264 streams > > since they cannot be decoded by the dxr3. Note that it doesn't really detect > the video type (I couldn't find an easy way to do it) but it uses the video > type returned by PatPmtParser (which doesn't work with old pes recordings, > but those shouldn't have h264 streams anyway). > When it detects a stream of type 0x1b, it shows a frame from the file > notSupported.mpg which must be in the plugins/dxr3 subdirectory of the > configuration directory. > It uses the same method than the vdr-xine plugin, I attached[*] a frame that > says "video format not supported", but you can make your own by simply > making a 720x576 png image then transform it this way: > > cat notSupported.png | pngtopnm \ > | ppmtoy4m -F 25:1 -A 4:3 -I p -r -S 420mpeg2 -v 2 -n 1 \ > | mpeg2enc -f 8 -a 2 -q 1 -n p -I 0 -T 120 -R 2 -g 10 -G 12 -o > /dev/stdout \ > | cat >notSupported.mpg > > If there's no file available, it will just show a black screen. > > [*]attachment removed due to the size limit on the mailing list, it's > available at http://ventoso.org/luca/vdr/notSupported.mpg > > Bye > -- > Luca > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Dxr3plugin-users mailing list > Dxr...@li... > https://lists.sourceforge.net/lists/listinfo/dxr3plugin-users > > |
7 messages has been excluded from this view by a project administrator.
