Closed dyphire closed 4 months ago
Landed in
4724988
.
To be honest, this implementation is not very practical. I want something like filter_file = "~~/files/bilibili.json"
, which supports reading bilibili exported json format file of the filter word. Or read a filter word file in xml format from the more general dandanplay.
bilibili: Do you mean https://api.bilibili.com/x/dm/filter/user?
dandanplay: The exported XML file uses the same format for rules with the 正则表达式
checkbox checked and unchecked in the UI.
<?xml version="1.0" encoding="utf-8"?>
<filters>
<item enabled="true">t=123</item>
<item enabled="true">t=4.+</item>
<item enabled="true">t=5\d</item>
</filters>
bilibili: Do you mean https://api.bilibili.com/x/dm/filter/user?
I mean this: File content example:
[{"type":0,"filter":"援交","opened":true,"id":3505920},{"type":0,"filter":"对不起","opened":true,"id":3505921}]
Support for filter files exported from bilibili landed in c650e8b
.
It takes ~40 ms to filter with ~2000 danmaku and ~1000 rules, perhaps doesn't need something like Aho–Corasick algorithm (increases binary size by ~200KB).
Do you need regex/user based blocking?
Do you need regex/user based blocking?
Regex matching seems to be necessary. but if this affects performance even further it should not be considered.
The feature of blocking users can be left to the filter option. For example, the filter=userid=bilibili
can be used to block specific sources of danmaku (this should allow for runtime updates), for dandanplay other more specific userid blocking is of little use.
Regex matching seems to be necessary. but if this affects performance even further it should not be considered.
It takes ~40 ms to filter with ~2000 danmaku and ~500 regex rules, increases binary size by ~950 KB. The time spent is not directly proportional to the number of rules, and the time spent is strongly influenced by the content of the rules, so this result may not mean much. I'm not going to introduce this feature if no one really needs it. I don't care much about potential demand, only real demand. According to repository Traffic (Git clones) and Releases assets download count, not too many people are using this plugin.
Edit: Sorry for misunderstanding you if you mean it seems to be necessary for you. It's fine if you don't know if you really need it.
The feature of blocking users can be left to the filter option. For example, the
filter=userid=bilibili
can be used to block specific sources of danmaku (this should allow for runtime updates)
Open a new issue if you need it.
dandanplay: The exported XML file uses the same format for rules with the
正则表达式
checkbox checked and unchecked in the UI.
Fail to distinguish between regex rules and other rules in the config file, ignore this feature for now.
Regex matching seems to be necessary. but if this affects performance even further it should not be considered.
It takes ~40 ms to filter with ~2000 danmaku and ~500 regex rules, increases binary size by ~950 KB. The time spent is not directly proportional to the number of rules, and the time spent is strongly influenced by the content of the rules, so this result may not mean much. I'm not going to introduce this feature if no one really needs it. I don't care much about potential demand, only real demand. According to repository Traffic (Git clones) and Releases assets download count, not too many people are using this plugin.
I agree that the cost is not proportional to the added size and functionality. I also don't think it's necessary to implement it.
Landed in
4724988
.