m.shamraeva on 12 Dec, 2011 09:51 PM
Uploading should work well for files in SRT format, as well as
the other subtitle formats supported by UniversalSubtitles, so far
as the file being uploaded is properly formatted.
I can see at least two problems with the file you've
Lines 1-999 have spaces between the line number and the line
break symbol. These spaces prevent subtitle blocks from being
imported. Only lines starting from #1000, which do not have trailing spaces,
get imported - you can see this in the revision history for Greek
Some lines are duplicated - there is more than one block with
the same number. Examples: lines #10
After removing the trailing spaces and duplicate entries (which
can be done with the use of a text editor), please try uploading
the file again - it should work fine.
Hi, thanks for responding.
It is uploaded now.
The error was the spaces between the line number
and the line break symbol, as you pointed out.
Because a translation does not necessarily produce
the same number of blocks as the original.
and I haven't found yet a way to handle non-latin srt texts using bash scripts
that's why some blocks have the same number.
This occasionaly happens while editing text.
Same number in subsequent blocks doesn't count as an error
while showing a video in vlc.
It seems that vlc does not pay attention to the number sequence
The requirement with the upload is the absence of trailing spaces
after the line number,
but with downloading, the resulting file contains a carriage return in
every newline !
I understand the reasoning behind that, however it might not be at the
The timecodes of the uploaded file are altered,
I guess under the assumption that this is an attempted optimization.
However, in cases the timecode range
becomes unreasonably short and requires new editing.
"Optimizing" timecodes for all blocks shouldn't be rather an option
for the user?