Hi,
I found another bug in these days when using SUPer 0.2.3:
...
SUPer: INFO : => optimised as 2 display sets.
SUPer: INFO : EPOCH 01:15:28:01->01:15:30:08, 2->2 event(s):
SUPer: INFO : => Screen layout: 2 window(s), processing...
Encoding: : 3it [00:00, 56.62it/s]
Process SUPinternal:
Traceback (most recent call last):
File "multiprocessing\process.py", line 314, in _bootstrap
File "multiprocessing\process.py", line 108, in run
File "supergui.py", line 196, in from_bdnxml
File "SUPer\interface.py", line 146, in optimise
File "SUPer\render2.py", line 541, in analyze
File "SUPer\render2.py", line 945, in _convert
File "SUPer\render2.py", line 684, in _get_undisplay
File "SUPer\render2.py", line 733, in <lambda>
File "SUPer\segments.py", line 510, in from_scratch
File "SUPer\segments.py", line 476, in pal_id
File "SUPer\segments.py", line 152, in payload
TypeError: 'NoneType' object cannot be interpreted as an integer
SUPui: INFO : Closed gracefully SUPer process.
I checked that when the Graphic size(Width,Height) and position(X,Y) are the same in two adjacent events, this will report an error and close process.In fact, the content of these PNGs(00108673_0.png, 00108698_0.png) are identical too, and their subtitle text within the .ass is exactly the same. In other words, it's a human error when authoring the .ass, which leads to the same dialogue subtitle being split into two timelines.
Hi, I found another bug in these days when using SUPer 0.2.3:
I checked that when the Graphic size(Width,Height) and position(X,Y) are the same in two adjacent events, this will report an error and close process.In fact, the content of these PNGs(00108673_0.png, 00108698_0.png) are identical too, and their subtitle text within the .ass is exactly the same. In other words, it's a human error when authoring the .ass, which leads to the same dialogue subtitle being split into two timelines.
I manually modified the xml file: connect the InTC/OutTC of two events, and reference one of the two PNG images Graphic property, like this:
and finally have SUPer processing the xml again, and the error no longer occurs...