By reusing the regexes, we avoid recompiling them for each stream item being processed, and also they now are next to the other regexes defined in the M3uParser class.
I added extra flexibility when parsing the M3U, now the only field that is always stored is the url (which is always present). All the other fields are only stored if they were present in the original m3u. Also, if the field was defined as an empty string (eg.: #EXTINF:-1 tvg-id="", Google), it is stored as an empty string.
Also, I changed the way of generating the M3U to avoid concatenating big strings in the memory, which usually consumes large portions of memory and slows down when the string gets big (I'm processing M3U files of several megabytes). Using a list avoids these issues, since the big string is only generated at the end of the processing.
This way, when generating JSON and M3U it only generates the fields that were originally present in the parsed M3U.
For example, with this input:
#EXTM3U
#EXTINF:-1 tvg-id="google" tvg-name="Google" tvg-logo="" group-title="Google Group", Google
http://www.google.com/
Now using parse_m3u and to_file( ... , 'm3u') the generated file is exactly the same as the original (parsed) M3U.
By reusing the regexes, we avoid recompiling them for each stream item being processed, and also they now are next to the other regexes defined in the
M3uParser
class.I added extra flexibility when parsing the M3U, now the only field that is always stored is the
url
(which is always present). All the other fields are only stored if they were present in the original m3u. Also, if the field was defined as an empty string (eg.:#EXTINF:-1 tvg-id="", Google
), it is stored as an empty string.Also, I changed the way of generating the M3U to avoid concatenating big strings in the memory, which usually consumes large portions of memory and slows down when the string gets big (I'm processing M3U files of several megabytes). Using a list avoids these issues, since the big string is only generated at the end of the processing.
This way, when generating JSON and M3U it only generates the fields that were originally present in the parsed M3U.
For example, with this input:
Now using
parse_m3u
andto_file( ... , 'm3u')
the generated file is exactly the same as the original (parsed) M3U.Related to #7 and #10