xy-VSFilter Project (High Performance VSFilter Compatible Subtitle Filters)

[madshi]

Double click "activate debug mode.bat". Then reproduce the problem. Afterwards there should be a "madVR - log.txt" file on your desktop.

[ikarad]

Double click "activate debug mode.bat". Then reproduce the problem. Afterwards there should be a "madVR - log.txt" file on your desktop.

Thanks.
Do you know how turn off debug mode after?

The log.txt will be in madvr folder?

[madshi]

Just double click "activate release mode.bat" when you're done. That batch file will only exist once you entered debug mode. The log file will be on your desktop.

[ikarad]

log File is here
https://ufile.io/b1ghq

I said an mistake yesterday. In 32 bits, it doesn't work.

[Telion]

https://www2.zippyshare.com/v/ZnTMPx2Q/file.html
Based on a quick testing, seems like the main problem is fixed. But during it I've encountered a strange behaviour when a hard-positioned sign along with a subtitle line both are jumping up & down repeatedly, i.e. the repositioning is on & off multiple times during the display of that sign (in the ASS it is one continuous time interval for both). It's reproducing stably, but during the frame stepping the exact sequence and duration of "up" & "down" frames are different every time.

I've experienced this only once through the whole episode with many other moments of signs displayed together with dialogs, and everything else was OK. I don't know yet how often and in what exact conditions can this happen. I've cut out and uploaded that part (https://mega.nz/#!8u4CiQxS!f2YDVrMl_ivPmiHqxh_wPt6iSmQKeynRbXBWFINAhTk), so maybe you could determine what's happening there. But even now your fix is pretty usable, many thanks again!

[madshi]

@Telion,

I think the test build has a bug, if cyberbeing implements my tweaked code, it might fix it. Not 100% sure, though.

@ikarad,

thanks for the video, it helped me reproduce the problem. I'd suggest that you remove the link because it's more than a little sample, so from a copyright point of view it's not a good idea to post it publically. Anyway, the problem is this: XySubFilter connects to madVR first. For DVD subtitles, however, LAV Video Decoder is the one who's responsible and XySubFilter is not involved at all! LAV Video Decoder tries to connect to madVR, too (for subtitles), but the connection gets rejected because XySubFilter is already connected. Because of that LAV Video Decoder can't deliver the subtitles to madVR.

This might actually be a timing problem: If XySubFilter connects first, it won't work. If LAV connects first, it will work. That might explain why it works in one bitdepth, but not the other. Or maybe it even varies. In any case, you can "solve" it by disabling XySubFilter, when watching DVDs. Unfortunately I don't really have a better solution available right now. It is on my to do list to support more than one subtitle connection. That would fully solve the problem, but I didn't get around implementing that yet.

[cyberbeing]

@Telion,
I think the test build has a bug, if cyberbeing implements my tweaked code, it might fix it. Not 100% sure, though.


https://www116.zippyshare.com/v/1kKfjQOK/file.html

Your tweaked code fixes the flickering back and forth with that sample. Though the original movable line still becomes unmovable when the typesetting appears, and movable again when it disappears. As mentioned in email, it would be preferred if lines could maintain their initial movable/unmovable state throughout their duration. Is that possible?

This might actually be a timing problem: If XySubFilter connects first, it won't work. If LAV connects first, it will work. That might explain why it works in one bitdepth, but not the other. Or maybe it even varies. In any case, you can "solve" it by disabling XySubFilter, when watching DVDs. Unfortunately I don't really have a better solution available right now. It is on my to do list to support more than one subtitle connection. That would fully solve the problem, but I didn't get around implementing that yet.

Hmm... @ikarad just to confirm, does the same issue occur when you run Restore_Default_Settings.reg or otherwise set "XySubFilter->Properties->Loading->Load when needed"?

When "Load when needed" is set, XySubFilter shouldn't connect to madVR unless there is a connectable subtitle pin or an auto-loaded external subtitle in the directory.

Since you previously said it worked when you blocked LavSplitter, I assume that means XySubFilter is connecting to LavSplitter's Subtitle Pin?

What does "XySubFilter->Properties->Pin Info" show in those cases? I'm somewhat curious what kind of subtitle pin LavSplitter is exposing for DVD titles if LavVideo is already connected to LavSplitter.

Maybe you could try adding Lav Video Decoder to MPC-HC external filters, and setting the merit to Preferred and see if that allows it to enter the graph early enough to fix the issue.

[ikarad]

Hmm... @ikarad just to confirm, does the same issue occur when you run Restore_Default_Settings.reg or otherwise set "XySubFilter->Properties->Loading->Load when needed"?

When "Load when needed" is set, XySubFilter shouldn't connect to madVR unless there is a connectable subtitle pin or an auto-loaded external subtitle in the directory.

Since you previously said it worked when you blocked LavSplitter, I assume that means XySubFilter is connecting to LavSplitter's Subtitle Pin?

If I set "Load when needed", xysubfilter is not launched. Subs are displayed

[ikarad]

What does "XySubFilter->Properties->Pin Info" show in those cases? I'm somewhat curious what kind of subtitle pin LavSplitter is exposing for DVD titles if LavVideo is already connected to LavSplitter.



If I select always load, xysubfilter is launched and pin info show nothing
https://preview.ibb.co/cFtTgz/Sans_titre.jpg (https://ibb.co/nmtiEK)

When subs are displayed (for example if I turn off madvr), pin info show nothing but subs are displayed
https://preview.ibb.co/bJiQuK/Sans_titre.jpg (https://ibb.co/jkFG1z)

[cyberbeing]

If I set "Load when needed", xysubfilter is not launched. Subs are displayed

Does that resolve all your issues? If so, this isn't really a bug, considering "Load when needed" is the default setting for XySubFilter.

"Always Load" by design is set to have XySubFilter be loaded into the graph extremely aggressively by a Video Decoder helper filter with max merit, and always connect to madVR even if no subtitles or connectable pins exists. "Load when Needed" by comparison loads XySubFilter into the graph with a Audio Decoder helper, and will leave the graph if no subtitles or connectable pins exist.

[ikarad]

Does that resolve all your issues? If so, this isn't really a bug, considering "Load when needed" is the default setting for XySubFilter.


If 'load when needed" is set, xysubfilter is not used. Then, it works but it should works even with xysubfilter used.

I have set "always load" because on some videos, xysubfilter doesn't launched and xysubfilter has less bug than internal sub renderer of mpc-hc with fonts.

[cyberbeing]

"Always Load" really shouldn't be needed for general use. It mainly exists for users who want to be able to display subtitles on videos without an Audio Track. It also gives users the option to manually load external subtitles on videos without a subtitle pin. For that second part though, external subtitles will be auto-loaded by XySubFilter set to "Load when needed" if they have an identical name to the video.

In which situations were you finding XySubFilter failing to load when "Load when needed" was set?

[madshi]

Your tweaked code fixes the flickering back and forth with that sample. Though the original movable line still becomes unmovable when the typesetting appears, and movable again when it disappears. As mentioned in email, it would be preferred if lines could maintain their initial movable/unmovable state throughout their duration. Is that possible?
Not easily, unfortunately. I'd have to rewrite/change quite a bit of code to make that work, which I don't have the time for atm.

So the only question is which problem is worse: The one reported by Telion? Or the one we may get if we allow the global movable state to switch back and forth, affecting *all* rendered subtitle lines immediately?

[Telion]

So the only question is which problem is worse: The one reported by Telion? Or the one we may get if we allow the global movable state to switch back and forth, affecting *all* rendered subtitle lines immediately?
I've quickly run the build based on your fix against the same aforementioned episode and didn't notice any apparent problems. Surely that doesn't guarantee anything, so it's up to you guys to decide - I just hope you'll find a way.

[cyberbeing]

So the only question is which problem is worse: The one reported by Telion? Or the one we may get if we allow the global movable state to switch back and forth, affecting *all* rendered subtitle lines immediately?

I'd say just allow the global movable state to switch back and forth, until we come up with a better solution. IMHO, the toggle box was added to allow movement to black bars for true simple ASS/SSA subtitles (like those converted from SRT for styling purposes) which don't contain complex typesetting. For people who use the same functionality already for SRT and know their ASS/SSA scripts are generally simple, it should be good enough for now.

The setting is disabled by default specifically, since we don't expect it to handle extremely complex SSA/ASS scripts flawlessly. I'm sure someone could create a script intentionally to cause movable/non-movable to be toggled so frequently that is causes severe readability issues, in which case the feature should just be disabled by the user. Until the behavior is enhanced, we are not expecting it to handle such a situation perfectly.

[Edit: Actually, after thinking about this, maybe you could add a feature which limits the frequency that changes from IsMovable=False to IsMovable=True are processed (i.e. ignore Provider IsMovable=True for X seconds after IsMovable=False occurs, user defined?), while always processing IsMovable=True to IsMovable=False instantly. Though I'm unsure if that would be worth the development effort to add, since it would only be a workaround for a problem which likely won't occur often.]

[madshi]

I'd say just allow the global movable state to switch back and forth, until we come up with a better solution. IMHO, the toggle box was added to allow movement to black bars for true simple ASS/SSA subtitles (like those converted from SRT for styling purposes) which don't contain complex typesetting. For people who use the same functionality already for SRT and know their ASS/SSA scripts are generally simple, it should be good enough for now.

The setting is disabled by default specifically, since we don't expect it to handle extremely complex SSA/ASS scripts flawlessly. I'm sure someone could create a script intentionally to cause movable/non-movable to be toggled so frequently that is causes severe readability issues, in which case the feature should just be disabled by the user. Until the behavior is enhanced, we are not expecting it to handle such a situation perfectly.

[Edit: Actually, after thinking about this, maybe you could add a feature which limits the frequency that changes from IsMovable=False to IsMovable=True are processed (i.e. ignore Provider IsMovable=True for X seconds after IsMovable=False occurs, user defined?), while always processing IsMovable=True to IsMovable=False instantly. Though I'm unsure if that would be worth the development effort to add, since it would only be a workaround for a problem which likely won't occur often.]
Of course it would be possible to add a delay, with a user options, but I already see problems describing such an option in such a way that the average user even understands what it means. So I'd say: Let's just release the build as it is, and if users complain, we can still think about what to do then. But probably it's good enough as it is, so probably nobody will complain.

[worewo]

Trying to open external PGS subtitles (whether autoloading or manual) results in my player freezing for extended periods of time, and when it does finally load the text is either greatly out of sync or don't display at all.

Muxing the subs into the video allows it to load correctly. The issue is also consistently reproducible when I extract subs from any video and try to load them externally.

Is this a known issue with external PGS subs?
External PGS subs don't work for me properly either.

My player never freezes, but the subtitles get out-of-sync as the movie goes on. The subtitle delay seems to be dependent on how far I am into the movie, rather than how long the video file has been playing for. Muxing the subs into the file, or using the default MPC-BE subtitle renderer always makes things work fine.

[cyberbeing]

External PGS support has always had known-issues in XySubFilter ever since it was implemented.

1) External PGS seeking is completely broken and will cause the subs to go way out-of-sync. For non-stop sequential playback starting from frame 0, it generally works acceptably if you never seek.

2) Slow opening of external PGS was a regression caused a long time ago by this commit (Rewrite CTextFile::ReadString, specifically the TextFile.cpp changes) (https://github.com/Cyberbeing/xy-VSFilter/commit/02440d472def3a9e0b2ce84f958c8b0c0aa3ad7f) for unknown reasons.

Unfortunately, neither of these external PGS bugs were tracked down and fixed by the original developer while he was still around.

[madshi]

So what's the decision on the "movable" issue? I suppose we should allow the "movable" state to switch back and forth?

[cyberbeing]

Yeah, it seems that's the better option for now, compared to it potentially stopping working entirely for the second half of a video. If no new problems come up, I'll release it with that change this weekend.

[madshi]

Thanks, that would be great!

[cyberbeing]

XySubFilter 3.1.0.752 has been released (https://github.com/Cyberbeing/xy-VSFilter/releases/tag/3.1.0.751)

XySubFilter .zip Archive (32-bit) (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.1.0.752/XySubFilter_3.1.0.752_x86.zip) | XySubFilter .zip Archive (64-bit) (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.1.0.752/XySubFilter_3.1.0.752_x64.zip)

Debug Symbols for XySubFilter 3.1.0.752 (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.1.0.752/XySubFilter_3.1.0.752_Debug_Symbols.7z)

Bug Fix

Fix for SSA/ASS repositioning becoming permanently disabled after typesetting was displayed


Note: XySubFilter is no longer being actively developed. The original developer stopped working on the project back in 2014, and ever since then it's been in limbo. The changes in this release were made possible by madshi the developer for madVR.

[madshi]

Awesome - thank you! :)

[madshi]

P.S: The debug symbol link doesn't work.

[cyberbeing]

fixed the link, I had missed changing one of the 751 to 752 in the url when I copied my old post.

[gfxnow]

Many thanks to Madshi and Cyberbeing for breathing new life in to this abandoned project.

[Tanuki]

I still use version 705 because of several "bugs" I have seen with versions 744 and 746 : one with vobsubs placement (but I don't have a file to test anymore), and one with an anime OP karaoke (released in april 2016, http://dl.free.fr/nCeCntvPl) that lags for several seconds near the end. Unfortunately, the new version 752 doesn't work neither.

I tried to find something related in this thread after the october 2015 releases, but I haven't.

I use Zoom player, Madvr, LAV filters

Any thoughts ?

[sneaker_ger]

one with an anime OP karaoke (released in april 2016, http://dl.free.fr/nCeCntvPl) that lags for several seconds near the end. Unfortunately, the new version 752 doesn't work neither.
Same problem with 3.1.0.801 (pinterf), in case anyone is wondering. Doesn't happen with MPC-HC EVR-CP, though, only madvr.

But on closer look madvr reports dropped frames even with MPC-HC ISR (i5-2500K), they just don't seem as obvious as with XySubFilter. Does madvr report no dropped frames for you with 705? Sample seems extremely CPU hungry.

[cyberbeing]

Thanks for pointing out that perf regression from 3.1.0.705. It seems this is one instance where our original xy tag parsing/caching was significantly faster than MPC-HC's implementation, which I had merged is since I thought it was always faster. My original test case back then must have been too limited.

Here is a test build which reverts the MPC-HC implementation and restores the original xy tag parsing/caching implementation:
https://www69.zippyshare.com/v/dBNj6Fpg/file.html

Please compare it against 3.1.0.352 on extremely line/tag heavy scripts and see which you find overall faster. I'll go back to our original implementation in the next release if you don't find any instances where it is significantly slower than 3.1.0.352.

As for VobSub placement, I'm unsure what that would refer to. If you come across a sample which reproduces that issue again (as a regression from 3.1.0.705), please send it to me. Did you have Black Bar detection enabled in madVR? There is a chance that could have been a madVR bug which has since been fixed.

[amayra]

in the next release
there problem i want to report to you since you have plan to work for this project lettel more
my issue is when i use ASS"Advanced Substation Alpha" file and renamed style name with uppercase
VSFilter don't lead or detected this syle only if i rename every line with uppercase name to match what i used in style manager evertime

[cyberbeing]

If I'm understanding you correctly, you are just saying that style names are case-sensitive? If so, that isn't a bug. VSFilter has always treated case-sensitive style names as unique entities.

If that is not the issue, could you give a better example of what you're talking about?

[amayra]

If I'm understanding you correctly, you are just saying that style names are case-sensitive? If so, that isn't a bug. VSFilter has always treated case-sensitive style names as unique entities.

If that is not the issue, could you give a better example of what you're talking about?
you are correct, but why VSFilter is case-sensitive when i can't use same style name in subtitle editor ?

[cyberbeing]

If you are talking about Aegisub, I'm not sure. As far as I'm aware Libass is also case-sensitive when it comes to style names. It must just be to keep script tidy and avoid typos, or maybe there was some compatibility issue with some other renderer which existed a long time in the past?

[JohnLai]

cyberbeing, when xy-vsfilter is used with mpc-hc on fast-forward mode (CTRL+UP) such as 2X, 4X, 8X or even 16X, the subtitle will not be in sync with the 'fastforward' as if the subtitle is running at normal speed.

However, the ancient https://trac.mpc-hc.org/ticket/3504 method that uses ​https://nightly.mpc-hc.org/mpc-hc_apps/vsfilter/ original vsfilter works perfectly with 'fastforward' mode.
Is it possible to implement xy-vsfilter subtitle synchronization for fastforward mode?

[cyberbeing]

What exactly are you testing? I'm not seeing any difference between the old MPC-HC VSFilter 2.41, MPC 1.7.13.112 VSFilter and xy-VSFilter 3.0.0.306 with MKV+ASS samples. All seem to go out-of-sync on fast-forward in MPC-HC. If this is something universally broken with VSFilter.dll, it's doubtful it would be fixed at this point.

Fast-forward works with XySubFilter & MPC-HC ISR though.

[JohnLai]

What exactly are you testing? I'm not seeing any difference between the old MPC-HC VSFilter 2.41, MPC 1.7.13.112 VSFilter and xy-VSFilter 3.0.0.306 with MKV+ASS samples. All seem to go out-of-sync on fast-forward in MPC-HC. If this is something universally broken with VSFilter.dll, it's doubtful it would be fixed at this point.

Fast-forward works with XySubFilter & MPC-HC ISR though.

Maybe I should rephrase it. Now, this only happens with bitmap subtitle (BD and DVD native sub).

I mean MPC-HC internal subtitle renderer and XY-Vsfilter don't render subtitle in sync with fastforward speed.

The original VSfilter renders subtitle in sync on fastforward correctly.

[cyberbeing]

I assume you are testing xy-VSFilter 3.0.0.306 and MPC-HC VSFilter 2.41 with internal PGS & VOBSUB subtitles? Could you also try old versions of xy-VSFilter as well, such as 3.0.0.211 & 3.0.0.65, as well as the original Gabest VSFilter 2.39.5.3 (https://www33.zippyshare.com/v/1EycMceC/file.html
). In terms of VSFilter 2.41 & 2.39, please also test them with and without buffering enabled, and see if there is any difference. I no longer have any PGS & VOBSUB samples on my system to easily test this myself.

Either way, you'll probably need to wait for MPC-HC or MPC-BE to fix this if even their most recent VSFilter.dll releases are broken for this particular test-case. We never worked on core bitmap subtitle parsing/rendering code ourselves, all of it was basically merged as-is from the original Gabest MPC and MPC-HC. No guarantee it would be the same fix though, since one difference in xy-VSFilter is it doesn't pre-buffer subtitles. If the fix requires buffering, it's probably a lost cause for xy-VSFilter. Pre-buffering was something the original dev never got around to re-adding support for, suggesting it wasn't something trivial to integrate with our current code.

[JohnLai]

Well yes, vobsub and PGS subtitle type.
Buffering and no buffering doesn't seem to make any difference.

>.< Well, I give up. Guess I should fastforward (seek) few seconds instead of changing framerate (apparently, this is the correct term for 2x,4x,8x and 16x, haha my mistake)

[Tanuki]

Thanks for pointing out that perf regression from 3.1.0.705. It seems this is one instance where our original xy tag parsing/caching was significantly faster than MPC-HC's implementation, which I had merged is since I thought it was always faster. My original test case back then must have been too limited.

Here is a test build which reverts the MPC-HC implementation and restores the original xy tag parsing/caching implementation:
https://www69.zippyshare.com/v/dBNj6Fpg/file.html

Please compare it against 3.1.0.352 on extremely line/tag heavy scripts and see which you find overall faster. I'll go back to our original implementation in the next release if you don't find any instances where it is significantly slower than 3.1.0.352.

As for VobSub placement, I'm unsure what that would refer to. If you come across a sample which reproduces that issue again (as a regression from 3.1.0.705), please send it to me. Did you have Black Bar detection enabled in madVR? There is a chance that could have been a madVR bug which has since been fixed.

For the vobsub placement problem, I remembered an obvious example (my memory isn't as bad as I expected) : http://dl.free.fr/vrbBwaBoi
after 19s, with the jpn vobsub track. It works as expected with 705, not after. I don't have "black bar detection" enabled in madvr.

For the performance thing, I don't have another example I can remember than the one I already pointed so I can't test more.

[cyberbeing]

I don't see any vobsub placement problem with that sample. 705 and 752 look identical to me after 19s, with the song lyrics are on top and dialog on bottom as I would expect with the jpn vobsub track. I tested with MPC-HC 1.83 & LAVFilters 0.73.1, EVR-CP & madVR.

As for the other thing, just use the 750 build (https://www69.zippyshare.com/v/dBNj6Fpg/file.html) I linked above normally, since it should resolve the performance regression on that previous sample. If you can't think of anything else, that's fine. I'll be trying to track down some samples myself anyway.

[supercoolman]

there are issue with XySubFilter 3.1.0.746 BETA3 where last line of an external SSA subtitle is not displayed if it doesn't end with line break. in a text editor, this means SSA file must end with a blank/empty line
haven't test the latest version to see if it's fixed, but also don't see this fixed in the newer releases' Bug Fix section



confirmed 3.1.0.752 also has the same behaviour

[Mano]

Is it normal that when i enable sub in video the color of the movie changed?


Default no sub
https://imgur.com/oprrT9R

With english sub selected
https://imgur.com/SSo0l5f

[cyberbeing]

@supercoolman Thanks for reporting that. Looks like it is caused by a bug this Read Buffering commit (https://github.com/Cyberbeing/xy-VSFilter/commit/02440d472def3a9e0b2ce84f958c8b0c0aa3ad7f) written by the Aegisub author. Since Aegisub always adds a new line at end of file this must have been overlooked. I'll try to see if he's still around to push a fix.

@Mano That is a bug in madVR, I believe. XySubFilter only provides subtitles, it never touches the video. I seem to remember someone reporting a bug like that with HDR video in one of the madVR threads months ago, but if it still isn't fixed you should probably open a bug report (http://bugs.madshi.net/bug_report_page.php) so it isn't forgotten about.

[pinterf]

there are issue with XySubFilter 3.1.0.746 BETA3 where last line of an external SSA subtitle is not displayed if it doesn't end with line break. in a text editor, this means SSA file must end with a blank/empty line
haven't test the latest version to see if it's fixed, but also don't see this fixed in the newer releases' Bug Fix section

confirmed 3.1.0.752 also has the same behaviour
I was reported a similar issue, see issue and fix here:
https://github.com/pinterf/xy-VSFilter/issues/1
https://github.com/pinterf/xy-VSFilter/commit/569cc5aa2f9c658de6ea52ad8c2c7414fc5072f0
As I recall there had been other similar parts in the code but I could test and fix only this specific one.

@cyberbeing: if the project is still somewhat live again, I'd recommend this x64 fix as well:
https://github.com/pinterf/xy-VSFilter/commit/a80ecea6f66b4b0ffede17b1982d32806f8c24cf

[cyberbeing]

Thanks pinterf, I'll merge those in. Looks like you only fixed it for SRT, I assume the same change could be used for SSA/ASS?

Test Build [previous 750 test build + pinterf SRT & x64 fixes + pinterf fix used for SSA/ASS (untested)] (https://www100.zippyshare.com/v/mSf0lO7f/file.html)

Any idea if your fix for the missing last line could be moved from STS.cpp to TextFile.cpp, since that is where the regression occurred? It would prevent the need to add that fix for every text subtitle format in STS.cpp, and simply things.

The project is still pretty much dead, aside from minimal maintenance on my part.

[supercoolman]

I have been manually fixing that (adding newlines) on all ASS subs over the years. just decided to bring it up. didn't know bug was filed on that already

btw/ot, what's going on with aegisub? is it in not, less or similarly active than XySubFilter ?

[cyberbeing]

Pretty much, though back in June 2018 he did push out a new trunk build (http://plorkyeran.com/aegisub/) on his site with some fixes from his Github. With the original MPC-HC team dying off, and even Libass updating rather rarely nowadays, everything has sort of stagnated. Or rather the state of subtitle development has returned to the status quo from before we first released xy-VSFilter in 2011 which triggered a large peak in interest in the following years, so you could argue this is actually the normal state of things.

[pinterf]

Any idea if your fix for the missing last line could be moved from STS.cpp to TextFile.cpp, since that is where the regression occurred? It would prevent the need to add that fix for every text subtitle format in STS.cpp, and simply things.

The project is still pretty much dead, aside from minimal maintenance on my part.
I don't remember, unfortunately I don't have overview on the project as a whole, tried to find a more practical place for it but due to my ignorance the actual fix remained where I put it first.

[supercoolman]

finishing OT...

I was wondering since this GitHub project (https://github.com/Aegisub/Aegisub) has been getting commits, but not a single release since 2014

[krmit]

finishing OT...

I was wondering since this GitHub project (https://github.com/Aegisub/Aegisub) has been getting commits, but not a single release since 2014

Well, last release (r8942) was 06/09/18, and previous - about 2 years ago.