I understand the thinking, but you also have to be careful about setting arbitrary limits that could inhibit what the user is trying to do (admittedly I doubt there will ever be that many lines).

Often we take the approach that if the user really tries to do something completely crazy then its just tough luck if things go belly up. There are places where we're more rigid though, such as dealing with interfacing to external applications. So this is a bit of a grey area, the user has to be explicitly doing something to create these files, but they are generated by an app that could go wrong, so you're right we don't really want to cause TVH to crash due to lack of resources.

However I would suggest that you change a couple of things:

1. Make the count based on "parsed" lines, ultimately what you're trying to protect against is it consuming resources due to a bad/long file?

2. If you really want a limit on number of processed lines, which is still no bad thing, as otherwise the issue could be CPU consumption as global_lock is held, then add that as well.

3. Increase BOTH limits to something that's way above anything that's ever going to be likely, while still not being so large as to cause the system to crash. 50 lines, might seem huge, but depending on what generates the file there could be textual lines included that waste lines and if you had someone creating a scene based file for some long running show made of lots of little segments you could potentially exceed 50.  

E.g. think of it like this, each entry in the list is approx 25 bytes. If you allowed for 10k entries, that would still only be 250kB, on any modern system, that's still small fry and will only ever exist for a short period of time while the info is passed down the chain to the client.